O i18next está obsoleto em 2026?

Lançado em 2011, muito antes de componentes React, empacotamento com Webpack ou TypeScript se tornarem padrão, o i18next dominou o ecossistema por ser flexível e onipresente, conquistando plugins para diversas stacks e respostas no StackOverflow para quase todo tipo de dúvida.

O projeto não está abandonado, correções continuam sendo lançadas regularmente. No entanto, há uma diferença marcante entre manter um motor legado em funcionamento e evoluir ativamente com as arquiteturas frontend contemporâneas.

Nos últimos anos, o frontend migrou para compilação em tempo de build, React Server Components (RSC), tree-shaking agressivo e fluxos potencializados por IA. O núcleo do i18next segue fiel ao que era há mais de uma década: um singleton em tempo de execução que resolve chaves de texto no cliente.

Principais conclusões

Modo de manutenção:

No último ano, o next-i18next registrou cerca de 63 commits (aproximadamente um por semana) e o react-i18next cerca de 157, a maioria voltada a atualizações de dependências e correções pontuais.

Penalidade pesada em runtime:

react-i18next e next-i18next injetam ~17–18 KB gzipped (~60 KB minificados) antes de renderizar qualquer palavra traduzida, quase 4x mais que o next-intlayer (~4.7 KB).

Vazamento severo de conteúdo:

Em configurações estáticas padrão, até 89.8% dos dados de localização enviados para uma página pertencem a outras rotas ou a idiomas não visualizados.

Tree-shaking inviável:

Chamadas dinâmicas como t("home.hero.title") não podem ser analisadas por empacotadores, obrigando catálogos JSON inteiros a entrarem no chunk do cliente.

Incentivos comerciais:

Os mantenedores gerenciam o Locize. Criar uma esteira de tradução por IA local e sem custos diretamente na CLI concorreria com sua fonte primária de receita.

Manutenção vs. evolução ativa

Estrelas no GitHub refletem adoção histórica em vez de fôlego arquitetural recente.

Mostrar todo o conteúdo da tabela

Mostrar todo o conteúdo da tabela

Abrir a tabela em um modal para ver todo o conteúdo claramente

Repositório	Estrelas	Total de commits	Commits / ano	Último commit
i18next/i18next
i18next/react-i18next
i18next/next-i18next
aymericzip/intlayer

Atividade nos últimos doze meses:

Uma biblioteca enxuta pode ser completa e estável. Contudo, o ferramental de i18n continua a se transformar: bundlers modernos eliminam conteúdo desnecessário em tempo de build, modelos de linguagem traduzem em CI e editores utilizam Language Servers (LSP) e agentes de IA. A dependência exclusiva de plugins em tempo de execução impede que o i18next acompanhe essa evolução.

Medindo o impacto no bundle

Avaliado em build de produção com 10 rotas e 10 idiomas sob compressão gzip. Mais detalhes no relatório de benchmark de i18n.

Sobrecarga base da biblioteca

Tamanho inicial antes de adicionar qualquer texto traduzido:

Peso de página e vazamento de dados

Testado em React / TanStack Start (estratégia estática):

No Next.js:

Principais constatações

Peso de página:

No Next.js, o next-i18next adiciona 76.7 KB gzipped em relação ao projeto base (+50%). O next-intlayer acrescenta apenas 1.3 KB.

Vazamento de traduções:

Por padrão, cerca de 90% dos textos carregados em uma rota pertencem a outras páginas. A divisão manual de namespaces é desgastante e vulnerável a omissões.

Tempo de hidratação:

Componentes com react-i18next levaram 85 ms para hidratar, contra 24 ms no Intlayer. Repassar grandes estruturas JSON aos componentes atrasa a interatividade.

Por que o i18next é pesado?

Acúmulo de funcionalidades em tempo de execução

Executar integralmente no navegador requer enviar todos os módulos previamente: interpolação, regras plurais, contextos, registros de formatação e barramentos de eventos. Até mesmo a troca de uma frase simples carrega todo o motor.

Chaves dinâmicas inviabilizam o tree-shaking

Como "hero.title" é interpretada dinamicamente em runtime, os bundlers não têm como saber quais textos são acessados. Textos não utilizados acabam permanecendo nos pacotes do cliente.

