Code-hosting integrations¶

Weblate integrates with code-hosting sites in several separate places: repository access, incoming notifications, and pushing translations back. The exact setup depends on whether you use Hosted Weblate or run your own Weblate instance, and on whether Weblate should push directly or create pull or merge requests.

Utilitzeu aquesta pàgina com a llista de verificació orientada al proveïdor. Les pàgines de configuració individuals continuen sent la referència canònica per configurar la sintaxi.

Setup overview¶

Grant Weblate access to the repository.
- 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 Accés als repositoris des de Hosted Weblate.
- For self-hosted Weblate, create a dedicated code-hosting user and grant access using Weblate’s SSH key or an HTTPS token, see Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Configureu Repositori del codi font perquè Weblate pugui clonar el repositori.
Configureu les notificacions entrants perquè Weblate faci canvis poc després d’una empenta. El webhook o l’aplicació del dipòsit ha d’apuntar a l’URL del ganxo de Weblate que coincideix i el projecte ha de tenir Activa els punts d’inserció habilitat.
Decidiu com Weblate hauria de retrocedir les traduccions:
- Utilitzeu Git o Mercurial i URL de pujada al repositori per empènyer directament.
- Utilitzeu un backend VCS específic del proveïdor, com ara GitHub o GitLab, per crear sol·licituds d’extracció o fusió. Aquests backends necessiten credencials de l’API a la configuració de Weblate.
Opcionalment, configureu Branca per a la pujada quan Weblate hauria d’empènyer a una branca del dipòsit amunt en lloc d’utilitzar una bifurcació quan sigui compatible.

Impulsant canvis des de Weblate¶

Cada component de traducció pot tenir configurat un URL push (vegeu URL de pujada al repositori), i en aquest cas Weblate podrà enviar canvis al repositori remot. Weblate també es pot configurar per introduir canvis automàticament a cada commit; això està habilitat per defecte, vegeu Puja en fer una comissió.

Si no voleu que els canvis s’enviïn automàticament, podeu enviar manualment a Manteniment del repositori o utilitzant l’API mitjançant wlc push.

In case you do not want direct pushes by Weblate, there is support for GitHub pull requests, GitLab merge requests, Gitea pull requests, Pagure merge requests, Azure DevOps pull requests, or Gerrit review requests reviews. You can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as Sistema de control de versions in Configuració dels components.

En general, les opcions següents estan disponibles amb Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center i Bitbucket Cloud:

Configuració desitjada	Sistema de control de versions	URL de pujada al repositori	Branca per a la pujada
Sense empenta	Git	“buit”	“buit”
Empènyer directament	Git	SSH URL	“buit”
Push to separate branch	Git	SSH URL	Nom de la sucursal
Sense empenta	Mercurial	“buit”	“buit”
Empènyer directament	Mercurial	SSH URL	“buit”
Sol·licitud d’extracció de GitHub des de la bifurcació	GitHub pull requests	“buit”	“buit”
Sol·licitud d’extracció de GitHub des de la sucursal	GitHub pull requests	URL SSH [1]	Nom de la sucursal
Sol·licitud de combinació de GitLab des de la bifurcació	GitLab merge requests	“buit”	“buit”
Sol·licitud de combinació de GitLab des de la branca	GitLab merge requests	URL SSH [1]	Nom de la sucursal
Gitea merge request from fork	Gitea pull requests	“buit”	“buit”
Gitea merge request from branch	Gitea pull requests	URL SSH [1]	Nom de la sucursal
Sol·licitud de combinació de pàgines des de la bifurcació	Pagure merge requests	“buit”	“buit”
Sol·licitud de combinació de pàgines des de la sucursal	Pagure merge requests	URL SSH [1]	Nom de la sucursal
Azure DevOps pull request from fork	Azure DevOps pull requests	“buit”	“buit”
Azure DevOps pull request from branch	Azure DevOps pull requests	URL SSH [1]	Nom de la sucursal
Gerrit review	Gerrit review requests	SSH URL	Target branch name (optional)
Bitbucket Data Center pull request from fork	Bitbucket Data Center pull requests	“buit”	“buit”
Bitbucket Data Center pull request from branch	Bitbucket Data Center pull requests	URL SSH [1]	Nom de la sucursal
Bitbucket Cloud pull request from fork	Bitbucket Cloud pull requests	“buit”	“buit”
Bitbucket Cloud pull request from branch	Bitbucket Cloud pull requests	URL SSH [1]	Nom de la sucursal

