Nous vendons une infrastructure de traduction. Notre propre site marketing est disponible dans cinq locales. Lorsque nous avons audité le JSON que nous servons réellement, le premier problème n’était pas une question de ton. C’était un seul caractère incorrect au milieu d’un mot composé allemand, presque imperceptible au premier regard: une lettre cyrillique là où il fallait du latin. Le mot ressemblait à une entrée de glossaire jusqu’à ce qu’on examine le point de code. Si nos propres traductions sont défectueuses, pourquoi faire confiance au produit?
Cinq erreurs qui n’auraient jamais dû être livrées
Du cyrillique dans une interface allemande. Une ligne du glossaire contenait autrefois un mélange d’alphabets: le suffixe ressemblait à « ar » en caractères latins, mais une lettre ne l’était pas. Les lecteurs natifs le remarquent immédiatement. Le correcteur orthographique, non.
**The string:** …"Übersetzungsglossар"… (Cyrillic "р" in the compound)
**What it should be:** "Übersetzungsglossar"
**Why it matters:** It reads as corrupted text. It signals automated output nobody proofread in the target language.
Inversion du registre en allemand et en français. Le site est un outil pour développeurs. Le ton doit correspondre à la manière dont les ingénieurs écrivent réellement dans une interface produit. Nous avions utilisé le vouvoiement partout dans de et fr. Ce n’est pas un détail. Cela signifie que le parcours de traduction par défaut avait choisi le mauvais registre pour toute la surface, et pas seulement pour quelques chaînes marginales.
**The string:** "… wie Sie …" / "vous pouvez …"
**What it should be:** informal "du" / "tu" voice for product and FAQ
**Why it matters:** Every screen sounded like enterprise procurement, not like the product we sell to vibe coders.
Devise inventée. L’anglais parlait de dollars. L’allemand affichait des euros avec une mention mensuelle. Nous ne facturons pas un prix différent selon le pays. Le JSON laissait entendre le contraire.
**The string:** "20 €/Monat" (and similar) next to "$20/mo" elsewhere
**What it should be:** one USD amount, formatted per locale via code (e.g. Intl), not hand-invented symbols in JSON
**Why it matters:** Pricing trust. Mixed symbols read as either a bug or a hidden price change.
Faux amis autour de « coding ». Dans trois langues, « coding environment » a été traduit avec le mot désignant l’encodage. La FAQ expliquait aux utilisateurs qu’ils pouvaient rester dans leur « environnement d’encodage ». C’est faux, quelle que soit la manière dont on comprend le produit.
**The string:** Spanish "codificación", Italian "codifica", German "Codierung" in the wrong sense
**What it should be:** development environment wording (e.g. entorno de desarrollo / ambiente di sviluppo / Entwicklungsumgebung)
**Why it matters:** It is a semantic bug. It reads like we do not understand our own domain.
« Ship » compris comme expédition postale. Les chaînes allemandes et italiennes utilisaient des verbes associés aux colis, pas à la mise en production d’un logiciel. Même source anglaise, mauvais champ lexical. Cela venait de suggestions automatiques non corrigées, pas d’un choix stylistique délibéré.
**The string:** parcel-shipping verbs applied to "ship your app"
**What it should be:** release / deploy / deliver software wording
**Why it matters:** Developer trust. One wrong verb tells the reader the copy was never read by a developer in that language.
Pourquoi les traductions générées automatiquement dérivent
Ce n’est pas un réquisitoire contre les traducteurs. Une grande partie du site n’a jamais fait l’objet d’une relecture humaine chaîne par chaîne. Les modèles généralistes adoptent par défaut un registre formel, parce que c’est ce que l’on trouve dans les grands corpus bilingues du Web ouvert. Ils mélangent aussi des caractères proches issus de scripts différents lorsque l’objectif est de produire des « caractères plausibles », et non le « bon alphabet ». Sans glossaire, les choix de termes dérivent d’une clé voisine à l’autre. Sans règle de devise, le modèle invente des symboles locaux plausibles. Sans vérifications métier, encodage et programmation se confondent. C’est le mode d’échec que nous cherchons à réduire. Notre propre site l’a pourtant livré jusqu’à ce que nous l’auditions comme l’aurait fait un client.
Ce que nous avons construit après le nettoyage
Des corrections ponctuelles ne constituent pas un système. La partie durable, c’est un petit fichier de règles que toute l’équipe — et chaque futur lot de traduction automatique — peut traiter comme une loi, ainsi qu’un script de vérification à exécuter avant le merge.
Règles. i18n/LOCALIZATION_POLICY.md consigne le registre pour chaque locale, une tarification en USD uniquement dans le JSON, les choix concernant les emprunts — par exemple conserver vibe coders en anglais —, les règles sur les faux amis entre coding et encoding, ainsi que la typographie des littéraux inline. Il est volontairement court. Si une règle n’est pas écrite, un modèle ne l’appliquera pas de manière cohérente.
## Currency
- USD only in all locales. Use {monthlyPrice} and {overageRate} placeholders…
## False friends
- Coding environment is not encoding: Spanish desarrollo / Italian sviluppo / German Entwicklung…
Vérification. scripts/verify-translations.sh recherche du cyrillique dans les fichiers de locale latins, les symboles euro, les anciennes sous-chaînes problématiques et la parité des placeholders tarifaires avec messages/en.json. Les vérifications facultatives utilisent ripgrep lorsqu’il est installé. Le script fixe un seuil minimal, pas maximal. Il évite que le « problème corrigé une fois » ne réapparaisse discrètement lors de la prochaine modification en masse.
Du code, pas davantage de suppositions dans le JSON. Nous avons centralisé les montants en USD affichés dans lib/pricing.ts et relié formatUsdPerMonth et formatUsdOveragePer1k à la page d’accueil et à la FAQ, afin que les fichiers de locale cessent d’inventer des chiffres. Le bug ne venait pas seulement des mauvaises chaînes. Il venait aussi de l’absence de règles et de formateur en place avant le passage à l’échelle.
Ce que vous pouvez reprendre pour votre propre i18n assistée par l’IA
Si vous générez des traductions avec un modèle, le registre est le paramètre le plus variable. Verrouillez-le pour chaque locale avant d’ajouter d’autres langues. Verrouillez la devise dans le code, pas dans la prose. Verrouillez les tokens de marque et le jargon développeur. Lancez des vérifications automatisées qui font échouer le lot, au lieu de compter sur un « on vérifiera à l’œil plus tard ». Plus tard n’atteint jamais le même niveau de qualité que le premier passage.
Pour comprendre l’architecture qui sous-tend cet audit, lisez Comment localiser une application générée par l’IA et le comparatif des outils globalize.now vs Lokalise vs Crowdin. Si vous configurez l’i18n de votre propre repo et souhaitez les mêmes garde-fous, connectez le repo à globalize.now: la conversion s’exécute une fois, dans l’application; npx skills add globalize-now/globalize-skills est le point d’entrée que nous documentons pour les compétences qui s’installent à côté de votre code. Pour conclure honnêtement: nous avons utilisé notre propre produit, trouvé des bugs peu reluisants, écrit les règles et ajouté une barrière. C’est le niveau d’exigence que nous voulons pour tout lancement multilingue.
globalize.now transforme le texte codé en dur de votre application en fichiers de traduction prêts à l'emploi et les maintient à jour au fur et à mesure de vos déploiements.
Essayer globalize.now gratuitement