À moitié internationalisée ? Voici ce que globalize.now touche — et ce qu’il ne touche pas.

Si votre repo utilise déjà next-intl, react-i18next, i18next ou Lingui — dossiers de locales sur disque, dépendances dans package.json, fichiers de middleware ou de configuration — vous n’avez pas besoin d’un outil supplémentaire qui fait comme si vous partiez de zéro. globalize.now est une infrastructure de localisation propulsée par l’IA. En mode L1 — déjà internationalisé — le produit ignore la structure d’installation destructive et reste en mode synchronisation : il lit votre langue source, compare les autres locales lors d’un push et ouvre des pull requests avec les traductions manquantes. Cet article explique ce que ce mode touche, ce qu’il refuse de toucher et quoi faire lorsque la détection se trompe.

Pourquoi la plupart des conseils i18n supposent-ils que vous partez de zéro ?

Les textes marketing des outils i18n décrivent encore principalement le cas « greenfield » : aucune bibliothèque installée, aucun fichier de locale, aucune extraction effectuée. La plupart des codebases en production n’en sont pas là.

Au cours des dernières semaines, trois sessions initiales sans lien entre elles ont présenté le même profil : l’équipe a essayé l’i18n une fois, obtenu quelque chose de partiellement fonctionnel, puis s’est arrêtée — parce que tout retirer et recommencer semblait pire que de vivre avec ce bazar.

Si c’est votre cas, cet article s’adresse à vous.

À quoi ressemble concrètement une codebase à moitié internationalisée ?

Ces schémas reviennent sans cesse — détails anonymisés :

• Une app Next.js + next-intl dont la plupart des composants utilisent t(), mais dont les anciennes routes livrent encore de l’anglais codé en dur parce que la première vague de migration n’a jamais été terminée.
• Un projet React + i18next dont les fichiers de locale existent, mais ne contiennent que des valeurs anglaises — traduire était toujours prévu pour le trimestre suivant.
• Une arborescence messages/ où en.json est complète et es.json pratiquement vide.
• Un sélecteur de langue intégré au layout qui renvoie parfois une 404 parce que le routing n’a été migré qu’à moitié.

Aucun de ces projets n’a besoin de repartir de zéro avec globalize.now. Ils ont besoin de l’outil pour terminer le travail.

Quels signaux globalize.now analyse-t-il lors de la première exécution ?

La détection se déroule en deux étapes, pas une seule.

Commencez par pointer globalize.now vers le repo. La connexion dans l’app exécute la détection et la conversion unique pour vous. Si vous préférez que votre agent effectue cette passe en local, installez les compétences — quelques fichiers de playbook sont alors déposés dans .claude/skills/, sans rien modifier d’autre dans votre repo :

npx skills add globalize-now/globalize-skills

Invitez ensuite votre agent — Claude Code, Cursor ou Codex. L’agent lit les compétences installées et les utilise pour analyser votre repo :

Set up localization for my project

C’est lors de cette deuxième étape que la détection s’exécute réellement. L’agent recherche :

• Dépendances package.json : next-intl, react-i18next, i18next, @lingui/core, @lingui/react, @lingui/macro ou tout plugin i18next-*.
• Dossiers de locales : messages/ à la racine du repo, un dossier locales/ ou src/i18n/ avec des sous-dossiers par locale.
• Fichiers de locale existants : en.json, en.po, en.yml, en.yaml ou le fichier de la locale par défaut attendu par votre bibliothèque.
• Configuration propre au framework : i18n.config.ts, le middleware next-intl, lingui.config.js ou des équivalents.

Si au moins deux de ces signaux sont présents, le projet est traité comme L1 — déjà internationalisé — et le flux d’installation bifurque au lieu d’exécuter toute la structure greenfield. Vous trouverez plus de détails dans l’article du centre d’aide sur l’i18n existante.

Que refuse de modifier le mode L1 ?

C’est la partie qui intéresse le plus les équipes. En mode L1, globalize.now ne :

• Lance pas la passe générale d’extraction des chaînes qui analyse les composants à la recherche de littéraux codés en dur.
• Ne génère pas de nouvelles clés de traduction et ne réorganise pas la structure de clés que vous avez déjà commitée.
• Ne crée pas de fichiers de locale pour les langues que vous n’avez pas encore configurées.
• N’injecte pas de sélecteur de langue. Si vous en avez un, il reste en place. Si vous n’en avez pas, nous n’en ajoutons pas.
• Ne réécrit pas le routing, le middleware ni la configuration du framework à votre place.

Votre configuration i18n existante reste la vôtre. Nous ne la refactorisons pas dans ce mode.

Que fait le mode synchronisation L1 après la détection ?