GitHub¶

GitHub repository access¶

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 Accés als repositoris des de Hosted Weblate.

HTTPS amb testimoni d’accés personal¶

Per a un únic dipòsit privat, l’accés HTTPS amb un testimoni d’accés sol ser la configuració més senzilla quan el proveïdor admet Git sobre HTTPS. Utilitzeu el nom d’usuari i el testimoni necessaris pel proveïdor a Repositori del codi font.

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

El testimoni necessita accés de lectura per a la clonació i accés d’escriptura per push. Els backends VCS específics del proveïdor que creen sol·licituds d’extracció o fusió poden requerir credencials d’API separades.

Per utilitzar aquest enfocament:

Creeu un testimoni d’accés personal tal com es descriu a Creació d’un testimoni d’accés per a l’ús de la línia d’ordres.
Incloeu el testimoni a l’URL del vostre dipòsit: https://username:token@github.com/owner/repo.git.

Això és adequat quan comenceu amb Weblate o treballeu amb un únic dipòsit.

SSH with a dedicated user¶

Per a configuracions amb diversos dipòsits, utilitzeu l’accés SSH amb un usuari d’allotjament de codi dedicat per a Weblate. Afegiu la clau SSH pública de Weblate a aquest usuari, concediu-li accés als repositoris i utilitzeu URL SSH a Repositori del codi font, per exemple git@example.com:group/project.git.

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

Això també evita les restriccions del proveïdor sobre la reutilització de claus SSH. Alguns llocs d’allotjament de codi permeten afegir una clau SSH pública només una vegada, o només a un sol usuari o implementar una entrada de clau. Mantenir la clau SSH de Weblate en un usuari dedicat permet que aquest usuari tingui accés a diversos dipòsits sense reutilitzar la clau en diversos llocs.

Això manté els testimonis d’accés personals, de projecte o d’API fora dels URL del dipòsit. Les credencials de l’API del proveïdor encara són necessàries quan s’utilitza un backend VCS específic del proveïdor per crear sol·licituds d’extracció o fusió; aquestes credencials es configuren per separat de l’URL del dipòsit de Git.

Per a GitHub, creeu un usuari dedicat, per exemple weblate-bot, i utilitzeu els URL SSH de GitHub per als vostres dipòsits, per exemple 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.

Nota

Quan s’utilitza GitHub per a sol·licituds d’extracció, la configuració Branca per a la pujada afecta el comportament: si no s’estableix, el projecte es bifurca i els canvis s’envien a través d’una bifurcació. Si s’estableix, els canvis s’envien al repositori amunt i a la branca escollida.

GitHub notifications¶

Weblate inclou suport natiu per a 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. Its deliveries use the generic GitHub webhook URL and are authenticated using a separate webhook secret configured by the Hosted Weblate operator. 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 → Code-hosting connections → 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-app 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 GitHub App installation has access to. For organization accounts, Weblate verifies that the install-time GitHub user can administer the organization installation.

Projects that are not in a workspace cannot connect a GitHub account through the GitHub App.

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 Weblate GitHub App has its own webhook URL containing an opaque token that uniquely identifies a single registered App:

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:

El Payload URL consisteix en l’URL del vostre lloc web adjunt per /hooks/github/, per exemple, per al servei Hosted Weblate, això és https://hosted.weblate.org/hooks/github/.

Podeu deixar altres valors a la configuració predeterminada. Weblate pot gestionar ambdós tipus de contingut i només consumeix l’esdeveniment push.

Vegeu també

GitHub pull requests¶

This adds a thin layer atop Git using the GitHub API to allow pushing translation changes as pull requests, instead of pushing directly to the repository.

Git envia els canvis directament a un repositori, mentre que el backend de GitHub crea sol·licituds d’extracció. Aquest últim no és necessari només per accedir als repositoris Git.

Per crear sol·licituds d’extracció, seleccioneu GitHub com a Sistema de control de versions i configureu GITHUB_CREDENTIALS. Per a GitHub.com, utilitzeu api.github.com com a amfitrió de l’API. El testimoni ha de permetre a Weblate llegir i escriure continguts del repositori i crear sol·licituds d’extracció. Si Weblate ha de bifurcar els dipòsits privats, el testimoni també pot necessitar accés d’administració.

GitLab¶

GitLab repository access¶

HTTPS with personal or project access token¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

