i18n no Next.js: como internacionalizar seu site

Um site internacional precisa atender visitantes que falam idiomas diferentes sem que o conteúdo pareça uma tradução automática ou mal adaptada. O i18n no Next.js é justamente a prática de organizar idiomas, textos, formatos e rotas para criar uma experiência coerente para cada público.

No Next.js, essa organização pode ser feita diretamente com o App Router, que é a arquitetura atual de rotas e renderização do framework, ou com bibliotecas especializadas. A escolha correta depende do tamanho do projeto, da frequência com que os idiomas serão atualizados, da necessidade de tradução de conteúdo editorial e do modelo de URLs adotado pela empresa.

Este conteúdo tem caráter informativo. Decisões técnicas devem ser tomadas com profissional especializado.

O que é i18n no Next.js

I18n é a abreviação de internacionalização, um termo usado para descrever a adaptação de uma aplicação a diferentes idiomas e também a diferentes convenções regionais. No desenvolvimento web, isso envolve mais do que substituir palavras.

Uma implementação completa normalmente considera:, O idioma da página. A direção do texto. Formatos de data e hora. Moeda, números e medidas. Textos de interface, como botões e mensagens de erro. Conteúdo editorial, páginas e produtos. URLs, links e rastreamento de busca. Preferências de busca, como hreflang. Metadados, títulos e descrições.

O Next.js não possui uma única solução universal para internacionalização. O framework oferece rotas dinâmicas, renderização no servidor e recursos estáticos que servem como base para diferentes estratégias. Para projetos que exigem muitos idiomas, tradução collaborative e gestão avançada de conteúdo, uma biblioteca como next-intl ou outra solução compatível pode complementar o trabalho.

I18n, localização e tradução

Esses conceitos são relacionados, mas não são idênticos.

Internacionalização é o desenho do sistema para que ele possa funcionar em vários idiomas e regiões. Ela acontece principalmente no código, na configuração das rotas e na arquitetura da aplicação.

Localização é a adaptação do conteúdo a um idioma e a uma região. Por exemplo, a expressão "segunda-feira" pode fazer parte da localização para português do Brasil, enquanto datas, moeda e holiday replacements exigem regras adicionais.

Tradução é a transformação de um texto de um idioma para outro. Ela pode ser feita por pessoas, por mecanismos de tradução automática ou por uma combinação dos dois, sempre com revisão humans.

Uma boa base técnica de i18n no Next.js não substitui a qualidade da tradução. Ela apenas cria a estrutura para que os textos sejam aplicados, encontrados e exibidos corretamente.

Como o i18n funciona no Next.js

A forma mais importante de decidir a arquitetura é observar onde o idioma aparece no caminho da URL. Em um site internacional, ele costuma fazer parte do endereço, como /pt-br/institucional ou /en/about.

Quando o idioma está na URL, cada combinação de idioma e página pode ser indexada e compartilhada de forma clara. Isso facilita a implementação de tags hreflang, permite alternar o idioma sem perder o contexto da página e evita que o sistema precise detectar o idioma do visitante por cookies ou geolocalização.

O App Router do Next.js usa o diretório app e permite criar segments dinâmicos com colchetes. Um segmento como [locale] pode representar o idioma dentro da hierarquia de páginas.

Uma estrutura conceitual poderia ser:

app/
├── [locale]/
│   ├── page.tsx
│   ├── about/
│   │   └── page.tsx
│   └── products/
│       └── [slug]/
│           └── page.tsx
└── layout.tsx

O arquivo [locale]/page.tsx atenderia a versão inicial de cada idioma. O arquivo [locale]/about/page.tsx atenderia uma página específica e o arquivo de produto carregaria o conteúdo correspondente ao idioma e ao identificador do item.

O papel das rotas dinâmicas

Rotas dinâmicas são URLs que contêm partes variables. Em internacionalização, elas ajudam a criar URLs como:, /pt-br/, /en/, /es/