L1 privilégie la synchronisation. Une fois la détection terminée :

1. Nous lisons vos fichiers de locale existants pour comprendre la structure actuelle des clés et déterminer quelle langue fait foi.
2. Vous connectez le repo GitHub via la CLI ou l’app web de globalize.now.
3. À chaque push vers votre branche main, nous comparons le fichier de la langue source aux autres locales. Les traductions manquantes sont générées par l’IA en respectant le glossaire et le guide de style que vous avez configurés.
4. Une pull request arrive avec les fichiers de locale mis à jour. Vous la relisez et la mergez. Nous ne mergons jamais à votre place.

C’est toute la boucle. Pas de dashboard de traduction à surveiller. Pas d’exports manuels. Pas de jonglage entre formats de fichiers.

Comparez avec le parcours L0 présenté dans Comment ajouter l’i18n à une app Next.js créée avec Cursor en 15 minutes ? — même produit, point d’entrée différent.

Que se passe-t-il si seule une partie de l’interface utilise des appels de traduction ?

C’est la forme normale d’une migration en cours : les nouveaux écrans utilisent t(), tandis que les écrans historiques laissent encore passer des littéraux. En dehors du mode synchronisation, le pipeline des compétences traite les chaînes déjà associées à des clés comme verrouillées : il se concentre sur les littéraux qui ne sont pas encore connectés et préserve les clés existantes. Les équipes qui livrent chaque semaine alors que la migration est à moitié terminée sont l’utilisateur type « L1 mixte » dans nos logs.

Pour découvrir une conversion complète par agent sur une arborescence complexe, consultez Que se passe-t-il lorsqu’un agent d’IA internationalise un vrai monorepo ?.

Que faire si le flux d’installation a quand même tout généré ?

Nous renforçons la logique de détection afin que la mauvaise branche ne soit plus sélectionnée. Mais si npx skills add globalize-now/globalize-skills a déjà produit un diff de plus de 100 fichiers qui réécrit votre dossier de locales, ajoute un sélecteur que vous n’avez pas demandé ou remodèle le routing, ne commitez pas. Utilisez le widget de feedback — en bas à droite — avec votre liste de dépendances package.json et une brève description de l’organisation de vos dossiers de locales : nous pourrons basculer le repo manuellement en L1. Un flag CLI --existing-i18n en libre-service sera bientôt disponible.

La récupération sur votre machine consiste à appliquer git restore ., puis git clean -fd si nécessaire. Rien n’a été pushé, rien côté production n’a été cassé ; l’agent n’a touché qu’à votre branche locale. Le compte rendu complet se trouve dans globalize_skills a effectué trop de changements — que s’est-il passé ?.

Pourquoi « on a essayé l’i18n et on a calé » est-il devenu le scénario par défaut ?

Ce n’est pas un slogan — c’est un schéma qui se répète. Trois sessions indépendantes de première prise en main en six semaines, trois variantes de « oui, on a essayé ; maintenant, c’est bancal ». Une extension Chrome utilisée par des dizaines de milliers de personnes a subi un pic de trafic en Corée et déclenché une migration next-intl à moitié terminée. Une app créée avec Lovable a cassé son propre build en ajoutant le multilingue, puis a été revertée. Un repo React + Vite codé au feeling a branché i18next, rempli environ un tiers des clés, puis s’est arrêté là.

Le codebase parfaitement propre qui cherche simplement une librairie existe bel et bien, mais ce n’est pas le goulot d’étranglement. Le vrai problème, c’est le codebase qui a déjà tenté le coup et dont plus personne ne veut assumer les conséquences.

Le mode L1 est fait pour ce codebase.

Combien ça coûte ?

20 € par mois. Un seul plan. Environ 16 000 mots inclus — soit à peu près 80 écrans d’app classiques. 5 € de crédit de traduction à l’inscription. Que vous soyez en L0, sur un projet greenfield, ou en L1, à traîner trois ans de dette de locales, le prix reste le même — nous mesurons le volume traité et l’automatisation, pas le niveau de pagaille du premier commit.

Quels articles et documents du centre d’aide devrais-je lire ensuite ?

• Guide de configuration L0 pour une app Next.js dans Cursor
• Étude de cas monorepo — ce qu’un agent a réellement modifié
• Pourquoi les outils TMS classiques peinent avec les stacks modernes et Git-native
• Centre d’aide : j’ai déjà l’i18n — que fait globalize.now ?
• Centre d’aide : globalize_skills a effectué trop de changements

Publiez les langues que votre trafic attend déjà — connectez le repo sur globalize.now, ou découvrez comment l’automatisation via Git push s’intègre à un workflow d’équipe existant.