const { t } = useTranslation("home");

return <h1>{t("hero.title")}</h1>;

const { title } = useIntlayer("hero");

return <h1>{title}</h1>;

O compilador do Intlayer identifica o que Hero.tsx realmente utiliza e remove propriedades não referenciadas antes de emitir os bundles do cliente. Veja otimização de bundle para mais esclarecimentos.

Experiência do desenvolvedor

Arquivos JSON desconexos vs. co-localização

Com o i18next, as traduções ficam isoladas em diretórios JSON separados do código. O Intlayer reúne as declarações de conteúdo junto aos componentes:

{
  "title": "Ship in every language"
}

{
  "title": "Lance em todos os idiomas"
}

import { useTranslation } from "react-i18next";

export const Hero = () => {
  const { t } = useTranslation("hero");
  return <h1>{t("title")}</h1>;
};

import { t, type Dictionary } from "intlayer";

export default {
  key: "hero",
  content: {
    title: t({
      en: "Ship in every language",
      pt: "Lance em todos os idiomas",
    }),
  },
} satisfies Dictionary;

import { useIntlayer } from "react-intlayer";

export const Hero = () => {
  const { title } = useIntlayer("hero");
  return <h1>{title}</h1>;
};

Ao mover ou excluir Hero.tsx, seus arquivos de conteúdo acompanham o componente.

Autocompletar vs. segurança estrita de tipos

Estender CustomTypeOptions concede autocompletar no editor, mas não valida a integridade das traduções. Excluir uma chave de pt/home.json não causa falha no build, gerando apenas um fallback em tempo de execução.

O Intlayer infere os tipos a partir das próprias declarações, e o strictMode faz com que traduções faltantes interrompam o build com erros claros.

Comparativo de ferramentas

A tradução e o modelo do Locize

O Locize é a solução comercial mantida pelos mesmos criadores do i18next. Sustentar projetos abertos é fundamental, mas esse arranjo gera incentivos divergentes: uma biblioteca cuja renda depende de uma plataforma SaaS de tradução tem pouco interesse em oferecer uma solução gratuita de tradução local por IA na CLI.

O Intlayer apoia um formato aberto:

• intlayer fill preenche traduções pendentes no terminal ou em pipelines de CI usando suas próprias chaves de API da OpenAI, Anthropic, Mistral ou Gemini.
• O CMS Intlayer é código aberto e pode ser hospedado via Docker Compose.
• Compilador, CLI, editor e CMS são distribuídos sob a licença Apache 2.0.

Em quais cenários o i18next ainda faz sentido?

Como melhorar minha configuração atual do i18next?

O Intlayer oferece pacotes de compatibilidade direta que preservam com exatidão as assinaturas de função das bibliotecas i18next (i18next, react-i18next e next-i18next). Não é necessário reescrever seus componentes para usufruir de uma arquitetura otimizada por compilador.

A configuração é feita com um único comando:

npx intlayer init --interactive

Essa CLI interativa:

1. Instala o pacote de compatibilidade @intlayer/i18next.
2. Configura aliases no empacotador para que suas importações habituais (useTranslation, Trans, t) apontem para o Intlayer, permitindo remover a biblioteca antiga do seu package.json.
3. Ativa imediatamente o suporte a Language Server (LSP) no editor, a eliminação de código inútil no build (tree-shaking) e fluxos locais de tradução por IA.

Para instruções passo a passo, explore nossos guias dedicados:

• Camadas de compatibilidade: Mantenha a sintaxe existente com os adaptadores para i18next, react-i18next e next-i18next.
• Migração de catálogos: Converta arquivos JSON em dicionários tipados com os guias: a partir do i18next, a partir do react-i18next ou a partir do next-i18next.
• Estratégia híbrida: Mantenha o runtime do i18next enquanto utiliza o Intlayer com o i18next para tipar e traduzir catálogos automaticamente.

Examine sua aplicação em produção com o scanner de SEO para i18n gratuito:

Leituras recomendadas

• Benchmark Next.js i18n: avaliação detalhada de performance
• react-i18next vs react-intl vs Intlayer
• O next-intl está obsoleto em 2026?
• Arquitetura orientada a compilador vs i18n declarativa