Come aggiungo l'i18n a un'app Next.js costruita con Cursor in 15 minuti?

Installi una CLI, invii un prompt a Cursor, e il tuo progetto Next.js passa da JSX solo in inglese a un'app multilingue funzionante con routing [locale], chiavi generate automaticamente e sincronizzazione automatica a ogni push. globalize.now è un'infrastruttura di localizzazione basata su IA che fa il lavoro di i18n che Cursor ha saltato: estrarre le stringhe hardcoded, generare chiavi next-intl e file di traduzione, e mantenere le traduzioni sincronizzate a ogni push su Git. La guida qui sotto presuppone un progetto App Router standard. Tempo totale sul nostro repo di test: 13 minuti e 40 secondi.

Cosa non funziona davvero quando Cursor costruisce la tua UI Next.js?

Cursor ottimizza per una UI funzionante, non per l'architettura. Produce codice a partire da istruzioni in linguaggio naturale e aggiorna parti di codice tramite prompt, il che significa che il JSX viene scritto come lo scriverebbe una persona per un prototipo veloce: testo inline, nessuna chiave, nessun file di traduzione, nessun segmento [locale].

Una tipica pagina Next.js generata da Cursor si presenta così:

// 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>
  )
}

Tre stringhe hardcoded in una sola pagina. Un'app vera ne ha centinaia distribuite su decine di componenti. Il Pages Router in passato includeva una configurazione i18n integrata, ma è stata rimossa quando l'App Router è diventato predefinito, lasciando agli sviluppatori il compito di configurare middleware, segmenti di route dinamici e una libreria esterna come next-intl. Nulla nel comportamento predefinito di Cursor fa questo lavoro al posto tuo.

Il risultato è lo schema che abbiamo già descritto in Perché le traduzioni della tua app Lovable si rompono a ogni rilascio: la codebase cresce, le stringhe hardcoded si accumulano, e «aggiungiamo lo spagnolo il mese prossimo» si trasforma in un refactoring di settimane.

Come configuro globalize.now su un progetto Cursor?

Collega il tuo repository su globalize.now. La prima conversione avviene una sola volta, nell'app: legge il repo, sostituisce le stringhe hardcoded con chiavi e apre una pull request da revisionare. Ogni push successivo traduce ciò che è nuovo.

Per guidare invece quel primo passaggio da Cursor, installa le skill dalla root del progetto:

npx skills add globalize-now/globalize-skills

La CLI rileva il tuo stack, sceglie il preset giusto per Cursor e installa le regole per l'agente nel tuo progetto. Su un progetto Next.js 16 App Router, l'output è questo:

✓ 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

I file delle skill convivono con le tue regole Cursor esistenti. Indicano all'agente Cursor come gestire l'estrazione delle stringhe, come generare chiavi coerenti con le convenzioni next-intl e come configurare il segmento di route [locale]. Nulla lascia la tua macchina. Il tuo codice non viene caricato da nessuna parte.

Se usi Claude Code o Codex invece di Cursor, la CLI installa i file delle skill equivalenti per quegli strumenti. Il flusso a valle è identico.

Come estrae l'agente le stringhe hardcoded da una codebase Cursor?

Apri il pannello dell'agente in Cursor e invia un prompt:

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

L'agente carica le regole installate, scansiona le directory app/ e components/ e restituisce un report. Su un sito marketing di 12 pagine, il report si presenta tipicamente così:

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'agente sta facendo ciò che la documentazione di next-intl definisce la parte più faticosa: middleware, segmenti di route dinamici, configurazione delle richieste e conversione componente per componente all'uso di hook di traduzione. Rivedi il piano e confermi. L'agente applica le modifiche come un'unica modifica multi-file che puoi accettare o rifiutare nella vista diff di Cursor.

Come genera le chiavi next-intl e i file di traduzione?

Dopo aver approvato il piano, l'agente genera la struttura standard di next-intl. Il repo guadagna quattro elementi nuovi:

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

All'interno di messages/en.json, le 47 stringhe estratte diventano chiavi con namespace, raggruppate per componente o route:

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

L'originale page.tsx viene riscritto per usare useTranslations per i componenti client e getTranslations per i componenti server. La suddivisione è automatica. L'agente legge quali componenti hanno la direttiva "use client" e sceglie l'hook corretto.

I file JSON per spagnolo, tedesco e arabo vengono generati con traduzioni di prima bozza che rispettano un glossario costruito dall'agente a partire dai nomi dei tuoi componenti e delle tue prop. I termini di brand restano in inglese. La gestione RTL è integrata nel layout: l'attributo dir viene impostato in base alla lingua, e le proprietà logiche CSS sostituiscono le utility fisse sinistra/destra dove l'agente riesce a rilevarle.

È lo stesso schema end-to-end che abbiamo applicato a un monorepo di produzione in Cosa succede quando un agente IA internazionalizza un monorepo reale?. Il formato della guida è lo stesso; gli input sono diversi.

Come funziona la sincronizzazione a ogni push su Git dopo la prima esecuzione?

La prima esecuzione avviene una sola volta. La sincronizzazione è per sempre.

Una volta che l'agente ha finito, colleghi il repo a globalize.now nella dashboard. Da quel momento:

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 non deve essere aperto. Claude Code non deve essere in esecuzione. La sincronizzazione avviene a livello Git, quindi funziona indipendentemente da quale strumento abbia scritto il prossimo lotto di UI. Quando Cursor rigenera un componente la settimana successiva e aggiunge tre nuovi pulsanti, quei pulsanti arrivano già tradotti nella prossima PR.

Non c'è alcun export manuale. Nessuna coda di revisione. Nessun andirivieni di file CSV. La promessa del prodotto è la stessa che abbiamo descritto in Come globalizzare la tua app con globalize.now: configuralo una volta, sincronizzazione automatica a ogni push.

E se hai già una configurazione next-intl scritta a mano?

L'agente la legge per prima cosa.

Se i18n/request.ts esiste già, l'agente adotta la tua configurazione invece di sovrascriverla. Se messages/en.json ha già Pricing.heading, l'agente riutilizza quella chiave invece di generarne una nuova. Se la tua convenzione di namespace è pricing.heading (minuscolo, con punti) invece di Pricing.heading (PascalCase, annidato), l'agente si adegua.

L'unica cosa che l'agente si rifiuterà di fare è sovrascrivere silenziosamente un file di traduzione esistente. Se si verifica una collisione di chiavi, si ferma e chiede conferma. Questo comportamento è codificato nelle regole delle skill installate da npx skills add globalize-now/globalize-skills, non è qualcosa che devi configurare tu.

globalize.now se ne occupa. Collega il tuo repository Next.js: la conversione avviene una sola volta, nell'app; le skill npx skills add globalize-now/globalize-skills coprono il lavoro successivo nel tuo editor. Scopri come funziona su globalize.now.