Comment ajouter l'i18n à une application Next.js construite avec Cursor en 15 minutes ?

Vous installez un CLI, envoyez un seul prompt à Cursor, et votre projet Next.js passe d'un JSX uniquement en anglais à une application multilingue fonctionnelle avec routage [locale], clés générées et synchronisation automatique à chaque push. globalize.now est une infrastructure de localisation propulsée par l'IA qui fait le travail d'i18n que Cursor n'a pas fait: extraire les chaînes codées en dur, générer les clés next-intl et les fichiers de traduction, et garder les traductions synchronisées à chaque push Git. La démonstration ci-dessous suppose un projet App Router standard. Temps total sur notre dépôt de test: 13 minutes 40 secondes.

Qu'est-ce qui pose vraiment problème quand Cursor construit votre interface Next.js ?

Cursor optimise pour une interface fonctionnelle, pas pour l'architecture. Il produit du code à partir d'instructions en langage naturel et met à jour des parties du code via des prompts, ce qui fait que le JSX est écrit comme le ferait un humain pour un prototype rapide: texte inline, aucune clé, aucun fichier de traduction, aucun segment [locale].

Une page Next.js typique générée par Cursor ressemble à ceci:

// app/page.tsx
export default function Home() {
  return (
    <main>
      <h1>Welcome to Acme</h1>
      <p>Get started in seconds.</p>
      <button>Sign up</button>
    </main>
  )
}

Trois chaînes codées en dur sur une seule page. Une vraie application en compte des centaines réparties sur des dizaines de composants. Le Pages Router proposait autrefois une configuration i18n intégrée, mais elle a été retirée quand l'App Router est devenu le défaut, laissant aux développeurs le soin de câbler le middleware, les segments de route dynamiques et une bibliothèque externe comme next-intl. Rien dans le comportement par défaut de Cursor ne fait cela pour vous.

Le résultat, c'est le schéma que nous avons décrit dans Pourquoi les traductions de votre application Lovable se cassent à chaque déploiement: la base de code grossit, les chaînes codées en dur s'accumulent, et « ajouter l'espagnol le mois prochain » se transforme en refonte de plusieurs semaines.

Comment configurer globalize.now sur un projet Cursor ?

Connectez votre dépôt sur globalize.now. La première conversion s'exécute une seule fois, dans l'application: elle lit le dépôt, remplace les chaînes codées en dur par des clés, et ouvre une pull request que vous validez. Chaque push suivant traduit ce qui est nouveau.

Pour piloter cette première passe depuis Cursor à la place, installez les compétences depuis la racine du projet:

npx skills add globalize-now/globalize-skills

Le CLI détecte votre stack, choisit le préset adapté à Cursor, et installe des règles d'agent dans votre projet. Sur un projet Next.js 16 App Router, le résultat ressemble à ceci:

✓ Stack detected: Next.js 16 (App Router)
✓ Editor detected: Cursor
✓ Preset selected: globalize-guide + next-intl
✓ Installed 4 skill files to .cursor/rules/
Done in 1.2s

Les fichiers de compétences cohabitent avec vos règles Cursor existantes. Ils indiquent à l'agent Cursor comment gérer l'extraction des chaînes, comment générer des clés cohérentes avec les conventions next-intl, et comment câbler le segment de route [locale]. Rien ne quitte votre machine. Votre code n'est pas envoyé sur un serveur.

Si vous utilisez Claude Code ou Codex au lieu de Cursor, le CLI installe les fichiers de compétences équivalents pour ces outils. Le flux qui suit est identique.

Comment l'agent extrait-il les chaînes codées en dur d'une base de code Cursor ?

Ouvrez le panneau d'agent de Cursor et envoyez un seul prompt:

Set up i18n for this project. Use English, Spanish, German, and Arabic.

L'agent charge les règles installées, analyse les répertoires app/ et components/, et transmet son rapport. Sur un site marketing de 12 pages, le rapport ressemble généralement à ceci:

Detected Next.js 16 with App Router.
Found 47 hardcoded strings across 12 components.
Best fit: next-intl. RTL required for Arabic.