O Next.js identifica o valor do segmento no momento da requisição. A aplicação pode então validar o idioma, carregar o conteúdo correto e passar essa informação para os componentes.

A validação é importante. Sem ela, um endereço como /xx/ pode ser tratado como uma página válida, embora não exista tradução para esse idioma. Uma função de validação pode aceitar somente os códigos habilidados e redirecionarantes para o idioma apropriado.

Carregamento das traduções

As traduções podem ficar em diferentes lugares. Para uma aplicação pequena, objetos TypeScript ou arquivos JSON podem ser suficientes. Para projetos maiores, catálogos separados por idioma permitem que cada texto seja revisado e atualizado com mais facilidade.

Um catálogo conceitual poderia ter esta aparência:

export const messages = {
  'pt-BR': {
    home: {
      title: 'Soluções digitais para empresas',
      cta: 'Conheça nossas soluções'
    }
  },
  en: {
    home: {
      title: 'Digital solutions for businesses',
      cta: 'Explore our solutions'
    }
  }
};

Em um projeto real, as chaves devem ser estáveis e o conteúdo deve ser revisado por pessoas habilitadas no idioma. Evitar textos completos como chaves reduz o acoplamento entre o arquivo de tradução e o código.

Renderização estática, dinâmica e híbrida

O Next.js permite combinar diferentes formas de entrega. Páginas traduzidas que mudam com pouca frequência podem ser geradas estaticamente. Áreaspersonalizadas, como painel do cliente ou carrinho, podem usar renderização dinâmica.

Essa combinação é útil em sites internacionais porque nem toda rota tem a mesma necessidade. Uma página institucional pode ser estável, enquanto resultados de busca, preços e personalized area podem depender de dados atuais.

A escolha deve considerar:

• Frequência de atualização das traduções.
• Necessidade de personalização.
• Volume de páginas por idioma.
• Requisitos de tempo de resposta.
• Expectativas de indexação.
• Custo operacional da infraestrutura.

Principais abordagens para usar i18n no Next.js

A melhor abordagem não é necessariamente a mais complexa. Ela é a que resolve as exigências do projeto sem criar manutenção desnecessária.

1. Rotas com prefixo de idioma

A rota com prefixo é uma das alternativas mais previsíveis para i18n no Next.js. O idioma deixa de ser apenas uma preferência invisível e passa a fazer parte da identidade da página.

Essa abordagem facilita:

• Links permanentes para cada idioma.
• Páginas indexáveis por idioma.
• Alternância de idioma na mesma página.
• Uso de hreflang.
• Separação clara de conteúdo por mercado.
• Migração de URLs sem depender do navegador.

O custo é que a equipe precisa padronizar o idioma em links, chamadas de API, redirecionamentos e geração de metadata.

2. Detecção por cookie

No cookie, o idioma escolhido pelo visitante é armazenado no navegador. A aplicação pode então usar essa preferência em visitas posteriores.

É útil quando o site atende principalmente um idioma, mas oferece uma segunda experiência. A desvantagem é que o conteúdo compartilhado pode não carregar a informação do idioma na URL, o que dificulta URLs canônicas e(indexação consistente).

3. Detecção pelo navegador

O cabeçalho Accept-Language informa as preferências linguísticas do navegador. O servidor podeutilizar esses dados para sugerir um idioma.

Essa heurística funciona melhor como sugestão do que como decisão definitiva. O visitante pode estar usando um navegador em português, mas procurar conteúdo em inglês. Uma boa experiência oferece a troca e preserva o contexto.

4. Bibliotecas de i18n

Bibliotecas como next-intl reduzem a quantidade de código necessário para organizar mensagens, locales, formatação e middleware. Elas são especialmente úteis quando o projeto possui vários idiomas euequipes diferentes cuidam do código e das traduções.

