Como adicionar i18n a um aplicativo Next.js criado no Cursor em 15 minutos?

Você instala uma única CLI, envia um prompt ao Cursor, e seu projeto Next.js passa de um JSX só em inglês para um app multilíngue funcional, com roteamento [locale], chaves geradas e sincronização automática a cada push. globalize.now é uma infraestrutura de localização baseada em IA que faz o trabalho de i18n que o Cursor deixou passar: extrair strings hardcoded, gerar chaves next-intl e arquivos de locale, e manter as traduções sincronizadas a cada push no Git. O passo a passo abaixo parte de um projeto padrão com App Router. Tempo total no nosso repositório de teste: 13 minutos e 40 segundos.

O que realmente quebra quando o Cursor constrói sua UI em Next.js?

O Cursor otimiza para uma UI funcional, não para arquitetura. Ele gera código a partir de instruções em linguagem natural e atualiza trechos de código via prompts, o que significa que o JSX é escrito como um humano escreveria um protótipo rápido: texto direto no código, sem chaves, sem arquivos de locale, sem segmento [locale].

Uma página típica de Next.js gerada pelo Cursor se parece com isto:

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

Três strings hardcoded em uma única página. Um app de verdade tem centenas delas espalhadas por dezenas de componentes. O Pages Router costumava vir com uma configuração de i18n embutida, mas ela foi removida quando o App Router se tornou o padrão, deixando para os desenvolvedores a tarefa de configurar middleware, segmentos de rota dinâmicos e uma biblioteca externa como o next-intl. Nada no comportamento padrão do Cursor faz isso por você.

O resultado é o padrão que já vimos em Por que as traduções do seu app no Lovable quebram a cada deploy: a base de código cresce, as strings hardcoded se acumulam, e “adicionar espanhol mês que vem” vira um refactor de várias semanas.

Como eu configuro o globalize.now em um projeto Cursor?

Conecte seu repositório em globalize.now. A primeira conversão roda uma única vez, dentro do app: ela lê o repositório, substitui as strings hardcoded por chaves e abre um pull request para você revisar. A partir daí, todo push traduz o que houver de novo.

Para conduzir essa primeira passagem a partir do Cursor, instale as skills a partir da raiz do projeto:

npx skills add globalize-now/globalize-skills

A CLI detecta sua stack, escolhe o preset certo para o Cursor e instala as regras de agente no seu projeto. Em um projeto Next.js 16 com App Router, a saída é assim:

✓ 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

Os arquivos de skill ficam junto das suas regras existentes do Cursor. Eles dizem ao agente do Cursor como lidar com a extração de strings, como gerar chaves consistentes com as convenções do next-intl e como configurar o segmento de rota [locale]. Nada sai da sua máquina. Seu código não é enviado para lugar nenhum.

Se você usa Claude Code ou Codex em vez do Cursor, a CLI instala os arquivos de skill equivalentes para essas ferramentas. O fluxo a partir daí é idêntico.

Como o agente extrai strings hardcoded de uma base de código no Cursor?

Abra o painel de agente do Cursor e envie um único prompt:

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

O agente carrega as regras instaladas, escaneia os diretórios app/ e components/, e retorna um relatório. Em um site institucional com 12 páginas, o relatório costuma ser assim:

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)

O agente está fazendo o que a documentação do next-intl chama de parte dolorosa: middleware, segmentos de rota dinâmicos, configuração de requisições e a conversão componente por componente para usar hooks de tradução. Você revisa o plano e confirma. O agente aplica as mudanças como uma única edição multi-arquivo que você pode aceitar ou rejeitar na visualização de diff do Cursor.

Como ele gera as chaves e os arquivos de locale do next-intl?

Depois que você aprova o plano, o agente gera a estrutura padrão do next-intl. O repositório ganha quatro novidades:

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, as 47 strings extraídas viram chaves organizadas em namespaces, agrupadas por componente ou rota:

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

O page.tsx original é reescrito para usar useTranslations nos componentes client e getTranslations nos componentes server. A divisão é automática. O agente identifica quais componentes têm a diretiva "use client" e escolhe o hook correto.

Os arquivos JSON em espanhol, alemão e árabe são gerados com traduções de primeira passagem que respeitam um glossário construído pelo agente a partir dos nomes dos seus componentes e props. Termos de marca permanecem em inglês. O suporte a RTL já vem configurado no layout: o atributo dir é definido a partir do locale, e propriedades lógicas de CSS substituem utilitários fixos de esquerda/direita onde o agente consegue detectá-los.

Esse é o mesmo padrão de ponta a ponta que aplicamos em um monorepo de produção em O que acontece quando um agente de IA internacionaliza um monorepo real?. O formato do passo a passo é o mesmo; os insumos é que mudam.

Como funciona a sincronização via Git push depois da primeira execução?

A primeira execução acontece uma única vez. A sincronização é para sempre.

Depois que o agente termina, você conecta o repositório ao globalize.now pelo dashboard. A partir daí:

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

O Cursor não precisa estar aberto. O Claude Code não precisa estar rodando. A sincronização acontece na camada do Git, então funciona não importa qual ferramenta tenha escrito o próximo lote de UI. Quando o Cursor regenerar um componente semana que vem e adicionar três botões novos, esses botões chegam já traduzidos no próximo PR.

Não existe exportação manual. Não existe fila de revisão. Não existe ida e volta de CSV. A promessa do produto é a mesma que documentamos em Como globalizar seu app com globalize.now: configure uma vez, sincronize automaticamente a cada push.

E se você já tiver uma configuração de next-intl feita manualmente?

O agente a lê primeiro.

Se i18n/request.ts já existir, o agente adota sua configuração em vez de sobrescrevê-la. Se messages/en.json já tiver Pricing.heading, o agente reaproveita essa chave em vez de gerar uma nova. Se sua convenção de namespace for pricing.heading (minúsculo, com pontos) em vez de Pricing.heading (PascalCase, aninhado), o agente se adapta a ela.

A única coisa que o agente se recusa a fazer é sobrescrever silenciosamente um arquivo de locale existente. Se houver colisão de chaves, ele para e pergunta. Esse comportamento está codificado nas regras de skill instaladas por npx skills add globalize-now/globalize-skills, não é algo que você precisa configurar.

O globalize.now resolve isso. Conecte seu repositório Next.js e a conversão roda uma única vez, dentro do app; as skills do npx skills add globalize-now/globalize-skills cuidam do trabalho que vem depois, direto no seu editor. Veja como funciona em globalize.now.