Intégration avec le système de contrôle de versions¶
Weblate reconnait actuellement Git (avec un suppor étendu with extended pour 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, et Poussées Azure DevOps demandées) et Mercurial comme serveurs de contrôle de version.
Accès aux dépôts¶
Le dépôt VCS que vous voulez utiliser doit être accessible à Weblate. Avec un dépôt accessible publiquement il vous suffit de saisir l’URL correcte (par exemple https://github.com/WeblateOrg/weblate.git), mais pour les dépôts privés ou pour les URLs de push, le paramètrage est plus complexe et nécessite une authentification.
Accès aux dépôts à partir de Hosted Weblate¶
Note
This section applies only to Hosted Weblate (hosted.weblate.org). If you are running your own self-hosted Weblate instance, please see the next section instead.
Pour Hosted Weblate, il existe un utilisateur de push dédié enregistré sur GitHub, Bitbucket, Codeberg, et GitLab (avec le nom de l’utilisateur weblate, l’adresse courriel hosted@weblate.org, et un nom ou une description du profil Utilisateur de push Weblate).
Indication
Il peut y avoir plus d’utilisateurs Weblate sur les plateformes, associés à d’autres instances Weblate. Pour trouver le bon utilisateur de Hosted Weblate il est recommandé de chercher en fonction de l’adresse courriel hosted@weblate.org.
Vous devez ajouter cet utilisateur en tant que collaborateur et lui donner les droits appropriés sur votre dépôt (la lecture seule convient pour recopier mais les droits en écriture sont nécessaires pour pouvoir pousser sur le dépôt). En fonction du service et des paramètres de votre organisation, cela peut être immédiat ou nécessiter une confirmation du côté Weblate.
L’utilisateur weblate de GitHub reçoit les invitations automatiquement dans les cinq minutes. Un traitement manuel peut être nécessaire avec les autres services, donc soyez patient.
Une fois que l’utilisateur weblate est ajouté à votre dépôt, vous pouvez configurer Dépôt du code source et URL pour l’envoi du dépôt en utilisant le protocole SSH (par exemple 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, …)¶
Note
This section applies to self-hosted Weblate instances. If you are using Hosted Weblate (hosted.weblate.org), see Accès aux dépôts à partir de Hosted Weblate instead.
For self-hosted Weblate, 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).
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¶
Les versions récentes de OpenSSH (pa exemple celle utilisée dans le conteneur Weblate Docker) désactivent les signatures RSA qui utilisent l’algorithme de hachage SHA-1 par défaut. Cette modification a été faite car l’algorithme de hachage SHA-1 peut être craqué cryptographiquement, et il est possible de créer des collisions de préfixe de hachage choisis pour moins de 50K USD.
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
Pour ces cas il peut être nécessaire de réactiver sélectivement RSA/SHA1 pour autoriser la connexion et (ou) l’authentification de l’utilisateur via les options HostkeyAlgorithms et PubkeyAcceptedAlgorithms. Par exemple la phrase suivante dans DATA_DIR/ssh/config va activer RSA/SHA1 pour l’hôte et l’authentification de l’utilisateur pour un hôte de destination unique :
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¶
There are two main approaches to accessing GitHub repositories with Weblate:
Option 1: HTTPS with Personal Access Token (simpler for getting started)
Use HTTPS authentication with a personal access token and your GitHub account. This works for both read-only access (cloning) and read-write access (pushing changes or creating pull requests).
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’re starting with Weblate or working with a single repository.
Option 2: SSH with Dedicated User (recommended for multiple repositories)
For setups with multiple repositories, it is recommended to 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 (e.g.,
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 Requêtes de fusion 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.
Dépôts GitLab¶
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 GitLab sur l’utilisation permise de la clé SSH (car chaque clé ne peut être utilisée qu’une seule 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.
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.
L’URL doit contenir un nom utilisateur, pour un jeton d’accès personnel c’est le nom utilisateur actuel ( https://user:personal_access_token@gitlab.com/example/example.git), pour les jetons d’accès au projet la valeur peut être non vide (https://example:project_access_token@gitlab.com/example/example.git).
Note
Les règles concernant les jetons d’accès aux projets ont changé selon les versions de GitLab, une valeur non vide est demandée actuellement, mais les anciennes versions attendaient autre chose (un nom de projet, un nom utilisateur de robot). En cas de doute, vérifier dans la documentation GitLab de votre version.
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¶
Voir aussi
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.
Si vous ne fournissez pas les informations personnelles dans l’URL et que le dépôt en a besoin, Git échouera avec l’erreur :
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Modifié dans la version 5.10.2: Weblate uses proactive authentication with Git 2.46.0 and newer when HTTP credentials are supplied.
Ceci rend possible l’accès aux dépots Azure DevOps et accélère l’accès aux dépôts authentifiés.
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 poussée forcée¶
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.
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.
Ceci ajoute simplement un mince niveau par dessus Git en utilisant Bitbucket Data Center 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 Tirages demandés du Bitbucket Data Center, 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 Data 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.
Ceci ajoute simplement un mince niveau par dessus Git en utilisant Bitbucket Cloud 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 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.
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.