next-intl vs react-i18next vs Lingui: qual usar em 2026

Para um projeto com App Router do Next.js, use o next-intl. Para uma SPA React, ou qualquer coisa que possa crescer além de um único framework, use o react-i18next. Se extração em tempo de compilação e bundles enxutos importam mais para você do que o tamanho do ecossistema, use o Lingui. As três são bibliotecas de i18n em runtime: elas entregam traduções aos seus componentes, e nenhuma delas escreve suas chaves ou arquivos de locale por você. O globalize.now é uma infraestrutura de localização com IA que produz essas chaves e catálogos a partir da sua base de código, e funciona com as três bibliotecas.

O que essas três bibliotecas realmente fazem?

Todas resolvem o mesmo problema de runtime: dado uma chave e um locale, retornar a string certa, corretamente pluralizada e formatada. Isso inclui interpolação, formatação de datas e números, e regras de plural via mensagens no estilo ICU.

O que nenhuma delas faz é produzir as traduções. Uma biblioteca de runtime consome um catálogo que já existe. Alguém ainda precisa encontrar cada string visível ao usuário nos seus componentes, substituí-la por uma chave e preencher um arquivo de locale para cada idioma. Essa é uma camada separada da stack, e manter as duas camadas distintas é o jeito mais rápido de fazer essa comparação fazer sentido: você vai escolher exatamente uma biblioteca de runtime, e ela não compete com a ferramenta que preenche os catálogos dela. Nossa documentação para desenvolvedores detalha essa divisão.

Quando usar o next-intl?

Quando você está no Next.js com o App Router. O next-intl é a única das três bibliotecas desenhada em torno das primitivas do App Router: Server Components assíncronos, helpers de navegação e roteamento sensíveis a locale, e APIs de metadata. Em setembro de 2026, está na versão 4 e soma cerca de cinco milhões de downloads semanais no npm, o que o torna a resposta padrão para novos projetos Next.js na prática, não só na teoria.

As mensagens seguem o ICU MessageFormat, então plurais, gênero e interpolação seguem o mesmo padrão usado pelo resto da indústria. Se a sintaxe ICU é nova para você, escrevemos um guia em linguagem simples sobre ICU MessageFormat. A contrapartida é o acoplamento: o next-intl é uma biblioteca do Next.js. Se você sair do Next.js, leva sua camada de i18n junto na migração.

Quando usar o react-i18next?

Quando você não está no Next.js, ou quando quer o maior ecossistema por trás. O react-i18next é a ligação (binding) React do i18next, e com cerca de quatorze milhões de downloads semanais no npm, é de longe a biblioteca de i18n mais usada em React. O núcleo do i18next é mantido há mais de uma década e tem plugins para quase tudo: backends que carregam catálogos via HTTP, detectores de idioma, camadas de cache, bindings para frameworks além do React.

Essa é a biblioteca que a maioria das ferramentas de codificação com IA usa por padrão. Peça ao Cursor ou ao Lovable para "adicionar traduções" a um app Vite + React e você quase sempre vai receber uma configuração do i18next. Esse padrão faz sentido: funciona em qualquer lugar, e seu formato de catálogo JSON é o mais próximo de uma língua franca que o ecossistema tem. A contrapartida é que ele é anterior aos Server Components, então no App Router exige mais integração manual do que o next-intl, e a maior parte do trabalho de tradução acontece no cliente, a menos que você configure de outra forma.

Quando o Lingui é a escolha certa?

Quando o tamanho do bundle e a ergonomia do código-fonte são sua prioridade. O Lingui, na versão principal 6 em setembro de 2026, adota uma abordagem compiler-first: você escreve as mensagens inline com macros, e o CLI dele as extrai em catálogos no momento do build. Os catálogos compilados são entregues sem sobrecarga de parsing em runtime, o que mantém o custo do i18n no seu bundle baixo.

O Lingui também padroniza o uso de arquivos PO do gettext como formato de catálogo, algo que tradutores profissionais lidam há décadas. Seus downloads semanais giram em torno de um milhão e meio, uma ordem de grandeza abaixo do react-i18next, então espere menos respostas no Stack Overflow e menos plugins de terceiros. Funciona com React em geral, não só com Next.js, mas, assim como o react-i18next, não é construído em torno das primitivas do App Router da forma que o next-intl é.

Como elas se comparam num relance?

Qual escolher para uma base de código gerada por IA?

Escolha pelo framework, como já explicado — mas saiba que a escolha da biblioteca não é onde os apps gerados por IA erram. Cursor, Claude Code e Lovable produzem strings em inglês fixas por padrão, seja qual for a biblioteca de i18n instalada, e um agente editando um componente vai continuar adicionando strings assim mesmo depois de você configurar a biblioteca.

Então a sequência real é: escolha a biblioteca de runtime que o seu framework pede, e depois resolva a extração e a manutenção de catálogos como um problema à parte. Para o caso do Next.js, documentamos a configuração completa em adicionando i18n a um app Next.js criado pelo Cursor, e a página de integração com Next.js mostra como o globalize.now prepara chaves e arquivos de locale para o next-intl antes de qualquer integração em runtime.

Você ainda precisa de infraestrutura de localização usando uma biblioteca de runtime?

Sim, porque a biblioteca só lê catálogos — produzi-los e mantê-los é a parte que consome seu tempo. O globalize.now atua nessa camada: conecte seu repositório e ele converte a base de código uma vez, substituindo strings fixas por chaves e gerando os arquivos de locale. Depois dessa conversão inicial, jobs de push traduzem as novas entradas de catálogo que seus commits introduzem.

A saída é JSON ou PO — JSON para configurações com next-intl e i18next, PO para o formato nativo do Lingui — de modo que os catálogos chegam no formato que sua biblioteca de runtime já consome. Se seu app já tem uma configuração parcial de i18n, isso também é tratado: o globalize.now funciona com i18n já existente em vez de substituí-lo. Planos e taxas de uso estão na página de preços.

Nenhuma das três bibliotecas é uma escolha errada. next-intl se você está no App Router, react-i18next se você quer o máximo de ecossistema, Lingui se você quer extração em tempo de compilação e catálogos PO. Escolha uma, mantenha suas strings fora dos componentes, e deixe a camada de catálogo cuidar do resto.