¿Cómo localizar adecuadamente los números?

¿Qué advertencias debo tener en cuenta al localizar números en mi aplicación front-end?

Ejemplo: en portugués brasileño (pt-BR) dividimos miles con puntos y decimales con comas. En inglés de EE. UU. (En-EE. UU.) Eso es lo contrario. En pt-BR presentamos los dígitos separados por miles, lo mismo que en-US. Pero al leer sobre el inglés indio (en-IN) hoy me encontré con esta joya:

Se prefiere el sistema de numeración indio para la agrupación de dígitos. Cuando se escribe en palabras, o cuando se habla, los números de menos de 100,000 / 100,000 se expresan tal como están en inglés estándar. Los números que incluyen más allá de 100,000 / 100,000 se expresan en un subconjunto del sistema de numeración indio.

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

Lo 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

Además de comas y puntos y otros separadores específicos, parece que el enmascaramiento también es una preocupación válida.

¿Qué otras advertencias debo tener en cuenta al localizar números en mi aplicación front-end? ¿Especialmente si estoy mostrando números a conjuntos de caracteres no latinos?

La mayoría de los lenguajes y marcos de programación ya tienen un mecanismo de trabajo sensible que puede usar para esto.

Por ejemplo, el ecosistema C # tiene el espacio de nombres System.Globalization , que le permite especificar lo Cultureque desea:

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

Esto no es algo que quieras reinventar. Use las funciones de internacionalización proporcionadas por su idioma o marco favorito.

Algunas respuestas excelentes aquí ya, pero no mencionaron una cosa que creo que es importante no olvidar: asegúrese de que donde sea que tenga lugar un formateo de números, esté claro (o se pueda controlar) para qué se utiliza la salida:

• cuando se trata de la interfaz de usuario, se debe aplicar el formato localizado

• cuando el número se escribirá en un archivo, o se enviará a través de la red, u otra forma en la que se necesita el número en forma legible por máquina , asegúrese de que no esté formateado de acuerdo con la cultura actual, sino de acuerdo con una configuración fija (por ejemplo, en el entorno .NET, use InvariantCulture).

De lo contrario, tiene problemas cuando los números se escriben o envían utilizando la cultura A, y se leen o reciben utilizando la cultura B.

Según mi experiencia, este es uno de los mayores obstáculos para hacer una localización adecuada de los números: en un intento de centralizar el formato y la conversión de números, las personas comienzan a crear funciones generales y reutilizables para el formateo, y luego comienzan a usarlas en todo el lugar. Sin embargo, tan pronto como uno necesite los números también en un formato de cadena legible por máquina en otro lugar del programa, se necesitan dos variantes: un formato localizado y otro no localizado. Esto introduce un alto riesgo de mezclar las dos formas de conversiones (especialmente cuando los desarrolladores y las máquinas de prueba tienen su configuración regional predeterminada similar a la configuración "fija" utilizada para el formateo sin UI, pero parte de la base de usuarios no la tiene).

Anexo: este problema puede volverse realmente desagradable en situaciones en las que no está claro de antemano si el número será procesado por una máquina o por un humano (o ambos) más adelante. Por ejemplo, como parte de la salida de un archivo de registro. En tales casos, probablemente sea mejor atenerse al estándar "neutral" de no usar ningún separador excepto el punto como separador decimal.

La localización adecuada es bastante difícil. La mayoría de los ecosistemas de programación tienen intentos de encontrar soluciones para la localización, pero en mi experiencia están todos más o menos rotos. Por lo tanto, sugeriría:

• No intentes automatizar la localización. No siempre funcionará. Es difícil detectar los problemas y frustrante para los usuarios.

• Sea coherente: no mezcle diferentes idiomas y convenciones de formato, por ejemplo, separadores decimales de estilo brasileño en texto en inglés.