Per a GitLab, el testimoni necessita l’àmbit write_repository per poder impulsar canvis al dipòsit. El testimoni d’accés al projecte requereix el rol de Desenvolupador per impulsar.

L’URL ha de contenir un nom d’usuari. Per a un testimoni d’accés personal, és el nom d’usuari real: https://user:personal_access_token@gitlab.com/example/example.git. Per als testimonis d’accés al projecte, pot ser un valor no en blanc: https://example:project_access_token@gitlab.com/example/example.git.

Nota

Les regles per utilitzar fitxes d’accés al projecte han canviat entre les versions de GitLab, el valor no en blanc és el requisit actual, però les versions anteriors tenien expectatives diferents (nom del projecte, nom d’usuari del bot). Comproveu la documentació de GitLab que coincideix amb la vostra versió si no esteu segurs.

SSH with a dedicated user¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

Per a GitLab, creeu un usuari dedicat i utilitzeu els URL SSH de GitLab, per exemple git@gitlab.com:group/project.git.

For Hosted Weblate repositories on GitLab, add the hosted weblate user with the required repository permissions, see Accés als repositoris des de Hosted Weblate.

GitLab notifications¶

Weblate té suport per a ganxos GitLab. Afegiu un webhook de projecte amb destinació a l’URL /hooks/gitlab/ a la vostra instal·lació de Weblate, per exemple https://hosted.weblate.org/hooks/gitlab/.

Troubleshooting

Comproveu Historial de sol·licituds de webhook de GitLab si s’entreguen els webhooks.
The response payload contains information about matched components.

Vegeu també

GitLab merge requests¶

Això afegeix una capa fina a la part superior de Git utilitzant la GitLab API per permetre empènyer els canvis de traducció com a sol·licituds de combinació en lloc d’empènyer directament al repositori.

No cal fer-ho servir per accedir als repositoris Git, el normal Git funciona igual, l’única diferència és com es gestiona l’empensió a un repositori. Amb Git els canvis s’envien directament al repositori, mentre que el backend de GitLab crea una sol·licitud de combinació.

Per crear sol·licituds de combinació, seleccioneu GitLab com a Sistema de control de versions i configureu GITLAB_CREDENTIALS.

La configuració Branca per a la pujada afecta on Weblate envia els canvis abans d’obrir la sol·licitud de combinació. Si no s’estableix, el projecte es bifurca i els canvis s’envien a través d’una bifurcació. Si està establert, els canvis s’envien al repositori aigües amunt i a la branca escollida.

Gitea, Forgejo i Codeberg¶

Gitea, Forgejo, and Codeberg repository access¶

HTTPS amb un testimoni d’accés¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

SSH with a dedicated user¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

For Hosted Weblate repositories on Codeberg, add the hosted weblate user with the required repository permissions, see Accés als repositoris des de Hosted Weblate.

Gitea notifications¶

Weblate té suport per a webhooks de Gitea. Afegiu un Gitea Webhook per a l’esdeveniment Push events amb destinació a l’URL /hooks/gitea/ a la vostra instal·lació de Weblate, per exemple https://hosted.weblate.org/hooks/gitea/. Això es pot fer a Webhooks al repositori Configuració.

Vegeu també

Forgejo notifications¶

Weblate té suport per als webhooks de Forgejo. Afegiu un Forgejo Webhook per a l’esdeveniment Push events amb destinació a l’URL /hooks/forgejo/ a la vostra instal·lació de Weblate, per exemple https://hosted.weblate.org/hooks/forgejo/. Això es pot fer a Webhooks al repositori Configuració.

Vegeu també

Gitea pull requests¶

Afegit a la versió 4.12.

Això afegeix una capa fina a la part superior de Git utilitzant l”API Gitea per permetre enviar els canvis de traducció com a sol·licituds d’extracció en lloc d’empènyer directament al repositori.

Per crear sol·licituds d’extracció, seleccioneu Gitea com a Sistema de control de versions i configureu GITEA_CREDENTIALS.

Bitbucket¶

Bitbucket repository access¶

HTTPS amb un testimoni d’accés¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

SSH with a dedicated user¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

For Hosted Weblate repositories on Bitbucket, add the hosted weblate user with the required repository permissions, see Accés als repositoris des de Hosted Weblate.

Per empènyer directament, utilitzeu Git o Mercurial amb URL de pujada al repositori.

Bitbucket notifications¶

