Pourquoi les fichiers de traduction se désynchronisent-ils sans cesse ?

Les fichiers de traduction dérivent parce que deux systèmes possèdent les mêmes données et qu’aucun ne prend le dessus. Votre repo change lorsqu’un développeur merge. Vos fichiers de traduction changent lorsque quelqu’un pense à les mettre à jour. Ce sont deux horloges différentes, et l’écart entre elles abrite les clés manquantes, les clés orphelines et les chaînes obsolètes. globalize.now comble cet écart en générant les clés et les fichiers de traduction là où le code est écrit. Il n’y a donc plus de seconde horloge susceptible de prendre du retard.

Qu’est-ce qui désynchronise réellement les fichiers de locale ?

Un fichier est rédigé, les autres sont maintenus. Ce ne sont pas les mêmes tâches.

Un développeur qui implémente une fonctionnalité modifie en.json, parce que c’est le fichier dans lequel la chaîne doit être ajoutée. Les autres locales, c’est le problème de quelqu’un d’autre, selon le calendrier de quelqu’un d’autre. Un développeur qui décrivait ce schéma sur DEV a identifié deux modes d’échec : les clés sont ajoutées au fichier anglais puis oubliées dans les autres, si bien qu’une partie de l’application repasse silencieusement en anglais; ou les clés sont supprimées dans une locale mais subsistent dans une autre, si bien que les entrées mortes s’accumulent. Dans les deux cas, le mécanisme de détection est une réclamation client, plusieurs semaines plus tard.

Aucun de ces cas n’est un problème de traduction. Rien n’a été mal traduit. Les chaînes n’ont simplement jamais été acheminées.

C’est le mode d’échec qui survit à toutes les mises à niveau des outils, parce que les outils interviennent en aval de l’endroit où la chaîne a été créée. Si la chaîne n’entre jamais dans le pipeline, un meilleur pipeline ne changera rien. La même cause racine apparaît encore plus tôt dans la chaîne lorsqu’un agent de codage écrit des chaînes qui n’ont jamais été associées à une clé.

Pourquoi les fichiers de locale génèrent-ils autant de conflits de merge?

Parce qu’il s’agit de données générées, modifiées à la main, dans un format conçu pour être écrit par des machines.

Un fichier de locale est une map plate associant des clés à des chaînes. Deux branches qui ajoutent chacune une fonctionnalité ajoutent toutes deux des entrées à cette map, généralement au même endroit, généralement dans la même zone alphabétique. Git voit deux modifications sur des lignes adjacentes, dans un fichier dont il ne comprend pas la structure sémantique, et demande à une personne de résoudre le conflit.

La personne qui le résout est un développeur qui ne lit pas la langue cible. Le choix prudent consiste à conserver les deux côtés, ce qui introduit des clés en double. Le choix rapide consiste à n’en garder qu’un, ce qui supprime silencieusement des traductions.

Personne ne résout manuellement les conflits dans un lockfile. On le régénère. Les fichiers de locale méritent le même traitement dès qu’ils cessent d’être des documents écrits par une personne.

À quel point une traduction devient-elle obsolète pendant sa review?

Assez pour ne plus décrire le produit — et cela se mesure publiquement.

Un rapport de terrain publié sur DevOps.com a suivi cinq pull requests de localisation réelles dans des projets open source. Le cas le plus instructif est la PR Kilo Code #8377: les vérifications automatisées étaient au vert, la review du mainteneur est arrivée plus tard, et le dépôt avait déjà évolué entre-temps. La PR a été fermée avec une invitation à la soumettre de nouveau pour l’architecture actuelle. Le même rapport décrit un ticket OpenClaw où des bénévoles proposaient des traductions en espagnol, japonais, portugais, coréen, chinois et vietnamien, tandis que les mainteneurs expliquaient ne disposer d’aucun moyen de les intégrer.

Lisez-les comme des rapports de latence, pas comme des rapports de qualité. Les traductions étaient correctes au moment de leur rédaction. L’interface a changé pendant qu’elles attendaient.

C’est le coût que personne ne chiffre lorsqu’il compare les outils de localisation. Tout le monde mesure la traduction. Presque personne ne mesure le temps qu’une chaîne passe en transit, ni ce que devient l’interface pendant son absence.

Quel est réellement le coût de l’aller-retour?