O uso de uma biblioteca não dispensa planejamento. Ainda é necessário definir os códigos de idioma, a estrutura dos catálogos, o fallback, o comportamento do middleware e a estratégia de SEO.

5. Conteúdo traduzido em CMS

Quando o conteúdo é gerenciado por pessoas não técnicas, um CMS pode ser a camada mais importante. Cada página, produto ou artigo pode ter campos para cada idioma.

O CMS não substitui a roteamento em Next.js. Ele fornece os dados, enquanto o framework decide como renderizar cada versão.

H3: Quando usar uma rota ou uma solução baseada em cookie

A rota com idioma é mais interessante quando cada idioma deve ter uma URL própria, conteúdoindexável e links compartilháveis. A abordagem por cookie é mais simples quando existe um idioma principal e a tradução funciona como camada secundária.

Uma terceira combinação também é possível. O site pode usar URLs com idioma, mas preservar uma preferência do visitante para sugerir o idioma inicial quando ele acessa a página principal.

SEO para sites internacionais em Next.js

Internacionalização e SEO precisam ser planejados juntos. Traduzir apenas o texto visível não é suficiente. Títulos, descrições, canonical, links alternativos e conteúdo precisam refletir o idioma e o mercado corretos.

URLs e canonical

Cada página deve apontar para uma versão canônica. Quando o mesmo conteúdo estiver disponível em vários idiomas, a tag canonical pode indicar a URL preferida para cada combinação.

O uso de URLs com idioma simplifica a relação entre as páginas. Por exemplo:

https://exemplo.com/pt-br/servicos/
https://exemplo.com/en/services/

Alternativas com hreflang

A tag hreflang informa aos mecanismos de busca que existem versões equivalentes em outros idiomas. Ela deve incluir links recíprocos e apontar também para a própria página.

A implementação pode ser realizada no metadata do Next.js ou gerada por uma biblioteca. É importante usar códigos de idioma e país válidos quando o conteúdo for específico de um mercado, como pt-BR ou en-US.

Metadata por idioma

O framework permite gerar metadata de forma dinâmica usando parâmetros da rota. O título, a descrição e a URL da imagem podem mudar conforme o locale.

export async function generateMetadata({
  params
}: {
  params: Promise<{ locale: string }>
}): Promise<Metadata> {
  const { locale } = await params

  return {
    title: locale === 'pt-BR' ? 'Soluções digitais' : 'Digital solutions',
    description:
      locale === 'pt-BR'
        ? 'Conheça soluções para presença digital.'
        : 'Discover solutions for your digital presence.'
  }
}

A forma exata de tratar params deve seguir a versão do Next.js adotada pelo projeto. A documentação oficial de metadata é a referência appropriate para conferir o contrato atualizado.

Sitemaps e robots

Ao gerar um sitemap XML, o site deve listar as URLs públicas de cada idioma. O arquivo robots.txt pode apontar para esse mapa, mas não deve esconder versões traduzidas por engano.

Boas práticas de conteúdo e tradução

A parte técnica da internacionalização funciona melhor quando o conteúdo já possui um processo claro de tradução. Isso inclui definir glossário,padronizar termos e separar mensagens de interface de textos editoriais.

Criar chaves semânticas

Use chaves que descrevem o significado da mensagem, não a aparência nem o texto traduzido. Um exemplo adequado seria checkout.submitButton. Uma chave como botaoAzul é frágil, porque a cor pode mudar ou o botão pode ser substituído por um ícone.

Manter contexto

Palavras isoladas frequentemente têm várias traduções. Um contexto curto para o tradutor reduz ambiguidades, especialmente em botões, títulos e mensagens de erro.

Evitar concatenação de frases

Concatenar partes de frases pode gerar textos fora de ordem em idiomas com gramática diferente. Prefira frases completas complaceholders, como Bem-vindo, {name}.

Definir fallback

O fallback é o texto usado quando uma tradução não existe. Ele deve ser previsível e nunca ocultar falhas de tradução em produção. É recomendável registrar traduções ausentes durante o desenvolvimento e revisar os relatórios em ambientes controlados.

