Versiebeheerintegratie¶
Weblate ondersteunt momenteel Git (met uitgebreide ondersteuning voor GitHub pull requests, GitLab verzoeken voor samenvoegen, Gitea pull requests, Verzoeken Gerrit review, Subversion, Bitbucket Cloud pull requests, Pull requesten op Bitbucket Data Center en Azure DevOps pull requests) en Mercurial als backends voor versiebeheer.
Voor provider-specifieke stappen voor instellen die toegang tot de opslagruimte, inkomende notificaties en terugpushen van vertalingen combineren, bekijk Integraties codehosten.
Toegang tot opslagruimten¶
De opslagruimte van het VCS dat u wilt gebruiken moet toegankelijk zijn vanuit Weblate. Met een publiek beschikbare opslagruimte hoeft u slechts de juiste URL in te voeren (bijvoorbeeld https://github.com/WeblateOrg/weblate.git), maar voor privé opslagruimten of voor URL’s voor pushen is het instellen meer complex en vereist authenticatie.
Problemen met URL’s voor opslagruimten oplossen¶
Weblate valideert URL’s voor opslagruimten en pushen voor het verbinden. HTTPS en SSH zijn standaard toegestaan; beheerders van de instantie kunnen dit aanpassen met VCS_ALLOW_SCHEMES.
Hostnamen voor opslagruimten moeten worden opgelost vanaf de server van Weblate. Als VCS_RESTRICT_PRIVATE is ingeschakeld, weigert Weblate ook doelen die oplossen naar interne of anderszins niet-publieke adressen. Gebruik een publiek toegankelijke URL voor de opslagruimte waar mogelijk. Voor een opzettelijke private opslagruimte op een vertrouwd netwerk, vraag de beheerder van de instantie om de hostnaam toe te voegen aan VCS_ALLOW_HOSTS.
Git over HTTPS en SSH kan verbindingen binden aan adressen die zijn goedgekeurd bij valideren. Backends die dit niet veilig kunnen doen, inclusief Mercurial en Subversion, vereisen de hostnaam voor de vertrouwde opslagruimte in VCS_ALLOW_HOSTS terwijl beperkingen voor private adressen zijn ingeschakeld.
Configureer de uiteindelijke URL voor de opslagruimte waar mogelijk direct. Weblate kan een permanente HTTP-verwijzing alleen automatisch accepteren als die op dezelfde host blijft en het doel met succes is gevalideerd. Verwijzingen naar een andere host of protocol moeten handmatig worden geconfigureerd.
Toegang tot opslagruimten vanuit Hosted Weblate¶
Notitie
Dit gedeelte is alleen van toepassing op Hosted Weblate (hosted.weblate.org). Als u uw eigen zelf gehoste Weblate instantie uitvoert, bekijk dan in plaats daarvan het volgende gedeelte.
Voor opslagruimten van GitHub op Hosted Weblate, gebruik de Hosted Weblate-app uit de werkstroom van Weblate Verbinden met GitHub-account wanneer dat mogelijk is. De app geeft toegang tot de opslagruimte, ontvangt inkomende notificaties, pusht vertaalbranches en maakt pull requests zonder de Hosted Weblate-gebruiker weblate uit te nodigen. Bekijk Toegang tot opslagruimten van GitHub voor de volledige opstelling.
Voor directe SSH-toegang buiten de werkstroom van de GitHub-app, en voor opslagruimten van Bitbucket, Codeberg en GitLab heeft Hosted Weblate een toegewezen gebruiker voor pushen (met de gebruikersnaam weblate, e-mail hosted@weblate.org en een naam of beschrijving van een profiel Weblate push user).
Hint
Er mogen meer gebruikers van Weblate op de platforms zijn, toegewezen voor andere instanties van Weblate. Zoeken op e-mail hosted@weblate.org wordt aanbevolen om de juiste gebruiker voor Hosted Weblate te zoeken.
U moet deze gebruiker toevoegen als een deelnemer en de toepasselijke rechten geven voor uw opslagruimte (read-only is oké voor klonen, write is vereist voor pushen). Afhankelijk van de service, en de instellingen van uw organisatie, gebeurt dit onmiddellijk of vereist het bevestiging van de kant van Weblate.
De gebruiker weblate op GitHub accepteert uitnodigingen automatisch binnen vijf minuten als u daar met opzet directe SSH-toegang gebruikt. Handmatige verwerking zou voor andere services nodig kunnen zijn, wees dus geduldig.
Voor deze opstelling voor directe SSH-gebruiker, als de gebruiker weblate eenmaal is toegevoegd aan uw opslagruimte, kunt u Broncode-opslagruimte en URL voor pushen naar de opslagruimte configureren met het protocol SSH, bijvoorbeeld git@example.com:group/project.git.
Toegang tot opslagruimten van sites voor het hosten van code (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Notitie
Dit gedeelte is van toepassing op zelf gehoste instanties van Weblate. Als u Hosted Weblate (hosted.weblate.org) gebruikt, bekijk dan in plaats daarvan Toegang tot opslagruimten vanuit Hosted Weblate.
Voor zelfgehoste Weblate is een enkele private opslagplaats vaak het gemakkelijkst om in te stellen met een HTTPS-URL voor de opslagruimte met een toegangstoken, bekijk Integraties codehosten.
Voor meerdere opslagruimten, maak een aangewezen gebruiker voor de site voor het hosten van code die wordt geassocieerd met een Weblate SSH-sleutel (bekijk Weblate SSH-sleutel). Op deze manier associeert u de Weblate SSH-sleutel aan een enkele gebruiker, omdat platforms vaak het eenmalig gebruik van een SSH-sleutel afdwingen. Geef deze gebruiker toegang tot de opslagruimten en gebruik de URL van SSH voor toegang tot de opslagruimten (bekijk SSH-opslagruimten).
SSH-opslagruimten¶
Een veelvoorkomende methode voor toegang tot privé-opslagruimten is gebaseerd op SSH. Autoriseer de publieke Weblate SSH-sleutel (bekijk Weblate SSH-sleutel) om op deze manier toegang te krijgen tot de opslagruimte upstream.
Waarschuwing
Op GitHub kan elke sleutel maar een keer gebruikt worden, bekijk Toegang tot opslagruimten van GitHub en Toegang tot opslagruimten vanuit Hosted Weblate.
Weblate slaat ook de vingerafdruk voor d esleutel van de host op bij de eerste verbinding en laat de verbinding met de host mislukken als die later wordt gewijzigd (bekijk Verifiëren van sleutels voor SSH-host).
In het geval er aanpassingen moeten worden gedaan, doe dat dan vanuit de beheerinterface van Weblate:
Weblate SSH-sleutel¶
Veranderd in versie 4.17: Weblate genereert nu zowel SSH-sleutels van RSA als van Ed25519. Gebruiken van Ed25519 wordt aanbevolen voor nieuwe opstellingen.
De publieke sleutel van Weblate is zichtbaar voor alle gebruikers die bladeren door de pagina Over Weblate.
Beheerders kunnen de momenteel door Weblate gebruikte publieke sleutel genereren of weergeven in de verbinding (vanuit SSH keys) op de startpagina van de beheerinterface.
Notitie
De corresponderende private SSH-sleutel kan momenteel geen wachtwoord hebben, zorg er dus voor dat die goed beveiligd is.
Hint
Maak een back-up van de gegenereerde private SSH-sleutel van Weblate.
Verifiëren van sleutels voor SSH-host¶
Weblate slaat automatisch de sleutels voor SSH-host op bij de eerste toegang en onthoud die voor later gebruik.
Als VCS_RESTRICT_PRIVATE is ingeschakeld, lost Weblate de host voor de opslagruimte op en valideert die voordat de sleutel ervan wordt gescand, en verbindt ssh-keyscan alleen met de goedgekeurde adressen. De opgeslagen sleutel blijft geassocieerd met de originele hostnaam.
Voor verbindingen van Git past Weblate ook HostName en Port toe uit DATA_DIR/ssh/config voor het valideren en vastzetten van het effectieve doel. SSH-configuratie en SSH_EXTRA_ARGS zijn vertrouwde, door de beheerder beheerde, invoeren. Ze kunnen routeren van de verbinding wijzigen en SSH_EXTRA_ARGS mag het vastzetten van het adres door Weblate overschrijven; beheerders zijn verantwoordelijk voor hun effecten.
In het geval dat u de vingerafdruk van de sleutel wilt verifiëren voordat u verbindt met de opslagruimte, voeg de sleutels voor de SSH-host van de servers, waartoe u toegang wilt, toe in Host sleutel toevoegen, in hetzelfde gedeelte van de beheerinterface. Voer de hostnaam in waarvoor u toegang wilt (bijv. gitlab.com) en druk op Indienen. Verifieer of de vingerafdruk overeenkomt met de server die u hebt toegevoegd.
De toegevoegde sleutels met vingerafdrukken worden weergegeven het bericht met de bevestiging:
Verbinden met oude servers van SSH¶
Recente uitgaven van OpenSSH (bijvoorbeeld die welke wordt gebruikt in Weblate Docker container) schakelen standaard RSA-handtekeningen, die het hash-algoritme SHA-1 gebruiken, uit. Deze wijziging is gemaakt omdat het hash-algoritme SHA-1 cryptografisch gezien defect is en het mogelijk is om botsingen van hashes met gekozen voorvoegsel te maken voor <USD$50K.
Voor de meeste gebruikers zal deze wijziging onzichtbaar zijn en er is geen noodzaak om de sleutels SSH-RSA te vervangen. OpenSSH heeft ondersteunde handtekeningen voor RFC8332 RSA/SHA-256/512 vanaf uitgave 7.2 en bestaande sleutels SSH-RSA zullen automatisch het sterkere algoritme gebruiken, indien mogelijk.
Incompatibiliteit ligt meer voor de hand bij het verbinden met oudere implementaties van SSH die niet zijn geüpgraded of niet nauwgezet de verbeteringen in het SSH-protocol hebben bijgehouden. De verbinding met SSH naar een dergelijke server zal mislukken met:
no matching host key type found. Their offer: ssh-rsa
Voor deze gevallen zou het noodzakelijk kunnen zijn om selectief RSA/SHA1 opnieuw in te schakelen om verbinding en/of authenticatie van de gebruiker via de opties HostkeyAlgorithms en PubkeyAcceptedAlgorithms mogelijk te maken. De volgende stanza in DATA_DIR/ssh/config zal,bijvoorbeeld, RSA/SHA1 inschakelen voor host en gebruikerauthenticatie voor een enkele bestemmingshost:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
We bevelen het inschakelen van RSA/SHA1 alleen aan als een tijdelijke maatregel, totdat oude implementaties kunnen worden geüpgraded of opnieuw kunnen worden geconfigureerd met een ander type sleutel (zoals ECDSA of Ed25519).
Opslagruimten van GitHub¶
Gedetailleerde toegang tot opslagruimte van GitHub wordt behandeld in Toegang tot opslagruimten van GitHub.
Opslagruimten van GitLab¶
Gedetailleerde toegang tot opslagruimte van GitLab wordt behandeld in Toegang tot opslagruimten van GitLab.
Weblate interne URL’s¶
Deel een opstelling met een opslagruimte tussen verschillende onderdelen door naar zijn plaatsing te verwijzen als naar weblate://project/onderdeel in andere (gekoppelde) onderdelen. Op deze manier gekoppelde onderdelen gebruiken de configuratie van de opslagruimte van het VCS van het hoofd (verwezen) onderdeel.
Waarschuwing
Verwijderen van het hoofdonderdeel verwijdert ook gekoppelde onderdelen.
Gekoppelde onderdelen delen de volledige checkout van de opslagruimte; de koppeling isoleert ze niet naar bepaalde bestanden of mappen. Gebruikers, die een gekoppeld onderdeel mogen beheren, kunnen bewerkingen configureren die bestanden beïnvloeden, overal in de gedeelde checkout. Ze kunnen, bijvoorbeeld, bestandsmaskers, opmaak en sjablonen wijzigen, of add-ons installeren en configureren die bestanden in de opslagruimte lezen, maken of aanpassen. Weblate kan resulterende wijzigingen committen en pushen met behulp van de configuratie van het hoofdonderdeel van de opslagruimte.
Koppel alleen onderdelen waarvan de eigenaar van de opslagruimte de beheerders van elk gekoppeld onderdeel vertrouwt met de volledige checkout. Gebruik afzonderlijke opslagruimten als onderdelen isolatie op bestandsniveau nodig hebben.
Weblate past automatisch de URL van de opslagruimte aan bij het maken van een onderdeel, als het een onderdeel vindt met een overeenkomende opstelling voor de opslagruimte. U kunt dit overschrijven in de laatste stap van de configuratie voor een onderdeel.
Redenen om dit te gebruiken:
Bespaart schijfruimte op de server, de opslagruimte wordt maar een keer opgeslagen.
Maakt bijwerken sneller, slechts een opslagruimte wordt bijgewerkt.
Er is slechts een enkele geëxporteerde opslagruimte met vertalingen van Weblate (bekijk Git exporter).
Sommige add-ons kunnen werken op meerdere onderdelen die een opslagruimte delen, bijvoorbeeld Git-commits samenvoegen.
HTTPS opslagruimten¶
Voor toegang tot beveiligde opslagruimten van HTTPS, neem de gebruikersnaam en het wachtwoord op in de URL. Geen zorgen, Weblate zal deze informatie verwijderen wanneer de URL aan gebruikers wordt weergegeven (zelfs als het toegestaan is de URL van de opslagruimte als geheel te bekijken).
Bijvoorbeeld de GitHub URL met authenticatie toegevoegd zou eruit kunnen zien als: https://user:uw_toegangs_token@github.com/WeblateOrg/weblate.git.
In het geval dat u geen inloggegevens in de URL opgeeft en de opslagruimte vereist die, zal Git falen met een fout:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Veranderd in versie 5.10.2: Weblate gebruikt proactieve authenticatie met Git 2.46.0 en nieuwer als inloggegevens van HTTP worden opgegeven.
Dit maakt het mogelijk om toegang te verkrijgen tot opslagplaatsen van Azure DevOps en maakt toegang tot geauthenticeerde opslagplaatsen sneller.
Notitie
Als uw gebruikersnaam of wachtwoord speciale tekens bevat, moeten die als URL worden gecodeerd, bijvoorbeeld https://gebruiker%40example.com:%24wachtwoord%23@bitbucket.org/….
Proxy gebruiken¶
Als u toegang nodig hebt tot opslagruimten van GIT met HTTPS die een proxyserver gebruiken, configureer dan de per-protocol-omgevingsvariabelen die worden beschreven in HTTP proxy.
Parameters versiebeheer¶
Added in version 2026.9.
Parameters voor versiebeheer stemmen fijn af hoe een onderdeel interacteert met zijn opslagruimte, zonder een ander versiebeheerssysteem te moeten kiezen. Ze worden per onderdeel geconfigureerd in Parameters versiebeheer, en alleen de voor het geselecteerde Versiebeheersysteem van toepassing zijnde parameters worden aangeboden.
Lijst met parameters voor versiebeheer¶
Naam parameter |
Versiebeheersystemen |
Label |
Helptekst |
|---|---|---|---|
create_merge_request |
|
Merge requests maken |
Open een pull of merge request voor de wijzigingen in de vertaling. Indien uitgeschakeld, pusht Weblate direct naar de vertaalde branch, wat daarvoor schrijftoegang vereist. |
git_force_push |
|
Afgedwongen pushen |
Overschrijf de branch op afstand in plaats van het pushen van non-fast-forward-wijzigingen te weigeren. Gebruik dit alleen met een opslagruimte die is aangewezen voor vertalingen, omdat het commits voor upstream, die niet aanwezig zijn in Weblate, negeert. |
merge_request_automerge |
|
Pull requests automatisch samenvoegen |
Schakel in GitHub auto-merge voor pull requests, gemaakt door Weblate, in, zodat ze worden samengevoegd als de vereiste controles zijn voltooid. Pull requests die niet ergens op wachten, worden direct samengevoegd. |
merge_request_merge_method |
|
Samenvoegmethode |
Methode die wordt gebruikt bij het automatisch samenvoegen van pull requests. De opslagruimte moet het toestaan. Beschikbare keuzes:
|
Git¶
Hint
Weblate heeft Git 2.46 of nieuwer nodig.
Notitie
Weblate valideert permanente http-verwijzingen die op de hostnaam van de opslagruimte blijven en slaat automatisch de canonical URL voor de opslagruimte op. De wijziging wordt vastgelegd in de geschiedenis van het onderdeel als onderhoud aan de opslagruimte. Verwijzingen naar een andere hostnaam moeten handmatig worden geconfigureerd.
Zie ook
Bekijk Toegang tot opslagruimten voor informatie over hoe toegang te krijgen tot de verschillende soorten opslagruimten.
Git LFS¶
Weblate ondersteunt bestanden die worden gevolgd door Git LFS als vertaalbestanden. Het download of upload geen Git LFS-objecten. Git LFS smeren en pre-push uploads zijn uitgeschakeld voor door Weblate beheerde opslagruimten, dus door LFS gevolgde bestanden blijven pointerbestanden. Dit gedrag is van toepassing op elke provider van hosten voor Git.
Een opslagruimte kan Git LFS gebruiken voor bestanden die Weblate niet hoeft te lezen of aan te passen. De opslagruimte upstream blijft de autoritatieve bron voor deze objecten LFS. Kloon vanaf upstream als u de feitelijke bestanden nodig hebt in plaats van hun verwijzingen, omdat opslagruimten die worden geserveerd door Weblate geen objecten LFS bevatten.
Voor de werkstroom van GitLab merge requests, schakelt Weblate Git LFS uit in zijn beheerde fork. Dit voorkomt dat GitLab vertaalbranches met alleen verwijzingen weigert als de opslagruimte upstream objecten LFS heeft toegevoegd nadat de fork werd gemaakt. Bestaande beheerde forken worden opnieuw geconfigureerd bij hun volgende push. Dit wijzigt niet de configuratie voor Git LFS van het project upstream.
Submodules voor Git¶
Weblate vult geen Git-submodules bij het klonen van opslagruimten. Het initialiseert submodules niet en werkt ze niet bij, en het valt niet terug op opslagruimten van submodules bij het ontdekken van bestanden of bijwerken van vertalingen. Bestanden die zijn opgeslagen binnen een submodule zijn daarom niet beschikbaar voor bestandsmaskers als Weblate wordt verbonden met de ouder-opslagruimte.
Als vertaalbestanden leven binnen een submodule, voeg de opslagruimte van de submodule toe aan Weblate als een eigen onderdeel in plaats van via zijn ouder-opslagruimte. Weblate kan dan naar de opslagruimte klonen, bijwerken, committen en pushen die feitelijk de vertaalbestanden bevat. De ouder-opslagruimte legt alleen de verwijzing voor committen vast voor de submodule, dus het bijwerken van die verwijzing moet buiten Weblate gebeuren, bijvoorbeeld in uw normale werkstroom voor ontwikkelen of CI.
Pushen afdwingen¶
Schakel de git_force_push parameter voor versiebeheer in om ervoor te zorgen dat Weblate altijd pushen forceert. Dit is alleen bedoeld voor het geval dat een afzonderlijke opslagruimte voor de vertalingen wordt gebruikt.
Waarschuwing
Gebruik het voorzichtig, omdat het gemakkelijk leidt tot verloren gegane indieningen in uw opslagruimte upstream.
Veranderd in versie 2026.9: Dit was eerder een apart versiebeheersysteem Git met afgedwongen pushen. Bestaande componenten zijn gemigreerd naar Git met de parameter git_force_push ingeschakeld.
Aanpassen van de configuratie van Git¶
Weblate roept alle opdrachten voor het VCS aan met HOME=$DATA_DIR/home (bekijk DATA_DIR), daarom moet het bewerken van de gebruikerconfiguratie worden gedaan in DATA_DIR/home/.git.
GitHub pull requests¶
Gedetailleerd instellen van pull requests in GitHub wordt behandeld in GitHub pull requests.
GitLab verzoeken voor samenvoegen¶
Gedetailleerd instellen van merge requests in GitLab wordt behandeld in GitLab verzoeken voor samenvoegen.
Gitea pull requests¶
Gedetailleerd instellen van pull requests in Gitea wordt behandeld in Gitea pull requests.
Pull requesten op Bitbucket Data Center¶
Gedetailleerd instellen van pull requests in Bitbucket Data Center wordt behandeld in Pull requesten op Bitbucket Data Center.
Bitbucket Cloud pull requests¶
Gedetailleerd instellen van pull requests in Bitbucket Cloud wordt behandeld in Bitbucket Cloud pull requests.
Pagure verzoeken voor samenvoegen¶
Gedetailleerd instellen van merge requests in Pagure wordt behandeld in Pagure verzoeken voor samenvoegen.
Gerrit¶
Gedetailleerd instellen van review requests in Gerrit wordt behandeld in Verzoeken Gerrit review.
Azure DevOps pull requests¶
Gedetailleerd instellen van pull requests in Azure DevOps wordt behandeld in Azure DevOps pull requests.
Mercurial¶
Mercurial is een ander VCS dat u direct in Weblate kunt gebruiken.
Notitie
Het zou moeten werken met elke versie van Mercurial, maar er zijn soms incompatibele wijzigingen in de interface voor de opdrachtregel die integratie met Weblate verbreekt.
Zie ook
Bekijk Toegang tot opslagruimten voor informatie over hoe toegang te krijgen tot de verschillende soorten opslagruimten.
Subversion¶
Weblate gebruikt git-svn voor interactie met opslagruimten van subversion. Het is een Perl-script dat Subversion in staat stelt te worden gebruikt door een cliënt van Git, wat gebruikers in staat stelt een volledige kloon van de interne opslagruimte te onderhouden en lokaal in te dienen.
Notitie
Weblate probeert automatisch de lay-out van de opslagruimte van Subversion te detecteren - het ondersteunt zowel directe URL’s voor tak of opslagruimten met standaard lay-out (takken/, tags/ en trunk/). Meer informatie hierover is te vinden in de git-svn documentatie. Als uw opslagruimte geen standaard lay-out heeft en u fouten tegenkomt, probeer dan de naam van de tak op te nemen in de URL van de opslagruimte en laat de tak leeg.
Inloggegevens Subversion¶
Weblate verwacht dat u van tevoren het certificaat hebt geaccepteerd (en uw inloggegevens indien nodig). Het zal zoeken om ze in te voegen in de map DATA_DIR. Accepteer het certificaat door svn eenmaal te gebruiken met de omgevingsvariabele $HOME ingesteld op de DATA_DIR:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example
Zie ook
Lokale bestanden¶
Hint
Daaronder gebruikt dit Git. Het vereist dat Git is geïnstalleerd en stelt u in staat om over te schakelen naar Git zelf met de volledige geschiedenis van uw vertalingen.
Weblate kan ook werken zonder een VCS op afstand. De initiële vertalingen worden geïmporteerd door ze te uploaden. Later kunt u individuele bestanden vervangen door een bestand te uploaden, of tekenreeksen van vertalingen direct toe te voegen vanuit Weblate (momenteel alleen beschikbaar voor eentalige vertalingen).
Op de achtergrond maakt Weblate een opslagruimte voor Git voor u en alle wijzigingen worden daarin bijgehouden. In het geval dat u later bepaalt om een VCS te gebruiken om de vertalingen op te slaan, heeft u al een opslagruimte in Weblate waarop u uw integratie kunt baseren.