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, Tirages GitHub demandés, Gerrit, Subversion, Requêtes de pull de Bitbucket Cloud, Poussées Bitbucket Server demandées, and Poussées Azure DevOps demandées) and Mercurial as version control back-ends.
Accès aux dépôts¶
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.
Accès aux dépôts à partir de 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).
Accès aux dépôts sur les sites d’hébergement de code (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 Clé SSH Weblate). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of a SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see Dépôts SSH).
Indication
Sur Hosted Weblate, ceci est préconfiguré pour la plupart des sites publics, voir Accès aux dépôts à partir de Hosted Weblate.
Dépôts SSH¶
The most frequently used method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Clé SSH Weblate) to access the upstream repository this way.
Avertissement
Dans GitHub, chaque clé ne peut être utilisée qu’une seule fois, voir Dépôts GitHub et Accès aux dépôts à partir de 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 Vérification des clés SSH de l’hôte).
Si une correction est nécessaire, voici ce que vous devez faire à partir de l’interface administrateur Weblate :
Clé SSH Weblate¶
Modifié dans la version 4.17: Weblate génère dorénavant les clés SSH RSA et Ed25519. Il est recommandé d’utiliser Ed25519 pour les nouvelles configurations.
La clé publique Weblate est visible pour tous les utilisateurs en affichant la page A propos.
Les administrateurs peuvent générer ou afficher la clé publique utilisée actuellement par Weblate pour la connexion (de clé SSH) sur la page de l’interface administrateur.
Note
La clé privée SSH correspondante ne peut pas avoir actuellement de mot de passe donc assurez-vous qu’elle soit bien protégée.
Indication
Faites une sauvegarde des clés SSH privées générées de Weblate.
Vérification des clés SSH de l’hôte¶
Les clés SSH de l’hôte sont automatiquement stockées par Weblate lors du premier acccès et il s’en souvient donc pour les utilisations suivantes.
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:
Se connecter aux anciens serveurs SSH¶
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.
Pour la plupart des utilisateurs, cette modification devrait être invisible et il n’est pas nécessaire de remplacer les clés ssh-rsa. OpenSSH prend en charge les signatures RFC8332 RSA/SHA-256/512 depuis la version 7.2 et les clés ssh-rsa existantes utiliseront automatiquement l’algorithme le plus puissant lorsque cela sera possible.
L’incompatibilité est plus probable avec la connexion à des implémentations de SSH plus anciennes et qui n’ont pas été mises à niveau ou qui n’ont pas suivi de près les améliorations du protocole SSH. La connexion SSH à un tel serveur échouera avec :
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¶
L’accès via SSH est possible (voir Dépôts SSH), mais si vous voulez accéder à plusieurs dépôts, vous atteindrez une limitation de GitHub sur l’utilisation permise de la clé SSH (chaque clé ne pouvant être utilisée qu’une fois).
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.
Pour de plus petits déploiements, utiliser l’authentification HTTPS avec un jeton d’accès personnel et votre compte GitHub, voir Creating an access token for command-line use.
Pour les configurations plus importantes il vaut mieux créer un utilisateur dédié pour Weblate, lui assigner la clé publique SSH générée par Weblate (voir Clé SSH Weblate) et lui attribuer le droit d’accès à tous les dépôts que vous souhaitez traduire. Cette approche est aussi utilisée dans Hosted Weblate, où l’utilisateur dédié est weblate.
Voir aussi
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¶
Si vous devez accéder aux dépôts VCS par HTTP ou HTTPS en utilisant un serveur proxy, configurez le VCS pour qu’il puisse l’utiliser.
Ceci peut être fait en utilisant les variables d’environnement http_proxy, https_proxy, et all_proxy (tel que décrit dans la documentation cURL) ou en les forçant dans la configuration VCS, par exemple :
git config --global http.proxy http://user:password@proxy.example.com:80
Note
La configuration du proxy doit être faite avec un utilisateur qui exécute Weblate (voir aussi Permissions du système de fichiers) et avec HOME=$DATA_DIR/home (voir DATA_DIR), sinon Git executé par Weblate ne l’utilisera pas.
Voir aussi
Git¶
Indication
Weblate needs Git 2.28 or newer.
Voir aussi
Voir Accès aux dépôts pour des informations sur la façon d’accéder aux différents types de dépôts.
Git avec force push¶
Cela se comporte exactement comme Git lui-même, la seule différence étant que les poussées sont toujours forcées. Ceci est prévu dans le cas uniquement où vous utilisez un dépôt séparé pour les traductions.
Avertissement
A utiliser avec précaution car vous pourriez perdre des validations dans le dépôt amont.
Personnalisation de la configuration Git¶
Weblate utilise toutes les commandes VCS avec HOME=$DATA_DIR/home (voir DATA_DIR), c’est pourquoi pour modifier la configuration de l’utilisateur il faut être dans DATA_DIR/home/.git.
Assistants distants Git¶
Vous pouvez aussi utiliser Git remote helpers pour prendre en charge d’autres systèmes de contrôle de version supplémentaires, mais attendez-vous à avoir à déboguer les problèmes éventuels.
Actuellement, les assistants pour Bazaar et Mercurial sont disponibles avec des dépôts séparés sur GitHub : git-remote-hg et git-remote-bzr. Téléchargez-les manuellement et mettez à jour votre chemin de recherche (par exemple ~/bin). Assurez-vous que les systèmes de contrôle des versions sont installés.
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
L’inconvénient d’utiliser des assistants Git à distance est par exemple avec Mercurial, que l’assistant distant crée quelquefois un nouveau conseil quand vous poussez à nouveau les modifications.
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 pousse les modifications directement sur un depôt, alors que Requêtes de fusion GitHub crée des demandes de tirage. Ces dernières ne sont pas nécessaires pour accéder à la plupart des dépôts Git.
Vous devez configurer vos informations de connexion à l’API ( GITHUB_CREDENTIALS) dans les paramètres Weblate pour que cela fonctionne. Une fois configuré, vous verrez l’option GitHub quand vous sélectionnerez Système de contrôle de version.
Voir aussi
Requêtes de fusion GitLab¶
Ceci ajoute un simple niveau par dessus Git en utilisant GitLab API pour permettre de pousser les modifications de traduction en tant que demandes de fusion au lieu de pousser directement sur le dépôt.
Ceci n’est pas nécessaire pour accéder aux dépôts Git, le Git ordinaire fonctionne de la même manière, la seule différence réside dans la façon dont on gère la poussée sur un dépôt. Avec Git les modifications sont poussées directement sur le dépôt alors que Requêtes de fusion GitLab crée une demande de fusion.
Vous devez configurer vos informations de connexion à l’API ( GITLAB_CREDENTIALS) dans les paramètres Weblate pour que cela fonctionne. Une fois configuré, vous verrez l’option GitLab quand vous sélectionnerez Système de contrôle de version.
Voir aussi
Tirages GitHub demandés¶
Ajouté dans la version 4.12.
Ceci ajoute un simple niveau par dessus Git en utilisant Gitea API pour permettre de pousser les modifications de traduction en tant que requêtes de tirage au lieu de pousser directement sur le dépôt.
Il n’est pas nécessaire d’utiliser ceci pour accéder aux dépôts Git, le simple Git fonctionne de la même manière, la seule différence est dans la manière de pousser sur le dépôt. Avec Git les modifications sont poussées directement sur le dépôt, alors que Tirages GitHub demandés crée des demandes de tirage.
Vous devez configurer les données de connexion à l’API ( GITEA_CREDENTIALS) dans les paramètres de Weblate pour que cela fonctionne. Une fois configuré, vous verrez une option Gitea quand vous sélectionnerez Système de contrôle de version.
Voir aussi
Poussées Bitbucket Server demandées¶
Ajouté dans la version 4.16.
Ceci ajoute simplement un niveau par dessus Git en utilisant Bitbucket Server API pour permettre de pousser les modifcations de traduction en tant que demandes de tirage, au lieu de les pousser directement sur le dépôt.
Avertissement
Ceci ne prend pas en charge l’API Bitbucket Cloud.
Il n’est pas nécessaire d’utiliser cela pour accéder aux dépôts Git, d’ordinaire Git fonctionne de la même manière, la seule différence réside dans la façon de pousser sur un dépôt. Avec Git, les modifications sont poussées directement sur le dépôt, tandis qu’avec Poussées Bitbucket Server demandées, une demande de tirage est créée.
Vous devez configurer les informations de connexion à l’API (BITBUCKETSERVER_CREDENTIALS) dans les paramètres de Weblate pour que cela fonctionne. Une fois configuré, vous pourrez voir une option Bitbucket Server quand vous sélectionnerez Système de contrôle de version.
Requêtes de pull de Bitbucket Cloud¶
Ajouté dans la version 5.8.
This just 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
This is different from Bitbucket Server 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 Requêtes de pull de Bitbucket Cloud creates pull request.
You need to configure API credentials (BITBUCKETCLOUD_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Bitbucket Cloud option when selecting Système de contrôle de version.
Requêtes de fusion Pagure¶
Ajouté dans la version 4.3.2.
Ajoute un niveau élémentaire par-dessus Git en utilisant Pagure API pour permettre de pousser les modifications de traductions en tant que requêtes de fusion au lieu de les pousser directement sur le dépôt.
Il n’est pas utile d’utiliser ceci pour accéder aux dépôts Git, d’ordinaire Git fonctionne de la même façon, mais la seule différence réside dans la manière de pousser sur un dépôt. Avecles modifications Git sont poussées directement sur le dépôt, alors que Requêtes de fusion Pagure crée une demande de fusion.
Pour que cela fonctionne, vous devez configure les paramètres de connexion à l’API ( PAGURE_CREDENTIALS `) dans les paramètres Weblate. Une fois configuré, vous verrez l'option :guilabel:`Pagure si vous séletionnez Système de contrôle de version.
Voir aussi
Gerrit¶
Ajoute une simple surcouche à Git en utilisant l’ouil git-review pour permettre de pousser les modifications de traduction en tant que demandes de relecture Gerrit, au lieu de les pousser directement dans le dépôt.
La documentation Gerrit contient les détails de la configuration nécessaire pour configurer de tels dépôts.
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 pousse les modifications directement dans un répertoire, alors que Poussées Azure DevOps demandées crée des demandes de récupération. Ces dernières ne sont pas nécessaires pour accéder à la plupart des dépôts Git.
Vous devez configurer les données de connexion API (AZURE_DEVOPS_CREDENTIALS) dans les paramètres Weblate pour que cela fonctionne. Une fois configuré vous verrez une option Azure DevOps quand vous sélectionnerez Système de contrôle de version.
Voir aussi
Mercurial¶
Mercurial et un autre VCS que vous pouvez directement utiliser dans Weblate.
Note
Cela devrait fonctionner avec n’importe quelle version de Mercurial, mais il existe quelques fois des modifications incompatibles de l’interface en mode ligne de commande qui cassent l’intégration de Weblate.
Voir aussi
Voir Accès aux dépôts pour des informations sur la façon d’accéder aux différents types de dépôts.
Subversion¶
Weblate utilise git-svn pour interagir avec les répertoires subversion . C’est un script Perl qui permet aux subversions d’être utilisés par un client Git, autorisant les utilisateurs à maintenir un clone complet du dépôt interne et à valider localement.
Note
Weblate essaie de trouver la structure du dépôt Subversion automatiquement - il supporte à la fois les URL directes pour les branches ou les dépôts avec la structure standard (branches/, balises/ et tronc/). Vous trouverez plus d’informations à ce sujet dans la documentation git-svn. Si votre dépôt n’a pas la structure standard et que vous rencontrez des erreurs, essayez d’inclure le nom de la branche dans l’URL du dépôt et de laisser la branche à vide.
Identifiants pour Subversion¶
Weblate suppose que vous avez accepté le certificat du serveur (et vos données de connexion si nécessaire). Il va les insérer dans le répertoire DATA_DIR. Acceptez le certificat en utilisant svn une fois avec la variable d’environnement HOME initialisée avec 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
Fichiers locaux¶
Indication
Il repose sur Git. Ce qui nécessite que Git soit installé et vous permet de basculer sur l’utilisation de Git en natif avec l’historique complet de vos traductions.
Weblate peut également travailler sans VCS distant. Les traductions initiales sont importées par téléversement. Ensuite vous pouvez remplacer les fichiers individuels par des téléversements, ou ajouter les chaînes traduites directement à partir de Weblate (disponible actuellement que pour les traductions monolingues).
Weblate crée pour vous en arrière plan un dépôt Git et toutes les modifications sont tracées. Si ultérieurement vous décidez d’utiliser un VCS pour stocker les traductions, vous disposez déjà alors d’un dépôt sur lequel Weblate peut réaliser votre intégration.