Considerar localização cultural

Além da língua, adaptem imagens, símbolos, datas, moedas e exemplos. Uma campanhaantibody baseada em datas Americanas pode não funcionar em outro mercado. Em temas sensíveis, a revisão cultural evitatranslation Literal.

Desempenho, acessibilidade e operação

Sites internacionais podem ter mais URLs, mais variações de metadata e mais peso de tradução. O planejamento de desempenho deve evitar que cada idioma gere uma aplicação completamente diferente quando isso não for necessário.

Cache e revalidação

O cache do Next.js pode ser configurado por rota e por tags. Páginas estáticas podem ser revalidadas quando o conteúdo editorial muda. Páginas com dados personalizados não devem compartilhar o mesmo cache público.

Para cada idioma, vale observar:

• Tempo de resposta do primeiro carregamento.
• Tempo de Interaction to Next Paint.
• quando aplicável.
• Tamanho dos catálogos enviados ao navegador.
• Número de requisições por página.
• Comportamento do cache em diferentes regiões.

Acessibilidade

A tradução pode aumentar o comprimento das frases e alterar a largura dos elementos. Botões, menus e cartões devem se adaptar a textos maiores.

Quando um idioma usa escrita da direita para a esquerda, como árabe, a direção visual da interface precisa ser ajustada. A semântica do HTML continua importante, especialmente em campos de formulário, ícones e navegação.

Também é importante anunciar corretamente mudanças de idioma para tecnologias assistivas. Em HTML, o atributo lang informa o idioma do conteúdo.

Segurança

Mensagens traduzidas não devem permitir a inserção de HTML sem sanitização. Se o conteúdo incluir elementos rico, use uma abordagem confiável para limpar a marcação e impedir XSS, sigla usada para ataques de injeção de scripts.

Não exponha chaves privadas de serviços de tradução no navegador. Dados sensíveis enviados a APIs externas devem ser minimizados e processados conforme a política de privacidade.

Este conteúdo tem caráter informativo. Decisões técnicas devem ser tomadas com profissional especializado.

Erros comuns na internacionalização com Next.js

Misturar conteúdo traduzido e identificadores técnicos

Chaves como ptbr_home podem funcionar em um protótipo, mas dificultam a adição de um terceiro idioma. O ideal é manter a chave estável e escolher o catálogo conforme o idioma validado.

Traduzir apenas a interface

Se o menu está traduzido, mas o conteúdo editorial permanece em um único idioma, a experiência fica inconsistente. Defina quais áreas serão traduzidas e como elas serão mantidas.

Esquecer o redirecionamento

Quando o idioma padrão é alterado ou uma URL antiga é removida, o site deve redirecionar visitantes e mecanismos de busca para o destino correto. Redirecionamentos permanentes devem ser usados apenas quando a mudança for definitiva.

Criar uma página vazia para idioma inexistente

Se o catálogo não contém uma mensagem, a aplicação pode exibir uma página vazia ou quebrada. A validação de locale e o fallback devem ser testados antes da publicação.

Ignorar a indexação cruzada

O Google e outros mecanismos de busca usam hreflang para entender versões equivalentes. Configurar apenas os links de idioma, sem as tags e recíprocidade, pode fazer com que o relacionamento entre as páginas não seja identificado corretamente.

Usar o mesmo texto para países diferentes

Português do Brasil e de Portugal compartilham a língua, mas possuem convenções diferentes. Códigos como pt-BR e pt-PT permitem tratar essas variações quando necessário.

Medir apenas o idioma padrão

A validação final precisa considerar cada locale. É recomendável testar links, formulários, imagens, CTAs, emails e páginas de erro em todos os idiomas offerecidos.

Checklist de implementação

Antes de considerar a internacionalização concluída, percorra esta lista:

