Localisation continue

Lingo.dev maintient vos traductions synchronisées avec votre code. À chaque modification, il détecte ce qui a changé, le traduit à l’aide de votre moteur de localisation connecté — avec les règles de glossaire, la voix de marque et la configuration du modèle par langue appliquées de manière cohérente — puis valide les résultats ou ouvre une pull request. Les traductions incomplètes n’arrivent jamais en production.

Choisissez votre intégration#

Chaque intégration dispose de son propre guide. Choisissez celle qui correspond à votre configuration :

À l’exception de GitHub App, chaque intégration exécute la CLI Lingo.dev. Autrement dit, tout environnement CI/CD avec Node.js peut lancer la localisation directement, même sans intégration native.

Comment fonctionne GitHub App#

Installez l’application une seule fois et ajoutez un .lingo/config.json au dépôt. Ensuite, Lingo.dev exécute la localisation pour vous — sans pipeline, sans secret de clé API, sans lockfile :

1. Surveille les modifications — réagit par défaut aux pushes sur la branche par défaut, ainsi qu’aux pull requests une fois onPullRequest activé, en comparant les fichiers modifiés aux motifs source que vous configurez
2. Traduit le delta — envoie le contenu source modifié au moteur désigné par engineId
3. Réécrit les résultats dans GitHub — sur les pushes vers la branche par défaut, ouvre ou met à jour une pull request de traduction ; sur les pull requests, valide les fichiers traduits sur la branche de la PR et publie un commentaire de statut
4. Récupère et regroupe — détecte les modifications manquées lors d’une exécution précédente et répartit les mises à jour très volumineuses sur plusieurs commits

Vous pouvez soumettre les exécutions à une étape d’approbation ou déclencher les traductions manuellement avec des commandes /lingo dans une pull request. Consultez le guide GitHub App pour la configuration complète.

Comment fonctionnent les intégrations de pipeline#

GitHub Action, GitLab CI/CD, Bitbucket Pipelines et la CLI autonome exécutent tous la même CLI Lingo.dev comme étape de votre pipeline existant. Ils ont besoin de deux éléments : votre configuration i18n.json et une clé API.

À chaque exécution, l’intégration :

1. Repère les fichiers source — lit votre configuration de bucket pour trouver le contenu à traduire
2. Détecte les modifications — compare avec le lockfile i18n.lock pour identifier les chaînes nouvelles ou modifiées, afin de ne traduire que le delta
3. Traduit — envoie le contenu modifié via votre moteur de localisation configuré, avec toutes les règles appliquées — glossaire, voix de marque, paramètres de modèle par langue
4. Écrit les résultats — met à jour directement les fichiers des langues cibles
5. Valide ou ouvre une PR — selon le workflow choisi

Comme seules les chaînes modifiées sont traduites, les exécutions sont rapides et économiques, même sur des dizaines de langues.

Options de workflow#

GitHub App#

Le comportement de l’application se configure dans .lingo/config.json :

Consultez le guide GitHub App pour la configuration complète et la référence des commandes.

GitHub Action, GitLab CI, Bitbucket et CLI#

Quatre modèles de workflow couvrent la plupart des configurations d’équipe :

La première option — commit sur main — est la plus simple. Les traductions arrivent automatiquement, sans aucune intervention des développeurs. Les options basées sur des PR ajoutent une étape de relecture avant l’intégration des traductions.

Pour savoir comment choisir entre ces options, consultez Modèles avancés.

Étapes suivantes#