Aller au contenu
21 octobre 202610 min readProduct

Des traductions IA qui respectent votre format i18n

La traduction IA est douée avec les mots et négligente avec la syntaxe. Elle perd un {{firstname}}, donne à un pluriel russe les deux formes de sa source anglaise, ou écrit une accolade de moins. La phrase se lit peut-être encore bien, mais votre app salue les gens sans leur nom, affiche « 2 новых сообщений » là où le russe demande « 2 новых сообщения », ou ne peut pas formater le message du tout.

Depuis le 21 octobre, Locize fait deux choses contre cela. Dans les projets MessageFormat et Fluent, l’IA reçoit les règles de syntaxe de votre format et les formes de pluriel de la langue cible. Et chaque traduction IA et automatique, dans chaque format i18n, est vérifiée par rapport à sa source avant d’être enregistrée. Une traduction qui casserait votre app ne l’atteint pas.

Cet article présente ce qui a changé, avec les exemples que nous avons testés et les chiffres que nous avons mesurés. L’article de la semaine dernière portait sur MessageFormat dans les bibliothèques i18next ; celui-ci porte sur les traductions.

La version (v2.21.0, 21 octobre 2026)
  • La vérification avant l’enregistrement : chaque traduction IA et automatique est vérifiée par rapport à sa source, dans chaque format i18n.
  • Les règles du format dans les prompts : la syntaxe de MessageFormat et de Fluent et les formes de pluriel de la langue cible.
  • Issue 243 : des formes de pluriel qui ne correspondent pas à la langue.
  • Poids des issues et « fix with AI » : les issues qui comptent le plus, et un bouton qui demande une correction à l’IA.
  • MessageFormat v2 comme format de projet.

L’IA connaît votre format et vos langues

Dans un projet MessageFormat ou Fluent, les instructions que Locize envoie à l’IA contiennent désormais les règles de syntaxe du format et les formes de pluriel de la langue cible. Elles vont à chaque fournisseur IA avec lequel Locize traduit, Locize AI et votre propre clé OpenAI, Gemini, Mistral ou Lara, dans la traduction automatique et dans l’éditeur. En bref, les règles disent :

  • Ne traduis que le texte. Garde chaque argument, variable, fonction et option exactement comme dans la source, et n’ajoute jamais de variable.
  • Donne à un pluriel exactement les formes dont la langue cible a besoin, avec les nombres que chacune représente : pour le russe one (1, 21, 31), few (2, 3, 4), many (0, 5, 6) et other, même quand la source anglaise n’en a que deux. Garde les cas exacts comme =0.
  • En MessageFormat, garde # et l’échappement par apostrophe, et ne traduis jamais les mots-clés comme plural ou select. En Fluent, garde le marqueur par défaut *, les références de termes comme -brand et les attributs.

Voici ce que cela change pour un pluriel russe. La source anglaise :

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

Une traduction qui reprend la forme anglaise se lit bien pour 1, 5 et 21, et mal pour 2, 3 et 4 (« У вас 2 новых сообщений ») :