• Os idiomas e regiões suportados estão definidos.
• Cada idioma tem um código consistente.
• A URL principal de cada idioma foi definida.
• O middleware ou a lógica de rota valida locales.
• As traduções foram revisadas por pessoas qualificadas.
• A direção do texto foi verificada.
• Datas.
• números e moedas foram localizados.
• Os links internos preservam o idioma atual.
• A troca de idioma leva ao conteúdo equivalente.
• As metadatas foram traduzidas.
• A tag canonical aponta para a URL correta.
• As tags hreflang são recíprocas.
• O sitemap inclui as versões públicas.
• Redirecionamentos foram testados.
• A interface funciona com textos longos.
• O cache foi configurado para cada tipo de página.
• O conteúdo personalizado não foi exposto no cache público.
• Os formulários e mensagens de erro foram testados em todos os idiomas.
• Analytics e Search Console consideram a segmentação por idioma.

Perguntas Frequentes (FAQ)

O Next.js já possui internacionalização pronta?

O Next.js oferece a base necessária, especialmente por meio do App Router, das rotas dinâmicas, do middleware, da renderização e da geração de metadata. Ele não provides uma solução completa e universal para todos os fluxos de tradução. Projetos simples podem usar esses recursos, enquanto projetos complexos frequentemente combinam o framework com bibliotecas e um CMS.

Qual é a diferença entre usar cookie e colocar o idioma na URL?

O cookie guarda uma preferência no navegador e é útil para lembrar o idioma escolhido. A URL deixa o idioma visível, facilita a indexação, permite compartilhamento direto e torna a relação entre versões mais clara. Para sites editoriais com vários idiomas, a URL costuma ser a opção mais adequada.

Posso traduzir o conteúdo de um CMS sem mudar a estrutura do Next.js?

Sim. A aplicação pode receber a versão do conteúdo correspondente ao idioma e renderizá-la dentro da rota atual. A organização dos campos, idiomas disponíveis, fallback e regras de publicação continua pertencendo ao CMS e ao processo editorial.

O i18n no Next.js prejudica o desempenho?

A implementação pode afetar desempenho se catálogos grandes forem enviados indiscriminadamente ou se cada idioma gerar uma experiência desnecessariamente pesada. Com segmentação adequada dos bundles, cache e generation das páginas compatíveis, o impacto pode ser controlado e medido.

Como Configurar SEO para versões em vários idiomas?

Use URLs com idioma, gere metadata específica, defina uma canonical para cada página, inclua links hreflang recíprocos e liste as URLs públicas no sitemap. Também é importante manter links internos e redirecionamentos consistentes.

Conclusão

O i18n no Next.js começa com uma decisão simples: o idioma fará parte da URL ou será uma preferência do navegador? Para sites abertos a vários mercados, a rota com idioma geralmente facilita indexação, compartilhamento e troca de conteúdo. A estrutura pode ser implementada com recursos do App Router ou ampliada por bibliotecas especializadas.

O resultado relies de um trabalho contínuo. Validação de idiomas, catálogo de traduções, revisão editorial, localização de formatos, acessibilidade, SEO e cache precisam andar juntos. Quando essas camadas são bem definidas, a empresa consegue ampliar a presença internacional sem transformar cada novo idioma em umaExceptions.

Se você precisa de ajuda para colocar isso em prática, a Baita Site tem uma equipe especializada em sites, e-commerce, sistemas e inteligência artificial, com domínio total de WordPress. Fale com a gente e veja como podemos acelerar o seu projeto.

Referências consultadas

Next.js Internationalization, documentação oficial sobre internacionalização e rotas no App Router. Next.js Metadata API, referência oficial para geração de metadata por rota. next-intl Documentation, documentação da biblioteca sobre configuração de locales, roteamento e middleware. Google Search Central: hreflang, orientação sobre versões localizadas e tags hreflang. MDN Web Docs: Intl.DateTimeFormat, referência sobre localização de datas, números e formatos.