Weblate és compatible amb els webhooks de Bitbucket. Afegiu un webhook que s’activa en el repositori, amb destinació a l’URL /hooks/bitbucket/ a la vostra instal·lació de Weblate, per exemple https://hosted.weblate.org/hooks/bitbucket/.

Vegeu també

Bitbucket Data Center pull requests¶

Afegit a la versió 4.16.

This adds a thin layer atop Git using the Bitbucket Data Center API to allow pushing translation changes as pull requests instead of pushing directly to the repository.

Avís

Això no és compatible amb l’API Bitbucket Cloud.

Per crear sol·licituds d’extracció, seleccioneu Bitbucket Data Center com a Sistema de control de versions i configureu BITBUCKETSERVER_CREDENTIALS.

Bitbucket Cloud pull requests¶

Afegit a la versió 5.8.

Això afegeix una capa fina a la part superior de Git utilitzant la Bitbucket Cloud API per permetre empènyer els canvis de traducció com a sol·licituds d’extracció en lloc d’empènyer directament al repositori.

Avís

This is different from Bitbucket Data Center API.

Per crear sol·licituds d’extracció, seleccioneu Bitbucket Cloud com a Sistema de control de versions i configureu BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

Azure Repos repository access¶

HTTPS amb un testimoni d’accés¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

Utilitzeu l’URL del clon HTTPS mostrat per Azure Repos per al dipòsit.

SSH with a dedicated user¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

Utilitzeu l’URL SSH mostrat per Azure Repos per al dipòsit.

Azure Repos notifications¶

Weblate és compatible amb els webhooks d’Azure Repos. Afegiu un webhook per a l’esdeveniment Code pushed amb destinació a l’URL /hooks/azure/ a la vostra instal·lació de Weblate, per exemple https://hosted.weblate.org/hooks/azure/. Això es pot fer a Servei ganxos a Configuració del projecte.

Vegeu també

Azure DevOps pull requests¶

This adds a thin layer atop Git using the Azure DevOps API to allow pushing translation changes as pull requests, instead of pushing directly to the repository.

Git envia els canvis directament a un repositori, mentre que el backend de Azure DevOps crea sol·licituds d’extracció. Aquest últim no és necessari només per accedir als repositoris Git.

Per crear sol·licituds d’extracció, seleccioneu Azure DevOps com a Sistema de control de versions i configureu AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Pagure repository access¶

HTTPS amb un testimoni d’accés¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

SSH with a dedicated user¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

Pagure notifications¶

Weblate té suport per a ganxos Pagure. Afegiu un webhook amb destinació a l’URL /hooks/pagure/ a la vostra instal·lació de Weblate, per exemple https://hosted.weblate.org/hooks/pagure/. Això es pot fer a Activar Web-hooks a Opcions del projecte:

Vegeu també

Pagure merge requests¶

Afegit a la versió 4.3.2.

Això afegeix una capa fina a la part superior de Git utilitzant la Pagure API per permetre empènyer els canvis de traducció com a sol·licituds de combinació en lloc d’empènyer directament al repositori.

Per crear sol·licituds de combinació, seleccioneu Pagure com a Sistema de control de versions i configureu PAGURE_CREDENTIALS.

Altres fluxos de treball¶

Gitee repository access¶

HTTPS amb un testimoni d’accés¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

SSH with a dedicated user¶

Configureu URL de pujada al repositori només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu Impulsant canvis des de Weblate.

Gitee notifications¶

Weblate és compatible amb els webhooks de Gitee. Afegiu un WebHook per a l’esdeveniment Push amb destinació a l’URL /hooks/gitee/ a la vostra instal·lació de Weblate, per exemple https://hosted.weblate.org/hooks/gitee/. Això es pot fer a WebHooks al repositori Gestió.

Vegeu també

Gerrit review requests¶

Gerrit support adds a thin layer atop Git using the git-review tool to allow pushing translation changes as Gerrit review requests, instead of pushing them directly to the repository.

The optional Branca per a la pujada setting selects the target branch for the Gerrit review. Leave it empty to use Branca del repositori. Use the short branch name, such as main; Weblate and git-review push the review to refs/for/<branch> automatically. Gerrit push options can be appended after % in either setting, for example main%topic=l10n. Gerrit interprets these options as the configured Weblate Gerrit account and applies its own permissions.

The Gerrit documentation has the details on the configuration necessary to set up such repositories. There is no separate code-hosting credential setting for this backend.

Credencials de Docker¶

For Docker installations, code-hosting API credentials can also be provided through environment variables, see Code-hosting sites credentials.