Intégration avec le système de contrôle de versions#

Weblate currently supports Git (with extended support for Requêtes de fusion GitHub, Requêtes de fusion GitLab, Gitea pull requests, Gerrit, Subversion, Bitbucket Server pull requests, and Azure DevOps pull requests) and Mercurial as version control back-ends.

Accessing repositories#

The VCS repository you want to use has to be accessible to Weblate. With a publicly available repository you just need to enter the correct URL (for example https://github.com/WeblateOrg/weblate.git), but for private repositories or for push URLs the setup is more complex and requires authentication.

Accessing repositories from Hosted Weblate#

For Hosted Weblate, there is a dedicated push user registered on GitHub, Bitbucket, Codeberg, and GitLab (with the username weblate, e-mail hosted@weblate.org, and a name or profile description Weblate push user).

Indication

There can be more Weblate users on the platforms, designated for other Weblate instances. Searching by e-mail hosted@weblate.org is recommended to find the correct user for Hosted Weblate.

You need to add this user as a collaborator and give it appropriate permissions to your repository (read-only is okay for cloning, write is required for pushing). Depending on the service and your organization’s settings, this happens immediately, or requires confirmation on the Weblate side.

The weblate user on GitHub accepts invitations automatically within five minutes. Manual processing might be needed on the other services, so please be patient.

Once the weblate user is added to your repository, you can configure Dépôt du code source and URL pour l’envoi du dépôt using the SSH protocol (for example git@github.com:WeblateOrg/weblate.git).

Accessing repositories on code hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)#

Accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Weblate SSH key). This way you associate Weblate SSH key with a single user (this of frequently enforced by the platform) and grant this user access to the repository. You can then use SSH URL to access the repository (see SSH repositories).

Indication

On a Hosted Weblate, this is pre-cofigured for most of the public sites, please see Accessing repositories from Hosted Weblate.

SSH repositories#

The most frequently used method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Weblate SSH key) to access the upstream repository this way.

Avertissement

On GitHub, each key can only be used once, see Dépôts GitHub and Accessing repositories from Hosted Weblate.

Weblate also stores the host key fingerprint upon first connection, and fails to connect to the host should it be changed later (see Verifying SSH host keys).

In case adjustment is needed, do so from the Weblate admin interface:

_images/ssh-keys.webp

Weblate SSH key#

Modifié dans la version 4.17: Weblate now generates both RSA and Ed25519 SSH keys. Using Ed25519 is recommended for new setups.

The Weblate public key is visible to all users browsing the About page.

Admins can generate or display the public key currently used by Weblate in the connection (from SSH keys) on the admin interface landing page.

Note

The corresponding private SSH key can not currently have a password, so ensure it is well protected.

Indication

Make a backup of the generated private Weblate SSH key.

Verifying SSH host keys#

Weblate automatically stores the SSH host keys on first access and remembers them for further use.

In case you want to verify the key fingerprint before connecting to the repository, add the SSH host keys of the servers you are going to access in Add host key, from the same section of the admin interface. Enter the hostname you are going to access (e.g. gitlab.com), and press Submit. Verify its fingerprint matches the server you added.

The added keys with fingerprints are shown in the confirmation message:

_images/ssh-keys-added.webp

Connecting to legacy SSH servers#

Recent OpenSSH releases (for example the one used in Weblate Docker container) disable RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K.

For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.

Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. The SSH connection to such server will fail with:

no matching host key type found. Their offer: ssh-rsa

For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow connection and/or user authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms options. For example, the following stanza in DATA_DIR/ssh/config will enable RSA/SHA1 for host and user authentication for a single destination host:

Host legacy-host
   HostkeyAlgorithms +ssh-rsa
   PubkeyAcceptedAlgorithms +ssh-rsa

We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).

Dépôts GitHub#

Access via SSH is possible (see SSH repositories), but in case you need to access more than one repository, you will hit a GitHub limitation on allowed SSH key usage (since each key can be used only once).

