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 Gitea demandés, Gerrit, Subversion, Requêtes de pull de Bitbucket Cloud, Tirages demandés du Bitbucket Data Center, 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, …)¶
L’accès aux dépôts pour les sites qui hébergent le code se fait typiquement en créant un utilisateur dédié qui est associé à une clé SSH Weblate (voir Clé SSH Weblate). De cette manière vous associez une clé SSH Weblate à un utilisateur unique (les plateformes forcent souvent l’utilisation unique d’une clé SSH) et vous donnez à cet utilisateur l’accès au dépôt. Vous pouvez ensuite utiliser l’URL SSH pour accéder au dépôt (voir 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¶
La manière la plus fréquente utilisée pour accéder aux dépôts privés est basée sur SSH. Autorisez la clé SSH Weblate publique (voir Clé SSH Weblate) pour accéder au dépôt amont de cette façon.
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 enregistre aussi l’empreinte de la clé hôte lors de la première connexion, et refuse les connexions à l’hôte si elle est modifiée par la suite (voir 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.
Dans le cas où vous souhaitez vérifier la signature principale de la clé avant de vous connecter au ajoutez les clés SSH dde l’hôte dépôt, n 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. Vérifiez que sa signature principale correspond au serveur que vous avez ajouté.
Les clés ajoutées avec des signatures principales sont affichées dans le message de confirmation :
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
Nous recommandons d’activer RSA/SHA1 seulement comme mesure paliative jusqu’à ce que les anciennes implémentations puissent être mises à jour ou reconfigurées avec un autre type de clé (tel que ECDSA ou 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¶
Partager une configuration du dépôt entre différents composants en se référant à son emplacement tel que weblate://project/component dans les autres composants (liés). De cette manière, ils utilisent les paramètres du dépôt VCS du composant principal (référencé).
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.
Modifié dans la version 5.10.2: Weblate uses proactive authentication with Git 2.46.0 and newer when HTTP credentials are supplied.
This makes it possible to access Azure DevOps repositories and makes access to authenticated repositories faster.
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 nécessite Git 2.28 ou plus récent.
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::https://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 Gitea 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 Gitea 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
Tirages demandés du Bitbucket Data Center¶
Ajouté dans la version 4.16.
This just 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.
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 Tirages demandés du Bitbucket Data Center, une demande de tirage est créée.
You need to configure API credentials (BITBUCKETSERVER_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Bitbucket Data Center option when selecting 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
Ceci est différent de l’API Bitbucket Data Center.
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 Requêtes de pull de Bitbucket Cloud, une demande de tirage est créée.
Vous devez configurer les informations de connexion à l’API (BITBUCKETCLOUD_CREDENTIALS) dans les paramètres de Weblate pour que cela fonctionne. Une fois configuré, vous pourrez voir une option Bitbucket Cloud quand vous sélectionnerez 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 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.