Qu’est-ce que l’ICU MessageFormat et pourquoi est-il toujours si difficile à traduire?

L’ICU MessageFormat est un standard Unicode qui permet d’écrire une chaîne traduisible s’adaptant au nombre, au genre et à d’autres variables. Il reste difficile à traduire, car sa syntaxe a été conçue pour le code, pas pour les personnes qui localisent les produits. La spécification existe depuis plus de dix ans, et les personnes qui la trouvent la plus difficile à manier sont des traducteurs non techniques face à des accolades imbriquées. globalize.now est une infrastructure de localisation propulsée par l’IA qui se situe un niveau en dessous de ce problème : elle extrait les chaînes et génère les fichiers de locale où vivent ces patterns ICU, puis les maintient synchronisés à chaque Git push.

Qu’est-ce que l’ICU MessageFormat?

L’ICU MessageFormat est une syntaxe qui permet d’exprimer un message dont la formulation finale dépend de données d’exécution. Au lieu de concaténer des fragments dans le code, vous écrivez un pattern et le formateur sélectionne la branche correcte pour chaque locale.

Son usage le plus courant concerne les règles de pluriel:

{count, plural,
  one {You have # message}
  other {You have # messages}
}

# est remplacé par le nombre, et les branches one / other correspondent aux catégories de pluriel d’une langue. L’anglais en compte deux ; le polonais, le russe et l’arabe en comptent davantage. ICU gère également le genre et d’autres choix via select:

{gender, select,
  male {He liked your post}
  female {She liked your post}
  other {They liked your post}
}

C’est pourquoi ICU est devenu le standard de fait pour les règles de pluriel : il déplace la complexité grammaticale dans des données qui peuvent varier selon la langue, plutôt que dans une logique conditionnelle qui ne fonctionne que pour la langue dans laquelle elle a été écrite. Les bibliothèques d’exécution comme FormatJS, i18next et next-intl le comprennent toutes.

Pourquoi l’ICU MessageFormat est-il si difficile à traduire?

Il est difficile à traduire parce que sa syntaxe a été conçue pour les développeurs, alors que les personnes qui traduisent réellement les chaînes ne sont généralement pas des développeurs.

En ouvrant un fichier de locale, un traducteur ne voit pas « Vous avez 3 messages ». Il voit des accolades, les mots-clés plural et select, des catégories de pluriel qu’il ne reconnaît pas forcément et un placeholder # qui ressemble à une faute de frappe. Une accolade supprimée ou une catégorie renommée suffit à faire échouer la chaîne à l’exécution au lieu de l’afficher. La structure qui rend ICU puissant pour les ingénieurs est aussi celle qui le rend fragile entre les mains d’un linguiste.

C’est le fossé avec lequel le secteur de la localisation compose discrètement depuis des années. La plupart des outils affichent le pattern brut en espérant que le traducteur ne modifiera pas le mauvais caractère, ou masquent les formes plurielles derrière un éditeur distinct qui exige toujours de comprendre les catégories de pluriel. Aucun fournisseur n’a complètement réduit l’écart entre la complexité de la spécification et le modèle mental d’un traducteur non technique.

Qu’est-ce qui a changé avec MessageFormat 2.0?

MessageFormat 2.0 est une refonte complète de la syntaxe. En 2025, il est devenu un standard stable plutôt qu’un brouillon.

MF2 a atteint le statut de Final Candidate en mars 2025 et fait désormais partie intégrante de CLDR, publié dans le cadre du standard technique Unicode LDML et affiné au fil des versions LDML 47 et 48. L’implémentation de référence suit la spécification de la version LDML 48.2, publiée début 2026. La nouvelle syntaxe sépare les entrées de la logique de correspondance et prend en charge les fonctions de formatage nommées, ce qui rend les messages complexes plus lisibles:

.input {$count :number}
.match $count
one {{You have {$count} message}}
*   {{You have {$count} messages}}

L’objectif est d’obtenir un pattern plus facile à étendre et légèrement moins hostile à la lecture que les accolades imbriquées d’origine.

MessageFormat 2.0 résout-il le problème des traducteurs?

Pas encore, pour deux raisons.

Premièrement, MF2 améliore l’ergonomie de la syntaxe, mais cela reste une syntaxe. Un traducteur rencontre toujours .match, des clés de pluriel et des accolades. La charge cognitive est moindre qu’avec MF1, mais elle n’a pas disparu. Un traducteur non technique peut toujours casser un message en modifiant le mauvais token.

Deuxièmement, presque personne ne l’exécute en production. Son adoption reste limitée jusqu’en 2026 : le processus TC39 pour JavaScript demande qu’environ une douzaine d’organisations utilisent MF2 en production avant de progresser, et ce seuil n’est pas atteint. En pratique, la plupart des apps que vous livrez aujourd’hui utilisent encore l’ICU MessageFormat d’origine via des bibliothèques comme FormatJS et i18next. Le problème côté traducteur n’est donc pas résolu par une spécification ; il l’est par l’endroit où la syntaxe est produite et maintenue.

Où l’ICU MessageFormat casse-t-il dans les apps générées par l’IA?

Il casse tôt, car les outils de code IA produisent rarement un ICU correct du premier coup.

Quand vous construisez avec Cursor, Claude Code ou Lovable, le code généré gère généralement les nombres de manière naïve:

// What an AI coding tool often generates
const label = count + " " + (count === 1 ? "message" : "messages");

Cette logique est correcte en anglais et incorrecte dans la plupart des autres langues, car elle suppose exactement deux formes de pluriel. Elle intègre également la phrase au code de l’application : il n’y a donc aucun pattern ICU dans un fichier de locale à localiser. La chaîne reste invisible pour la couche de localisation jusqu’à ce que quelqu’un remarque la grammaire incorrecte en production. Les outils d’IA dupliquent aussi les clés et dispersent le texte codé en dur dans les composants. Même les équipes qui veulent utiliser ICU se retrouvent donc avec des chaînes qui n’ont jamais été intégrées à un fichier traduisible. La présentation de globalize.now pour les développeurs est conçue pour détecter précisément cette catégorie de chaînes avant leur mise en production.

Comment les développeurs doivent-ils gérer l’ICU MessageFormat en 2026?

Traitez ICU comme une infrastructure générée, pas comme du contenu à rédiger manuellement.

La règle pratique : les développeurs et les outils d’IA ne devraient pas écrire de concaténations de pluriels dans le code, et les traducteurs ne devraient pas modifier manuellement des accolades ICU brutes. Le pattern ICU doit se trouver dans un fichier de locale généré et maintenu automatiquement, puis être rendu à l’exécution par une bibliothèque comme FormatJS, i18next ou next-intl. La syntaxe reste ainsi correcte dès sa création et cohérente dans toutes les locales à mesure que l’app évolue. Si vous cherchez à déterminer où placer ICU par rapport à votre couche runtime, la comparaison globalize.now vs i18next explique comment l’infrastructure et le runtime se répartissent le travail.

C’est la couche sur laquelle globalize.now intervient. Il extrait les chaînes codées en dur de votre codebase, génère les clés et les fichiers de locale où vivent les patterns ICU, puis les resynchronise à chaque push Git pour que la structure reste correcte sans étape d’export manuel. Il ne cherche ni à devenir l’éditeur du traducteur ni à remplacer votre bibliothèque runtime ; il s’assure que les fichiers structurés autour d’ICU dont ces outils dépendent existent réellement et restent synchronisés. Le guide pour les vibe coders présente la même configuration pour les apps créées avec Lovable, Bolt et Replit, tandis que le workflow complet est décrit sur la page d’accueil de globalize.now.