i18n vs l10n: Qual a diferença?

Assim como o famoso cardápio *secreto* do In-N-Out Burger, cada nicho de mercado tem uma linguagem secreta que, uma vez dominada, faz você se sentir parte de um grupo seleto. O setor de tradução e localização não é diferente. Sentindo sempre um certo complexo de inferioridade em comparação com nossos amigos da matemática, nossa indústria decidiu inserir números no meio de nossas palavras-chave: i18n e l10n.

Parece técnico e intimidante, não é?

Descobri que é apenas uma abreviação para internacionalização e localização .

Internacionalização , ou i18n (pronuncia-se "ai-dezoito-en"), refere-se ao trabalho de engenharia que prepara o software para ser executado em qualquer idioma. Isso é feito extraindo sequências de texto do código, lidando com a codificação de caracteres e criando formatação flexível para datas, moedas e unidades. i18n é o trabalho técnico, nos bastidores, que é feito em preparação para a localização (l10n), que é o que é feito por localidade, por mercado.

A maioria das páginas explicativas que vejo ficam um pouco confusas porque tratam os tópicos i18n e l10n como duas variações da mesma tarefa e, em seguida, passam o resto do artigo falando sobre bibliotecas de código. Não são a mesma tarefa. A internacionalização é algo que sua equipe de engenharia faz, de preferência apenas uma vez! A localização, por outro lado, é o que acontece com seu site sempre que você adiciona um novo mercado, e é o fator que determina se um visitante multilíngue se sente acolhido ao acessá-lo ou se tem a sensação de ter entrado no vale da estranheza, ou seja, se algo está errado, mas ele não consegue identificar o quê.

Essa distinção não é apenas pedantismo da minha parte (com certeza é pedantismo, mas neste caso é importante para as equipes que trabalham com localização!). Um site pode ser perfeitamente internacionalizado e ainda assim ser interpretado como "desativado" no idioma de destino. Sua equipe teve o cuidado de projetar botões que se expandem para acomodar a expansão do texto em alemão, etiquetas de preço com o símbolo de moeda correto e datas impressas em um formato familiar ao leitor. That’s i18n! Mas e a frase ao lado do botão? Parece que foi escrito por alguém que entende do mercado ou parece que passou por um aplicativo de tradução e foi impresso diretamente? Essa é a função da localização e é o fator decisivo para que o visitante clique no conteúdo ou saia do site.

O que significa, de fato, o número i18n .

Eu já disse isso antes, mas vale a pena explicar (com o perdão do trocadilho): internacionalização é um numerônimo. Pegue a primeira letra (i), a última letra (n), conte as 18 letras entre elas e voilà , você obtém i18n. É uma abreviação que pegou porque os desenvolvedores queriam uma maneira de digitar a palavra sem ter que soletrá-la cinquenta vezes em uma revisão de código. Portanto, l10n para localização e a11y para acessibilidade, etc.

Mas a abreviatura é a parte chata. O que importa é o que o curso i18n realmente faz.

É o processo de estruturar uma base de código para que ela possa suportar qualquer idioma ou localidade sem precisar ser reescrita:

• Cadeias de texto extraídas do código para arquivos externos, em vez de serem codificadas diretamente no código.
• Codificação UTF-8, portanto, caracteres acentuados e alfabetos não latinos são exibidos corretamente.
• Layout que não pressupõe que o texto seja sempre lido da esquerda para a direita.
• Os formatos de data, número e moeda são tratados como variáveis, não como pressupostos fixos.

Se bem aplicada, a disciplina i18n é como água para um peixinho dourado, invisível e despercebida (no melhor sentido possível).

l10n: a parte que nunca termina

Se i18n for o carro, então l10n é o combustível. Ao decidir adicionar o francês, você está fazendo a localização. Ao adicionar japonês, você está localizando novamente. Não se trata de uma fase concluída, mas sim de um processo repetitivo. Por isso, a localização precisa de seu próprio fluxo de trabalho, responsável e conjunto de ferramentas, mantidos separados da engenharia.

Uma equipe pode lançar um produto genuinamente internacionalizado e ainda assim falhar no quesito localização, porque localização não é apenas trocar palavras. Também pode incluir expressões idiomáticas e formalidades, além de trocas de imagens e até mesmo mudanças sutis de cor!

Onde a diferença aparece em uma página ao vivo

Os problemas de formatação são a maneira mais fácil de ver os códigos i18n e l10n funcionando separadamente.

Tomemos os números como exemplo. Nos Estados Unidos, mil dólares e cinquenta centavos é escrito como 1,000.50. Grande parte da Europa escreve o mesmo valor que 1.000,50, apenas com a vírgula e o ponto invertidos. Um campo de moeda mostra US$ 99.00 nos EUA e € 99,00 na Alemanha, com os símbolos em lados opostos. As datas se dividiram ainda mais. 03/04/2026 Significa 4th de março nos EUA e 3rd de abril em quase todo o resto do mundo, razão pela qual existe o formato ISO 8601 (AAAA-MM-DD), para evitar a ambiguidade em vez de discutir sobre isso país por país. Os códigos de idioma também seguem um padrão: a norma ISO 639-1 atribui códigos de duas letras, como de, ja e pt, de modo que um sistema de localização tenha um identificador estável para trabalhar, em vez de ter que adivinhar a partir do nome de um país.

