Skip to main content

La localisation continue sans TMS

Votre code se déploie en continu. Vos traductions devraient en faire autant. Voici comment automatiser la localisation dans votre flux de développement.

Qu'est-ce que la localisation continue ?

La localisation continue consiste à traduire automatiquement les nouvelles chaînes dans le cadre de votre flux de développement, plutôt que de regrouper les traductions dans des versions périodiques. Lorsqu'un développeur ajoute une nouvelle fonctionnalité avec des chaînes d'interface, ces chaînes sont traduites avant la mise en production de la fonctionnalité.

L'approche traditionnelle

La plupart des équipes regroupent les traductions : elles collectent les nouvelles chaînes, les exportent vers un TMS, attendent les traducteurs, importent les résultats, puis publient. Cela crée un goulot d'étranglement de localisation qui retarde les versions internationales de plusieurs jours, voire plusieurs semaines.

1

Le développeur ajoute de nouvelles chaînes au fichier de la locale source

2

Les chaînes sont exportées et téléversées sur une plateforme TMS

3

Les traducteurs sont informés et commencent le travail

4

Les traductions sont relues et approuvées

5

Les fichiers traduits sont téléchargés et réintégrés

6

La fonctionnalité est mise en production avec les traductions (plusieurs jours à plusieurs semaines plus tard)

Days to weeks

L'approche native à l'IDE

Avec la traduction native à l'IDE, le développeur traduit les chaînes dans le cadre de son flux de développement habituel. Pas d'export, pas de téléversement, pas d'attente — les traductions ont lieu dans la même session que le développement.

1

Le développeur ajoute de nouvelles chaînes au fichier de la locale source

2

Le développeur demande à son assistant IA de traduire le fichier

3

Les fichiers traduits sont écrits directement dans le projet

4

La fonctionnalité est mise en production avec les traductions dans le même commit

Same commit

L'approche traditionnelle

6 steps

Multiple tools and platforms

Days to weeks per cycle

L'approche native à l'IDE

4 steps

Inside your editor

Same commit

3

Configurez votre pipeline de traduction

Pour les équipes qui souhaitent une traduction automatisée au-delà de l'IDE, ajoutez une étape CI/CD qui traduit les chaînes nouvelles ou modifiées à chaque push vers main. Cela fonctionne avec GitHub Actions, GitLab CI ou tout autre système CI/CD.

Commencez par la traduction native à l'IDE pour les petites équipes. Ajoutez l'automatisation CI/CD lorsque votre équipe dépasse 3 à 4 développeurs, ou lorsque vous avez besoin de traductions garanties à chaque fusion vers main.

Ajoutez la traduction comme étape dans votre pipeline CI/CD existant. La traduction s'exécute après la réussite de votre build et avant le déploiement, garantissant que chaque version inclut des traductions à jour.
.github/workflows/translate.yml
# .github/workflows/translate.yml
name: Translate
on:
  push:
    branches: [main]
    paths: ['locales/en/**']

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Translate changed strings
        run: |
          npx i18n-agent translate locales/en.json \
            --to de,ja,es,fr,ko,zh-Hans \
            --api-key ${{ secrets.I18N_AGENT_API_KEY }}

      - name: Commit translations
        run: |
          git config user.name "github-actions"
          git config user.email "[email protected]"
          git add locales/
          git diff --cached --quiet || git commit -m "chore: update translations"
          git push