In case the Pousser la branche is not set, the project is forked and changes pushed through a fork. In case it is set, changes are pushed to the upstream repository and chosen branch.

For smaller deployments, use HTTPS authentication with a personal access token and your GitHub account, see Creating an access token for command-line use.

For bigger setups, it is usually better to create a dedicated user for Weblate, assign it the public SSH key generated in Weblate (see Weblate SSH key) and grant it access to all the repositories you want to translate. This approach is also used for Hosted Weblate, there is dedicated weblate user for that.

URLs internes de Weblate#

Share one repository setup between different components by referring to its placement as weblate://project/component in other(linked) components. This way linked components use the VCS repository configuration of the main(referenced) component.

Avertissement

La suppression du composant principal entraîne la suppression des composants liés.

Weblate ajuste automatiquement l’URL du dépôt lors de la création d’un composant s’il trouve un composant avec une configuration de dépôt correspondante. Vous pouvez la remplacer dans la dernière étape de la configuration.

Raisons de l’utiliser :

  • Économise de l’espace disque sur le serveur, le dépôt n’est stocké qu’une seule fois.

  • Rend les mises à jour plus rapides, un seul dépôt est mis à jour.

  • Il n’y a qu’un seul dépôt exporté avec les traductions Weblate (voir Exportateur Git).

  • Certains greffons peuvent fonctionner sur plusieurs composants partageant un référentiel, par exemple Squasher les commits Git.

Dépôts HTTPS#

Pour accéder à des dépôts protégés en HTTPS, ajoutez le nom d’utilisateur et le mot de passe dans l’URL. Ne vous inquiétez pas, Weblate supprimera ces informations lorsque l’URL sera montrée aux utilisateurs (s’ils sont autorisés à voir l’URL du dépôt).

Par exemple, l’ajout de l’authentification dans l’URL de GitHub peut ressembler à : https://user:your_access_token@github.com/WeblateOrg/weblate.git.

Note

Si votre nom d’utilisateur ou votre mot de passe contient des caractères spéciaux, ceux-ci doivent être codés en URL, par exemple https://user%40example.com:%24password%23@bitbucket.org/….

Utilisation d’un proxy#

If you need to access HTTP/HTTPS VCS repositories using a proxy server, configure the VCS to use it.

This can be done using the http_proxy, https_proxy, and all_proxy environment variables, (as described in the cURL documentation) or by enforcing it in the VCS configuration, for example:

git config --global http.proxy http://user:password@proxy.example.com:80

Note

The proxy configuration needs to be done under user running Weblate (see also Permissions du système de fichiers) and with HOME=$DATA_DIR/home (see DATA_DIR), otherwise Git executed by Weblate will not use it.

Git#

Indication

Weblate nécessite Git 2.12 ou plus récent.

Voir aussi

Voir Accessing repositories pour des informations sur la façon d’accéder aux différents types de dépôts.

Git avec force push#

This behaves exactly like Git itself, the only difference being that it always force pushes. This is intended only in the case of using a separate repository for translations.

Avertissement

Use with caution, as this easily leads to lost commits in your upstream repository.

Personnalisation de la configuration Git#

Weblate invokes all VCS commands with HOME=$DATA_DIR/home (see DATA_DIR), therefore editing the user configuration needs to be done in DATA_DIR/home/.git.

Assistants distants Git#

You can also use Git remote helpers for additionally supporting other version control systems, but be prepared to debug problems this may lead to.

At this time, helpers for Bazaar and Mercurial are available within separate repositories on GitHub: git-remote-hg and git-remote-bzr. Download them manually and put somewhere in your search path (for example ~/bin). Make sure you have the corresponding version control systems installed.

Une fois que vous les avez installés, ces commandes peuvent être utilisées pour spécifier un dépôt dans Weblate.