У вас {count, plural, one {# новое сообщение} other {# новых сообщений}}

Avec les formes dont le russe a besoin, elle affiche « 1 новое сообщение », « 2 новых сообщения », « 5 новых сообщений » et « 1,5 нового сообщения » :

У вас {count, plural, one {# новое сообщение} few {# новых сообщения} many {# новых сообщений} other {# нового сообщения}}

Écrire des règles est la partie facile, alors nous avons mesuré nos propres règles de prompt et les avons corrigées. Nous avons fait traduire par Locize AI 8 pluriels de test en russe, polonais, ukrainien et tchèque, trois fois : 96 résultats par mesure. Avec la première version de notre règle Fluent, 57 % d’un lot revenaient corrects ; avec la règle que nous avons livrée, 100 %. Message par message, le taux est passé de 76 % à 99 %. La première version demandait au modèle de garder les clés de select inchangées, et en Fluent un pluriel est un select, donc le modèle gardait souvent les variantes anglaises, ou imbriquait un second select dans l’une d’elles.

Chaque traduction IA et automatique est vérifiée avant d’être enregistrée

De bonnes règles rendent les bons résultats probables. La vérification fait en sorte que les résultats cassés restent dehors. Le workflow de traduction automatique et AI Bulk vérifient désormais chaque résultat par rapport à sa source avant de l’enregistrer, dans chaque format i18n, i18next compris :

  • il doit pouvoir être analysé ;
  • il doit garder les placeholders et les balises de la source ;
  • en MessageFormat et Fluent, un pluriel a besoin des formes de la langue cible.

Ce qui arrive à un résultat qui échoue dépend de la gravité :

  • Cassé : il ne peut pas être analysé, ou un placeholder ou une balise manque ou a été ajouté. Il n’est pas enregistré. Un résultat IA a d’abord droit à un second essai où le problème est nommé ; si cet essai échoue aussi, le fournisseur suivant prend la clé, comme si le premier n’avait rien renvoyé. Si aucun fournisseur n’y parvient, la clé reste non traduite, et vous la voyez comme telle.
  • Seules les formes de pluriel sont fausses : il est enregistré, parce qu’une forme fausse pour certains nombres vaut mieux que pas de traduction, et il est marqué pour relecture, sauf si Mark machine translations est réglé sur never dans le workflow de relecture. L’issue 243 (plus bas) montre ce qui manque.

Un exemple tiré d’un projet i18next. La source est Hi {{firstname}}, your workspace is ready., et l’IA répond Hallo, dein Workspace ist bereit. Jusqu’ici, cette réponse était enregistrée, et les utilisateurs allemands voyaient une salutation sans leur nom. Désormais, la vérification signale le {{firstname}} manquant, le modèle a droit à un second essai avec exactement ce problème dans le prompt, et s’il perd encore le placeholder, le fournisseur suivant traduit la clé.

Pour les projets i18next, la vérification dit rarement non. Nous l’avons fait tourner sur un échantillon de traductions IA enregistrées dans des projets i18next avant que la vérification existe : 0,16 % auraient échoué, presque toutes parce qu’un placeholder ou une balise avait disparu ou était apparu. Celles-ci vont désormais au fournisseur suivant au lieu d’atterrir dans vos fichiers.

Dans l’éditeur, l’assistant IA et le bouton de traduction automatique font la même vérification, mais vous laissent la décision. Une ligne sous chaque résultat indique qu’il a été vérifié, ou ce qui ne va pas, et vous appliquez le résultat ou, dans l’assistant, le rejetez :

L’assistant IA dans un projet MessageFormat : le pluriel russe proposé n’a que one et other, et la ligne en dessous indique que les formes de pluriel de count ne correspondent pas à la langue, few et many manquent

AI Bulk n’applique pas un résultat cassé, et vous dit combien il en a laissé de côté :

AI Bulk après un passage : 2 traductions n’ont pas été appliquées parce qu’elles ont échoué à la vérification

La vérification porte sur la structure, pas sur la langue. Savoir si une traduction dit la bonne chose, c’est le rôle de la Quality Estimation et de la revue IA. Et si vous traduisez avec un LLM dans votre propre pipeline, notre article Quand les traductions IA dérapent explique pourquoi les pluriels et les placeholders sont parmi les premières choses qui y tournent mal. Les détails de la vérification sont dans la documentation de la traduction automatique.

Des formes de pluriel qui correspondent à la langue (issue 243)

La vérification avant l’enregistrement a une sœur qui s’exécute sur tout ce qui est déjà dans votre projet. Dans les projets MessageFormat (v1 et v2) et Fluent, chaque pluriel est vérifié par rapport aux formes de pluriel de sa langue, dans chaque langue, la langue source comprise. L’issue 243 liste les formes manquantes avec des exemples de nombres, comme few (2, 3, 4), et les formes que la langue n’utilise jamais, comme zero en allemand : Intl ne la sélectionne jamais, donc 0 affiche la forme other.

L’issue 243 dans le panneau des issues de l’éditeur : il manque many (0, 5, 6) et few (2, 3, 4) au pluriel de count ; l’issue a le poids medium et un bouton fix with AI
  • Certaines formes ne servent à une langue que pour les millions exacts ou pour les décimales, comme le many français. Elles sont facultatives : les détails de l’issue les montrent comme non traduites (optional), jamais comme une issue.
  • Les cas exacts comptent. En anglais, =1 couvre one ; en russe non, parce que le one russe vaut aussi pour 21 et 31.
  • L’issue est un avertissement et ne bloque rien : vous enregistrez comme avant.

Dans les projets i18next, Locize crée déjà les clés de pluriel dont chaque langue a besoin (_few et _many pour le russe), donc l’issue s’applique à MessageFormat et Fluent. Tout ce qu’elle compte est dans la documentation de l’issue 243.

Poids des issues et « fix with AI »

Toutes les issues ne comptent pas autant pour les personnes qui utilisent votre app. Un placeholder manquant peut casser un écran ; un double espace ne gêne presque personne. La ligne Issue settings de la carte Translation Quality dans les réglages du projet (anciennement « Issues to ignore ») ouvre désormais une liste de toutes les issues. Pour chaque issue, vous pouvez l’ignorer, lui donner un poids (high, medium ou low) et activer fix with AI.

La boîte de dialogue Issue settings : par issue un poids, un interrupteur fix with AI et un interrupteur Ignore
La boîte de dialogue Issue settings : par issue un poids, un interrupteur fix with AI et un interrupteur Ignore
  • L’éditeur étiquette chaque issue avec son poids, et le filtre des avertissements et erreurs liste les issues high en premier.
  • « Fix with AI » ajoute un bouton à l’issue. Il ouvre l’assistant IA avec l’issue comme instruction. La réponse passe par la même vérification que toute traduction IA et n’est qu’une proposition : vous l’appliquez ou la rejetez.
  • Il n’est proposé que pour les issues qu’une IA peut corriger à partir de la source sans avoir à trancher : termes du glossaire, placeholders et arguments, formes de pluriel, longueur, ponctuation, nombres, parenthèses, URL et balises HTML.
  • Chaque utilisation coûte des tokens IA de votre plan, ou un appel à votre propre fournisseur IA, c’est pourquoi il est désactivé jusqu’à ce que vous l’activiez.

Voici « fix with AI » sur le pluriel russe de l’issue 243. L’instruction nomme les formes dont le russe a besoin, et la réponse a passé la vérification :

Fix with AI sur l’issue 243 : l’instruction à l’assistant IA nomme les catégories de pluriel russes avec des exemples de nombres, et la réponse avec one, few, many et other est marquée comme vérifiée, avec discard et set

Les nouveaux projets démarrent avec des poids par défaut. Dans les projets existants, la liste n’affiche aucun poids tant que vous n’en avez pas défini, et use the default weights les remplit en un clic. Les issues que votre projet ignore sont désormais aussi masquées dans la vue des issues de l’éditeur. Le poids par défaut de chaque issue est dans la documentation des contrôles.

MessageFormat 2 comme format de projet

Les projets peuvent désormais utiliser MessageFormat v2, le standard Unicode pour les messages, avec la coloration syntaxique, les mêmes contrôles et les mêmes règles IA que le format que vous connaissez sous le nom de MessageFormat, qui s’appelle désormais MessageFormat v1. Locize est ainsi l’un des premiers systèmes de gestion de traduction à prendre en charge MessageFormat 2 comme format de projet.

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

La traduction russe reçoit one, few, many et le fourre-tout *, et les règles IA couvrent les deux erreurs que nous avons vues le plus souvent dans nos tests : other écrit là où MessageFormat 2 demande *, ce qui rend le message invalide, et un espace juste après {{, que MessageFormat 2 garde comme texte, si bien que votre app l’affiche.

Un pluriel russe en MessageFormat 2 avec un cas exact pour 0 et les variantes one, few, many et *, avec la coloration syntaxique dans l’éditeur Locize

Dans l’éditeur, un message MessageFormat 2 est un seul texte coloré, comme un message MessageFormat v1. Pour i18next, le plugin est i18next-mf2 ; l’article de la semaine dernière le montre avec des arguments typés et la CLI, et notre tour d’horizon de MessageFormat 2 explique quand un changement en vaut la peine. Le format lui-même est décrit dans la documentation des formats i18n.

Pour commencer

  • La vérification et les règles du format ne vous demandent rien : elles s’appliquent à chaque projet qui traduit avec l’IA ou la traduction automatique.
  • Poids : ouvrez Issue settings dans la carte Translation Quality et cliquez sur use the default weights, ou définissez les vôtres.
  • « Fix with AI » : activez-le par issue dans la même liste.
  • MessageFormat v2 : choisissez-le comme format i18n quand vous créez un projet, ou plus tard dans les réglages du projet.

Si vous voulez voir la vérification sur vos propres messages, créez un projet gratuit et importez vos fichiers.

Questions fréquentes

Locize vérifie-t-il les traductions IA avant de les enregistrer ? Oui. Le workflow de traduction automatique et AI Bulk vérifient chaque traduction IA et automatique par rapport à sa source avant de l’enregistrer : elle doit pouvoir être analysée et garder les placeholders et les balises, et en MessageFormat et Fluent, un pluriel a besoin des formes de la langue cible. Un résultat IA cassé a droit à un second essai où le problème est nommé ; s’il échoue encore, le fournisseur suivant prend la clé.

Que se passe-t-il quand une traduction IA perd un placeholder ? Elle n’est pas enregistrée. Le modèle a droit à un second essai où le placeholder manquant est nommé, puis le fournisseur suivant traduit la clé ; si aucun n’y parvient, la clé reste non traduite. Dans l’éditeur, l’assistant IA et le bouton de traduction automatique affichent le problème, et vous décidez.

Comment Locize gère-t-il les pluriels russes ou polonais dans la traduction IA ? Dans les projets MessageFormat et Fluent, le prompt nomme les formes de pluriel de la langue cible avec des exemples de nombres. Un résultat auquel il manque des formes est enregistré et marqué pour relecture, et l’issue 243 liste ce qui manque. Dans les projets i18next, Locize crée les clés de pluriel dont chaque langue a besoin.

Combien coûte « fix with AI », et quelles issues peut-il corriger ? Chaque utilisation coûte des tokens IA de votre plan, ou un appel à votre propre fournisseur IA, c’est pourquoi il est désactivé jusqu’à ce que vous l’activiez par issue. Il est proposé pour les issues qu’une IA peut corriger à partir de la source sans avoir à trancher, comme les formes de pluriel, les placeholders, les termes du glossaire, la longueur et les balises, et sa réponse n’est qu’une proposition.

Locize prend-il en charge MessageFormat 2 ? Oui. MessageFormat v2 est un format de projet avec la coloration syntaxique, les mêmes contrôles et les mêmes règles IA que MessageFormat v1. Pour i18next, utilisez i18next-mf2.

Fatigué de gérer vos traductions à la main ?

Locize est le backend de gestion de traductions créé par l'équipe i18next : diffusion CDN, traduction IA, édition in-context, sans redéploiement.

Démarrez votre essai gratuit de 14 jours