Le CLI de Lingo.dev fonctionne dans n’importe quel environnement CI/CD avec Node.js. Ajoutez-le comme étape de pipeline pour traduire à chaque push : le lockfile garantit que seules les chaînes modifiées sont traitées, pour des traductions rapides et économiques, même à mesure que votre projet grandit.
Sur GitHub ? Deux façons de procéder
La GitHub App est l’option la plus simple sur GitHub : vous l’installez une fois, puis elle réagit automatiquement aux pushes et aux pull requests. Aucun runner, aucun secret de clé API, aucun lockfile ; il suffit de configurer le dépôt avec .lingo/config.json et un engineId.
La GitHub Action et les autres intégrations ci-dessous exécutent le CLI dans votre propre pipeline à l’aide de i18n.json, d’un lockfile i18n.lock et d’un secret LINGODOTDEV_API_KEY. Choisissez cette option si vous voulez exécuter la traduction en parallèle des autres étapes CI, ou si vous n’utilisez pas GitHub.
La suite de ce guide couvre la GitHub Action et le CLI.
Comment ça marche#
Le pipeline CI/CD exécute le CLI comme étape après le checkout. Le CLI lit votre configuration i18n.json, compare les fichiers source au lockfile pour identifier les changements, traduit le delta via un moteur de localisation configuré, puis écrit le résultat dans les fichiers de langue cibles. Le pipeline commit ensuite les fichiers traduits ou ouvre une pull request, selon le workflow que vous préférez.
Choisissez votre workflow#
Quatre modèles de workflow couvrent la plupart des organisations d’équipe. Commencez par le plus simple, puis passez à un niveau supérieur à mesure que votre équipe grandit.
| Workflow | Fonctionnement | Idéal pour | Compromis |
|---|---|---|---|
| Commit sur main | Traduit et commit directement sur main | Petites équipes, zéro friction | Aucune étape de relecture des traductions |
| PR depuis main | Traduit et ouvre une PR pour relecture | Équipes qui relisent les traductions | Nécessite une approbation manuelle de la PR |
| Commit sur une branche de fonctionnalité | Traduit à chaque push sur une branche de fonctionnalité | Branches de fonctionnalité longue durée | Commits de traduction dans l’historique de la branche |
| PR depuis une branche de fonctionnalité | Traduit et ouvre une PR depuis une branche de fonctionnalité | Contrôle maximal par fonctionnalité | Plusieurs PR par fonctionnalité |
Notre recommandation pour commencer
Le commit sur main convient bien à la plupart des équipes. Les traductions sont livrées à chaque push, le lockfile garantit la cohérence, et le glossaire ainsi que les règles de voix de marque du moteur de localisation assurent la qualité. Passez à des workflows basés sur des PR lorsque vous avez besoin d’une relecture humaine des traductions.
Configuration rapide#
Stockez votre clé API Lingo.dev comme secret CI/CD, puis ajoutez l’étape de traduction à votre pipeline.
Lingo.dev propose une GitHub Action officielle qui gère le checkout, la traduction et la création de commit ou de PR.
Vous préférez ne pas gérer de fichier de workflow, de secret de clé API ou de lockfile ? La GitHub App assure une localisation continue sur GitHub sans rien de tout cela : installez-la une fois, puis configurez .lingo/config.json.
Commit sur main :
name: Translate
on:
push:
branches: [main]
permissions:
contents: write
jobs:
translate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: lingodotdev/lingo.dev@main
with:
api-key: ${{ secrets.LINGODOTDEV_API_KEY }}PR depuis main - ajoutez pull-request: true et un GH_TOKEN :
name: Translate
on:
push:
branches: [main]
permissions:
contents: write
pull-requests: write
jobs:
translate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: lingodotdev/lingo.dev@main
with:
api-key: ${{ secrets.LINGODOTDEV_API_KEY }}
pull-request: true
env:
GH_TOKEN: ${{ github.token }}Consultez le guide complet d’intégration GitHub Actions pour les workflows sur branches de fonctionnalité, les messages de commit personnalisés, la prise en charge des monorepos et la signature GPG.
Vérification des traductions#
L’option --frozen et le lockfile font partie de la GitHub Action et du CLI. La GitHub App suit l’état des traductions côté serveur et n’a ni lockfile ni équivalent à --frozen.
Utilisez l’option --frozen comme garde-fou de déploiement pour vous assurer qu’aucun contenu non traduit n’arrive en production. Le CLI se termine avec un code de sortie non nul si certaines chaînes doivent encore être traduites.
npx lingo.dev@latest run --frozenAjoutez ceci comme étape de pipeline distincte avant le déploiement :
- name: Verify translations
run: npx lingo.dev@latest run --frozenWorkflows monorepo#
Pour les monorepos avec plusieurs packages, chacun ayant ses propres fichiers de traduction, utilisez l’option working-directory pour cibler des packages spécifiques :
- uses: lingodotdev/lingo.dev@main
with:
api-key: ${{ secrets.LINGODOTDEV_API_KEY }}
working-directory: apps/webConflits de fusion#
Cela s’applique à la GitHub Action et au CLI. La GitHub App n’utilise pas de lockfile, elle n’a donc aucun conflit i18n.lock à résoudre.
Le lockfile (i18n.lock) peut entrer en conflit lors de la fusion de branches contenant des modifications de traduction. La résolution est simple : supprimez le lockfile en conflit, terminez la fusion, puis régénérez-le :
git merge feature-branch
rm i18n.lock
git add .
git merge --continue
npx lingo.dev@latest lockfile --forceLa commande lockfile --force reconstruit le lockfile à partir de l’état actuel de vos fichiers source sans déclencher de nouvelles traductions. Consultez le guide des modèles d’intégration avancés pour les résolutions basées sur le rebase et les stratégies de prévention des conflits.
