Code hosting integrations¶
Weblate s’intègre aux sites d’hébergement de code à plusieurs niveaux : accès au dépôt, réception des notifications et renvoi des traductions. La configuration exacte dépend du fait que vous utilisiez Weblate hébergé ou que vous exploitiez votre propre instance Weblate, ainsi que de la manière dont Weblate doit procéder : en envoyant directement les modifications ou en créant des demandes de modification.
Utilisez cette page comme une liste de contrôle destinée aux développeurs. Les pages de configuration individuelles restent la référence officielle en matière de syntaxe de configuration.
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.
Pour une installation Weblate auto-hébergée, créez un utilisateur dédié à l’hébergement du code et accordez-lui l’accès à l’aide de la clé SSH de Weblate ou d’un jeton HTTPS ; voir 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.
Configurez les notifications entrantes afin que Weblate récupère les modifications peu après leur publication. Le webhook ou l’application du dépôt doit pointer vers l’URL de hook Weblate correspondante, et l’option Activer les points d’ancrage doit être activée pour le projet.
Choisissez la manière dont Weblate doit renvoyer les traductions :
Utilisez Git ou Mercurial et URL pour l’envoi du dépôt pour effectuer un push directement.
Utilisez un backend VCS spécifique à un fournisseur, tel que GitHub ou GitLab, pour créer des demandes de pull ou de fusion. Ces backends nécessitent des identifiants API dans les paramètres de Weblate.
Vous pouvez définir Pousser la branche si vous souhaitez que Weblate effectue un push vers une branche du dépôt en amont plutôt que d’utiliser une fourche, lorsque cela est pris en charge.
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 |
|||
|---|---|---|---|
Pas de push |
vide |
vide |
|
Pousser directement |
URL SSH |
vide |
|
Pousser dans une branche séparée |
URL SSH |
Nom de la branche |
|
Pas de push |
vide |
vide |
|
Pousser directement |
URL SSH |
vide |
|
Requête d’extraction GitHub à partir du fork |
vide |
vide |
|
Requête d’extraction GitHub depuis la branche |
SSH URL [1] |
Nom de la branche |
|
Demande de merge GitLab à partir du fork |
vide |
vide |
|
GitLab merge request from branch |
SSH URL [1] |
Nom de la branche |
|
Gitea merge request from fork |
vide |
vide |
|
Gitea merge request from branch |
SSH URL [1] |
Nom de la branche |
|
Pagure merge request from fork |
vide |
vide |
|
Pagure merge request from branch |
SSH URL [1] |
Nom de la branche |
|
Azure DevOps pull request from fork |
vide |
vide |
|
Azure DevOps pull request from branch |
SSH URL [1] |
Nom de la branche |
|
Gerrit review |
URL SSH |
Target branch name (optional) |
|
Bitbucket Data Center pull request from fork |
vide |
vide |
|
Bitbucket Data Center pull request from branch |
SSH URL [1] |
Nom de la branche |
|
Bitbucket Cloud pull request from fork |
vide |
vide |
|
Bitbucket Cloud pull request from branch |
SSH URL [1] |
Nom de la branche |
GitHub¶
GitHub repository access¶
HTTPS with personal access token¶
For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in Dépôt du code source.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.
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.
SSH with a dedicated user¶
For setups with multiple repositories, use SSH access with a dedicated code
hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the
user access to the repositories, and use SSH URLs in Dépôt du code source,
for example git@example.com:group/project.git.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places.
This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL.
On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Accès aux dépôts à partir de Hosted Weblate.
For GitHub, create a dedicated user, for example weblate-bot, and use
GitHub SSH URLs for your repositories, for example
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.
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¶
HTTPS with personal or project access token¶
For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in Dépôt du code source.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.
For GitLab, the token needs write_repository scope to be able to push changes to the repository. The project access token requires Developer role for pushing.
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.
SSH with a dedicated user¶
For setups with multiple repositories, use SSH access with a dedicated code
hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the
user access to the repositories, and use SSH URLs in Dépôt du code source,
for example git@example.com:group/project.git.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places.
This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL.
On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Accès aux dépôts à partir de Hosted Weblate.
For GitLab, create a dedicated user and use GitLab SSH URLs, for example
git@gitlab.com:group/project.git.
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.
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.
The Pousser la branche configuration affects where Weblate pushes changes before opening the merge request. If it is not set, the project is forked and changes are pushed through a fork. If it is set, changes are pushed to the upstream repository and chosen branch.
Gitea, Forgejo, and Codeberg¶
Gitea, Forgejo, and Codeberg repository access¶
HTTPS with an access token¶
For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in Dépôt du code source.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.
SSH with a dedicated user¶
For setups with multiple repositories, use SSH access with a dedicated code
hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the
user access to the repositories, and use SSH URLs in Dépôt du code source,
for example git@example.com:group/project.git.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places.
This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL.
On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Accès aux dépôts à partir de Hosted Weblate.
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.
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.
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.
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 Gitea backend creates pull requests.
To create pull requests, select Gitea as
Système de contrôle de version and configure GITEA_CREDENTIALS.
Bitbucket¶
Bitbucket repository access¶
HTTPS with an access token¶
For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in Dépôt du code source.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.
SSH with a dedicated user¶
For setups with multiple repositories, use SSH access with a dedicated code
hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the
user access to the repositories, and use SSH URLs in Dépôt du code source,
for example git@example.com:group/project.git.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places.
This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL.
On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Accès aux dépôts à partir de Hosted Weblate.
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/.
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.
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 Bitbucket Data Center backend creates a pull request.
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.
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 Bitbucket Cloud backend creates a pull request.
To create pull requests, select Bitbucket Cloud as
Système de contrôle de version and configure BITBUCKETCLOUD_CREDENTIALS.
Azure DevOps¶
Azure Repos repository access¶
HTTPS with an access token¶
For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in Dépôt du code source.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.
Use the HTTPS clone URL shown by Azure Repos for the repository.
SSH with a dedicated user¶
For setups with multiple repositories, use SSH access with a dedicated code
hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the
user access to the repositories, and use SSH URLs in Dépôt du code source,
for example git@example.com:group/project.git.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places.
This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL.
On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Accès aux dépôts à partir de Hosted Weblate.
Use the SSH URL shown by Azure Repos for the repository.
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.
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 repository access¶
HTTPS with an access token¶
For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in Dépôt du code source.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.
SSH with a dedicated user¶
For setups with multiple repositories, use SSH access with a dedicated code
hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the
user access to the repositories, and use SSH URLs in Dépôt du code source,
for example git@example.com:group/project.git.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places.
This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL.
On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Accès aux dépôts à partir de Hosted Weblate.
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:
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.
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 Pagure backend creates a merge request.
To create merge requests, select Pagure as
Système de contrôle de version and configure PAGURE_CREDENTIALS.
Other workflows¶
Gitee repository access¶
HTTPS with an access token¶
For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in Dépôt du code source.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.
SSH with a dedicated user¶
For setups with multiple repositories, use SSH access with a dedicated code
hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the
user access to the repositories, and use SSH URLs in Dépôt du code source,
for example git@example.com:group/project.git.
Configure URL pour l’envoi du dépôt only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Envoi des modifications depuis Weblate.
This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places.
This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL.
On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Accès aux dépôts à partir de Hosted Weblate.
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.
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. 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.
Docker credentials¶
For Docker installations, code hosting API credentials can also be provided through environment variables, see Code hosting sites credentials.