• Admite explícitamente un conjunto dado de configuraciones regionales. Trabaje junto con sus traductores para determinar el formato adecuado para fechas y números. Probablemente terminará creando su propio kit de herramientas de localización, aunque la mayoría (pero no todos) los problemas pueden delegarse en una biblioteca existente.

• Haga elecciones de formato simples configurables por cada usuario: formatos para fechas y horas, separadores decimales, moneda preferida, ... Esto es especialmente útil para viajeros, expatriados u otras personas que necesitan mezclar múltiples lugares o culturas independientemente del idioma.

Una consideración importante: debe decidir cuánto es suficiente. Porque si te pasas por la madriguera del conejo tratando de localizarlo perfectamente, se volverá cada vez más complejo.

Tome una etiqueta típica como "Ha seleccionado n elementos". Esto se lee mal si solo hay un elemento seleccionado. La solución fea pero pragmática es escribir "Ha seleccionado n elemento (s)". Pero si quieres hacerlo correctamente, necesitas dos textos diferentes dependiendo de n. Si intenta hacer esto en varias configuraciones regionales, rápidamente se volverá realmente complejo, ya que los diferentes idiomas tienen una gramática diferente. Algunos idiomas tienen diferentes conjugaciones para uno, dos y múltiples elementos, etc. Por este motivo, las personas con conocimiento siempre se quejarán de que los marcos de localización existentes son insuficientes.

Pero tienes que elegir tus batallas y decidir qué nivel de sofisticación es suficiente. Para muchos propósitos, una biblioteca de localización estándar para formatear números y fechas debería ser suficiente.

No puedes estar al tanto de todas las advertencias de los idiomas. Estás hablando de números, pero hay plurales, géneros, colación. Debe saber que existen y confiar en el extenso trabajo realizado por otras personas, especialmente los proyectos de UCI y CLDR.

La mayoría de los lenguajes modernos implementan algunas o todas las características de estos proyectos, pero incluso si no lo hacen, leer sobre estos proyectos le dará una buena idea de qué buscar.

http://site.icu-project.org

http://cldr.unicode.org

Actualizar

La herramienta de encuesta CLDR proporciona acceso a todos los patrones. Eso le mostrará cómo formatear un número en cierto idioma y región. Por ejemplo, portugués (Portugal):

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

Y si realmente desea verificar todos los datos (y tal vez usarlos), puede descargar el CLDR en formato JSON desde GitHub:

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

Más información sobre descargas aquí:

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

Bueno, aunque estoy contento con todas las respuestas aquí, no estoy realmente satisfecho con cada una de ellas por separado para marcar una como la respuesta correcta.

Hasta ahora, esto es lo que debemos tener en cuenta al localizar números:

Para humanos :

• Miles de separadores no siempre se separan en miles. Ver caso indio en la pregunta;
• Los caracteres de miles y decimales varían de cultura a cultura. En alemán, miles se dividen utilizando espacios, por ejemplo, mientras que en inglés son comas y en portugués son puntos;
• No tenemos información si hay una diferencia relevante entre los idiomas de izquierda a derecha y de derecha a izquierda;
• Proporcione un conjunto específico de localizaciones compatibles y deje en claro para sus usuarios;
• Permita que sus usuarios cambien la localización predeterminada a una de las localizaciones compatibles y estarán felices y le enviarán pasteles agradecidos, porque es un dios generoso. :);

Para computadoras :

• Recuerde que las máquinas no son indulgentes y siempre deben recibir el mismo formato al serializar y deserializar un número;
• Quédese con un solo formato para ello;
• Use el formato mínimo necesario posible. Evite la separación de miles, los decimales deberían ser suficientes para la serialización y la deserialización.

Para desarrolladores :

• (como sugiere @hyde a continuación): Use la biblioteca existente para la localización;
• Si puede, use probadores nativos y especifique casos de prueba de localización / internacionalización, de lo contrario confíe en la biblioteca;
• Recuerde que la localización es un problema mayormente resuelto. Cada idioma principal tiene una biblioteca, nativa o externa, que puede localizar números, fechas y horas;