blog 18ways

i18n Está Quebrado: Pare de Escrever Chaves de Tradução

Uma forma nativa de IA de fazer i18n no Next.js, sem prejudicar o SEO.

Internacionalização (muitas vezes abreviada para i18n), localização (l10n) e suporte multilíngue descrevem a mesma ideia: adaptar seu produto para que as pessoas possam usá-lo no próprio idioma.

i18n Ainda é Construído Como se Fosse 2005

Toda empresa acaba percebendo que precisa dar suporte a vários idiomas. Nesse ponto, o time de produto se recosta como um mecânico, puxa o ar entre os dentes e diz: “Quantas páginas estamos falando? Isso dá pelo menos quatro sprints.”

Uma reação, no estilo de um mecânico, ao custo e ao esforço do trabalho tradicional de i18n

A forma subjacente como implementamos i18n não mudou em 20 anos. A maioria das “boas práticas” de i18n foi definida muito antes das arquiteturas web modernas, e tudo o que veio depois foi simplesmente sobreposto a elas.

I18n é a única parte do desenvolvimento web moderno que ainda envolve exportar arquivos e enviá-los para alguém. É considerado um setup moderno se, em vez de mandar por e-mail, você os envia por meio de uma API.

Num mundo de pipelines de CI e deploys medidos em minutos, em vez de dias, provavelmente devemos nos considerar sortudos por não precisar enviar nada por fax.

Por que a i18n Parece Quebrada

O desenvolvimento web moderno avançou incrivelmente rápido.

Temos:

Ainda assim, os fluxos de trabalho de internacionalização continuam parecendo pertencer a outra era.

Mesmo aplicações relativamente pequenas acabam rapidamente tendo que lidar com:

Os desenvolvedores não começam querendo construir sistemas assim. Eles acabam entrando nisso por acidente, quando obstáculos comuns de i18n pegam de surpresa desenvolvedores que não estão familiarizados com o fato de que idiomas diferentes estruturam frases de formas completamente diferentes… e acabam aceitando, a contragosto, o status quo definido há 20 anos.

Com o tempo, a internacionalização se torna uma das partes mais complexas da stack.

A UI moderna não cabe dentro de strings de tradução

Considere uma interface simples:

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

Isto é fácil de entender. É simples.

Em algum momento, decidimos internacionalizá-lo. Então, extraímos o texto para um arquivo de tradução:

json
{
  "mainPage": {
    "greeting": "Hello world",
    "cta": "<0>Click here</0> to view your <1>{{description}}</1>"
  }
}

E referenciamos isso no nosso código:

jsx
<h1>{t('mainPage.greeting')}</h1>
<p>
  <Trans key="mainPage.cta">
    <a href="#/">Click here</a> to view your <b>{{ description: serverResponse.productDescription }}</b>
  </Trans>
</p>

Mas, espere, agora temos texto em inglês tanto no nosso código quanto no nosso arquivo de tradução? Sim. Diferentes bibliotecas de i18n colocam verniz diferente nisso, mas tentar traduzir texto que é parcialmente formatado ao extraí-lo para um arquivo JSON legível por humanos é uma batalha perdida.

A UI moderna é estruturada, mas os sistemas de tradução são construídos sobre a base de strings planas.

Quando entram em cena marcação, variáveis e conteúdo dinâmico, a abstração começa a vazar.

Conteúdo dinâmico e gerado por usuários quebram a i18n tradicional

As coisas ficam ainda mais difíceis quando o conteúdo não é estático.

Tome este exemplo novamente:

jsx
<b>{serverResponse.productDescription}</b>

Essa string vem de uma API. Como transformamos isso em uma chave de tradução?

Spoiler: você não precisa. Agora seu backend também precisa dar suporte à internacionalização.

Seu backend agora precisa gerenciar:

De repente, os tradutores também precisam ter acesso aos sistemas de backend.

E o problema só aumenta quando conteúdo gerado por usuários entra em cena.

Avaliações. Comentários. Anúncios em marketplaces. Fóruns.

Os pipelines tradicionais de i18n partem do pressuposto de que os desenvolvedores controlam todo o texto. Cada vez mais, isso simplesmente não é verdade.

O fato de empresas como a Amazon terem começado a experimentar avaliações de usuários traduzidas em 2026 diz muito sobre o quão lentamente o ecossistema de i18n evoluiu.

A Detecção de Localidade Ainda É uma Bagunça

Até mesmo determinar qual idioma um usuário quer é surpreendentemente complicado.

