Comment localiser une app générée par l’IA

Ce guide explique comment internationaliser puis localiser une app générée par l’IA : clés, fichiers de traduction, extraction, glossaires et automatisation capable d’absorber les changements rapides de l’interface. globalize.now est une infrastructure de localisation propulsée par l’IA qui garde ces catalogues alignés avec Git à chaque push : vous configurez une fois, synchronisez automatiquement à chaque push et évitez les allers-retours manuels de fichiers. Pour comprendre pourquoi les codebases conçues d’abord avec l’IA ignorent souvent la couche i18n, lisez Le code IA a cassé la localisation — et personne ne l’a réparée. Pour le contexte sectoriel à travers les différentes générations d’outils, consultez Les trois étapes du développement de la localisation — et pourquoi l’IA change tout. Pour choisir l’ordre des fournisseurs quand les repos sont encore désordonnés, lisez globalize.now vs Lokalise vs Crowdin et le guide pratique Comment internationaliser votre app avec globalize.now.

---

Que signifie réellement « localiser une app générée par l’IA » ?

La localisation (l10n) correspond à ce que voient les utilisateurs : la bonne langue, les bons pluriels, les dates, la devise et la mise en page adaptés à leur locale.

L’internationalisation (i18n) correspond à ce que font d’abord les ingénieurs : rendre les textes visibles par l’utilisateur adressables, réutilisables et sûrs à traduire à grande échelle.

La plupart des blocages du type « on ne peut pas encore localiser » sont en réalité des blocages d’i18n. Corrigez l’architecture une fois, et la localisation devient un problème d’exploitation plutôt qu’un chantier d’archéologie.

---

Que doit contenir une checklist d’architecture i18n avant de choisir les outils ?

Avant de choisir un logiciel de coordination des traductions ou un prestataire, vérifiez que ces briques existent — ou prévoyez de les introduire dans cet ordre :

• Une librairie i18n au runtime adaptée à votre stack (React, Next.js, Rails, etc.), avec un seul pattern pris en charge pour les chaînes d’interface.
• Des clés de traduction stables (namespacées et hiérarchiques), plutôt que des phrases anglaises utilisées comme identifiants.
• Des fichiers de ressources de locale (JSON, PO, YAML) versionnés dans le repo ou générés en CI.
• Des pluriels et variables au format ICU pour les phrases dynamiques comme "{count} items", afin que les traducteurs puissent réorganiser la grammaire sans risque.
• Un pipeline d’extraction des chaînes pour éviter que les nouvelles interfaces contournent silencieusement le catalogue.

---

Comment extraire les chaînes sans perdre en vélocité ?

Les repos générés par l’IA répètent souvent les mêmes libellés (« Save », « Cancel », « Learn more ») dans des dizaines de fichiers. Votre passe d’extraction doit :

1. Détecter les littéraux visibles par l’utilisateur dans les composants, les routes et les primitives d’interface partagées — tout en ignorant les chaînes techniques (classes CSS, identifiants d’analytics, URL sauf si elles sont visibles par l’utilisateur).
2. Normaliser les doublons en une seule clé avec des références, afin que les traducteurs voient une seule unité de sens.
3. Émettre une locale source (généralement l’anglais) comme valeur canonique de chaque nouvelle clé.
4. Réécrire les points d’appel pour utiliser l’API i18n choisie par votre équipe — mécaniquement, afin que le diff reste facile à relire.

Voici à quoi ressemble un avant/après minimal dans du code de style React :

<button>Submit order</button>

Après extraction et création des clés :

<button>{t("checkout.submit_order")}</button>

// locales/en.json
{
  "checkout.submit_order": "Submit order"
}

---

Pourquoi les glossaires et les guides de style sont-ils importants avant de multiplier les langues ?

La traduction automatique est rapide. Elle peut aussi donner à chaque écran l’impression de venir d’un produit différent si vous ne définissez pas de contraintes. Avant de passer à de nombreuses langues, consignez :

• Les termes de marque qui ne doivent pas être traduits (nom du produit, noms des fonctionnalités).
• Les traductions à privilégier pour les termes à risque (« contact », « essai », « facturation », « espace de travail »).
• Le ton : formel ou conversationnel, et deuxième personne ou formulation neutre.

Injectez ce glossaire dans votre stack de coordination ou votre profil de MT afin que les brouillons automatisés restent alignés sur les décisions déjà prises par votre équipe.

---

Comment les contrôles automatisés doivent-ils structurer la boucle d’assurance qualité des traductions ?

