Quais são as advertências que devo ter ao localizar números no meu aplicativo front-end?
Exemplo: em português brasileiro (pt-BR), dividimos milhares de pontos e decimais com vírgulas. Em inglês dos EUA (en-US) é o contrário. Na pt-BR apresentamos os dígitos separados pelos milhares, o mesmo que en-US. Mas lendo sobre inglês indiano (en-IN) hoje me deparei com essa preciosidade:
The Indian numbering system is preferred for digit grouping. When written in words, or when spoken, numbers less than 100,000/100 000 are expressed just as they are in Standard English. Numbers including and beyond 100,000 / 100 000 are expressed in a subset of the Indian numbering system.
O que significa:
1000000 units in pt-BR are formatted 1.000.000
1000000 units in en-US are formatted 1,000,000
1000000 units in en-IN are formatted 10,00,000
Além de vírgulas e pontos e outros separadores específicos, parece que o mascaramento também é uma preocupação válida.
Quais outras ressalvas devo ter ao localizar números no meu aplicativo front-end? Especialmente se estou mostrando números para conjuntos de caracteres não latinos?
A maioria das linguagens de programação e frameworks já tem um mecanismo de trabalho sensato que você pode usar para isso.
Por exemplo, o ecossistema C # tem o System.Globalization namespace, que permite especificar o Culture que você quer:
Console.WriteLine(myMoneyValue.ToString("C", "en-US"));
Isso não é algo que você queira reinventar. Use os recursos de internacionalização fornecidos pela sua linguagem ou estrutura favorita.
Algumas excelentes respostas já estão aqui, mas elas não mencionam uma coisa que eu acho importante não esquecer: certifique-se de onde quer que uma formatação numérica ocorra, é claro (ou pode ser controlado) para que serve a saída:
quando é para a interface do usuário, a formatação localizada deve ser aplicada
quando o número for gravado em um arquivo, ou enviado pela rede, ou outra forma de onde o número é necessário no formato legível por máquina , verifique se ele é < strong> not formatado de acordo com a cultura atual, mas de acordo com uma configuração fixa (por exemplo, no ambiente .NET, use InvariantCulture ).
Caso contrário, você terá problemas quando os números forem escritos ou enviados usando a cultura A e lidos ou recebidos usando a cultura B.
Para minha experiência, este é um dos maiores obstáculos na localização adequada de números: na tentativa de centralizar a formatação e conversão de números, as pessoas começam a criar funções gerais e reutilizáveis para a formatação e começam a usá-las por todo o lugar. No entanto, assim que alguém precisar dos números também em um formato de string legível por máquina em algum outro lugar do programa, duas variantes serão necessárias: uma formatação localizada e uma não localizada. Isso apresenta um alto risco de misturar as duas formas de conversão (especialmente quando os desenvolvedores e máquinas de teste têm suas configurações de localidade padrão semelhantes à configuração "fixa" usada para formatação não-UI, mas parte da base de usuários não).
Adendo: este problema pode se tornar realmente desagradável em situações em que não está claro de antemão se o número será processado por uma máquina, ou por um humano (ou ambos) mais tarde. Por exemplo, como parte da saída de um arquivo de log. Em tais casos, é melhor seguir o padrão "neutro" de não usar nenhum separador, exceto o ponto como separador decimal.
A localização adequada é bastante difícil. A maioria dos ecossistemas de programação tem tentativas de soluções para localização, mas, na minha experiência, estão todos mais ou menos quebrados. Eu sugeriria, portanto:
Não tente automatizar a localização. Nem sempre funcionará. É difícil identificar os problemas e frustrar os usuários.
Seja consistente: não misture idiomas e convenções de formatação diferentes, por exemplo Separadores decimais no estilo brasileiro em texto em inglês.
Suporte explicitamente um determinado conjunto de códigos de idioma. Trabalhe junto com seus tradutores para descobrir a formatação adequada para datas e números. Você provavelmente acabará criando seu próprio kit de ferramentas de localização, embora a maioria dos problemas (mas não todos) possa ser delegada a uma biblioteca existente.
Faça opções simples de formatação configuráveis por cada usuário: formatos para datas e horas, separadores decimais, moeda preferida,…. Isso é especialmente útil para viajantes, expatriados ou outras pessoas que precisam misturar vários locais ou culturas, independentemente do idioma.
Uma consideração importante: você deve decidir quanto é suficiente. Porque se você for à procura de uma localização perfeita, ficará cada vez mais complexo.
Pegue um rótulo típico como "Você selecionou n itens". Isso é errado se houver apenas um item selecionado. A solução feia mas pragmática é escrever "Você selecionou n item (s)". Mas se você quiser fazer isso corretamente, você precisa de dois textos diferentes, dependendo do n. Se você tentar fazer isso em várias localidades, isso se tornará realmente complexo, já que idiomas diferentes possuem gramática diferente. Alguns idiomas têm diferentes conjugações para um, dois e vários itens e assim por diante. Por essa razão, as pessoas que sabem sempre reclamarão que as estruturas de localização existentes são insuficientes.
Mas você tem que escolher suas batalhas e decidir qual nível de sofisticação é suficiente. Para muitos propósitos, uma biblioteca de localização padrão para formatação de números e datas deve ser suficiente.
Você não pode estar ciente de todas as advertências de idiomas. Você está falando de números, mas existem plurais, gêneros, agrupamentos. Você precisa saber que eles existem e confiar no trabalho extensivo realizado por outras pessoas, mais notavelmente os projetos de ICU e CLDR.
A maioria das linguagens modernas implementa alguns ou todos os recursos desses projetos, mas, mesmo que não, ler sobre esses projetos lhe dará uma boa idéia do que procurar.
Atualizar
A ferramenta de pesquisa CLDR fornece acesso a todos os padrões. Isso mostrará como formatar um número em determinado idioma e região. Por exemplo, Português (Portugal):
E se você realmente deseja verificar todos os dados (e talvez usá-los), você pode fazer o download do CLDR no formato JSON do GitHub:
Mais informações sobre downloads aqui:
Bem, enquanto estou feliz com todas as respostas aqui, não estou realmente satisfeito com cada uma delas separadamente para marcar uma como a resposta correta.
Até agora, isso é o que devemos saber ao localizar números:
Para humanos :
Para computadores :
Para desenvolvedores :