Integraties hosten code¶

Weblate integreert op verschillende plaatsen met sites voor het hosten van code: toegang tot opslagruimten, inkomende notificaties en het terugplaatsen van vertalingen. De exacte opstelling is afhankelijk van het feit of u Hosted Weblate gebruikt of uw eigen instantie van Weblate uitvoert en of Weblate direct pull requests zou moeten pushen of maken.

Gebruik deze pagina als een provider-geöriënteerde controlelijst. De individuele pagina’s voor de instellingen behouden de canonical verwijzing voor het instellen van syntaxis.

Overzicht instellingen¶

Geef Weblate toegang tot de opslagruimte.
- Op Hosted Weblate, voeg de gehoste gebruiker weblate toe waar die beschikbaar is, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.
- Voor zelf gehoste Weblate, maak een aangewezen gebruiker voor het hosten van code en geef die toegang met Weblate’s SSH-sleutel of een HTTPS-token, bekijk Toegang tot opslagruimten van sites voor het hosten van code (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Configureer Broncode-opslagruimte zodat Weblate de opslagruimte kan klonen.
Configureer inkomende notificaties, zodat Weblate wijzigingen kort na het pushen ophaalt. De webhook voor de opslagruimtere of de app moet verwijzen naar de overeenkomende URL voor de hook van Weblate, en het project moet Hooks inschakelen hebben ingeschakeld.
Bepaal hoe Weblate push-vertalingen terug zou moeten plaatsen:
- Gebruik Git of Mercurial en URL voor pushen naar de opslagruimte om direct te pushen.
- Gebruik een provider-specifiek VCS-backend, zoals GitHub of GitLab, om pull of merge requests te maken. Deze backends hebben inloggegevens voor de API nodig in de instellingen van Weblate.
Stel, optioneel, Push-tak in voor wanneer Weblate naar een branch in de opslagruimte upstream zou moeten pushen in plaats van naar een fork, indien ondersteund.

Wijzigingen vanuit Weblate pushen¶

Elk vertaalonderdeel kan een URL voor pushen ingesteld hebben (bekijk URL voor pushen naar de opslagruimte), en in dat geval zal Weblate in staat zijn de wijziging naar de opslagruimte op afstand te pushen. Weblate kan ook worden geconfigureerd om automatisch wijzigingen te pushen bij elke indiening (commit); dit is standaard ingeschakeld, bekijk Pushen na commit.

Wanneer u niet wilt dat wijzigingen automatisch worden gepusht, kunt u handmatig pushen onder Onderhoud opslagruimte of met de API via wlc push.

Voor het geval dat u geen direct pushen door Weblate wilt, is er ondersteuning voor GitHub pull requests, GitLab verzoeken voor samenvoegen, Gitea pull requests, Pagure verzoeken voor samenvoegen, Azure DevOps pull requests, of reviews van Verzoeken Gerrit review. U kunt deze activeren door te kiezen voor GitHub, GitLab, Gitea, Gerrit, Azure DevOps, of Pagure als Versiebeheersysteem in Configuratie onderdeel.

In het algemeen zijn de volgende opties beschikbaar met Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center en Bitbucket Cloud:

Gewenste instelling	Versiebeheersysteem	URL voor pushen naar de opslagruimte	Push-tak
Niet pushen	Git	leeg	leeg
Direct pushen	Git	SSH URL	leeg
Pushen naar afzonderlijke tak	Git	SSH URL	Naam tak
Niet pushen	Mercurial	leeg	leeg
Direct pushen	Mercurial	SSH URL	leeg
GitHub pull request vanuit fork	GitHub pull requests	leeg	leeg
GitHub pull request vanuit tak	GitHub pull requests	SSH URL [1]	Naam tak
GitLab merge request vanuit fork	GitLab verzoeken voor samenvoegen	leeg	leeg
GitLab merge request vanuit tak	GitLab verzoeken voor samenvoegen	SSH URL [1]	Naam tak
Gitea merge request vanuit fork	Gitea pull requests	leeg	leeg
Gitea merge request vanuit tak	Gitea pull requests	SSH URL [1]	Naam tak
Pagure merge request vanuit fork	Pagure verzoeken voor samenvoegen	leeg	leeg
Pagure merge request vanuit tak	Pagure verzoeken voor samenvoegen	SSH URL [1]	Naam tak
Azure DevOps pull request vanuit fork	Azure DevOps pull requests	leeg	leeg
Azure DevOps pull request vanuit tak	Azure DevOps pull requests	SSH URL [1]	Naam tak
Gerrit review	Verzoeken Gerrit review	SSH URL	Naam doelbranch (optioneel)
Pull request op Bitbucket Data Center uit fork	Pull requesten op Bitbucket Data Center	leeg	leeg
Bitbucket Data Center pull request vanuit tak	Pull requesten op Bitbucket Data Center	SSH URL [1]	Naam tak
Bitbucket Cloud pull request vanuit fork	Bitbucket Cloud pull requests	leeg	leeg
Bitbucket Cloud pull request vanuit tak	Bitbucket Cloud pull requests	SSH URL [1]	Naam tak

GitHub¶

Toegang tot opslagruimten van GitHub¶

Er bestaan twee belangrijke benaderingen voor toegang tot opslagruimten van GitHub met Weblate:

Optie 1: HTTPS met Personal Access Token

Gebruik authenticatie met HTTPS met een persoonlijk toegangstoken en uw GitHub-account. Dat werkt zowel voor toegang alleen-lezen en toegang lezen-schrijven.

Die benadering gebruiken:

Maak een persoonlijk toegangstoken zoals beschreven in Een toegangstoken maken om te gebruiken op de opdrachtregel.
Neem het token op in de URL van uw opslagruimte: https://gebruikersnaam:token@github.com/eigenaar/repo.git.

Dit is geschikt als u net begint met Weblate of werkt met een enkele opslagruimte.

Optie 2: SSH met een aangewezen gebruiker

Voor instellingen met meerdere opslagruimten, maak een aangewezen gebruiker voor Weblate. Dat vermijdt de beperking van GitHub dat elke SSH-sleutel slechts een keer per platform mag worden gebruikt.

Die benadering gebruiken:

Maak een account voor een aangewezen gebruiker voor GitHub (bijvoorbeeld weblate-bot).
Voeg de publieke sleutel van Weblate toe aan deze gebruiker, (bekijk Weblate SSH-sleutel).
Geef deze gebruiker toegang tot alle opslagruimten die u wilt vertalen.
Gebruik SSH URL’s voor uw opslagruimten: git@github.com:eigenaar/repo.git.

Deze benadering wordt ook gebruikt voor Hosted Weblate, die voor dat doel een aangewezen gebruiker weblate heeft.

Notitie

Bij het gebruiken van GitHub voor pull requests, beïnvloedt de configuratie van Push-tak het gedrag: indien niet ingesteld wordt het project geforkt en de wijzigingen gepusht via een fork. Indien wel ingesteld, worden wijzigingen gepusht naar de opslagruimte upstream en de gekozen tak.

GitHub notificaties¶

Weblate heeft eigen ondersteuning voor GitHub.

Wanneer u Hosted Weblate gebruikt, is de aanbevolen benadering om de Weblate app te installeren. De app levert GitHub-notificaties af aan Hosted Weblate, dus u hoeft geen afzonderlijke Webhook in GitHub te configureren. Het geeft echter niet zelf Hosted Weblate toegang tot de opslagruimte. Om wijzigingen terug te pushen moet u nog steeds de Hosted Weblate weblate GitHub-gebruiker toevoegen als een deelnemer met schrijftoegang, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.

Als u de app niet gebruikt, voeg de Weblate webhook toe in de instellingen voor de opslagruimte (Webhooks), voor het ontvangen van notificaties voor elke push naar een opslagruimte van GitHub, zoals weergegeven in de afbeelding hieronder:

De Payload URL bestaat uit uw URL voor Weblate, gevolgd door /hooks/github/, voor de service Hosted Weblate is dit bijvoorbeeld https://hosted.weblate.org/hooks/github/.

U kunt de andere waarden laten staan op de standaard instellingen Weblate kan beide typen inhoud afhandelen en gebruikt alleen de gebeurtenis push.

Zie ook

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 het backend GitHub pull requests maakt. Het laatste is niet nodig om puur toegang te krijgen tot opslagruimten van Git.

Selecteer, om pull requests te maken, GitHub als Versiebeheersysteem en configureer GITHUB_CREDENTIALS. Gebruik voor GitHub.com api.github.com als de API-host. Het token moet Weblate toestaan om inhoud van de opslagruimte te lezen en te schrijven en pull requests te maken. Als Weblate private opslagruimten zou moeten forken, heeft het token misschien ook beheersrechten nodig.

GitLab¶

Toegang tot opslagruimten van GitLab¶

Toegang via SSH is mogelijk, bekijk SSH-opslagruimten, maar als 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 een persoonlijk toegangstoken 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 zijn 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.

GitLab notificaties¶

Weblate heeft ondersteuning voor hooks van GitLab. Voeg een webhook voor het project toe met als doel de URL /hooks/gitlab/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/gitlab/.

Probleemoplossing

Controleer GitLab webhook request history als webhooks worden afgeleverd.
De lading van het antwoord bevat informatie over overeenkomende onderdelen.

Zie ook

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 het backend Git worden wijzigingen direct naar de opslagruimte gepusht, terwijl het backend GitLab een merge request maakt.

Selecteer, om merge requests te maken, GitLab als Versiebeheersysteem en configureer GITLAB_CREDENTIALS.

Gitea, Forgejo en Codeberg¶

Voor opslagruimten van Hosted Weblate op Codeberg, voeg de gehoste gebruiker van weblate toe waar schrijftoegang nodig is, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.

Gitea notificaties¶

Weblate heeft ondersteuning voor webhooks van Gitea. Voeg een Gitea Webhook toe voor de gebeurtenis Push events met als doel de URL /hooks/gitea/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/gitea/. Dit kan worden gedaan in Webhooks onder Settings voor de opslagruimte.

Zie ook

Forgejo notificaties¶

Weblate heeft ondersteuning voor webhooks van Forgejo. Voeg een Forgejo Webhook toe voor de gebeurtenis Push events met als doel de URL /hooks/forgejo/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/forgejo/. Dit kan worden gedaan in Webhooks onder Settings voor de opslagruimte.

Zie ook

Gitea pull requests¶

Added in version 4.12.

Dit voegt 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 de backend Gitea pull requests maakt.

Selecteer, om pull requests te maken, Gitea als Versiebeheersysteem en configureer GITEA_CREDENTIALS.

Bitbucket¶

Hosted Weblate heeft een aangewezen gebruiker weblate voor toegang tot Bitbucket, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.

Direct pushen, gebruik Git of Mercurial met URL voor pushen naar de opslagruimte.

Bitbucket notificaties¶

Weblate heeft ondersteuning voor webhooks van Bitbucket. Voeg een webhook toe die wordt geactiveerd bij pushen vanuit de opslagruimte, met als doel de URL /hooks/bitbucket/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/bitbucket/.

Zie ook

Pull requesten op Bitbucket Data Center¶

Added in version 4.16.

Dit voegt 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 de backend Bitbucket Data Center een pull request maakt.

Selecteer, om pull requests te maken, Bitbucket Data Center als Versiebeheersysteem en configureer BITBUCKETSERVER_CREDENTIALS.

Bitbucket Cloud pull requests¶

Added in version 5.8.

Dit voegt 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.

Selecteer, om pull requests te maken, Bitbucket Cloud als Versiebeheersysteem en configureer BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

Azure Repos notificaties¶

Weblate heeft ondersteuning voor webhooks van Azure Repos. Voeg een webhook toe voor de gebeurtenis Code pushed met als doel de URL /hooks/azure/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/azure/. Dit kan worden gedaan in Service hooks onder Project settings.

Zie ook

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 de backend Azure DevOps pull requests maakt. Het laatste is niet nodig om alleen toegang te krijgen tot opslagruimten van Git.

Selecteer, om pull requests te maken, Azure DevOps als Versiebeheersysteem en configureer AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Pagure notificaties¶

Weblate heeft ondersteuning voor hooks van Pagure. Voeg een webhook toe met als doel de URL /hooks/pagure/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/pagure/. Dit kan worden gedaan in Activate Web-hooks onder Project options:

Zie ook

Pagure verzoeken voor samenvoegen¶

Added in version 4.3.2.

Dit voegt 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.

Selecteer, om merge requests te maken, Pagure als Versiebeheersysteem en configureer PAGURE_CREDENTIALS.

Andere werkstromen¶

Gitee notificaties¶

Weblate heeft ondersteuning voor webhooks van Gitee. Voeg een WebHook toe voor de gebeurtenis Push met als doel de URL /hooks/gitee/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/gitee/. Dit kan worden gedaan in WebHooks onder Management van de opslagruimte.

Zie ook

Verzoeken Gerrit review¶

Ondersteuning van Gerrit voegt 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.

The optional Push-tak setting selects the target branch for the Gerrit review. Leave it empty to use Tak opslagruimte. Use the short branch name, such as main; Weblate and git-review push the review to refs/for/<branch> automatically. Do not include Gerrit push options such as %submit or %l=Code-Review+2 in the branch name.

De documentatie van Gerrit heeft de details voor de noodzakelijke configuratie om dergelijke opslagruimten op te stellen. Er is geen afzonderlijke instelling voor inloggegevens voor code hosten voor dit backend.

Inloggegevens Docker¶

Voor installaties van Docker kunnen inloggegevens voor de API van code hosten ook worden opgegeven met omgevingsvariabelen, bekijk Inloggegevens sites hosten code.