La localisation continue expliquée

La localisation continue est l’idée que le processus de traduction ne se termine jamais et que votre contenu doit être continuellement prêt pour la publication. Plutôt qu’une phase de traduction précédant chaque lancement, la traduction tourne en parallèle du développement comme un flux constant en arrière-plan.

La conséquence pratique est que vous publierez parfois avec des chaînes non traduites. Ce n’est pas un échec du modèle, c’est le compromis qu’il impose : parce que vous publiez en continu, une traduction manquante n’est en ligne que quelques jours plutôt qu’un trimestre.

Pourquoi le modèle par phases ne fonctionne plus#

La séquence traditionnelle — tout construire, geler, traduire, tester, publier — fonctionne quand vous publiez deux fois par an. Elle échoue face à la livraison continue, pour des raisons structurelles :

• Le gel est un mensonge. Le développement ne s’arrête pas pendant que la traduction se déroule, si bien qu’au retour des traductions, la source a déjà bougé.
• Le lot est énorme. Six mois de chaînes arrivent d’un coup chez les traducteurs, avec une échéance.
• Le retour arrive trop tard. La question d’un traducteur sur une chaîne révèle un problème de copy, trois mois après que ce texte a été écrit.
• Le rythme de publication dépend de la langue la plus lente. Une seule langue en retard retarde tout.

Le décalage est une question de fréquence. Si le code est livré chaque semaine et la traduction deux fois par an, les deux systèmes ne peuvent pas être couplés sans que l’un bloque l’autre.

À quoi ressemble la localisation continue#

La boucle, en cinq étapes qui se répètent indéfiniment :

1. Configurer les langues — une langue source et vos langues cibles.
2. Pousser les fichiers source vers la plateforme de traduction chaque fois qu’ils changent, depuis la CI plutôt qu’à la main.
3. Les chaînes sont extraites en segments. Les traducteurs voient exactement ce qui est nouveau. Les questions vont vers un fil partagé visible par tous, si bien que la même ambiguïté n’est pas expliquée n fois. Comme les traducteurs travaillent sur une base de données plutôt que sur un fichier, plusieurs peuvent travailler sur la même langue en même temps.
4. Traduire en continu. Les nouveaux segments apparaissent au fur et à mesure de leur création ; les chaînes source supprimées disparaissent automatiquement des fichiers cibles.
5. Récupérer les traductions selon un calendrier ou avant chaque publication, et livrer ce qui est prêt.

Les deux propriétés qui font que cela fonctionne sont que les deux sens sont automatisés et que l’unité de travail est le segment plutôt que le fichier. Retirez l’une des deux et vous en revenez à envoyer des fichiers par e-mail.

Le problème des branches de fonctionnalités#

C’est la partie qui piège presque toutes les équipes, et elle a une forme précise.

Le développeur A termine la fonctionnalité A et pousse les fichiers linguistiques mis à jour. Le développeur B termine la fonctionnalité B et pousse les siens. L’envoi de B écrase celui de A — et comme la plateforme supprime les chaînes qui n’existent plus dans le fichier source, les chaînes de la fonctionnalité A sont maintenant supprimées, avec tout le travail de traduction déjà effectué sur elles.

La cause est que les fichiers linguistiques sont des artefacts constitués d’un fichier entier, poussés depuis n’importe quelle branche qui se trouve être active à cet instant, alors que l’état de traduction est global. La plupart des plateformes, WebTranslateIt compris, ne modélisent pas les branches, donc la solution relève du processus : poussez les fichiers linguistiques depuis exactement une seule branche.

Option 1 — une branche d’intégration dédiée. Fusionnez les fonctionnalités terminées dans une branche i18n à un rythme donné, disons chaque vendredi. Poussez les fichiers linguistiques depuis là. Les traducteurs travaillent les jours suivants. Intégrez les traductions et publiez. Choisissez cette option quand livrer du contenu non traduit est inacceptable.

Option 2 — pousser depuis main. Fusionnez les branches de fonctionnalités dans main au fur et à mesure qu’elles sont prêtes, et poussez les fichiers linguistiques depuis main. Les nouvelles chaînes partent non traduites et sont complétées lors d’une publication ultérieure. Choisissez cette option quand vous pouvez tolérer de brefs écarts, ce qui est le cas pour la plupart des logiciels grand public.

Dans les deux cas, la règle est la même : une seule branche fait référence pour les fichiers linguistiques, et rien d’autre ne pousse. Faites-le respecter par la CI plutôt que par une page de wiki.