.gitlab-ci.yml
# .gitlab-ci.yml
translate:
  stage: deploy
  only:
    changes:
      - locales/en/**
  script:
    - npx i18n-agent translate locales/en.json
        --to de,ja,es,fr --api-key $I18N_AGENT_API_KEY
    - git add locales/ && git commit -m "chore: translations" && git push
4

Ajoutez le contrôle qualité des traductions au CI

Des vérifications automatisées dans votre pipeline CI détectent les traductions manquantes, les espaces réservés cassés et les formats de messages ICU invalides avant qu'ils n'atteignent la production. Il s'agit de scripts simples qui comparent votre fichier de locale source à toutes les locales cibles.

Sans validation des traductions au niveau du CI, les traductions manquantes atteignent silencieusement la production. Les utilisateurs voient des clés brutes comme « settings.title » ou des chaînes vides au lieu du texte traduit. Une vérification CI de 5 minutes permet d'éviter cela entièrement.
check-translations.sh
#!/bin/bash
# check-translations.sh — Run in CI to catch missing translations

SOURCE="locales/en.json"
LANGS=("de" "ja" "es" "fr")
EXIT_CODE=0

# Extract all keys from source
SOURCE_KEYS=$(jq -r '[paths(scalars)] | map(join(".")) | .[]' "$SOURCE" | sort)
SOURCE_COUNT=$(echo "$SOURCE_KEYS" | wc -l)

for lang in "${LANGS[@]}"; do
  TARGET="locales/$lang.json"
  if [ ! -f "$TARGET" ]; then
    echo "❌ Missing: $TARGET"
    EXIT_CODE=1
    continue
  fi

  TARGET_KEYS=$(jq -r '[paths(scalars)] | map(join(".")) | .[]' "$TARGET" | sort)
  MISSING=$(comm -23 <(echo "$SOURCE_KEYS") <(echo "$TARGET_KEYS"))

  if [ -n "$MISSING" ]; then
    COUNT=$(echo "$MISSING" | wc -l)
    echo "❌ $lang: $COUNT missing keys"
    echo "$MISSING" | head -5
    EXIT_CODE=1
  else
    echo "✅ $lang: all $SOURCE_COUNT keys present"
  fi
done

exit $EXIT_CODE
check-placeholders.sh
#!/bin/bash
# check-placeholders.sh — Validate placeholder consistency

SOURCE="locales/en.json"
LANGS=("de" "ja" "es")

for lang in "${LANGS[@]}"; do
  TARGET="locales/$lang.json"

  # Compare placeholders like {{name}}, {count}, %s, %d
  jq -r 'paths(scalars) as $p | [($p | join(".")), (getpath($p))]
    | @tsv' "$SOURCE" | while IFS=$'\t' read -r key value; do
    SOURCE_PH=$(echo "$value" | grep -oE '\{\{[^}]+\}\}|%[sd@]' | sort)
    TARGET_VAL=$(jq -r "getpath($(echo $key | jq -R 'split(".")'))" "$TARGET")
    TARGET_PH=$(echo "$TARGET_VAL" | grep -oE '\{\{[^}]+\}\}|%[sd@]' | sort)

    if [ "$SOURCE_PH" != "$TARGET_PH" ]; then
      echo "❌ $lang/$key: placeholder mismatch"
      echo "   Source: $SOURCE_PH"
      echo "   Target: $TARGET_PH"
    fi
  done
done

Validez les traductions dans le CI

Ajoutez i18n-validate à votre pipeline CI pour détecter automatiquement les clés manquantes, les espaces réservés cassés et les problèmes de pluriel. Utilisez i18n-pseudo pour générer de fausses traductions destinées aux tests de non-régression visuelle.
5

Détectez et gérez la dérive des traductions

La dérive des traductions se produit lorsque les chaînes source changent mais que les traductions ne sont pas mises à jour. Le texte anglais dit « Save changes », mais l'allemand affiche encore l'ancien texte. La détection de dérive compare les horodatages ou les empreintes de contenu des fichiers source et de traduction.

Les traductions obsolètes sont pires que les traductions manquantes. Une traduction manquante est manifestement erronée — l'utilisateur voit une clé ou la langue de repli. Une traduction obsolète affirme la mauvaise chose de façon convaincante, ce qui peut induire les utilisateurs en erreur ou générer des problèmes de support.
detect-drift.sh
#!/bin/bash
# detect-drift.sh — Find stale translations

SOURCE="locales/en.json"
SOURCE_HASH=$(md5sum "$SOURCE" | cut -d' ' -f1)
HASH_FILE=".translation-hashes"

# Compare current source hash with stored hash
if [ -f "$HASH_FILE" ]; then
  STORED_HASH=$(grep "^en:" "$HASH_FILE" | cut -d: -f2)
  if [ "$SOURCE_HASH" != "$STORED_HASH" ]; then
    echo "⚠️  Source strings changed since last translation"
    echo "   Run translations to update all locales"

    # Show which keys changed
    git diff HEAD~1 "$SOURCE" | grep '^[+-]' | grep -v '^[+-][+-]'
  fi
fi

# Update stored hash
echo "en:$SOURCE_HASH" > "$HASH_FILE"
6

Choisissez votre approche de traduction

Tout le contenu n'a pas besoin de la même approche de traduction. Les chaînes et libellés d'interface se prêtent parfaitement à la traduction par IA. Le contenu marketing bénéficie d'une combinaison IA + relecture humaine. Les textes juridiques et de conformité doivent toujours passer par des traducteurs humains professionnels.

La traduction par IA traite plus de 80 % des chaînes d'application typiques à une qualité de production. Réservez les traducteurs humains aux textes juridiques, à la voix de marque et au contenu culturellement sensible, là où la nuance compte le plus.
Cost Comparison
Translation Approach Comparison:

Content Type         | Approach          | Cost/word  | Quality
─────────────────────┼───────────────────┼────────────┼──────────
UI strings, labels   | AI/LLM            | $0.001-01  | Production
Tooltips, help text  | AI/LLM            | $0.001-01  | Production
Marketing copy       | AI + human review | $0.05-0.15 | High
Legal / compliance   | Human translator  | $0.15-0.40 | Certified
Brand voice content  | Human translator  | $0.20-0.50 | Premium
7

Flux Git pour les traductions

Traduisez sur votre branche de fonctionnalité avant la fusion, pas après. Cela garantit que chaque fusion vers main inclut des traductions complètes. Ajoutez une vérification préalable à la fusion qui contrôle l'exhaustivité des traductions pour toutes les locales prises en charge.

Les fichiers JSON de locale volumineux provoquent de fréquents conflits de fusion lorsque plusieurs branches les modifient simultanément. Triez les clés par ordre alphabétique et utilisez une clé par ligne pour réduire la taille des diffs et faciliter la résolution des conflits.

Les fichiers de traduction résident dans votre dépôt aux côtés de votre code. Ils sont versionnés, relisibles dans les pull requests, et déployés via le même pipeline que le reste.
.gitattributes + package.json
# .gitattributes — reduce merge conflicts in locale files
locales/*.json merge=union

# Sort keys alphabetically to minimize diffs:
# package.json script:
"sort-locales": "node -e \"
  const fs = require('fs');
  const f = process.argv[1];
  const d = JSON.parse(fs.readFileSync(f));
  const s = (o) => Object.keys(o).sort().reduce((r,k) =>
    ({...r, [k]: typeof o[k]==='object' ? s(o[k]) : o[k]}), {});
  fs.writeFileSync(f, JSON.stringify(s(d), null, 2)+'\\n');
\""

Pièges courants

Traiter la localisation comme une étape post-développement

La plus grande erreur : attendre la fin du développement pour traduire. Cela crée des goulots d'étranglement, retarde les versions et relègue la traduction au second plan. Traduisez pendant le développement, pas après.

Absence de validation des traductions au niveau du CI

Sans vérifications automatisées, les traductions manquantes, les espaces réservés cassés et les formats invalides atteignent la production. Ajoutez une validation de l'exhaustivité et du format à votre pipeline CI.

Sur-ingénierie avec un TMS

Un TMS a été conçu pour gérer les flux de travail des traducteurs humains. Si vous utilisez la traduction par IA, vous n'avez peut-être pas besoin de la lourdeur d'un TMS. Commencez simplement — traduisez dans l'IDE ou le CI/CD — et n'ajoutez un TMS que si vous avez besoin de gérer des traducteurs humains.

Absence de suivi de la fraîcheur des traductions

Sans suivi de la fraîcheur, vous ne savez pas quelles traductions sont obsolètes. Les chaînes source changent, mais les anciennes traductions persistent. Intégrez la détection de dérive à votre flux de travail pour repérer le contenu obsolète.

Essayez i18n Agent maintenant

Déposez votre fichier de traduction ici

JSON, YAML, PO, XML, CSV, Markdown, Properties

ou cliquez pour parcourir

Langues cibles

Aucune inscription requiseEstimation instantanée

Questions fréquentes