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.
- For GitHub repositories on Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow. The App gives Hosted Weblate repository access without inviting the hosted weblate user.
- For other Hosted Weblate repositories, and for direct SSH pushes outside the GitHub App workflow, add the hosted weblate user where it is available, see 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¶

Hosted Weblate GitHub App¶

On Hosted Weblate, the recommended setup is to connect the Hosted Weblate app from the Weblate workspace where your project lives. Use the Connect GitHub account flow, install the App on the GitHub user or organization that owns your repositories, grant it access to the repositories you want to translate, and import components from the connected GitHub account.

The App-backed workflow uses GitHub installation access tokens for cloning, pushing translation branches, creating pull requests, and receiving incoming notifications. You do not need to invite the Hosted Weblate weblate GitHub user or configure a separate repository webhook for components imported this way.

Use the Hosted Weblate weblate GitHub user only when you intentionally configure direct SSH pushes outside the GitHub App workflow, see Toegang tot opslagruimten vanuit Hosted Weblate.

HTTPS met persoonlijk toegangstoken¶

Voor een enkele private opslagruimte is HTTPS-toegang met een toegangstoken gewoonlijk de eenvoudigste opstelling als de provider Git over HTTPS ondersteunt. Gebruik de door de provider vereiste gebruikersnaam en token in Broncode-opslagruimte.

Configureer URL voor pushen naar de opslagruimte alleen als Weblate wijzigingen direct zou moeten pushen of wanneer de gekozen werkstroom een push-URL vereist, bekijk Wijzigingen vanuit Weblate pushen.

Het token heeft leestoegang nodig voor klonen en schrijftoegang voor pushen. Provider-specifieke VCS backends die pull of merge requests maken vereisen misschien afzonderlijke inloggegevens voor de API.

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.

SSH met een aangewezen gebruiker¶

Voor opstellingen met meerdere opslagruimten: gebruik toegang met SSH met een aangewezen gebruiker voor het hosten van code voor Weblate. Voeg Weblate’s publieke SSH-sleutel toe aan die gebruiker, geef die gebruiker toegang tot de opslagruimten en gebruik SSH-URL’s in Broncode-opslagruimte, bijvoorbeeld git@example.com:group/project.git.

Dat vermijdt ook beperkingen van de provider voor het hergebruiken van SSH-sleutels. Sommige sites voor het hosten van code staan toe dat een publieke SSH-sleutel maar een keer wordt toegevoegd, of alleen aan een enkele gebruiker of uitrol sleutelitem. Weblate’s SSH-sleutel uitgeven aan een aangewezen gebruiker laat die gebruiker toegang krijgen tot meerdere opslagruimten, zonder de sleutel op verscheidene plaatsen te gebruiken.

Dat houdt persoonlijke, project- of API-toegangstokens buiten de URL’s van opslagruimten. Provider API-inloggegevens zijn nog steeds nodig bij het gebruiken van provider-specifieke VCS-backend om pull of merge requests te maken; die inloggegevens worden afzonderlijk geconfigureerd van de URL voor de Git-opslagruimte.

On Hosted Weblate, use provider integrations where available. For GitHub, the recommended setup is the Hosted Weblate app. For direct SSH access on supported code hosting sites, use the hosted weblate user, see Toegang tot opslagruimten vanuit Hosted Weblate.

Voor GitHub, maak een aangewezen gebruiker, bijvoorbeeld weblate-bot, en gebruik SSH-URL’s van GitHub voor uw opslagruimten, bijvoorbeeld git@github.com:owner/repo.git.

On Hosted Weblate, use this SSH-user workflow only for direct SSH pushes outside the recommended Hosted Weblate app workflow.

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.

If you are using Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow. It uses GitHub App webhooks, so you do not need to configure a separate Webhook in GitHub. Components imported from the connected GitHub account also use the App for repository access and pull requests, without inviting the Hosted Weblate weblate GitHub user.

The Hosted Weblate legacy app is kept for existing webhook-only setups. Use it only when you need the legacy app to deliver GitHub notifications to Hosted Weblate.

For self-hosted Weblate, register the GitHub App using the in-app registration flow described below. Weblate generates the App manifest, GitHub returns the credentials, and they are stored in the database - there is no settings-based configuration.

