A Língua Não Deve Ser Associada Ou Identificada Com

O princípio mais ignorado no desenvolvimento de localização

Quando você trabalha com padrões de localização e internacionalização de software, existe uma linha que todo mundo atravessa sem perceber. A língua não deve ser associada ou identificada com a cultura de um país, ou com a etnia de seus falantes, ou com uma identidade nacional. Isso parece óbvio no papel, mas na prática é onde a maioria dos erros acontece — e eu vejo isso repetidamente em código de produção. Você já deve ter visto campos como locale sendo preenchidos com valores como "pt_BR" para todos os conteúdos em português do Brasil, como se tudo que é falado ali fosse culturalmente idê ntico. Ou então strings traduzidas que incluem referências culturais específicas de uma variante que nunca vai ser usada por parte dos usuários. O problema é que o português brasileiro não soa igual em São Paulo, no Recife e no Sul do país, e o espanhol mexicano é radicalmente diferente do espanhol rioplatense em termos de vocabulário e tom — mesmo sendo a mesma língua. Essa confusão leva a decisões ruins de arquitetura. Eu já vi times inteiros mapearem variant dialetais inteiras como se fossem mercados separados, criando centenas de pastas de tradução duplicadas por diferenças que em grande parte dos casos não afetam a interface do usuário. O resultado era um processo de atualização que levava semanas para propagar uma correção simples, porque cada "local" precisava ser editado individualmente.

Como tratar língua e localização como camadas separadas

A abordagem correta começa com uma separação clara entre o que é língua e o que é região. O padrão BCP 47 — que substituiu o antigo RFC 4646 — foi criado exatamente para isso. Ele permite especificar língua, variante, script e região de forma granular, como "pt-BR-latn-br" ou "es-MX-latn-mx". Mas o ponto principal é que a língua em si é uma coisa, e a região é outra. Na prática, o fluxo que funciona é o seguinte. Primeiro, você mapeia cada string do software para a língua, não para o país. O conteúdo em português brasileiro e o conteúdo em português europeu compartilham a mesma base de strings; as diferenças são tratadas como variantes opcionais, não como traduções independentes. Depois, você aplica regras regionais apenas onde elas realmente afetam a experiência — formatação de data, moeda, unidades de medida, ordinais e algumas escolhas vocabulares de alto impacto. O resto fica neutro. Para quem usa i18next, React-intl ou bibliotecas similares, a configuração padrão muitas vezes empurra você para uma estrutura de pastas por locale. O ajuste necessário é inverter essa lógica: use o código da língua como chave primária e trate as variantes como sobreposições. Um arquivo "pt.json" contém a versão base. Um arquivo "pt-BR.json" sobrescreve apenas o que precisa ser diferente. Isso reduz o volume de trabalho de manutenção em cerca de 60 a 70 por cento em projetos que eu acompanhei, porque a maior parte do conteúdo é idêntica entre variantes.

O erro mais comum que eu vejo em code review

Pessoas colocam traduções dentro de componentes condicionais baseados em país, em vez de usar o sistema de pluralização e variáveis que as bibliotecas de i18n já oferecem. Já passei horas corrigindo código onde o desenvolvedor escrevia um if-else gigante para cada país lusófono, com strings hardcoded, porque achava que a variante regional era a unidade básica de tradução. Isso quebra quando o produto precisa expandir para Angola ou Moçambique, que são mercados legítimos e têm necessidades próprias — e que, ironicamente, compartilham mais com o português europeu do que com o brasileiro em vários aspectos. Também é frequente encontrar campos como "idioma" ou "nationalidad" em formulários que pedem para o usuário informar sua língua. Isso é um erro conceitual. Língua e nacionalidade não são a mesma coisa. Um usuário pode falar português e ser cidadão canadense, ou falar espanhol e ter dupla nacionalidade. Separar esses campos desde o início evita problemas de conformidade com LGPD e GDPR depois.

Casos onde a separação não funciona tão bem

Nem sempre dá para manter língua e cultura completamente isoladas. Em interfaces de saúde, educação ou serviços governamentais, o vocabulário técnico varia muito entre regiões e as diferenças podem mudar o significado. Um exemplo concreto: o termo para " cepéia " (um tipo de tratamento prisional ou medida educacional) tem conotações diferentes em Portugal e no Brasil, e usar a mesma string traduzida para ambos gera confusão real nos formulários que eu implementei. Nesses casos, a solução não é voltar para a abordagem de pastas por país. É documentar explicitamente onde a variant regional é crítica e isolar essas strings com comentários no código. A maioria dos editores de formato JSON e YAML suporta comentários nativos ou você pode usar arquivos XLIFF, que permitem metadados explicativos por string. Isso mantém a estrutura limpa sem esconder as ressalvas importantes.

O que não fazer

Não use nomes de países como sinônimo de línguas. Não crie traduções duplicadas para Variantes que não têm diferenças significativas no contexto do seu produto. Não ignore o script — o mesmo código de língua com scripts diferentes (latim vs. cirílico para o sérvio, por exemplo) exige tratamento separado. Tampouco trate dados demográficos como proxy para preferências linguísticas. Pesquisas mostram que a autodeclaração linguística de um usuário nem sempre corresponde ao locale que ele usa no sistema operacional. Confiar apenas em geolocalização para definir o idioma padrão gera erros que afetam diretamente a taxa de conversão em mercados não anglófonos.

Um exemplo prático de implementação

No último projeto que lideramos, a equipe começou com uma estrutura de 47 pastas de locale. Depois de reaplicar o princípio de separar língua de região, reduzimos para 8 arquivos base de língua mais 12 arquivos de variante. A carga de tradução caiu de 14 pessoas em tempo integral para 4 revisores especializados, e o tempo para lançar uma nova variante de mercado passou de três semanas para dois dias. A diferença foi puramente organizacional, não tecnológica — o mesmo framework, a mesma infraestrutura, a mesma base de código. O que permanece é a lição mais simples: a língua não deve ser associada ou identificada com uma única cultura, país ou identidade. Ela é uma ferramenta que se adapta. O software que a interpreta deve fazer o mesmo.