Continu ou agile ?#

Ce sont des processus différents, et le choix porte sur votre tolérance au contenu non traduit.

La localisation continue — la traduction ne s’arrête jamais, les publications sortent avec ce qui est prêt, les écarts se combleront à la prochaine mise en production. Convient aux applications web et aux produits grand public à déploiements fréquents et à surface de publication tolérante.

La localisation agile — trois phases répétées : un mini-sprint de développement, une publication en langue source qui tourne en parallèle d’un mini-sprint de traduction, puis une publication en langues cibles. Convient là où une publication est un événement discret : soumissions aux app stores mobiles, logiciel embarqué, tout ce qui implique une revue réglementaire ou un moment marketing.

Les deux sont pris en charge par le même outillage. La différence est de savoir si vous conditionnez la publication à l’exhaustivité de la traduction.

Un compromis courant : fonctionner en continu pour l’application web et en agile pour les applications mobiles, parce que la revue des app stores rend de toute façon les publications mobiles discrètes.

Ce qui la fait vraiment fonctionner#

Automatiser les deux sens. Une CLI dans la CI, ou une GitHub Action. Si un humain doit se souvenir de synchroniser, il ne le fera pas, et la dérive reste invisible jusqu’à ce que quelqu’un remarque qu’une langue accuse trois mois de retard.

Donner du contexte au moment du push. Des commentaires de développeur et des captures d’écran ajoutés à la création de la chaîne coûtent quelques secondes au développeur et évitent une question à chaque traducteur. Les ajouter plus tard n’arrive jamais.

S’appuyer sur la mémoire de traduction. La localisation continue génère un flux de petits changements, et de petits changements comparés à une mémoire déjà établie donnent surtout des correspondances floues élevées. C’est l’avantage économique du modèle : le filet d’eau est bon marché d’une façon que le lot ne l’a jamais été.

Rendre le contenu non traduit visible dans le produit, pas seulement dans un rapport — un repli qui ressemble manifestement à un repli en préproduction. Un repli silencieux vers l’anglais signifie qu’une langue peut rester à moitié traduite pendant des mois sans que personne ne le remarque.

Suivre l’exhaustivité par langue et la traiter comme un indicateur de santé. Le mode de défaillance de la localisation continue est une langue qui prend discrètement du retard parce que personne ne s’en occupe.

Gérer les pluriels et les placeholders au moment du push. Un placeholder ou une structure de pluriel qui ne casse qu’en production est un bug lent à trouver. La validation dans l’éditeur de traduction est l’endroit le moins coûteux pour l’attraper.

Une configuration minimale#

Toute la boucle se résume à deux commandes câblées dans la CI. La CLI de WebTranslateIt est wti :

wti push          # envoyer les fichiers source mis à jour
wti pull          # récupérer les traductions
wti status        # exhaustivité par langue
wti diff          # ce qui changerait, sans rien changer

wti diff est celle qu’il faut connaître. L’exécuter dans une vérification de pull request montre exactement quelles chaînes une fusion ajouterait ou retirerait du projet de traduction, ce qui transforme « personne n’a remarqué que ça supprime 40 segments » en une partie visible de la revue de code.

Une organisation viable pour le modèle push-depuis-main :

• À la fusion vers main : wti push pour les fichiers source uniquement. Les nouvelles chaînes deviennent disponibles aux traducteurs quelques minutes après l’arrivée du code.
• Chaque nuit, ou avant publication : wti pull, et ouvrir une pull request si quelque chose a changé. Les traductions arrivent comme un diff qu’on peut relire plutôt que comme un changement inexpliqué de l’arbre de travail.
• À chaque pull request : wti diff, rapporté comme une vérification.

Il existe aussi une GitHub Action si vous préférez ne pas gérer la CLI dans vos fichiers de workflow. Dans tous les cas, la propriété qui compte est qu’aucun humain n’est dans la boucle pour le cas courant.

Quand ne pas s’en préoccuper#

Si vous publiez deux fois par an dans deux langues, le modèle par phases convient et l’automatisation est du superflu. La localisation continue est une réponse à la fréquence de publication, et l’adopter avant que cette fréquence existe résout un problème que vous n’avez pas.

Le signal pour basculer est simple : quand le cycle de traduction est devenu ce qui conditionne vos publications, ou quand personne ne peut dire à quel point une langue donnée est actuellement complète.