A expansão de texto é o aspecto que as equipes de engenharia mais subestimam. Phrase’s own i18n documentation uses a shoe size as a clean illustration: a UK size 10 is a European size 38, and a US size 38 is a completely different EU 6. Agora, traduza um rótulo de interface do usuário da mesma maneira e você obterá o mesmo tipo de discrepância no comprimento das palavras. Em alemão e finlandês, os textos originais costumam ser de 20 % a 35 % mais longos que o texto em inglês, razão pela qual um botão com o rótulo "Submit" cabe perfeitamente, enquanto "Zur Kasse gehen" não, a menos que o layout tenha sido construído com contêineres flexíveis. O árabe e o hebraico, por serem línguas RTL (da direita para a esquerda), apresentam um problema completamente diferente: todo o layout é espelhado, e não apenas a direção do texto.

Nada disso é resolvido adequadamente no momento da tradução. Isso deve ser resolvido no código, por isso insisto em fazer o exercício i18n corretamente antes de começar o l10n .

O processo: construa sua casa sobre uma base sólida.

Em um ambiente saudável, a internacionalização ocorre uma única vez e a localização se repete indefinidamente sobre ela. Você extrai suas strings, define sua codificação e cria layouts flexíveis uma única vez. Em seguida, você traduz para o francês. Mais tarde, você traduz para o japonês. Mais tarde, o árabe foi adicionado, sem alterar novamente a arquitetura subjacente, pois esta foi construída desde o início para lidar com qualquer idioma.

O que atrapalha as equipes é pular a primeira etapa e tentar implementar a correção na segunda. É aí que você se depara com strings codificadas em níveis de complexidade de três componentes e seletores de data que só entendem o formato MM/DD/AAAA. No fim, o projeto de tradução se transforma em uma refatoração que ninguém havia planejado.

Precisamos reconstruir nossa infraestrutura?

Já participei de reuniões de vendas suficientes para saber o que mais preocupa as equipes: "Precisamos reconstruir toda a nossa infraestrutura para fazer isso direito?" A premissa aqui é que, se o site não foi internacionalizado desde o início, então a localização correta significa uma reformulação e desmontagem completas. Na maioria das vezes, a resposta é NÃO.

Se a camada de localização for executada sobre o site existente, em vez de dentro de seu código-fonte, nenhuma recompilação será necessária. Estou revelando um pouco do meu jogo aqui, mas é exatamente assim que Bablic funciona. Na maioria das vezes, um pequeno trecho de JavaScript é executado no navegador do visitante e substitui o texto traduzido pelo texto na localidade correta no momento da solicitação, sem rastrear ou reconstruir o site de origem (o servidor original onde a página está hospedada).

A preocupação com o desempenho que geralmente surge é que uma abordagem do lado do navegador significa carregar um conjunto completo de traduções a cada visualização de página. Se essa for uma preocupação real para você, escolha uma ferramenta que ofereça cache de pré-tradução, que armazena o texto traduzido anteriormente para que o navegador não precise acessar uma API de tradução do zero a cada solicitação.

A essa altura, você deve estar pensando: "Mas meu produto é um aplicativo nativo com lógica condicional profundamente aninhada e sem separação entre strings e código"... blá blá blá. Bem, esse é um problema de engenharia que uma camada do lado do navegador não resolverá! Nesse caso, procure uma solução com um SDK. Mas para sites de marketing e lojas virtuais, páginas criadas inicialmente em um idioma e que agora precisam atender a cinco mercados diferentes, a ideia de reestruturar a arquitetura geralmente está errada.

Não traduza sem contexto.

A page can pass every i18n check (the currency’s right, the date format is right) and still read as obviously foreign to the person it’s supposed to be speaking to. Os clientes conseguem perceber quando uma mensagem não atinge o objetivo ou está ligeiramente errada, e as pessoas que notam isso não convertem. Esse é o vale da estranheza que mencionei antes, e é um verdadeiro obstáculo à conversão.

Compreender e aplicar o contexto ajuda a resolver esse problema. Em primeiro lugar, ao controlar termos específicos, como o nome da sua marca e os nomes próprios do seu produto, você garante que frases importantes sejam traduzidas da mesma forma todas as vezes, independentemente do que um mecanismo de tradução automática utilize por padrão. Um glossário que permite consolidar essas decisões é o que garante que uma página traduzida reflita a sua marca, em vez de uma versão genérica direcionada a ninguém em particular.

A segunda é a capacidade de realmente olhar para a página traduzida e corrigir o que está errado, no próprio local, sem precisar ser fluente no idioma de destino para identificar uma frase estranha. Um editor contextual mostra a página traduzida em tempo real e permite que você edite diretamente, o que significa que um colega que fala espanhol pode verificar o resultado em poucos minutos, em vez de um tradutor ter que refazer tudo a partir de uma planilha.

Para a maioria das páginas, a tradução automática (TA) é um ponto de partida razoável. Os mecanismos padrão do Bablic são o Google Translate e o DeepL, que processam o primeiro rascunho a uma velocidade que nenhuma equipe humana consegue alcançar. Para a maioria das empresas com as quais conversamos, esses mecanismos, combinados com um glossário e uma verificação pontual com um editor contextual, são suficientes para dar a sensação de que seu site está verdadeiramente localizado.

Perguntas frequentes