Workflows de localisation CI/CD

Lingo.dev automatise votre localisation dans le CI/CD. Deux options s’offrent à vous : l’app GitHub, qui réagit côté serveur à vos pushes et pull requests, ou le CLI, exécuté dans votre propre pipeline. Dans les deux cas, vos traductions restent synchronisées à chaque modification, et seules les chaînes réellement modifiées sont traitées — pour une localisation rapide et rentable, même à mesure que votre projet grandit.

Option 1 : app GitHub (recommandée)#

L’app GitHub est la façon la plus simple d’exécuter une localisation continue. Elle surveille votre dépôt et traduit côté serveur, sans rien à installer dans votre pipeline ni aucune clé API à stocker comme secret CI.

La configuration ne se fait qu’une seule fois :

1. Installez l’app GitHub Lingo.dev sur votre dépôt.
2. Validez un .lingo/config.json avec votre orgId, vos engineId, votre langue source, vos langues cibles et les fichiers à traduire. Exécutez lingo init et lingo link en local pour le générer, puis validez le résultat.
3. Poussez.

À partir de là, l’app prend en charge pour vous les deux styles de workflow :

• Lors d’un push sur votre branche par défaut, elle commit les traductions sur cette branche.
• Lors d’une pull request, elle ajoute les traductions à cette PR afin que vous puissiez les relire avant la fusion.

Comme l’app suit l’état des traductions côté serveur, il n’y a aucun lockfile dans votre dépôt qui puisse créer des conflits, ni d’étape de vérification à configurer : elle se contente de garder vos langues cibles synchronisées avec votre source.

Option 2 : le CLI dans votre propre pipeline#

Si vous n’utilisez pas GitHub, ou si vous voulez que la localisation s’exécute comme une étape explicite à côté de vos jobs de build et de test, exécutez le CLI vous-même. Il fonctionne dans n’importe quel environnement CI avec Node.js 22 ou version ultérieure : GitHub Actions, GitLab CI, Bitbucket Pipelines, ou tout autre système.

Le fonctionnement reste toujours le même :

1. Installez @lingo.dev/cli.
2. Authentifiez-vous avec votre clé API via la variable d’environnement LINGO_API_KEY.
3. Exécutez lingo push pour traduire les chaînes modifiées.
4. Validez les résultats, ou ouvrez une pull request depuis votre job.

Stockez votre clé API Lingo.dev comme secret CI et exposez-la sous LINGO_API_KEY. Le .lingo/config.json validé indique au CLI ce qu’il doit traduire, et le .lingo/lock.json validé (régénéré par lingo push) suit l’état afin que seules les chaînes modifiées soient traitées.

Exemple minimal avec GitHub Actions#

Ce workflow installe le CLI, traduit à chaque push sur main, puis commit les résultats :

name: Localize
on:
  push:
    branches: [main]
permissions:
  contents: write
jobs:
  localize:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm install -g @lingo.dev/cli
      - run: lingo push
        env:
          LINGO_API_KEY: ${{ secrets.LINGO_API_KEY }}
      - name: Commit translations
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add .
          git commit -m "chore: update translations" || echo "No changes"
          git push

Les deux mêmes lignes — npm install -g @lingo.dev/cli puis lingo push — s’intègrent aussi bien dans un bloc script: de GitLab CI que dans une étape Bitbucket Pipelines. Définissez LINGO_API_KEY comme variable CI masquée/protégée sur ces plateformes.

Commit ou pull request ?#

Quelle que soit l’option choisie, vous gardez la main sur la façon dont les traductions sont intégrées :

L’app GitHub vous offre automatiquement les deux : elle commit lors des pushes sur votre branche par défaut et ajoute les traductions aux PR ouvertes. Dans votre propre pipeline, c’est vous qui choisissez : committez les résultats comme montré ci-dessus, ou faites ouvrir une pull request par le job au lieu de pousser sur la branche.

Vérifier les traductions avant le déploiement#

Pour vous assurer qu’aucun contenu non traduit ne soit mis en production, ajoutez lingo check comme garde-fou avant votre étape de déploiement. La commande se termine avec un statut non nul s’il reste encore des chaînes à traduire :

- name: Verify translations
  run: lingo check

L’app GitHub garde les langues synchronisées en continu ; une étape de vérification dédiée est donc surtout utile si vous exécutez vous-même le CLI.

Monorepos#

Pour les monorepos où chaque package possède son propre .lingo/config.json, limitez l’exécution à un package en passant un glob, ou exécutez le CLI depuis le répertoire du package :

lingo push "apps/web/**"

Étapes suivantes#