¿Cómo añado i18n a una app de Next.js construida con Cursor en 15 minutos?

Instalas una CLI, envías un prompt a Cursor, y tu proyecto de Next.js pasa de ser JSX solo en inglés a una app multilingüe funcional con enrutamiento [locale], claves generadas y sincronización automática en cada push. globalize.now es infraestructura de localización impulsada por IA que hace el trabajo de i18n que Cursor deja sin hacer: extrae las cadenas codificadas, genera claves next-intl y archivos de locale, y mantiene las traducciones sincronizadas en cada push a Git. El recorrido siguiente asume un proyecto estándar con App Router. Tiempo total en nuestro repo de pruebas: 13 minutos y 40 segundos.

¿Qué falla realmente cuando Cursor construye tu UI en Next.js?

Cursor optimiza para que la UI funcione, no para la arquitectura. Genera código a partir de instrucciones en lenguaje natural y actualiza partes del código mediante prompts, lo que significa que el JSX se escribe como lo haría una persona creando un prototipo rápido: texto en línea, sin claves, sin archivos de locale, sin segmento [locale].

Una página típica de Next.js generada por Cursor tiene este aspecto:

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

Tres cadenas codificadas en una sola página. Una app real tiene cientos repartidas en decenas de componentes. El Pages Router incluía antes una configuración i18n integrada, pero se eliminó cuando el App Router pasó a ser el predeterminado, dejando a los desarrolladores la tarea de configurar el middleware, los segmentos de ruta dinámicos y una biblioteca externa como next-intl. El comportamiento predeterminado de Cursor no hace nada de esto por ti.

El resultado es el mismo patrón que vimos en Por qué las traducciones de tu app de Lovable se rompen cada vez que lanzas: el codebase crece, las cadenas codificadas se acumulan y «añadir español el mes que viene» se convierte en una refactorización de varias semanas.

¿Cómo configuro globalize.now en un proyecto de Cursor?

Conecta tu repositorio en globalize.now. La primera conversión se ejecuta una sola vez, dentro de la app: lee el repo, sustituye las cadenas codificadas por claves y abre un pull request que tú revisas. A partir de ahí, cada push traduce lo que sea nuevo.

Si prefieres lanzar esa primera pasada desde Cursor, instala los Skills desde la raíz del proyecto:

npx skills add globalize-now/globalize-skills

La CLI detecta tu stack, elige el preset adecuado para Cursor e instala las reglas del agente en tu proyecto. En un proyecto con Next.js 16 App Router, el resultado se ve así:

✓ 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

Los archivos de los Skills se instalan junto a tus reglas de Cursor existentes. Le indican al agente de Cursor cómo gestionar la extracción de cadenas, cómo generar claves coherentes con las convenciones de next-intl y cómo configurar el segmento de ruta [locale]. Nada sale de tu máquina. Tu código no se sube a ningún sitio.

Si usas Claude Code o Codex en lugar de Cursor, la CLI instala los archivos de Skill equivalentes para esas herramientas. El flujo posterior es idéntico.

¿Cómo extrae el agente las cadenas codificadas de un codebase en Cursor?

Abre el panel del agente en Cursor y envía un prompt:

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

El agente carga las reglas instaladas, escanea los directorios app/ y components/, y te devuelve un informe. En un sitio de marketing de 12 páginas, el informe suele verse así:

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)

El agente hace lo que la documentación de next-intl llama la parte dolorosa: middleware, segmentos de ruta dinámicos, configuración de request y conversión componente a componente para usar los hooks de traducción. Tú revisas el plan y lo confirmas. El agente aplica los cambios como una única edición multiarchivo que puedes aceptar o rechazar en la vista de diff de Cursor.

¿Cómo genera las claves y los archivos de locale de next-intl?

Una vez apruebas el plan, el agente genera la estructura estándar de next-intl. El repo gana cuatro elementos nuevos:

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

Dentro de messages/en.json, las 47 cadenas extraídas se convierten en claves organizadas por espacio de nombres, agrupadas por componente o ruta:

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

El page.tsx original se reescribe para usar useTranslations en los componentes cliente y getTranslations en los componentes servidor. La separación es automática. El agente comprueba qué componentes tienen la directiva "use client" y elige el hook correcto.

Los archivos JSON de español, alemán y árabe se generan con una primera pasada de traducción que respeta un glosario que el agente construye a partir de los nombres de tus componentes y props. Los términos de marca se mantienen en inglés. El soporte RTL queda integrado en el layout: el atributo dir se define según el locale, y las propiedades lógicas de CSS sustituyen a las utilidades fijas de izquierda/derecha donde el agente puede detectarlas.

Este es el mismo patrón de extremo a extremo que aplicamos en un monorepo de producción en ¿Qué pasa cuando un agente de IA internacionaliza un monorepo real?. El formato del recorrido es el mismo; los datos de entrada son distintos.

¿Cómo funciona la sincronización con cada push a Git después de la primera ejecución?

La primera ejecución es puntual. La sincronización es permanente.

Cuando el agente termina, conectas el repo a globalize.now desde el panel. A partir de ese 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

No hace falta tener Cursor abierto. No hace falta que Claude Code esté en ejecución. La sincronización ocurre a nivel de Git, así que funciona sin importar qué herramienta escribió el último lote de UI. Cuando Cursor regenere un componente la próxima semana y añada tres botones nuevos, esos botones llegarán ya traducidos en el siguiente PR.

No hay exportación manual. No hay cola de revisión. No hay ida y vuelta con CSV. La promesa del producto es la misma que documentamos en Cómo globalizar tu app con globalize.now: configúralo una vez y sincroniza automáticamente en cada push.

¿Y si ya tienes una configuración de next-intl hecha a mano?

El agente la lee primero.

Si i18n/request.ts ya existe, el agente adopta tu configuración en lugar de sobrescribirla. Si messages/en.json ya tiene Pricing.heading, el agente reutiliza esa clave en lugar de generar una nueva. Si tu convención de espacio de nombres es pricing.heading (minúsculas, con puntos) en lugar de Pricing.heading (PascalCase, anidada), el agente se adapta a ella.

Lo único que el agente se niega a hacer es sobrescribir en silencio un archivo de locale existente. Si se produce una colisión de claves, se detiene y pregunta. Ese comportamiento está codificado en las reglas de los Skills instalados por npx skills add globalize-now/globalize-skills, no es algo que tengas que configurar tú.

globalize.now se encarga de esto. Conecta tu repositorio de Next.js y la conversión se ejecuta una sola vez, dentro de la app; los Skills de npx skills add globalize-now/globalize-skills cubren el trabajo que sigue en tu editor. Descubre cómo funciona en globalize.now.