Plan:
- Install next-intl
- Move app/* into app/[locale]/*
- Generate i18n/request.ts and middleware.ts
- Extract 47 strings to messages/en.json
- Convert JSX to useTranslations / getTranslations calls

Proceed? (y/n)

L'agent fait ce que la documentation de next-intl appelle la partie pénible: middleware, segments de route dynamiques, configuration des requêtes, et conversion composant par composant pour utiliser les hooks de traduction. Vous validez le plan et confirmez. L'agent applique les changements sous forme d'une seule modification multi-fichiers, que vous pouvez accepter ou rejeter dans la vue de différences de Cursor.

Comment génère-t-il les clés et les fichiers de traduction next-intl ?

Une fois le plan approuvé, l'agent génère la structure next-intl standard. Le dépôt gagne quatre nouveautés:

i18n/
  request.ts
  routing.ts
middleware.ts
messages/
  en.json
  es.json
  de.json
  ar.json
app/
  [locale]/
    layout.tsx
    page.tsx
    ...

À l'intérieur de messages/en.json, les 47 chaînes extraites deviennent des clés à espace de noms, regroupées par composant ou par route:

{
  "Home": {
    "heading": "Welcome to Acme",
    "lede": "Get started in seconds.",
    "signupCta": "Sign up"
  }
}

Le fichier page.tsx original est réécrit pour utiliser useTranslations pour les composants clients et getTranslations pour les composants serveur. La répartition est automatique. L'agent repère quels composants portent la directive "use client" et choisit le hook adapté.

Les fichiers JSON espagnol, allemand et arabe sont générés avec une première passe de traductions qui respecte un glossaire que l'agent construit à partir des noms de vos composants et de vos props. Les termes de marque restent en anglais. La gestion RTL est intégrée à la mise en page: l'attribut dir est défini à partir de la locale, et les propriétés logiques CSS remplacent les utilitaires gauche/droite fixes lorsque l'agent peut les détecter.

C'est exactement le même schéma de bout en bout que nous avons appliqué sur un monorepo de production dans Que se passe-t-il quand un agent IA internationalise un vrai monorepo ?. Le format de la démonstration est identique ; les entrées diffèrent.

Comment fonctionne la synchronisation par push Git après la première exécution ?

La première exécution est unique. La synchronisation, elle, est permanente.

Une fois l'agent terminé, vous connectez le dépôt à globalize.now depuis le tableau de bord. À partir de là:

Push to main
   ↓
globalize.now diffs against last synced state
   ↓
New hardcoded strings get extracted + keyed
   ↓
Translations generated for every configured locale
   ↓
PR opened with locale file updates

Cursor n'a pas besoin d'être ouvert. Claude Code n'a pas besoin d'être en cours d'exécution. La synchronisation se fait au niveau Git, donc elle fonctionne quel que soit l'outil qui a écrit le prochain lot d'interface. Quand Cursor régénère un composant la semaine suivante et ajoute trois nouveaux boutons, ces boutons arrivent traduits dans la PR suivante.

Aucun export manuel. Aucune file de validation. Aucun aller-retour en CSV. La promesse produit est la même que celle décrite dans Comment internationaliser votre application avec globalize.now: configurez une fois, synchronisez automatiquement à chaque push.

Et si vous avez déjà une configuration next-intl écrite à la main ?

L'agent la lit en premier.

Si i18n/request.ts existe déjà, l'agent adopte votre configuration plutôt que de l'écraser. Si messages/en.json contient déjà Pricing.heading, l'agent réutilise cette clé plutôt que d'en générer une nouvelle. Si votre convention d'espace de noms est pricing.heading (minuscules, à points) plutôt que Pricing.heading (PascalCase, imbriqué), l'agent s'y adapte.

La seule chose que l'agent refusera de faire, c'est d'écraser silencieusement un fichier de traduction existant. En cas de collision de clés, il s'arrête et pose la question. Ce comportement est encodé dans les règles de compétences installées par npx skills add globalize-now/globalize-skills, ce n'est pas quelque chose que vous devez configurer.

globalize.now s'occupe de tout cela. Connectez votre dépôt Next.js, et la conversion s'exécute une seule fois, dans l'application ; les compétences npx skills add globalize-now/globalize-skills couvrent le travail qui suit dans votre éditeur. Découvrez comment ça marche sur globalize.now.