Os navegadores enviam preferências de idioma pelo cabeçalho Accept-Language:

text
Accept-Language: en-GB,en;q=0.9,fr;q=0.8

Isso diz ao servidor:

  1. Prefira o inglês britânico
  2. Então qualquer forma de inglês
  3. Então qualquer forma de francês

Na prática, implementar isso corretamente envolve:

Muitos frameworks deixam a maior parte dessa lógica para os desenvolvedores.

Até mesmo a detecção básica de localidade muitas vezes vira código personalizado da aplicação.

Troca de idioma é uma ideia de última hora

A infraestrutura de tradução é só metade do problema.

Ainda assim, os usuários precisam de um jeito de trocar de idioma.

A maioria das bibliotecas de i18n fornece a camada de tradução, mas deixa o resto do problema para o desenvolvedor:

Esses detalhes parecem pequenos, mas rapidamente se tornam uma quantidade significativa de infraestrutura da aplicação, especialmente se você não estiver familiarizado com todas as complexidades de i18n. A maioria das empresas e dos desenvolvedores não está.

O atalho: tradução automática de sites

Diante de toda essa complexidade, algumas equipes recorrem a ferramentas automáticas de tradução de sites. Essas plataformas prometem traduzir seu site automaticamente com o mínimo de esforço.

Várias empresas estão construindo versões cada vez mais sofisticadas dessa ideia. Infelizmente, elas introduzem um conjunto diferente de problemas:

O resultado costuma ser um site que, tecnicamente, oferece suporte a vários idiomas, mas entrega uma experiência visivelmente pior e é uma caixa-preta para os desenvolvedores trabalharem.

Como Chegamos Até Aqui

Começamos com algo lindamente simples:

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

E acabaram com chaves de tradução, dicionários JSON, pipelines fragmentados, camadas de localização separadas entre backend e frontend e ferramentas externas de tradução.

Aplicativos web modernos são sistemas incrivelmente sofisticados. Ainda assim, as ferramentas de i18n esperam fluxos de trabalho pensados para outra época, como uma Ferrari com manivela para dar partida no motor.

Repensando o Modelo

E se a internacionalização fosse mais ou menos assim?

jsx
<h1><T>Hello world!</T></h1>
<p>
  <T>
    <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
  </T>
</p>

Sem chaves de tradução.

Sem dicionários JSON.

Sem pipelines manuais.

Só texto.

Uma Abordagem Diferente

Essa ideia é a base por trás do 18ways.

18ways trata a tradução como uma preocupação otimizada em tempo de execução. Extrair chaves de tradução e gerenciar arquivos de tradução é um problema para máquinas, não para humanos.

Os desenvolvedores simplesmente marcam o texto que querem traduzir.

Nos bastidores, a 18ways:

Tudo continua compatível com SSR e seguro para SEO.

Traduções com Consciência de Contexto

Sistemas tradicionais de i18n perdem o contexto.

Um tradutor pode ver algo como:

text
home

Mas o que isso quer dizer?

Em alemão, esses significados exigem palavras completamente diferentes:

Se você tivesse que traduzir “home” para o alemão, o que preferiria ver? Uma string isolada ou a página em que ela realmente aparece?

Comparação entre traduzir uma string JSON isolada e traduzir dentro do contexto completo do site

Sistemas de tradução que só veem strings isoladas têm dificuldade com essas distinções.

A 18ways analisa traduções no contexto da UI real.

Nossos agentes de backend revisam as traduções conforme elas aparecem nas páginas reais e otimizam para:

Para quem conhece substantivos compostos em alemão, não se preocupe: a detecção de overflow também está incluída.

Capacitando Tradutores Humanos

Tudo o que ajuda a IA a produzir traduções melhores também ajuda tradutores humanos.

O 18ways oferece aos tradutores o mesmo ambiente sensível ao contexto que nossos agentes de IA usam.

Em vez de editar arquivos JSON, os tradutores revisam o texto diretamente na UI em que ele aparece.

Isso melhora drasticamente a precisão da tradução e a eficiência do fluxo de trabalho.

Como é uma i18n melhor

A internacionalização não precisa de outra camada de chaves de tradução, arquivos de strings e cola de pipeline.

Aplicativos modernos já têm a estrutura, o contexto e as informações de tempo de execução de que precisamos para fazer isso melhor.

A próxima geração de i18n deve ser construída para apps renderizados no servidor, conteúdo dinâmico, fluxos de trabalho nativos de IA e tradutores humanos trabalhando lado a lado.

Essa é a direção que a 18ways está tomando.

Alterando idioma