Bonnes pratiques avancées pour la localisation CI/CD : choix du workflow, vérification de l’exhaustivité des traductions et résolution des conflits de fusion.
Choisir le bon workflow#
Quatre modèles de workflow couvrent la plupart des organisations d’équipe. Chacun implique ses propres compromis en matière d’automatisation, de charge de relecture et de gestion des branches.
| Workflow | Idéal pour | Compromis |
|---|---|---|
| Commit sur main | Petites équipes, mises à jour sans friction | Aucune étape de relecture des traductions |
| PR depuis main | Les équipes qui veulent relire les traductions | Nécessite une approbation manuelle de la PR |
| Commit sur une branche de fonctionnalité | Branches de fonctionnalité de longue durée | Les commits de traduction apparaissent dans l’historique de la branche |
| PR depuis une branche de fonctionnalité | Contrôle maximal par fonctionnalité | Plusieurs PR à gérer par fonctionnalité |
Sur GitHub, la Lingo.dev GitHub App gère la plupart de ces cas de figure côté serveur — elle réagit aux pushes et aux PR, commit les traductions en retour et ne nécessite ni runner ni secret. Privilégiez les modèles CLI ci-dessous lorsque vous exécutez la localisation dans votre propre pipeline.
En cas de doute, commencez par "Commit sur main". C’est le workflow le plus simple, et il évite complètement les conflits de fusion puisqu’il n’y a pas de divergence entre les branches.
Vérifier l’exhaustivité des traductions#
La commande lingo check vérifie que l’ensemble du contenu est traduit sans générer de nouvelles traductions. Elle renvoie un code de sortie non nul si du contenu est manquant :
lingo checkUtilisez-la comme garde-fou de déploiement pour éviter de livrer du contenu non traduit. Installez la CLI avec npm install -g @lingo.dev/cli (Node 22+) et authentifiez le runner à l’aide d’une variable d’environnement LINGO_API_KEY.
name: Check translations
on: [push, pull_request]
jobs:
check:
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 check
env:
LINGO_API_KEY: ${{ secrets.LINGO_API_KEY }}Résoudre les conflits de fusion#
Des conflits de fusion surviennent lorsque le fichier .lingo/lock.json diverge entre les branches, généralement quand les traductions sont mises à jour indépendamment dans plusieurs branches.
Prévention#
Commiter les traductions directement sur main (au lieu d’utiliser des branches de fonctionnalité pour les traductions) élimine complètement les conflits de lockfile.
Résolution par merge#
Démarrer le merge
git merge <branch-name>Supprimer le lockfile en conflit
rm .lingo/lock.jsonTerminer le merge
git add .
git merge --continueRégénérer le lockfile
lingo pushL’exécution de lingo push reconstruit .lingo/lock.json à partir de l’état actuel de vos fichiers source dans le cadre du workflow de synchronisation habituel.
Résolution par rebase#
La même approche fonctionne aussi avec un rebase — supprimez .lingo/lock.json à chaque étape de conflit, poursuivez le rebase, puis exécutez lingo push à la fin pour régénérer le fichier de verrouillage :
git rebase <branch-name>
# On each conflict: rm .lingo/lock.json && git add . && git rebase --continue
lingo push