i18n: por que a localização vai muito além de traduzir palavras

Você já viu um botão escrito “Sign in” no meio de uma interface em português?Ou um site que traduz tudo， mas mantém o formato de data americano?Isso é i18n mal feito. A sigla vem de “internationalization” — aquele “i” seguido de 18 letras e um “n” — e não significa apenas traduzir textos. Significa preparar um produto para funcionar em qualquer cultura sem quebrar. Na prática， i18n é a espinha dorsal invisível que permite que um app aberto no Japão mostre a data como 2025年4月3日， enquanto no Brasil aparece 03/04/2025。e no Canadá francês use 2025-04-03. Sem i18n， cada novo mercado vira um projeto de engenharia do zero.Pergunta comum: “Mas i18n não é a mesma coisa que localização” Quase. i18n é o trabalho de engenharia que deixa o código pronto para receber diferentes idiomas e costumes. Localização (l10n) é a adaptação concreta — traduzir， ajustar imagens， revisar leis locais. Pense em i18n como construir uma casa com tomadas em vários padrões;

l10n é instalar o plugue certo para cada país. Um sistema com i18n bem-feito aceita novos idiomas sem reescrever o núcleo. Um sistema sem i18n exige gambiarras. Já vi uma equipe passar três semanas só para corrigir a ordem de nome e sobrenome em formulários porque o código assumia “primeiro nome， último nome” como regra universal. Na Hungria。o sobrenome vem primeiro. Emirados Árabes?

Nome do pai no meio. i18n resolve isso com regras configuráveis， não com if-else espalhados.Detalhe que muita gente esquece: i18n não é só texto. É número， moeda， calendário， fuso horário， endereço， plural。gênero gramatical. O inglês tem duas formas de plural (one apple， two apples). O árabe tem seis. O japonês não marca plural em substantivos comuns. Se seu código faz `if (count > 1) { plural }`， você já quebrou i18n para metade do mundo. A solução padrão são bibliotecas como ICU MessageFormat， que permitem regras por idioma. Outro clássico: ordenação alfabética. Em sueco， “ä” vem depois de “z”;em alemão， “ä” equivale a “a”. Uma lista de contatos ordenada com `sort()` padrão parece correta para um sueco e errada para um alemão. i18n exige collation sensível ao locale.Casos reais que ilustram o custo de ignorar i18n: um banco digital expandiu para o México e descobriu que o campo “CPF” não existia — precisava de RFC (Registro Federal de Contribuintes). O código tinha validação fixa de 11 dígitos. Resultado: três sprints perdidos. Outro exemplo: um e-commerce alemão usava “Straße” (rua) no endereço， mas o formulário limitava a 30 caracteres. “Straße” tem 6， mas nomes de rua alemães facilmente passam de 40. i18n define limites de campo por locale， não um número mágico global. E tem o clássico do botão que cresce 30% na tradução para o alemão e estoura o layout. i18n inclui design responsivo a variações de comprimento de string — ou pseudo-localização para testar isso antes do tradutor entrar em cena.

“Então i18n é coisa só de grandes empresas” Não. Qualquer produto que pretenda cruzar fronteiras precisa disso desde o primeiro commit. Mas há um mito: “vamos lançar em inglês e depois pensamos em i18n”. Errado. Refatorar i18n depois é como trocar o encanamento de um prédio habitado. Comece com strings externalizadas (nada de texto hardcoded)。use UTF-8 em tudo， armazene datas em UTC e converta na exibição， e adote um sistema de chaves de tradução (ex: `home.welcome_message`) em vez de português como chave. Custa pouco no início， salva meses depois. Já vi startups gastarem 40% do orçamento de engenharia em retrabalho por não terem feito isso.Ferramentas ajudam， mas não substituem decisões de arquitetura. React-i18next， FormatJS， Fluent， gettext — cada um tem seu lugar. O ponto crítico é separar conteúdo de apresentação. Um exemplo prático: em vez de `const greeting = 'Olá， ' + name`， use `t('greeting'。

{ name })` com a string “Olá， {name}” no arquivo de tradução. Parece bobo， mas essa indireção permite que o tradutor adapte a ordem das palavras. Em japonês， “Olá， {name}” vira “{name}さん、こんにちは” — o nome vem antes. Sem i18n， você teria que reescrever a função para cada idioma. Com i18n， o tradutor resolve sozinho.Um erro silencioso: confundir i18n com tradução automática. Jogar o site no Google Translate não é i18n. i18n exige revisão cultural. Um exemplo: ícone de “curtir” com polegar para cima funciona no Brasil e nos EUA， mas em partes do Oriente Médio é ofensivo. i18n não resolve isso sozinho， mas a arquitetura de i18n permite trocar o ícone por locale sem tocar no código. Outro caso: cores. Vermelho significa perigo no ocidente， sorte na China. Um dashboard financeiro que usa vermelho para “queda” pode confundir usuários chineses. i18n bem-feito separa a semântica (valor negativo) da apresentação (cor)。permitindo que o time de localização ajuste o tema por região.Por fim， i18n é um investimento em escala. Cada novo idioma adicionado a um sistema com i18n maduro custa dias;sem i18n。

custa meses e bugs. Empresas que tratam i18n como prioridade de engenharia — não como tarefa de tradução — lançam em novos mercados com metade do esforço. A pergunta que fica não é “quando vamos precisar de i18n”， mas “quanto vamos perder até implementar”. Se seu produto já tem usuários em mais de um país， mesmo que falem o mesmo idioma， i18n já é urgente. Formatos de data， moeda e endereço não perdoam.