Vous avez demandé à votre agent de code de traduire votre app en un seul prompt. Que vérifier avant de livrer ?

Vérifiez sept points avant de livrer une app traduite par Codex, Claude Code ou Cursor en un seul prompt : les chaînes longues tiennent-elles, les formes plurielles correspondent-elles à chaque langue, les variables ont-elles survécu, les termes restent-ils cohérents, le ton sonne-t-il juste pour un locuteur natif, chaque clé existe-t-elle dans chaque locale, et la prochaine fonctionnalité sera-t-elle seulement traduite ? globalize.now est une infrastructure de localisation propulsée par l’IA, et ce qui dérape après une traduction en un seul prompt est le plus souvent mécanique, ce qui est une bonne nouvelle : les problèmes mécaniques se vérifient.

La première passe est rarement le problème. Les agents actuels produisent rapidement des traductions lisibles. Ce qu’un prompt unique n’inclut pas, c’est une étape qui vérifie le résultat, et ces vérifications sont cette étape.

Le texte tient-il après traduction ?

Souvent non, et ce sont les boutons qui cèdent les premiers. Les recommandations du W3C sur la taille du texte en traduction notent que plus le message source est court, plus l’expansion probable est forte : un libellé de bouton de deux mots grandit proportionnellement plus qu’un paragraphe. Elles rappellent aussi que les noms composés de langues comme l’allemand ne se coupent pas forcément, et que certaines écritures demandent plus de place, à l’horizontale ou à la verticale, que le latin.

Un agent qui traduit des chaînes dans un fichier JSON ne voit jamais l’écran : il ne peut pas savoir que « Save changes » remplit désormais le bouton de bord à bord. Lancez l’app dans la locale la plus longue que vous livrez, parcourez les flux principaux et cherchez le texte tronqué, les boutons qui passent à la ligne et les en-têtes de tableau coupés. Si vous prenez en charge des langues RTL, faites la même passe dans l’une d’elles ; le guide de l’arabe et du RTL pour les apps Lovable traite de la direction du texte, que les vérifications de débordement seules ne couvrent pas.

La correction durable relève de la mise en page, pas de traductions plus courtes : laissez les conteneurs s’étendre, évitez les largeurs fixes sur le texte et cessez d’abréger pour faire tenir. Demandez à votre agent de s’en charger, car c’est du code.

Les formes plurielles correspondent-elles à la langue cible ?

Vérifiez-le tôt, car l’échec est silencieux. Unicode CLDR définit six catégories de pluriel : zero, one, two, few, many et other. L’anglais n’utilise que one et other. Le russe utilise one, few, many et other. Le gallois les utilise toutes les six, et la documentation d’i18next montre que l’arabe a lui aussi les six clés de pluriel.

Un agent qui copie la paire anglaise dans un fichier russe ou arabe produit un catalogue qui se parse et s’affiche, mais montre la mauvaise forme pour tout nombre relevant d’une catégorie absente du fichier. Aucune erreur ne sera levée. Avec i18next, rappelez-vous que la variable doit s’appeler exactement count, et la documentation précise qu’il n’y a aucun repli sur la clé simple si elle manque. Le même agent qui écrit count === 1 ? 'item' : 'items' dans un composant a le même bug avant même le début de la traduction ; ce qu’est ICU MessageFormat et pourquoi il piège les apps générées par IA traite du côté syntaxe.

La vérification est mécanique : pour chaque locale, comparez les clés de pluriel aux catégories que cette langue exige.

Les variables d’interpolation ont-elles survécu ?

Pas toujours, et un script tranche. Les variables d’interpolation comme {{name}} ou {count} doivent apparaître dans chaque traduction exactement telles qu’écrites. Les agents qui traduisent un long fichier reformulent parfois une variable, en suppriment une quand la phrase se lit mieux sans elle, ou traduisent le contenu d’une balise. Résultat : un blanc, une accolade littérale ou un plantage.

Comparez l’ensemble des variables de chaque chaîne traduite à celui de sa chaîne source. Ce court script Node le fait et signale aussi les clés présentes en anglais mais absentes d’une autre locale :

import fs from "node:fs";

const [src, ...targets] = process.argv.slice(2);
const read = (f) => JSON.parse(fs.readFileSync(f, "utf8"));
const vars = (s) =>
  [...String(s).matchAll(/\{\{?\s*[\w.]+\s*\}?\}/g)].map((m) => m[0]).sort().join(",");

const base = read(src);
let problems = 0;
for (const file of targets) {
  const loc = read(file);
  for (const [key, text] of Object.entries(base)) {
    if (!(key in loc)) { console.log(file, "missing", key); problems++; continue; }
    if (typeof text === "string" && vars(text) !== vars(loc[key])) {
      console.log(file, "variable mismatch", key); problems++;
    }
  }
}
process.exit(problems ? 1 : 0);

