O Caso a Favor e Contra a i18n Baseada em Compilador

Se você tem construído aplicações web por mais de uma década, sabe que a Internacionalização (i18n) sempre foi um ponto de atrito. Frequentemente é a tarefa que ninguém quer fazer — extrair strings, gerenciar arquivos JSON e se preocupar com regras de pluralização.

Recentemente, uma nova onda de ferramentas de i18n "baseadas em compilador" surgiu, prometendo fazer essa dor desaparecer. A proposta é sedutora: Basta escrever o texto nos seus componentes e deixar a ferramenta de build cuidar do resto. Sem chaves, sem imports, apenas magia.

Mas, como em todas as abstrações na engenharia de software, magia tem um preço.

Neste post do blog, exploraremos a mudança das bibliotecas declarativas para abordagens baseadas em compilador, as dívidas arquitetônicas ocultas que elas introduzem e por que o jeito "chato" pode ainda ser o melhor para aplicações profissionais.

Uma Breve História da Tradução

Para entender onde estamos, precisamos olhar para onde começamos.

Por volta de 2011–2012, o cenário do JavaScript era muito diferente. Bundlers como os conhecemos hoje (Webpack, Vite) não existiam ou estavam em sua infância. Estávamos juntando scripts diretamente no navegador. Nessa época, bibliotecas como i18next nasceram.

Elas resolveram o problema da única forma possível na época: Dicionários em tempo de execução. Você carregava um enorme objeto JSON na memória, e uma função buscava as chaves dinamicamente. Era confiável, explícito e funcionava em qualquer lugar.

Avançando para hoje. Temos compiladores poderosos (SWC, bundlers baseados em Rust) que conseguem analisar Árvores de Sintaxe Abstrata (AST) em milissegundos. Esse poder deu origem a uma nova ideia: Por que gerenciar chaves manualmente? Por que o compilador não pode simplesmente ver o texto "Hello World" e substituí-lo para nós?

Assim, nasceu o i18n baseado em compilador.

O Encanto do Compilador (A Abordagem "Mágica")

Há uma razão pela qual essa nova abordagem está em alta. Para um desenvolvedor, a experiência é incrível.

1. Velocidade e "Flow"

Quando você está concentrado, parar para pensar em um nome de variável (home_hero_title_v2) quebra seu fluxo. Com a abordagem do compilador, você digita <p>Welcome back</p> e continua. O atrito é zero.

2. A Missão de Resgate do Legado

Imagine herdar uma base de código enorme com 5.000 componentes e zero traduções. Adaptar isso para um sistema manual baseado em chaves é um pesadelo que dura meses. Uma ferramenta baseada em compilador atua como uma estratégia de resgate, extraindo instantaneamente milhares de strings sem que você precise tocar manualmente em um único arquivo.

3. A Era da IA

Este é um benefício moderno que não devemos ignorar. Assistentes de codificação com IA (como Copilot ou ChatGPT) geram naturalmente JSX/HTML padrão. Eles não conhecem seu esquema específico de chaves de tradução.

• Declarativo: Você precisa reescrever a saída da IA para substituir o texto por chaves.
• Compilador: Você copia e cola o código da IA, e ele simplesmente funciona.

A Verificação da Realidade: Por que a "Magia" é Perigosa

Embora a "magia" seja atraente, a abstração apresenta vazamentos. Confiar em uma ferramenta de build para entender a intenção humana introduz fragilidade arquitetural.

1. Fragilidade Heurística (O Jogo de Adivinhação)

O compilador precisa adivinhar o que é conteúdo e o que é código.

• className="active" é traduzido? É uma string.
• status="pending" é traduzido?
• O <MyComponent errorMessage="An error occurred" /> é traduzido?
• Um ID de produto como "AX-99" é traduzido?