Registering the GitHub App from Weblate¶

The fastest way to add the GitHub App is to let Weblate generate a GitHub App manifest with the correct permissions, events, and webhook URL pre-filled:

Sign in to Weblate with an account that has management access.
Open Manage → VCS Installations → Register Weblate GitHub App.
Fill in the form. The GitHub host defaults to github.com; change it to your GitHub Enterprise hostname if needed. Leave Organization blank to register the App under your personal account, or enter an organization slug to register it under that org.
Click Continue to GitHub and confirm on GitHub’s Create GitHub App page (you can still rename the App there).
GitHub redirects back to Weblate, which exchanges the temporary code for the App ID, private key, webhook secret, and slug and stores them in the database. The Connect GitHub account button is available immediately afterwards.

The manifest requests the permissions and event subscriptions Weblate needs (Contents and Pull requests read/write, Metadata read-only, Organization administration read-only, Workflows read/write, and the Installation, Meta and Push events), and sets the callback, setup and per-integration webhook URLs automatically, so no manual GitHub App configuration is required. GitHub delivers the Installation and Installation repositories events to all GitHub Apps by default.

GitHub only offers accounts where the signed-in GitHub user can install or request the app. If an organization is not shown during the install flow, check the user’s organization role and the organization’s GitHub App installation restrictions. On GitHub.com, public apps can be installed on other accounts; private apps can only be installed on the account that owns the app.

Connecting a workspace¶

Connected GitHub accounts are bound to a Weblate workspace. A user with project administration rights for any project in a workspace can connect a GitHub account on that workspace. After connecting, every project in the workspace can import components from repositories the app installation has access to. For organization installations, Weblate verifies that the install-time GitHub user can administer the organization installation.

Projects that are not in a workspace cannot connect a GitHub App installation.

Components imported through the GitHub App flow use the dedicated GitHub (via Weblate GitHub app) VCS backend. The component settings UI keeps the repository URL read-only to prevent the App-issued credentials from being redirected to an unrelated repository.

App webhook URL¶

Each registered GitHub App integration has its own webhook URL containing an opaque token that uniquely identifies a single integration:

https://weblate.example.com/hooks/integrations/<webhook_token>/

If you are not using a GitHub App, add the Weblate webhook in the repository settings (Webhooks) to receive notifications on every push to a GitHub repository, as shown on the image below:

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¶

HTTPS met persoonlijk of projecttoegangstoken¶

Voor GitLab moet het token 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.

SSH met een aangewezen gebruiker¶

Voor GitLab, maak een aangewezen gebruiker en gebruik SSH-URL’s van GitLab, bijvoorbeeld git@gitlab.com:group/project.git.

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.

De configuratie van Push-tak beïnvloedt waar Weblate wijzigingen naartoe pusht voordat het merge request wordt geopend. Als dit niet is ingesteld, wordt het project geforkt en de wijzigingen gepusht via een fork. Indien het wel is ingesteld, worden wijzigingen gepusht naar de opslagruimte upstream en gekozen tak.

Gitea, Forgejo en Codeberg¶

Gitea, Forgejo en Codeberg toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

SSH met een aangewezen gebruiker¶

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¶

Bitbucket toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

SSH met een aangewezen gebruiker¶

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 toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

Gebruik de HTTPS-URL voor klonen die door Azure Repos voor de opslagruimte wordt weergegeven.

SSH met een aangewezen gebruiker¶

Gebruik de SSH-URL die door Azure Repos voor de opslagruimte wordt weergegeven.

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 toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

SSH met een aangewezen gebruiker¶

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 toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

SSH met een aangewezen gebruiker¶

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.

De optionele instelling Push-tak selecteert de doelbranch voor de review van Gerrit. Laat die leeg om Tak opslagruimte te gebruiken. Gebruik de verkorte branchnaam, zoals main; Weblate en git-review pushen de review automatisch naar refs/for/<branch>. Opties voor pushen van Gerrit kunnen worden toegevoegd na % in elke instelling, bijvoorbeeld main%topic=l10n. Gerrit interpreteert deze opties als het geconfigureerde Weblate-account voor Gerrit en past zijn eigen rechten toe.

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.