Versiebeheerintegratie¶
Weblate ondersteunt momenteel Git (met uitgebreide ondersteuning voor GitHub pull requests, GitLab verzoeken voor samenvoegen, Gitea pull requests, Gerrit, Subversion, Bitbucket Cloud pull requests, Pull requesten op Bitbucket Data Center en Azure DevOps pull requests) en Mercurial als versiebeheer backends.
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.
Toegang tot opslagruimten vanuit Hosted Weblate¶
Notitie
This section applies only to Hosted Weblate (hosted.weblate.org). If you are running your own self-hosted Weblate instance, please see the next section instead.
Voor Hosted Weblate is er een toegewezen gebruiker voor pushen op GitHub, Bitbucket, Codeberg en GitLab (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 invitaties automatisch binnen vijf minuten. Handmatige verwerking zou voor andere services nodig kunnen zijn, wees dus geduldig.
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@github.com:WeblateOrg/weblate.git).
Toegang tot opslagruimten van sites voor het hosten van code (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Notitie
This section applies to self-hosted Weblate instances. If you are using Hosted Weblate (hosted.weblate.org), see Toegang tot opslagruimten vanuit Hosted Weblate instead.
For self-hosted Weblate, accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Weblate SSH-sleutel). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of a SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see SSH-opslagruimten).
SSH-opslagruimten¶
De meest frequent gebruikte 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 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.
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¶
There are two main approaches to accessing GitHub repositories with Weblate:
Option 1: HTTPS with Personal Access Token (simpler for getting started)
Use HTTPS authentication with a personal access token and your GitHub account. This works for both read-only access (cloning) and read-write access (pushing changes or creating pull requests).
To use this approach:
Create a personal access token as described in Creating an access token for command-line use.
Include the token in your repository URL:
https://username:token@github.com/owner/repo.git
This is suitable when you’re starting with Weblate or working with a single repository.
Option 2: SSH with Dedicated User (recommended for multiple repositories)
For setups with multiple repositories, it is recommended to create a dedicated user for Weblate. This avoids GitHub’s limitation that each SSH key can only be used once per platform.
To use this approach:
Create a dedicated GitHub user account (e.g.,
weblate-bot)Add Weblate’s public SSH key to this user (see Weblate SSH-sleutel)
Grant this user access to all repositories you want to translate
Use SSH URLs for your repositories:
git@github.com:owner/repo.git
This approach is also used for Hosted Weblate, which has a dedicated weblate user for that purpose.
Notitie
When using GitHub pull requests for pull requests, the Push-tak configuration affects the behavior: if not set, the project is forked and changes are pushed through a fork. If set, changes are pushed to the upstream repository and the chosen branch.
Opslagruimten van GitLab¶
Toegang via SSH is mogelijk (bekijk SSH-opslagruimten), maar in het geval dat u toegang nodig hebt tot meer dan een opslagruimte, zult u tegen een beperking van GitLab aanlopen met betrekking tot het toegestane gebruik van SSH-sleutels (omdat elke sleutel maar een keer mag worden gebruikt).
In het geval dat de Push-tak niet is ingesteld, wordt het project geforkt en de wijzigingen gepusht via een fork. In het geval het wel is ingesteld worden wijzigingen gepusht naar de opslagruimte upstream en de gekozen tak.
Het is mogelijk om zowel persoonlijke als project-toegangstokens te gebruiken. Het token moet het bereik write_repository hebben om in staat te zijn wijzigingen naar de opslagruimte te pushen. Het project-toegangstoken vereist de rol Ontwikkelaar voor pushen.
De URL moet een gebruikersnaam bevatten, voor persoonlijke toegangstokens is dat de feitelijke gebruikersnaam ( https://gebruiker:persoonlijk_toegangs_token@gitlab.com/example/example.git) voor project-toegangstokens mag het een niet lege waarde zijn (https://voorbeeld:project_toegangs_token@gitlab.com/example/example.git).
Notitie
De regels voor het gebruiken van project-toegangstokens is gewijzigd tussen uitgaven van GitLab, de niet lege waarde is het huidige vereiste, maar oudere versies hadden verschillende verwachtingen (projectnaam, bot gebruikersnaam). Bekijk de documentatie van GitLab die overeenkomt met uw versie als u er niet zeker van bent.
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.
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 het VCS met HTTP/HTTPS die een proxyserver gebruiken, configureer dan het VCS om het te gebruiken.
Dat kan worden gedaan met de omgevingsvariabelen http_proxy, https_proxy en all_proxy, (zoals beschreven in de cURL documentation) of door het af te dwingen in de configuratie van het VCS, bijvoorbeeld:
git config --global http.proxy http://user:password@proxy.example.com:80
Notitie
De configuratie van de proxy moet worden gedaan door de gebruiker waaronder Weblate wordt uitgevoerd (bekijk ook Rechten voor bestandssysteem) en met HOME=$DATA_DIR/home (bekijk DATA_DIR), anders zal Git, dat wordt uitgevoerd met Weblate, het niet gebruiken.
Git¶
Hint
Weblate heeft Git 2.28 of nieuwer nodig.
Zie ook
Bekijk Toegang tot opslagruimten voor informatie over hoe toegang te krijgen tot de verschillende soorten opslagruimten.
Git met afgedwongen push¶
Dit gedraagt zich exact hetzelfde als Git zelf, het enige verschil is dat het 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.
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¶
Dit voegt een dunne laag toe bovenop Git met de GitHub API om het pushen van wijzigingen in de vertalingen als pull requests mogelijk te maken, in plaats van ze direct naar de opslagruimte te pushen.
Git pusht wijzigingen direct naar een opslagruimte, terwijl GitHub pull requests pull requests maakt. Het laatste is niet nodig om puur toegang te krijgen tot opslagruimten van Git.
U moet inloggegevens voor de API configureren (GITHUB_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Eenmaal geconfigureerd, zult u een optie GitHub zien bij het selecteren van Versiebeheersysteem.
GitLab verzoeken voor samenvoegen¶
Dit voegt een dunne laag toe bovenop Git met de GitLab API om het pushen van wijzigingen in vertalingen als merge requests mogelijk te maken, in plaats van ze direct naar de opslagruimte te pushen.
Er is geen noodzaak om dit te gebruiken voor toegang tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen direct naar de opslagruimte gepusht, terwijl GitLab verzoeken voor samenvoegen een merge request maakt.
U moet inloggegevens voor de API configureren (GITLAB_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Eenmaal geconfigureerd, zult u een optie GitLab zien bij het selecteren van Versiebeheersysteem.
Gitea pull requests¶
Added in version 4.12.
Dit voegt eenvoudigweg een dunne laag toe bovenop Git met behulp van de Gitea API om wijzigingen in vertalingen als pull requests te kunnen pushen, in plaats van ze direct naar de opslagruimte te pushen.
Het is niet nodig om dit te gebruiken voor toegang tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen direct naar de opslagruimte gepusht, terwijl Gitea pull requests pull requests maakt.
U moet inloggegevens voor de API configureren (GITEA_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Gitea bij het selecteren van Versiebeheersysteem.
Pull requesten op Bitbucket Data Center¶
Added in version 4.16.
Dit voegt eenvoudigweg een dunne laag toe bovenop Git die de Bitbucket Data Center API gebruikt om wijzigingen in vertalingen als pull requesten te pushen, in plaats van ze direct naar de opslagruimte te pushen.
Waarschuwing
Dit ondersteunt niet Bitbucket Cloud API.
Er is geen noodzaak om dit te gebruiken om toegang te krijgen tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen rechtstreeks naar de opslagruimte gepusht, terwijl Pull requesten op Bitbucket Data Center een pull request maakt.
U moet inloggegevens voor de API configureren (BITBUCKETSERVER_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Bitbucket Data Center bij het selecteren van Versiebeheersysteem.
Bitbucket Cloud pull requests¶
Added in version 5.8.
Dit voegt eenvoudigweg een dunne laag toe bovenop Git met behulp van de Bitbucket Cloud API om wijzigingen in vertalingen als pull requests te kunnen pushen, in plaats van ze direct naar de opslagruimte te pushen.
Waarschuwing
Dit is anders dan in de Bitbucket data Center API.
Het is niet nodig om dit te gebruiken voor toegang tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen direct naar de opslagruimte gepusht, terwijl Bitbucket Cloud pull requests pull requests maakt.
U moet inloggegevens voor de API configureren (BITBUCKETCLOUD_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Bitbucket Cloud bij het selecteren van Versiebeheersysteem.
Pagure verzoeken voor samenvoegen¶
Added in version 4.3.2.
Dit voegt eenvoudigweg een dunne laag toe bovenop Git die de Pagure API gebruikt om wijzigingen in vertalingen als merge requests te pushen, in plaats van ze direct naar de opslagruimte te pushen.
Er is geen noodzaak om dit te gebruiken om toegang te krijgen tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen rechtstreeks naar de opslagruimte gepusht, terwijl Pagure verzoeken voor samenvoegen een merge request maakt.
U moet inloggegevens voor de API configureren (PAGURE_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Pagure bij het selecteren van Versiebeheersysteem.
Gerrit¶
Dit voegt eenvoudigweg een dunne laag toe bovenop Git die het programma git-review gebruikt om wijzigingen in vertalingen als Gerrit review requests te pushen, in plaats van ze direct naar de opslagruimte te pushen.
De documentatie van Gerrit heeft de details voor de noodzakelijke configuratie om dergelijke opslagruimten op te stellen.
Azure DevOps pull requests¶
Dit voegt eenvoudigweg een dunne laag toe bovenop Git die de Azure DevOps API gebruikt om wijzigingen in vertalingen als pull requests te pushen, in plaats van ze direct naar de opslagruimte te pushen.
Git pusht wijzigingen direct naar een opslagruimte, terwijl Azure DevOps pull requests pull requests maakt. Het laatste is niet nodig om alleen toegang te krijgen tot opslagruimten van Git.
U moet inloggegevens voor de API configureren (AZURE_DEVOPS_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Azure DevOps bij het selecteren van Versiebeheersysteem.
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.