|
Documentation
Réserver une démoPlateforme
PlateformeMCPCLIAPIWorkflows
GuidesChangelog

Localisation continue

  • Comment ça marche
  • Configuration

Plateformes

  • App GitHub
  • GitHub Actions
  • GitLab CI/CD
  • Bitbucket Pipelines
  • Bonnes pratiques avancées

Configuration

Mettez en place la localisation continue pour GitHub Actions, GitLab CI/CD, Bitbucket Pipelines ou la CLI autonome. Tous exécutent la CLI Lingo.dev dans votre pipeline : la configuration suit donc les mêmes trois étapes : configurer la CLI, ajouter votre clé API et choisir un workflow.

Vous préférez configurer la GitHub App ?

La GitHub App ne suit pas ce processus : pas de CLI locale, pas de i18n.json ni de secret de clé API. Il suffit d'installer l'application une fois, puis d'ajouter un .lingo/config.json au dépôt. Suivez plutôt le guide de la GitHub App.

Prérequis

Avant d'ajouter la CI/CD, vous devez disposer d'une configuration CLI opérationnelle, avec un fichier i18n.json, et pouvoir exécuter npx lingo.dev@latest run localement.

Étape 1. Configurer la CLI#

Si ce n'est pas déjà fait, suivez le guide Configuration de la CLI. À la fin, vous devriez avoir :

  • Un fichier i18n.json à la racine du projet
  • Une clé API (soit LINGO_API_KEY pour le moteur Lingo.dev, soit une clé fournisseur comme OPENAI_API_KEY)
  • La possibilité de générer des traductions localement avec npx lingo.dev@latest run

Étape 2. Ajouter votre clé API comme secret CI#

Stockez votre clé API dans le gestionnaire de secrets de votre plateforme CI :

  1. Accédez à Settings > Secrets and variables > Actions
  2. Cliquez sur New repository secret
  3. Nom : LINGODOTDEV_API_KEY, valeur : votre clé API
  4. Cliquez sur Add secret

Étape 3. Choisir un workflow et ajouter la configuration#

Choisissez le workflow qui correspond à votre équipe, puis suivez le guide adapté à votre plateforme :

WorkflowIdéal pour
Commit sur mainLes petites équipes qui veulent des mises à jour de traduction fluides et invisibles
PR depuis mainLes équipes qui veulent relire les traductions avant qu'elles n'arrivent sur main
Commit sur une branche de fonctionnalitéLes équipes qui travaillent avec des branches de fonctionnalité de longue durée
PR depuis une branche de fonctionnalitéLes équipes qui veulent un contrôle maximal sur chaque modification de traduction

Vous hésitez ? Commencez par "Commit sur main" : c'est l'option la plus simple. Vous pourrez en changer plus tard sans modifier votre i18n.json.

Pour les instructions de configuration propres à chaque plateforme et des exemples de workflow, consultez :

GitHub Actions
GitHub Action officielle avec des exemples de workflow
GitLab CI/CD
Image Docker avec des exemples de pipeline
Bitbucket Pipelines
Pipe officielle avec des exemples de workflow

Vérifier la configuration#

Une fois votre workflow CI configuré, poussez une modification pour le déclencher. L'intégration devrait :

  1. Exécuter le pipeline de traduction
  2. Valider les traductions ou ouvrir une PR (selon votre workflow)
  3. Mettre à jour le fichier i18n.lock

Pour vérifier dans la CI que les traductions sont complètes sans en générer de nouvelles, utilisez l'option --frozen :

bash
npx lingo.dev@latest run --frozen

La commande renvoie alors un code de sortie non nul si du contenu n'est pas traduit — pratique comme garde-fou avant le déploiement. Consultez Modèles avancés pour voir des exemples.

Étapes suivantes#

GitHub App
Configuration gérée sans secret de clé API ni i18n.json
GitHub Actions
Configurer la GitHub Action officielle
Modèles avancés
Vérifications de traduction, conflits de fusion, choix du workflow
Fonctionnement
Le pipeline de localisation CI/CD

Cette page vous a-t-elle été utile ?

Max PrilutskiyMax Prilutskiy·Mis à jour il y a 29 jours·3 min de lecture