A internacionalização (frequentemente abreviada para i18n), a localização (l10n) e o suporte multilíngue descrevem todos a mesma ideia: adaptar o seu produto para que as pessoas possam usá-lo na sua própria língua.

i18n Ainda É Construído Como Se Fosse 2005

Toda a empresa eventualmente percebe que precisa de suportar múltiplas línguas. Nesse momento, a equipa de produto recosta-se como um mecânico, suga o ar pelos dentes e diz: "Quantas páginas estamos a falar? Isso são pelo menos quatro sprints."

A forma subjacente como implementamos a i18n não mudou nos últimos 20 anos. A maioria das "melhores práticas" de i18n foi formada muito antes das arquiteturas web modernas, e tudo o que se seguiu foi simplesmente adicionado por cima delas.

A I18n é a única parte do desenvolvimento web moderno que ainda envolve a exportação de ficheiros e o envio para 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 implementações medidas em minutos em vez de dias, devemos provavelmente considerar-nos sortudos por não termos de enviar nada por fax.

Por que a i18n parece estar avariada

O desenvolvimento web moderno avançou de forma incrivelmente rápida.

Temos:

• componentes renderizados no servidor
• interface de streaming
• executores de borda
• implantação contínua
• Ferramentas nativas de IA

No entanto, os fluxos de trabalho de internacionalização ainda parecem pertencer a uma era diferente.

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

• chaves de tradução
• ficheiros de tradução JSON
• pipelines de tradução manual
• lógica de localização isolada do frontend vs backend
• ferramentas de gestão de tradução

Os desenvolvedores não se propõem a construir sistemas assim. Eles acabam tropeçando nisso, à medida que obstáculos comuns de i18n atrapalham desenvolvedores que não estão familiarizados com a forma como diferentes línguas estruturam as frases de maneira completamente diferente... e aceitam relutantemente o status quo estabelecido há 20 anos.

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

A UI moderna não se encaixa dentro de strings de tradução

Considere uma interface 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 algum momento decidimos internacionalizá-lo. Assim, 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 quanto no nosso arquivo de tradução? Sim. Diferentes bibliotecas de i18n aplicam diferentes formatações, mas tentar traduzir texto que está parcialmente formatado ao retirá-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.

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

Conteúdo Dinâmico e Gerado pelo Usuário Quebra a i18n Tradicional

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

Pegue este exemplo novamente:

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

Essa string está a vir de uma API. Como podemos transformá-la numa chave de tradução?

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

O seu backend deve agora gerir:

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

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

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

Avaliações. Comentários. Listagens de mercado. Fóruns.

As pipelines de i18n tradicionais assumem que os desenvolvedores controlam todo o texto. Cada vez mais, isso simplesmente não é verdade.

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

A Detecção de Localização Continua a Ser um Caos

Até mesmo determinar qual língua um utilizador deseja é surpreendentemente complicado.

Os navegadores 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 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 isto corretamente envolve:

• analisando pesos de qualidade
• normalizando locais (en, en-GB, en-US)
• idiomas suportados correspondentes
• manipulação da lógica de fallback
• respeitando as sobreposições explícitas do utilizador

Muitos frameworks deixam a maior parte desta lógica a cargo dos desenvolvedores.

Mesmo a deteção básica de localidade muitas vezes torna-se código de aplicação personalizado.

A Mudança de Idioma É uma Reflexão Tardia

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

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

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

• seletor de idiomas
• roteamento de localidade
• persistência de cookies
• Canonicalização de URL
• hreflang tags para SEO

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

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

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

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

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

O resultado é frequentemente um site que suporta tecnicamente vários idiomas, mas oferece uma experiência visivelmente pior, sendo uma caixa preta para os desenvolvedores trabalharem.

Como Chegámos Aqui

Começámos com algo lindamente simples:

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

E acabamos 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. No entanto, as ferramentas de i18n esperam fluxos de trabalho projetados para uma era diferente, como um Ferrari com uma manivela para dar partida ao motor.

Repensar o Modelo

E se a internacionalização parecesse mais assim?

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

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

Os desenvolvedores simplesmente marcam o texto que desejam traduzir.

Nos bastidores, 18ways:

• extrai as strings
• gera traduções usando IA
• armazenar os resultados em cache
• serve HTML traduzido diretamente do servidor

Tudo continua a ser amigável para SSR e seguro para SEO.

Traduções Conscientes do Contexto

Sistemas de i18n tradicionais perdem contexto.

Um tradutor pode ver algo como:

home

Mas o que é que isso significa?

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

• Haus - uma casa
• Página inicial - a página inicial
• Iniciar - um rótulo de navegação
• ao início - voltar ao início

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

Sistemas de tradução que apenas veem strings isoladas têm dificuldades com estas distinções.

A 18ways analisa traduções no contexto da interface do utilizador real.

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

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

Para quem está familiarizado com os substantivos compostos em alemão, não se preocupe, 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.

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

Em vez de editar ficheiros JSON, os tradutores revisam o texto diretamente na interface do utilizador onde aparece.

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

Como é um melhor i18n

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

As aplicações modernas já possuem a estrutura, o contexto e as informações de execução de que precisamos para fazer isso 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 trabalhando lado a lado.

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