País e idioma são coisas diferentes, e a frase parece óbvia até o momento em que um sistema precisa decidir, sozinho, qual regra aplicar a um endereço. No atalho mais comum, a interface descobre o idioma do usuário e usa essa informação para escolher o formato dos dados. O atalho funciona na maioria dos casos e falha de forma silenciosa no resto, que é onde os defeitos difíceis vivem.
Por que não dá para deduzir um do outro?
Porque a relação entre as duas dimensões é cruzada, não correspondente. Um mesmo idioma pode ser usado como língua oficial em vários países, e um mesmo país pode ter mais de uma língua oficial. Existem ainda situações em que a língua oficial não é a língua mais falada na rua, e outras em que a fronteira linguística não coincide com a fronteira administrativa.
O efeito prático é que qualquer tabela de conversão direta entre idioma e país vai estar errada em algum ponto, e geralmente em pontos onde vivem muitas pessoas. Um sistema que trata a relação como um para um está apostando contra a demografia.
A recomendação de projeto é simples e desconfortável: as duas dimensões entram no modelo separadamente, cada uma com sua finalidade declarada, e nenhuma delas é derivada da outra em tempo de execução.
As três camadas da localização
A localização costuma ser tratada como um único interruptor, e é aí que a confusão nasce. Na prática, ela tem três camadas que podem assumir valores diferentes ao mesmo tempo.
| Camada | O que ela controla | Exemplo de escolha independente |
|---|---|---|
| Idioma da interface | Os textos que o usuário lê | Idioma escolhido no seletor |
| Região do conteúdo | Quais dados e catálogos aparecem | País da entrega ou do cadastro |
| Formato dos dados | Como valores são escritos e validados | Convenção da região do dado |
As três camadas podem divergir legitimamente. Uma pessoa pode ler a interface em português, comprar em um site cuja operação está em outro país e ter um endereço em um terceiro formato. Cada uma dessas escolhas tem uma razão de ser, e nenhuma delas é um erro.
O defeito aparece quando o sistema usa a camada errada para responder uma pergunta. Trocar o idioma da interface e ver o formato de data mudar é um sintoma clássico: a primeira camada foi aplicada à terceira, onde ela não manda nada.
A divisão de trabalho entre rótulo de idioma e código de região
As duas etiquetas parecem intercambiáveis porque ambas aparecem no mesmo cabeçalho de requisição, mas descrevem objetos distintos. O rótulo de idioma descreve texto: qual idioma a pessoa lê, para escolher a redação da interface e dos materiais. O código de região descreve dado: sob qual convenção um valor foi escrito ou deve ser validado.
Quando o dado carrega apenas o idioma, o sistema perde a informação de que precisa para validar aquele conteúdo. Quando carrega apenas a região, perde a informação de que precisa para redigir a mensagem de erro. Um cadastro internacional bem modelado tende a guardar as duas, e a guardar também em qual delas cada decisão se baseia.
Vale mencionar um ponto de fronteira: existem contextos em que um território tem convenções que não se confundem com as do país ao qual se vincula. Tratar esses casos como exceção documentada é melhor do que tentar forçar uma regra única. Se o assunto for nomenclatura de língua e nome próprio, o texto sobre dados de nome por localidade aprofunda o lado linguístico, que aqui fica fora do escopo.
Quais erros aparecem quando o formato segue o idioma?
O erro mais citado é validar o dado de uma região com a regra de outra que compartilha o idioma. O sistema acerta a língua da mensagem e erra a regra de validação, com a consequência desagradável de que o usuário legítimo é rejeitado e não entende por quê.
O segundo erro é de ordenação. Listas de nomes ordenadas pela regra de um idioma ficam estranhas para leitores de outro, e o defeito só aparece quando alguém procura um item específico e não o encontra na posição esperada.
O terceiro é de comprimento. A mesma mensagem traduzida pode ficar consideravelmente mais longa, e layouts com largura fixa quebram na versão que ninguém testou. Esse erro aparece em botões, colunas de tabela e rótulos de etiqueta, três lugares onde o texto não tem para onde crescer.
O quarto é o inverso do primeiro: aceitar tudo em nome da flexibilidade. Um sistema que não valida nada nunca reclama, mas também nunca protege o dado, e a inconsistência migra da entrada para o relatório.
Como montar a matriz de teste
A matriz deve ser um cruzamento deliberado, e não um pareamento. Os dois eixos são amostrados de forma independente e depois combinados, com atenção explícita às combinações improváveis.
- Amostre o eixo do idioma por características de texto: comprimento, sinais diacríticos, alfabeto e direção de escrita.
- Amostre o eixo da região por características de dado: presença ou ausência de determinados campos, comprimento de valores e convenções de exibição.
- Inclua pelo menos uma combinação em que o idioma da interface não coincide com a região do cadastro, e outra em que coincida sem que o dado seja do mesmo lugar.
Se o seu produto é usado por pessoas que viajam, a combinação improvável é justamente a mais comum. Uma matriz pareada testa apenas o caminho fácil e depois entrega a impressão de cobertura completa.
Para quem desenvolve: deixe o formato seguir a região
A regra prática que resolve a maior parte dos casos é decidir, por campo, qual dimensão manda. Textos de interface seguem o idioma; regras de valor seguem a região do dado. Essa decisão deve estar escrita, porque ela é a única forma de alguém revisar uma linha de código seis meses depois e entender por que uma variável foi usada ali.
Vale também guardar as duas informações quando ambas existirem, e não tentar reconstruir uma a partir da outra mais tarde. Reconstrução por inferência é a origem da maioria dos defeitos descritos acima.
Por último, quando o sistema precisa escolher um valor padrão, escolha um padrão neutro e visível em vez de adivinhar. Um formato declarado como indefinido é uma pendência; um formato adivinhado errado é um defeito que vai levar meses para ser notado.
Próximos passos
Com os dois eixos separados, o próximo assunto natural é o controle que o usuário usa para informar a região, e é disso que trata o texto de teste de campo de seleção de país. Se o seu problema é definir o que pertence a cada grupo, veja agrupamentos regionais e níveis de mercado. Para comparar a sua convenção com a organização do site, visite a página de formatos de endereço e identidade por país.
Aviso: as combinações de idioma e região usadas neste texto são apenas exemplos de matriz, criados para demonstrar o método de cruzamento. Elas não descrevem a distribuição de usuários de nenhum produto nem representam a política de localização de uma empresa real.