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 requests.

Use this page as a provider-oriented checklist. The individual setting pages remain the canonical reference for setting syntax.

Setup overview¶

Grant Weblate access to the repository.
- For Hosted Weblate, add the hosted weblate user where it is available, see Accès aux dépôts à partir 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 Accès aux dépôts sur les sites d’hébergement de code (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Configure Dépôt du code source so Weblate can clone the repository.
Configure incoming notifications so Weblate pulls changes soon after a push. The repository webhook or app must point to the matching Weblate hook URL, and the project must have Activer les points d’ancrage enabled.
Decide how Weblate should push translations back:
- Use Git or Mercurial and URL pour l’envoi du dépôt to push directly.
- Use a provider-specific VCS backend, such as GitHub or GitLab, to create pull or merge requests. These backends need API credentials in the Weblate settings.
Optionally set Pousser la branche when Weblate should push to a branch in the upstream repository instead of using a fork where supported.

Envoi des modifications depuis Weblate¶

Each translation component can have a push URL set up (see URL pour l’envoi du dépôt), and in that case Weblate will be able to push changes to the remote repository. Weblate can also be configured to automatically push changes on every commit; this is enabled by default, see Pousser lors du commit.

If you do not want changes to be pushed automatically, you can push manually under Repository maintenance or using the API via wlc push.

In case you do not want direct pushes by Weblate, there is support for Requêtes de fusion GitHub, Requêtes de fusion GitLab, Tirages Gitea demandés, Requêtes de fusion Pagure, Poussées Azure DevOps demandées, or Gerrit review requests reviews. You can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as Système de contrôle de version in Configuration des composants.

Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center and Bitbucket Cloud:

Configuration désirée	Système de contrôle de version	URL pour l’envoi du dépôt	Pousser la branche
Pas de push	Git	vide	vide
Pousser directement	Git	URL SSH	vide
Pousser dans une branche séparée	Git	URL SSH	Nom de la branche
Pas de push	Mercurial	vide	vide
Pousser directement	Mercurial	URL SSH	vide
Requête d’extraction GitHub à partir du fork	Requêtes de fusion GitHub	vide	vide
Requête d’extraction GitHub depuis la branche	Requêtes de fusion GitHub	SSH URL [1]	Nom de la branche
Demande de merge GitLab à partir du fork	Requêtes de fusion GitLab	vide	vide
GitLab merge request from branch	Requêtes de fusion GitLab	SSH URL [1]	Nom de la branche
Gitea merge request from fork	Tirages Gitea demandés	vide	vide
Gitea merge request from branch	Tirages Gitea demandés	SSH URL [1]	Nom de la branche
Pagure merge request from fork	Requêtes de fusion Pagure	vide	vide
Pagure merge request from branch	Requêtes de fusion Pagure	SSH URL [1]	Nom de la branche
Azure DevOps pull request from fork	Poussées Azure DevOps demandées	vide	vide
Azure DevOps pull request from branch	Poussées Azure DevOps demandées	SSH URL [1]	Nom de la branche
Gerrit review	Gerrit review requests	URL SSH	Target branch name (optional)
Bitbucket Data Center pull request from fork	Tirages demandés du Bitbucket Data Center	vide	vide
Bitbucket Data Center pull request from branch	Tirages demandés du Bitbucket Data Center	SSH URL [1]	Nom de la branche
Bitbucket Cloud pull request from fork	Requêtes de pull de Bitbucket Cloud	vide	vide
Bitbucket Cloud pull request from branch	Requêtes de pull de Bitbucket Cloud	SSH URL [1]	Nom de la branche

GitHub¶

GitHub repository access¶

There are two main approaches to accessing GitHub repositories with Weblate:

Option 1: HTTPS with personal access token

Use HTTPS authentication with a personal access token and your GitHub account. This works for both read-only access and read-write access.

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 are starting with Weblate or working with a single repository.

Option 2: SSH with a dedicated user

For setups with multiple repositories, 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, for example weblate-bot.
Add Weblate’s public SSH key to this user, see Clé SSH Weblate.
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.

Note

When using GitHub for pull requests, the Pousser la branche 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.

GitHub notifications¶

Weblate intègre une prise en charge native de GitHub.

If you are using Hosted Weblate, the recommended approach is to install the Weblate app. The app delivers GitHub notifications to Hosted Weblate, so you do not need to configure a separate Webhook in GitHub. However, it does not by itself grant Hosted Weblate write access to the repository. To push changes back, you still need to add the Hosted Weblate weblate GitHub user as a collaborator with write access, see Accès aux dépôts à partir de Hosted Weblate.

If you are not using the 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:

The Payload URL consists of your Weblate URL appended by /hooks/github/, for example for the Hosted Weblate service, this is https://hosted.weblate.org/hooks/github/.

You can leave other values at default settings. Weblate can handle both content types and consumes just the push event.

Voir aussi

Requêtes de fusion GitHub¶

Ceci ajoute un simple niveau par dessus Git en utilisant GitHub API pour permettre de pousser les modifications de traduction en tant que demandes de tirage, au lieu de pousser directement sur le dépôt.

Git pushes changes directly to a repository, while the GitHub backend creates pull requests. The latter is not needed for merely accessing Git repositories.

To create pull requests, select GitHub as Système de contrôle de version and configure GITHUB_CREDENTIALS. For GitHub.com, use api.github.com as the API host. The token must allow Weblate to read and write repository contents and create pull requests. If Weblate should fork private repositories, the token might also need administration access.

GitLab¶

GitLab repository access¶

Access via SSH is possible, see Dépôts SSH, but if you need to access more than one repository, you will hit a GitLab limitation on allowed SSH key usage because each key can be used only once.

Si Pousser la branche n’est pas défini, le projet utilisera un fork et les modifications seront poussées via le fork. Dans le cas où il est défini, les modifications sont poussées sur le dépôt amont dans la branche sélectionnée.

Il est également possible d’utiliser les jetons d’accès personnels ou du projet. Les jetons doivent avoir la fonction écriture sur le dépôt pour pouvoir pousser les modifications sur le dépôt. Le jeton d’accès au projet nécessite d’avoir le rôle Developeur pour pouvoir pousser.

The URL needs to contain a username. For a personal access token, it is the actual username: https://user:personal_access_token@gitlab.com/example/example.git. For project access tokens it can be a non-blank value: https://example:project_access_token@gitlab.com/example/example.git.

Note

The rules for using project access tokens have changed between GitLab releases, the non-blank value is the current requirement, but older versions had different expectations (project name, bot user name). Check GitLab documentation matching your version if unsure.

GitLab notifications¶

Weblate has support for GitLab hooks. Add a project webhook with destination to /hooks/gitlab/ URL on your Weblate installation, for example https://hosted.weblate.org/hooks/gitlab/.

Dépannage

Check GitLab webhook request history if webhooks are delivered.
The response payload contains information about matched components.

Voir aussi

Requêtes de fusion GitLab¶

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

There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while the GitLab backend creates a merge request.

To create merge requests, select GitLab as Système de contrôle de version and configure GITLAB_CREDENTIALS.

Gitea, Forgejo, and Codeberg¶

For Hosted Weblate repositories on Codeberg, add the hosted weblate user where write access is needed, see Accès aux dépôts à partir de Hosted Weblate.

Gitea notifications¶

Weblate has support for Gitea webhooks. Add a Gitea Webhook for Push events event with destination to /hooks/gitea/ URL on your Weblate installation, for example https://hosted.weblate.org/hooks/gitea/. This can be done in Webhooks under repository Settings.

Voir aussi

Forgejo notifications¶

Weblate has support for Forgejo webhooks. Add a Forgejo Webhook for Push events event with destination to /hooks/forgejo/ URL on your Weblate installation, for example https://hosted.weblate.org/hooks/forgejo/. This can be done in Webhooks under repository Settings.

Voir aussi

Tirages Gitea demandés¶

Ajouté dans la version 4.12.

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

To create pull requests, select Gitea as Système de contrôle de version and configure GITEA_CREDENTIALS.

Bitbucket¶

Hosted Weblate has a dedicated weblate user for Bitbucket access, see Accès aux dépôts à partir de Hosted Weblate.

To push directly, use Git or Mercurial with URL pour l’envoi du dépôt.

Bitbucket notifications¶

Weblate has support for Bitbucket webhooks. Add a webhook which triggers upon repository push, with destination to /hooks/bitbucket/ URL on your Weblate installation, for example https://hosted.weblate.org/hooks/bitbucket/.

Voir aussi

Tirages demandés du Bitbucket Data Center¶

Ajouté dans la version 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.

Avertissement

Ceci ne prend pas en charge l’API Bitbucket Cloud.

To create pull requests, select Bitbucket Data Center as Système de contrôle de version and configure BITBUCKETSERVER_CREDENTIALS.

Requêtes de pull de Bitbucket Cloud¶

Ajouté dans la version 5.8.

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

Avertissement

Ceci est différent de l’API Bitbucket Data Center.

To create pull requests, select Bitbucket Cloud as Système de contrôle de version and configure BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

Azure Repos notifications¶

Weblate has support for Azure Repos webhooks. Add a webhook for Code pushed event with destination to /hooks/azure/ URL on your Weblate installation, for example https://hosted.weblate.org/hooks/azure/. This can be done in Service hooks under Project settings.

Voir aussi

Poussées Azure DevOps demandées¶

Ceci ajoute un niveau supplémentaire par dessus Git en utilisant Azure DevOps API pour permettre de pousser les modifications des traductions comme des requêtes pour pousser sur le dépôt, au lieu de les pousser directement.

Git pushes changes directly to a repository, while the Azure DevOps backend creates pull requests. The latter is not needed for merely accessing Git repositories.

To create pull requests, select Azure DevOps as Système de contrôle de version and configure AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Pagure notifications¶

Weblate has support for Pagure hooks. Add a webhook with destination to /hooks/pagure/ URL on your Weblate installation, for example https://hosted.weblate.org/hooks/pagure/. This can be done in Activate Web-hooks under Project options:

Voir aussi

Requêtes de fusion Pagure¶

Ajouté dans la version 4.3.2.

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

To create merge requests, select Pagure as Système de contrôle de version and configure PAGURE_CREDENTIALS.

Other workflows¶

Gitee notifications¶

Weblate has support for Gitee webhooks. Add a WebHook for Push event with destination to /hooks/gitee/ URL on your Weblate installation, for example https://hosted.weblate.org/hooks/gitee/. This can be done in WebHooks under repository Management.

Voir aussi

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 Pousser la branche setting selects the target branch for the Gerrit review. Leave it empty to use Branche du dépôt. 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.

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.

Docker credentials¶

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