Bonnes pratiques avancées

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é

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#

Le flag --frozen vérifie que tout le contenu est bien traduit sans générer de nouvelles traductions. Il renvoie un code de sortie non nul s’il manque du contenu :

bash

npx lingo.dev@latest run --frozen

Utilisez-le comme garde-fou au déploiement pour éviter de livrer du contenu non traduit.

yaml

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: 20
      - run: npx lingo.dev@latest run --frozen

Résoudre les conflits de fusion#

Des conflits de fusion surviennent lorsque le fichier i18n.lock 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

bash

git merge <branch-name>

Supprimer le lockfile en conflit

bash

rm i18n.lock

Terminer le merge

bash

git add .
git merge --continue

Régénérer le lockfile

bash

npx lingo.dev@latest lockfile --force

Cela reconstruit le lockfile à partir de l’état actuel de vos fichiers source sans déclencher de nouvelles traductions.

Résolution par rebase#

La même approche fonctionne avec un rebase : supprimez i18n.lock à chaque étape de conflit, poursuivez le rebase, puis régénérez le lockfile à la fin :

bash

git rebase <branch-name>
# On each conflict: rm i18n.lock && git add . && git rebase --continue
npx lingo.dev@latest lockfile --force

Étapes suivantes#

GitHub Actions

Configurer la GitHub Action officielle

i18n.lock

Comprendre comment le lockfile suit l’état des traductions

Fonctionnement

Le pipeline de localisation CI/CD

Configuration

Configurer la CI/CD pour votre projet

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é

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#

Le flag --frozen vérifie que tout le contenu est bien traduit sans générer de nouvelles traductions. Il renvoie un code de sortie non nul s’il manque du contenu :

bash

npx lingo.dev@latest run --frozen

Utilisez-le comme garde-fou au déploiement pour éviter de livrer du contenu non traduit.

yaml

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: 20
      - run: npx lingo.dev@latest run --frozen

Résoudre les conflits de fusion#

Des conflits de fusion surviennent lorsque le fichier i18n.lock 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

bash

git merge <branch-name>

Supprimer le lockfile en conflit

bash

rm i18n.lock

Terminer le merge

bash

git add .
git merge --continue

Régénérer le lockfile

bash

npx lingo.dev@latest lockfile --force

Cela reconstruit le lockfile à partir de l’état actuel de vos fichiers source sans déclencher de nouvelles traductions.

Résolution par rebase#

La même approche fonctionne avec un rebase : supprimez i18n.lock à chaque étape de conflit, poursuivez le rebase, puis régénérez le lockfile à la fin :

bash

git rebase <branch-name>
# On each conflict: rm i18n.lock && git add . && git rebase --continue
npx lingo.dev@latest lockfile --force

Étapes suivantes#

GitHub Actions

Configurer la GitHub Action officielle

i18n.lock

Comprendre comment le lockfile suit l’état des traductions

Fonctionnement

Le pipeline de localisation CI/CD

Configuration

Configurer la CI/CD pour votre projet