i18n está avariada: parem de escrever chaves de tradução

A internacionalização (muitas vezes abreviada para i18n), a localização (l10n) e o suporte multilingue descrevem todos a mesma ideia: adaptar o seu produto para que as pessoas o possam usar na sua própria língua.

i18n Ainda Foi Construído Como Se Fosse 2005

Todas as empresas acabam por perceber que precisam de suportar vários idiomas. Nessa altura, a equipa de produto recosta-se, como um mecânico, puxa ar pelos dentes e diz: “Quantas páginas estamos a falar? Isso são pelo menos quatro sprints.”

A forma subjacente como implementamos i18n não mudou em 20 anos. A maioria das “boas práticas” de i18n foram definidas muito antes das arquiteturas web modernas, e tudo o que veio depois limitou-se a ser colocado por cima delas.

A i18n é a única parte do desenvolvimento web moderno que ainda envolve exportar ficheiros e enviá-los a alguém. É considerado uma configuração moderna se, em vez de os enviar por e-mail, os carregar através de uma API.

Num mundo de pipelines de CI e deploys medidos em minutos em vez de dias, provavelmente devemos dar-nos por felizes por não termos de enviar fax para nada.

Porque é que o i18n Parece Partido

O desenvolvimento web moderno avançou incrivelmente depressa.

Temos:

• componentes renderizados no servidor
• interface de utilizador em streaming
• runtimes na edge
• implementação contínua
• Ferramentaria nativa de IA

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

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

• chaves de tradução
• Ficheiros de tradução JSON
• pipelines de tradução manuais
• lógica de localização isolada no frontend vs no backend
• ferramentas de gestão de traduções

Os programadores não começam por querer construir sistemas assim. Entram neles às apalpadelas, à medida que os obstáculos comuns da i18n põem em apuros programadores que não estão familiarizados com a forma como línguas diferentes estruturam frases de maneiras completamente diferentes… e aceitam relutantemente o estado das coisas definido há 20 anos.

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

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

Considere uma IU simples:

<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 determinado momento, decidimos internacionalizá-lo. Por isso, extraímos o texto para um ficheiro de tradução:

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

E fazemos referência a isso no nosso código:

<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, espera: agora temos texto em inglês tanto no nosso código como no ficheiro de tradução? Sim. Diferentes bibliotecas de i18n dão-lhe uma demão diferente, mas tentar traduzir texto que está parcialmente formatado, extraindo-o para um ficheiro JSON legível por humanos, é uma batalha perdida.

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

Assim que entram em cena markup, variáveis e conteúdo dinâmico, a abstração começa a deixar escapar coisas.

Conteúdo Dinâmico e Gerado pelo Utilizador Quebra a i18n Tradicional

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

Vejamos este exemplo novamente:

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

Essa string vem de uma API. Como é que a transformamos numa chave de tradução?

Spoiler: não. Agora o seu backend também precisa de suportar internacionalização.

O seu backend tem agora de gerir:

• os dados semânticos originais
• variantes traduzidas
• lógica de fallback
• deteção de idioma

Os tradutores, de repente, também precisam de acesso a sistemas de backend.

E o problema só cresce quando entra em cena conteúdo gerado pelo utilizador.

Avaliações. Comentários. Listagens no marketplace. Fóruns.

As pipelines tradicionais de i18n partem do princípio de que os programadores controlam todo o texto. Cada vez mais, isso simplesmente não é verdade.

O facto de empresas como a Amazon terem começado a experimentar avaliações de utilizadores traduzidas em 2026 diz muito sobre a lentidão com que o ecossistema de i18n evoluiu.

A Deteção de Localidade Ainda É uma Confusão

Até determinar que idioma um utilizador pretende é surpreendentemente complicado.

Os browsers enviam preferências de idioma através do cabeçalho Accept-Language:

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

Isto diz ao servidor:

1. Prefira inglês britânico
2. Depois, qualquer forma de inglês
3. Depois, qualquer tipo de francês

Na prática, implementar isto corretamente implica:

• análise de pesos de qualidade
• normalização de localidades (en, en-GB, en-US)
• correspondência entre idiomas suportados
• lidar com lógica de fallback
• respeitando substituições explícitas do utilizador

Muitas frameworks deixam a maior parte desta lógica a cargo dos programadores.

Até a deteção básica de localidade muitas vezes acaba por se tornar código de aplicação personalizado.

A Mudança de Idioma é uma ideia tardia

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

Os utilizadores ainda precisam de uma forma de mudar de idioma.

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

• comutadores de idioma
• roteamento por locale
• persistência de cookies
• canonização de URLs
• tags hreflang para SEO

Estes detalhes parecem pequenos, mas rapidamente se tornam numa quantidade significativa de infraestruturas da aplicação, especialmente se não estiver familiarizado com todas as complexidades da i18n. A maioria das empresas e dos programadores não está.

O Atalho: Tradução Automática de Websites

Perante toda esta complexidade, algumas equipas recorrem a ferramentas automáticas de tradução de websites. Estas plataformas prometem traduzir o seu site automaticamente com um esforço mínimo.

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

• as traduções acontecem frequentemente do lado do cliente
• o SEO falha
• conteúdo carregado dinamicamente não pode ser traduzido sem um piscar de idioma incorreto
• o controlo do programador desaparece

O resultado é muitas vezes um site que, tecnicamente, suporta vários idiomas, mas oferece uma experiência visivelmente pior e é uma caixa negra para os programadores trabalharem.

Como Acabámos Aqui

Começámos com algo maravilhosamente simples:

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

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

As aplicações web modernas são sistemas incrivelmente sofisticados. Ainda assim, as ferramentas de i18n pressupõem fluxos de trabalho concebidos para outra era, como um Ferrari com uma manivela para pôr o motor a trabalhar.

Repensar o Modelo

E se a internacionalização se parecesse mais com isto?

<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.

Apenas texto.

Uma Abordagem Diferente

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

O 18ways trata a tradução como uma preocupação de runtime optimizada. Extrair chaves de tradução e gerir ficheiros de tradução é um problema para máquinas, não para humanos.

Os programadores limitam-se a marcar o texto que querem traduzir.

Nos bastidores, o 18ways:

• extrai as strings
• gera traduções usando IA
• guarda os resultados em cache
• fornece HTML traduzido diretamente a partir do servidor

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

Traduções com Consciência do Contexto

Os sistemas tradicionais de i18n perdem o contexto.

Um tradutor poderá ver algo assim:

home

Mas o que é que isso quer dizer?

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

• Haus — uma casa
• Startseite — a página inicial
• Start - uma etiqueta de navegação
• zum Anfang — regressar ao início

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

Os sistemas de tradução que só veem cadeias isoladas têm dificuldade em lidar com estas distinções.

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

Os nossos agentes de backend analisam as traduções à medida que aparecem em páginas reais e otimizam para:

• contexto
• consistência
• restrições de layout
• qualidade da tradução

Para quem está familiarizado com substantivos compostos alemães, não se preocupem, a deteção de overflow também está incluída.

Capacitar Tradutores Humanos

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

O 18ways fornece aos tradutores o mesmo ambiente consciente do contexto que os nossos agentes de IA usam.

Em vez de editar ficheiros JSON, os tradutores revisam o texto diretamente na UI onde ele aparece.

Isto 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, ficheiros de strings e cola de pipeline.

As aplicações modernas já têm a estrutura, o contexto e a informação de execução de que precisamos para fazer isto melhor.

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

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