Pour cloner le projet gnuhello depuis Launchpad en utilisant Bazaar:

bzr::lp:gnuhello

Pour le dépôt hello de selenic.com en utilisant Mercurial:

hg::http://selenic.com/repo/hello

Avertissement

The inconvenience of using Git remote helpers is for example with Mercurial, the remote helper sometimes creates a new tip when pushing changes back.

Requêtes de fusion GitHub#

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 pushes changes directly to a repository, while Requêtes de fusion GitHub creates pull requests. The latter is not needed for merely accessing Git repositories.

You need to configure API credentials (GITHUB_CREDENTIALS) in the Weblate settings to make this work. Once configured, you will see a GitHub option when selecting Système de contrôle de version.

Requêtes de fusion GitLab#

This just 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 Requêtes de fusion GitLab creates merge request.

You need to configure API credentials (GITLAB_CREDENTIALS) in the Weblate settings to make this work. Once configured, you will see a GitLab option when selecting Système de contrôle de version.

Gitea pull requests#

Nouveau dans la version 4.12.

This just 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 Gitea pull requests creates pull requests.

You need to configure API credentials (GITEA_CREDENTIALS) in the Weblate settings to make this work. Once configured, you will see a Gitea option when selecting Système de contrôle de version.

Bitbucket Server pull requests#

Nouveau dans la version 4.16.

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

Avertissement

This does not support Bitbucket Cloud API.

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 Bitbucket Server pull requests creates pull request.

You need to configure API credentials (BITBUCKETSERVER_CREDENTIALS) in the Weblate settings to make this work. Once configured, you will see a Bitbucket Server option when selecting Système de contrôle de version.

Requêtes de fusion Pagure#

Nouveau dans la version 4.3.2.

This just 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 Requêtes de fusion Pagure creates merge request.

You need to configure API credentials (PAGURE_CREDENTIALS) in the Weblate settings to make this work. Once configured, you will see a Pagure option when selecting Système de contrôle de version.

Gerrit#

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 Gerrit documentation has the details on the configuration necessary to set up such repositories.

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 pushes changes directly to a repository, while Azure DevOps pull requests creates pull requests. The latter is not needed for merely accessing Git repositories.

You need to configure API credentials (AZURE_DEVOPS_CREDENTIALS) in the Weblate settings to make this work. Once configured, you will see a Azure DevOps option when selecting Système de contrôle de version.

Mercurial#

Mercurial is another VCS you can use directly in Weblate.

Note

It should work with any Mercurial version, but there are sometimes incompatible changes to the command-line interface which breaks Weblate integration.

Voir aussi

Voir Accessing repositories pour des informations sur la façon d’accéder aux différents types de dépôts.

Subversion#

Weblate uses git-svn to interact with subversion repositories. It is a Perl script that lets subversion be used by a Git client, enabling users to maintain a full clone of the internal repository and commit locally.

Note

Weblate tries to detect Subversion repository layout automatically - it supports both direct URLs for branch or repositories with standard layout (branches/, tags/ and trunk/). More info about this is to be found in the git-svn documentation. If your repository does not have a standard layout and you encounter errors, try including the branch name in the repository URL and leaving branch empty.

Identifiants pour Subversion#

Weblate expects you to have accepted the certificate up-front (and your credentials if needed). It will look to insert them into the DATA_DIR directory. Accept the certificate by using svn once with the $HOME environment variable set to the DATA_DIR:

# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example

Voir aussi

DATA_DIR

Fichiers locaux#

Indication

Underneath, this uses Git. It requires Git installed and allows you to switch to using Git natively with full history of your translations.

Weblate can also operate without a remote VCS. The initial translations are imported by uploading them. Later you can replace individual files by file upload, or add translation strings directly from Weblate (currently available only for monolingual translations).

In the background Weblate creates a Git repository for you and all changes are tracked in. In case you later decide to use a VCS to store the translations, you already have a repository within Weblate can base your integration on.