Inevitavelmente, você acaba "lutando" contra o compilador, adicionando comentários específicos (como // ignore-translation) para evitar que ele quebre a lógica da sua aplicação.

2. O Limite Rígido dos Dados Dinâmicos

A extração pelo compilador depende de análise estática. Ele precisa ver a string literal no seu código para gerar um ID estável. Se sua API retorna uma string de código de erro como server_error, você não pode traduzi-la com um compilador porque ele não sabe que essa string existe em tempo de build. Você é forçado a construir um sistema secundário "apenas em tempo de execução" só para dados dinâmicos.

3. "Explosão de Chunks" e Cascatas de Rede

Para permitir tree-shaking, as ferramentas de compilação frequentemente dividem as traduções por componente.

• A Consequência: Uma única visualização de página com 50 pequenos componentes pode disparar 50 requisições HTTP separadas para pequenos fragmentos de tradução. Mesmo com HTTP/2, isso cria um efeito cascata na rede que faz sua aplicação parecer lenta em comparação ao carregamento de um único pacote de idioma otimizado.

4. Sobrecarga de Performance em Tempo de Execução

Para tornar as traduções reativas (para que atualizem instantaneamente quando você troca de idioma), o compilador frequentemente injeta hooks de gerenciamento de estado em cada componente.

• O Custo: Se você renderizar uma lista de 5.000 itens, estará inicializando 5.000 hooks useState e useEffect apenas para texto. Isso consome memória e ciclos de CPU que bibliotecas declarativas (que normalmente usam um único provedor Context) economizam.

A Armadilha: Vendor Lock-in

Este é, sem dúvida, o aspecto mais perigoso da i18n baseada em compilador.

Em uma biblioteca declarativa, seu código-fonte contém a intenção explícita. Você possui as chaves. Se trocar de biblioteca, basta alterar a importação.

Em uma abordagem baseada em compilador, seu código-fonte é apenas texto em inglês. A "lógica de tradução" existe apenas dentro da configuração do plugin de build. Se essa biblioteca deixar de ser mantida, ou se você ultrapassar suas limitações, ficará preso. Você não pode "ejetar" facilmente porque não há nenhuma chave de tradução no seu código-fonte. Você teria que reescrever manualmente toda a sua aplicação para migrar para outra solução.

O Outro Lado: Riscos da Abordagem Declarativa

Para ser justo, a forma tradicional declarativa também não é perfeita. Ela tem seu próprio conjunto de "armadilhas".

1. Inferno dos Namespaces: Frequentemente, você precisa gerenciar manualmente quais arquivos JSON carregar (common.json, dashboard.json, footer.json). Se esquecer algum, o usuário verá as chaves brutas.
2. Carregamento Excessivo: Sem uma configuração cuidadosa, é muito fácil carregar acidentalmente todas as suas chaves de tradução para todas as páginas no carregamento inicial, inchando o tamanho do seu bundle.
3. Descompasso de Sincronização: É comum que chaves permaneçam no arquivo JSON muito tempo depois do componente que as utiliza ter sido deletado. Seus arquivos de tradução crescem indefinidamente, cheios de "chaves zumbi".

O Meio-Termo do Intlayer

É aqui que ferramentas como o Intlayer estão tentando inovar. O Intlayer entende que, embora compiladores sejam poderosos, magia implícita é perigosa.

O Intlayer oferece um comando único chamado transform. Em vez de apenas fazer mágica na etapa oculta de build, ele pode realmente reescrever o código do seu componente. Ele escaneia seu texto e o substitui por declarações explícitas de conteúdo na sua base de código.

Isso lhe dá o melhor dos dois mundos:

1. Granularidade: Você mantém suas traduções próximas aos seus componentes (melhorando modularidade e tree-shaking).
2. Segurança: A tradução torna-se código explícito, não uma mágica oculta em tempo de build.
3. Sem Aprisionamento: Como o código é transformado em uma estrutura declarativa padrão dentro do seu repositório, você não está escondendo lógica em um plugin do webpack.

Conclusão

Então, qual você deve escolher?

Se você é um Desenvolvedor Júnior, um Fundador Solo ou está construindo um MVP: A abordagem baseada em compilador é uma escolha válida. Ela permite que você avance incrivelmente rápido. Você não precisa se preocupar com estruturas de arquivos ou chaves. Você simplesmente constrói. A dívida técnica é um problema para o "Você do Futuro".

Se você está construindo uma Aplicação Profissional, de Nível Empresarial: Mágica geralmente é uma má ideia. Você precisa de controle.

• Você precisa lidar com dados dinâmicos provenientes de backends.
• Você precisa garantir desempenho em dispositivos de baixo custo (evitando explosões de hooks).
• Você precisa garantir que não fique preso a uma ferramenta de build específica para sempre.

Para aplicativos profissionais, Gerenciamento Declarativo de Conteúdo (como Intlayer ou bibliotecas consolidadas) continua sendo o padrão ouro. Ele separa suas preocupações, mantém sua arquitetura limpa e garante que a capacidade do seu aplicativo de falar múltiplos idiomas não dependa de um compilador "caixa preta" tentando adivinhar suas intenções.