Davantage en coordination qu’en traduction — c’est pourquoi la facture n’explique jamais la douleur.

Le coût visible est facturé au mot, à la clé ou au siège, une fois par mois. Le coût invisible, c’est un développeur qui demande « quel fichier dois-je modifier? », un deuxième qui résout un conflit dans une langue qu’il ne lit pas, un troisième qui remarque que le build allemand a onze clés manquantes, puis l’auteur de la fonctionnalité initiale à qui l’on demande des explications sur une chaîne écrite cinq semaines plus tôt.

Rien de tout cela n’apparaît dans un comparatif tarifaire. Tout est payé en temps de développement, au tarif d’un développeur, à chaque sprint. Un outil au prix affiché bas qui coûte une journée par semaine à deux ingénieurs n’est pas bon marché.

C’est l’aller-retour qui génère ce coût. Déplacer les fichiers entre l’endroit où les chaînes sont créées et celui où elles sont traduites est l’étape coûteuse, et elle le reste quel que soit le prestataire choisi. C’est aussi pourquoi la localisation remonte progressivement dans la boucle de développement.

Qu’est-ce qui change lorsque les clés sont générées là où le code est écrit?

La deuxième horloge disparaît, et la dérive n’a plus d’où venir.

La séquence n’est plus: un développeur écrit une chaîne codée en dur, quelqu’un la trouve plus tard, quelqu’un lui attribue une clé, quelqu’un envoie le fichier, quelqu’un la traduit, quelqu’un la renvoie. Elle devient: la chaîne est écrite avec une clé et une valeur, dans le même commit que la fonctionnalité, puis la traduction suit son cours.

Avec globalize.now, cela commence par une conversion unique. Vous connectez votre repo dans l’application, puis les chaînes codées en dur existantes sont extraites en clés et en fichiers de locale en un seul passage. Ensuite, les compétences de l’agent permettent à des agents de codage comme Cursor et Claude Code d’écrire des chaînes associées à des clés dès le départ au lieu de les coder en dur, tandis que les jobs lancés au push traduisent les nouvelles unités du catalogue au fur et à mesure de leur apparition.

Le mot important est « une fois ». La conversion est la partie difficile, et elle n’a lieu qu’une fois. La suite correspond à ce qui était auparavant manuel, mais s’exécute au même rythme que le code — c’est précisément l’intérêt de l’intégrer au workflow de développement plutôt que de le laisser à côté.

Les bibliothèques runtime ne changent pas. i18next et next-intl lisent toujours les fichiers de locale exactement comme avant. La manière dont les traductions sont servies ne change pas. Ce qui change, c’est la personne — ou plutôt l’outil — qui écrit les fichiers.

Comment distinguer la dérive d’un véritable problème de traduction?

Demandez-vous si un traducteur a déjà vu la chaîne.

Si le fichier allemand ne contient pas une clé, aucun traducteur n’a échoué. La chaîne n’en a jamais atteint un. C’est un problème d’acheminement, et ajouter des étapes de review ne fait qu’empirer les choses en ajoutant du temps d’attente à un processus dont le problème est déjà la latence.

Si le fichier allemand contient la clé mais que la formulation ne convient pas au contexte, c’est un véritable problème de traduction. Il mérite l’intervention d’une personne germanophone qui peut voir où la chaîne s’affiche. Ce temps est bien investi.

La plupart des équipes rencontrent bien plus souvent le premier cas que le second, mais les traitent comme un seul problème. C’est pourquoi la localisation semble interminable. Séparez-les et la charge diminue, car la partie acheminement cesse complètement d’être un travail humain. Cette distinction compte encore davantage pour les petites équipes — c’est pourquoi elle apparaît le plus nettement chez les développeurs solo et les petites équipes qui livrent rapidement.

Un test utile: parmi vos dix derniers bugs de localisation, comptez ceux qui concernaient des mots incorrects et ceux qui concernaient des mots manquants. Si la plupart étaient manquants, vous n’avez pas un problème de traduction. Vous avez un problème de plomberie, et la plomberie est automatisable, contrairement au jugement. La même logique s’applique lorsque vous cherchez à déterminer ce que la localisation devrait réellement vous coûter.

La dérive des fichiers de locale est un problème d’acheminement déguisé en problème de traduction. Connectez votre repo une fois, et l’acheminement ne sera plus votre problème.