Pourquoi les Fichiers de Localisation Traduits Cassent les Applications (et Ce Qui Doit Rester Intact)

Un Fichier de Localisation Est du Code avec des Phrases Dedans

Les fichiers de langue PO, YAML, .properties, RESX, XLIFF et JSON ressemblent à des listes de phrases, mais seules les valeurs sont du texte rédigé. Les clés sont des identifiants que le code recherche ; les espaces réservés sont des emplacements que le code remplit à l'exécution ; les échappements et le balisage sont une syntaxe dont dépend l'analyseur. Un traducteur qui traite toute la ligne comme du texte produira un fichier qui se lit à merveille et ne se charge pas, ou qui se charge puis plante la première fois qu'un écran formate un nombre. L'échec n'apparaît généralement que dans une seule langue, ce qui en fait le type de bogue le plus difficile à repérer en relecture.

Cinq Éléments Qui Doivent Survivre Intacts à la Traduction

• Clés et noms de ressources — le code recherche les chaînes par clé, donc une clé traduite n'est rien d'autre qu'une chaîne manquante.
• Espaces réservés — %s, %1$d, {0}, {name} et les arguments ICU sont remplis par le code ; en renommer ou en supprimer un casse la mise en forme ou provoque une erreur à l'exécution.
• Échappements et règles d'encodage — un fichier .properties lu avec la méthode classique Properties.load(InputStream) est traité comme du Latin-1, les autres caractères étant écrits sous forme d'échappements \uXXXX, si bien qu'un texte non latin brut peut se transformer en mojibake.
• Balisage dans les chaînes — les balises HTML, les codes en ligne XLIFF et le Markdown doivent rester équilibrés, sinon la chaîne affichée casse la page qui l'entoure.
• Structure du fichier — l'indentation YAML, les scalaires de bloc, les ancres et alias, et l'imbrication XML sont de la syntaxe ; une indentation décalée ou un nom d'ancre traduit change le sens du fichier.

Le Pluriel N'est Pas un Singulier Plus un "s"

L'anglais a deux formes de pluriel, et il est tentant de croire que toutes les langues en ont autant. Le manuel de GNU gettext montre pourquoi c'est faux : chaque langue déclare sa propre règle Plural-Forms, l'anglais utilise nplurals=2, et le russe a besoin de trois formes choisies selon les derniers chiffres du nombre. Un fichier PO traduit en russe avec seulement deux formes renseignées compile, s'exécute et affiche une grammaire incorrecte pour chaque quantité se terminant par 2, 3 ou 4. Bien gérer le pluriel, c'est produire le nombre d'entrées msgstr qu'exige la langue cible, et non le nombre que la langue source avait par hasard.

Les Espaces Réservés Doivent Parfois Changer de Place

L'ordre des mots varie d'une langue à l'autre, si bien qu'une phrase contenant deux valeurs doit souvent les placer dans l'ordre inverse. Les espaces réservés positionnels comme %1$s et %2$s, ou nommés comme {count} et {user}, existent précisément pour cela : la traduction peut les réordonner, mais chacun doit rester présent exactement une fois. Les espaces réservés anonymes, comme un simple %s, ne peuvent pas être réordonnés sans risque — un problème qu'il vaut mieux corriger dans les chaînes sources avant la traduction plutôt qu'après.

Les Règles de Format à Connaître Avant de Traduire

Chaque format a ses pièges. En YAML, la spécification donne à un bloc littéral (|) et à un bloc replié (>) un comportement différent vis-à-vis des sauts de ligne, et les ancres (&) et alias (*) permettent à un nœud d'en réutiliser un autre ; les deux doivent donc passer intacts. XLIFF 2.1 enveloppe la mise en forme d'origine dans des éléments en ligne comme <ph> et <pc>, qu'une traduction doit garder en place autour des bons mots. En .NET, les ressources RESX sont recherchées par nom à l'exécution pour la culture d'interface actuelle, si bien qu'un élément data renommé bascule silencieusement vers la langue par défaut. Enfin, un fichier .properties Java traite le premier =, : ou espace non échappé comme séparateur de clé, de sorte qu'un deux-points égaré dans une clé traduite la coupe en deux.

Une Liste de Contrôle Qui Détecte la Plupart des Problèmes

1. Comptez les espaces réservés dans chaque chaîne source et cible — le multiensemble doit correspondre, même si l'ordre diffère.
2. Comparez les clés, pas les valeurs — toute clé présente dans la source et absente ou renommée dans la cible est un bogue.
3. Chargez le fichier traduit avec le vrai analyseur (msgfmt, un chargeur YAML, ResXResourceReader) avant de le livrer.
4. Vérifiez les entrées de pluriel par rapport à la règle de la langue cible, et non de la langue source.
5. Affichez la traduction la plus longue dans l'élément d'interface le plus étroit — le texte dans d'autres langues est souvent plus long que l'anglais.