Como localizar números corretamente?

Quais advertências devo estar atento ao localizar números no meu aplicativo front-end?

Exemplo: em português do Brasil (pt-BR), dividimos milhares com pontos e decimais com vírgulas. No inglês dos EUA (en-US), é o contrário. Em pt-BR, apresentamos os dígitos separados por milhares, o mesmo que en-US. Mas lendo sobre o inglês indiano (en-IN) hoje me deparei com esta jóia:

O sistema de numeração indiano é o preferido para o agrupamento de dígitos. Quando escritos em palavras ou quando falados, números inferiores a 100.000 / 100.000 são expressos da mesma forma que no inglês padrão. Os números incluindo e além de 100.000 / 100.000 são expressos em um subconjunto do sistema de numeração indiano.

https://en.wikipedia.org/wiki/Indian_English#Numbering_system

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, pontos e outros separadores específicos, parece que o mascaramento também é uma preocupação válida.

Quais outras advertências devo estar atento ao localizar números no meu aplicativo front-end? Especialmente se eu estiver mostrando números para conjuntos de caracteres não latinos?

A maioria das linguagens e estruturas de programação já possui um mecanismo de trabalho sensível que você pode usar para isso.

Por exemplo, o ecossistema C # possui o espaço para nome System.Globalization , que permite especificar o que Culturevocê deseja:

Console.WriteLine(myMoneyValue.ToString("C", "en-US"));

Isso não é algo que você deseja reinventar. Use os recursos de internacionalização fornecidos pelo seu idioma ou estrutura favorita.

Algumas respostas excelentes já estão aqui, mas elas não mencionaram uma coisa que acho importante não esquecer: verifique onde quer que ocorra uma formatação de números, é claro (ou pode ser controlado) para que serve a saída:

• quando for 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 em que o número for necessário em formato legível por máquina , verifique se ele não está 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 são escritos ou enviados usando a cultura A e lidos ou recebidos usando a cultura B.

De acordo com a minha experiência, esse é um dos maiores obstáculos para a localização adequada de números: em uma 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, em seguida, começam a usá-las em todo o mundo. Lugar, colocar. No entanto, assim que você precisar dos números também em um formato de sequência legível por máquina em algum outro local do programa, são necessárias duas variantes: 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 as máquinas de teste têm suas configurações de localidade padrão semelhantes à configuração "fixa" usada para formatação sem interface do usuário, mas parte da base de usuários não possui).

Adendo: esse 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 ser humano (ou ambos) posteriormente. Por exemplo, como parte da saída de um arquivo de log. Nesses casos, provavelmente é melhor seguir o padrão "neutro" de não usar separador, exceto o ponto como separador decimal.

A localização adequada é bastante difícil. A maioria dos ecossistemas de programação tem tentativas de encontrar soluções para localização, mas, na minha experiência, elas são todas mais ou menos quebradas. Eu sugeriria, portanto:

• Não tente automatizar a localização. Nem sempre funciona. É difícil para você identificar os problemas e frustrante para seus usuários.

• Seja consistente: não misture idiomas diferentes e convenções de formatação, por exemplo, separadores decimais no estilo brasileiro em texto em inglês.

• Suporte explicitamente a um determinado conjunto de códigos de idioma. Trabalhe em conjunto com seus tradutores para descobrir a formatação adequada para datas e números. Você provavelmente criará seu próprio kit de ferramentas de localização, embora a maioria (mas não todos) dos problemas 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ê tentar encontrar na perfeição a toca do coelho, ficará cada vez mais complexo.

Escolha uma etiqueta típica como "Você selecionou n itens". Isso mostra 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, precisará de dois textos diferentes, dependendo do n. Se você tentar fazer isso em vários locais, ele rapidamente ficará realmente complexo, pois idiomas diferentes têm gramática diferente. Algumas línguas têm conjugações diferentes para um, dois e vários itens e assim por diante. Por esse motivo, as pessoas com conhecimento técnico sempre reclamam que as estruturas de localização existentes são insuficientes.

Mas você precisa escolher suas batalhas e decidir qual nível de sofisticação é suficiente. Para muitos propósitos, uma biblioteca de localização padrão para formatar 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, agrupamento. Você precisa saber que eles existem e contar com um extenso trabalho realizado por outras pessoas, principalmente os projetos de UTI e CLDR.

A maioria das linguagens modernas implementa alguns ou todos os recursos desses projetos, mas mesmo se não o fizerem, ler sobre esses projetos fornecerá uma boa idéia do que procurar.

http://site.icu-project.org

http://cldr.unicode.org

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):

http://st.unicode.org/cldr-apps/v#/pt_PT/Number_Formatting_Patterns/

E se você realmente deseja verificar todos os dados (e talvez usá-los), pode fazer o download do CLDR no formato JSON do GitHub:

https://github.com/unicode-cldr/cldr-json#cldr-json

Mais informações sobre downloads aqui:

http://cldr.unicode.org/index/downloads

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, é disso que devemos estar cientes ao localizar números:

Para humanos :

• Milhares de separadores nem sempre estão se separando aos milhares. Veja caso indiano na pergunta;
• Milhares e caracteres decimais variam de cultura para cultura. Em alemão, milhares são divididos usando espaços, por exemplo, enquanto em inglês são comuns e em português são pontos;
• Não temos informações se houver uma diferença relevante entre os idiomas da esquerda para a direita e da direita para a esquerda;
• Forneça um conjunto específico de localizações suportadas e deixe claro para seus usuários;
• Permita que seus usuários alterem a localização padrão para uma das localizações suportadas e eles ficarão felizes e enviarão bolos agradecidos, porque você é um deus generoso. :);

Para computadores :

• Lembre-se de que as máquinas não são tolerantes e sempre devem receber a mesma formatação ao serializar e desserializar um número;
• Ficar com um único formato para ele;
• Use o formato mínimo necessário possível. Para evitar a separação de milhares, os decimais devem ser suficientes para serialização e desserialização.

Para desenvolvedores :

• (como sugerido por @hyde abaixo): use a biblioteca existente para localização;
• Se puder, use testadores nativos e especifique casos de teste de localização / internacionalização; caso contrário, confie na biblioteca;
• Lembre-se de que a localização é um problema principalmente resolvido. Todo idioma principal possui uma biblioteca, nativa ou externa, que pode localizar números, datas e horas;