Lancez-le comme node check-locales.mjs locales/en.json locales/de.json locales/ru.json en CI. Il suppose des fichiers de clés à un seul niveau ; adaptez la boucle si votre catalogue est imbriqué.

La terminologie est-elle cohérente ?

Elle l’est au sein d’une même réponse, puis elle dérive d’une réponse à l’autre. Si la traduction d’une grosse app est répartie entre fichiers, sessions ou lots, rien n’impose que « workspace », « project » et le nom de votre produit sortent de la même façon à chaque fois. Vous vous retrouvez avec un bouton qui dit une chose et une page d’aide qui en dit une autre.

Écrivez les termes une fois pour toutes : un glossaire des noms de produit, des noms de fonctionnalités et des mots à ne pas traduire, puis faites-le lire par l’étape de traduction. globalize.now génère un glossaire partagé lors de la conversion du codebase : les termes existent donc comme données avant toute traduction. Sans outil, un court fichier de glossaire référencé dans les instructions de votre agent est le minimum ; l’article sur les règles AGENTS.md montre où ces instructions se placent.

Le ton sonne-t-il juste pour un locuteur natif ?

C’est la seule vérification qu’un script ne peut pas faire. Le registre, le niveau de politesse et la casse sont les endroits où les traductions one-shot sentent la machine : mauvais niveau de formalité, boutons à l’impératif qui sonnent comme des ordres, titre en capitales dans une langue où cela se lit comme un cri.

Ne relisez pas chaque chaîne. Choisissez une langue par famille de langues que vous livrez et faites relire par un locuteur natif les écrans de premier lancement, le parcours de paiement ou d’inscription et les messages d’erreur. Ce sont les écrans où le ton vous coûte des utilisateurs. Consignez ses corrections dans le glossaire pour que la prochaine exécution parte de là.

Chaque clé existe-t-elle, et chaque chaîne est-elle entrée dans le catalogue ?

Deux manques différents se ressemblent à l’écran. Une clé peut exister en anglais et manquer dans une locale, ce que le script ci-dessus détecte. Ou bien une chaîne a été codée en dur dans le composant sans jamais atteindre le catalogue, et aucune traduction ne pouvait donc la couvrir. Les agents laissent ce second cas dans les attributs, les toasts et les messages d’erreur plus souvent que dans le texte visible ; pourquoi les agents continuent d’ajouter des chaînes codées en dur décrit le schéma et la règle de lint qui l’attrape.

Passez l’app dans une locale non anglaise et parcourez-la. Tout l’anglais restant est soit une clé manquante, soit une chaîne qui n’est jamais entrée dans le système, et la correction n’est pas la même.

La prochaine fonctionnalité sera-t-elle traduite ?

Seulement si la traduction fait partie de la façon dont le code est livré, et c’est la vérification qu’une exécution à partir d’un seul prompt ne peut pas passer. Le prompt a traduit l’app telle qu’elle était cet après-midi-là. La prochaine fonctionnalité que construira votre agent arrivera en anglais, dans les mêmes fichiers, et les locales prendront du retard une fonctionnalité à la fois. Pourquoi les fichiers de traduction se désynchronisent décrit comment cela s’accumule.

C’est ici que l’approche one-shot et un pipeline se séparent. La localisation qui remonte dans la boucle de dev expose l’argument de fond ; la version pratique, c’est que la conversion a lieu une fois et que les changements suivants sont traduits là où ils sont faits. Avec globalize.now, vous connectez le dépôt dans l’app, le codebase est converti une fois, puis des jobs déclenchés par chaque push traduisent les nouvelles unités du catalogue, et les résultats arrivent sous forme de changements que vous relisez et mergez. La bibliothèque runtime et le format de catalogue restent les vôtres. Les équipes qui ont déjà un traducteur humain gardent cette étape de relecture ; elle cesse simplement d’être la seule chose entre du code en anglais seul et une release.

Si vous préférez tout garder dans vos propres scripts, le minimum est le script ci-dessus tournant en CI, plus une règle imposant que les nouvelles chaînes passent par le catalogue. Comment localiser une app générée par IA détaille tout le parcours, et le guide Claude Code couvre spécifiquement cet agent.

Par où commencer ?

Lancez le script sur vos fichiers de locale dès aujourd’hui ; cela prend une minute et vous dit si la structure est saine. Ouvrez ensuite l’app dans votre locale la plus longue et parcourez le flux de premier lancement. Si vous avez livré une app construite par IA et voulez que la conversion, la traduction et les mises à jour soient prises en charge plutôt que maintenues à la main, la page vibe coders en donne le panorama, la référence développeurs couvre les configurations d’agents, et la tarification a sa propre page.