Une fois les clés intégrées aux fichiers de locales, la boucle moderne est la suivante : brouillon MT → contrôles du linter (longueur, placeholders, termes interdits) → tests de régression automatisés sur les écrans à fort impact → livraison → mesure. L’automatisation fait gagner du temps ; le linter vous évite de livrer des placeholders cassés.

Les outils de type CLI peuvent vous donner rapidement une idée du travail restant dans le repo, par exemple :

✔ Scanned 312 files
✔ Found 1,284 user-visible literals
✔ Proposed 920 translation keys (364 duplicates merged)
✔ Wrote locales/en.json

Next: sync translation-ready keys to your coordination tool or run an MT batch with glossary v1

---

Quels prompts d’agent permettent de garder les refactors de localisation faciles à relire ?

Ces prompts partent du principe que vous travaillez dans un repo avec des tests et une code review. Ils sont conçus pour produire des diffs fiables — pas des refactors massifs et silencieux.

Comment inventorier les chaînes d’interface avant un refactor ?

You are analyzing a TypeScript React codebase for localization readiness.

Task: List every pattern where user-visible English might appear (JSX text, string props that render to the DOM, template literals interpolated into UI, aria-label/title/placeholder, toasts, empty states). Exclude className values, internal IDs, and URLs that are not shown to users.

Output: a table with columns: file path, line range, example string, recommended next step (extract key / ignore / needs product decision).

Comment introduire en toute sécurité une API t() typée et minimale ?

Add a minimal i18n helper used across the app: a typed t(key, vars?) function backed by JSON locale files in /locales. Do not translate yet—only wire English as the source locale.

Constraints:
- Keys use dot namespaces: "section.component.purpose"
- Support ICU-style pluralization for keys that need counts
- Add a dev-only warning when t() is called with a missing key

Show the file tree you created and example usage in two existing components.

Comment extraire mécaniquement les littéraux vers des clés namespacées ?

Refactor the following files to replace user-visible string literals with t("…") keys.

Rules:
- Prefer stable semantic keys, not English sentences as keys
- Deduplicate identical UI strings to one key
- Keep string interpolation correct using ICU message patterns
- Do not change layout/styling except where required by the refactor

After edits, print a JSON object mapping each new key to its English source string for translators.

Comment préparer un CSV de glossaire auquel les traducteurs peuvent se fier ?

From locales/en.json and the product marketing pages in this repo, propose a glossary CSV with columns: term_en, part_of_speech, definition_for_translators, do_not_translate (true/false), allowed_synonyms, notes_for_de.

Flag terms that are legally sensitive (pricing, trials, refunds) and terms that are ambiguous in software ("session", "organization", "member").

Quel garde-fou CI empêche l’arrivée de nouvel anglais codé en dur ?

Add a CI script that fails if new user-visible English literals appear in JSX outside of tests/fixtures.

Implementation guidance:
- Use the repo's existing package manager and test runner
- Provide a small allowlist file for exceptions (brand strings, intentional English)
- Print actionable file/line references on failure

Include README notes for how engineers should add exceptions responsibly.

---

Faut-il encore coller ces prompts à la main ?

De moins en moins. À la rédaction initiale de ce guide, copier-coller des prompts dans votre agent était la manière pratique d’exécuter la boucle. Depuis, les outils ont migré directement dans l’agent : les coding agents peuvent maintenant appeler la localisation via un serveur MCP, de sorte que l’extraction, la création des clés et la synchronisation des traductions deviennent des appels d’outils effectués par l’agent, plutôt que des prompts que vous collez. Consultez Présentation du MCP de globalize.now pour la configuration, et La localisation devient une compétence d’agent, pas un SDK pour comprendre l’importance architecturale de ce changement.

Les prompts ci-dessus restent utiles comme checklists de review : ils décrivent ce qu’un bon refactor i18n piloté par un agent doit faire, qu’une personne les colle ou qu’une compétence d’agent les encode. Évaluez tout refactor automatisé selon les mêmes critères : diffs faciles à relire, clés stables, interpolation compatible avec ICU et garde-fou CI qui bloque les régressions.

---

Quelle contrainte à long terme faut-il garder en tête lors de la localisation de produits créés avec l’IA ?

La localisation n’est pas un sprint unique — c’est un contrat avec votre futur vous. Si vous investissez une fois dans les clés, les catalogues et l’automatisation, chaque nouvel écran généré par l’IA coûte moins cher à livrer dans le monde entier.