Comment localiser correctement les nombres?

Quelles mises en garde dois-je connaître lors de la localisation de numéros dans mon application frontale?

Exemple: en portugais brésilien (pt-BR), nous séparons des milliers de points et de décimales de virgules. En anglais américain (en-US), c'est le contraire. Dans pt-BR, nous présentons les chiffres séparés par des milliers, comme en-US. Mais en lisant au sujet de l'anglais indien (en-IN) aujourd'hui, je suis tombé sur ce petit bijou:

Le système de numérotation indien est préféré pour le regroupement de chiffres. Lorsqu'ils sont écrits avec des mots ou quand ils sont parlés, les nombres inférieurs à 100 000/100 000 sont exprimés tels quels en anglais standard. Les numéros compris entre 100 000 et 100 000 et au-delà sont exprimés dans un sous-ensemble du système de numérotation indien.

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

Ce qui signifie:

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

Outre les virgules et les points et d’autres séparateurs spécifiques, il semble que le masquage soit également une préoccupation valable.

Quelles autres mises en garde dois-je connaître lors de la localisation de numéros dans mon application frontale? Surtout si je montre des chiffres à des jeux de caractères non latins?

La plupart des langages de programmation et des frameworks ont déjà un mécanisme de travail raisonnable que vous pouvez utiliser pour cela.

Par exemple, l’écosystème C # possède l’ espace de noms System.Globalization , qui vous permet de spécifier leCulture souhaité:

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

Ce n'est pas quelque chose que vous voulez réinventer. Utilisez les fonctionnalités d'internationalisation fournies par votre langage ou framework préféré.

Quelques excellentes réponses ici déjà, mais ils n'ont pas mentionné une chose qu'il est important de ne pas oublier: assurez-vous que chaque fois qu'un formatage numérique est utilisé, il est clair (ou peut être contrôlé) à quoi sert la sortie:

• quand c'est pour l'interface utilisateur, le formatage localisé doit être appliqué

• lorsque le numéro va être écrit dans un fichier, ou envoyé sur le réseau, ou sous une autre forme dont le numéro est nécessaire sous une forme lisible par machine , assurez-vous qu'il n'est pas formaté en fonction de la culture actuelle, mais selon un paramètre fixe (par exemple, dans l'environnement .NET, utilisez InvariantCulture).

Sinon, vous rencontrez des problèmes lorsque des nombres sont écrits ou envoyés avec la culture A et lus ou reçus avec la culture B.

Selon mon expérience, c’est l’un des plus gros obstacles à une bonne localisation des nombres: pour tenter de centraliser le formatage et la conversion des nombres, les utilisateurs commencent à créer des fonctions générales réutilisables pour le formatage, puis à les utiliser partout dans le monde. endroit. Cependant, dès que vous avez également besoin des nombres dans un format de chaîne lisible par machine ailleurs dans le programme, deux variantes sont nécessaires: une mise en forme localisée et une mise en forme non localisée. Cela introduit un risque élevé de confusion entre les deux formes de conversion (en particulier lorsque les paramètres régionaux par défaut des développeurs et des machines de test sont similaires au paramètre "fixe" utilisé pour le formatage autre que l'interface utilisateur, mais pas pour une partie de la base d'utilisateurs).

Addendum: ce problème peut devenir vraiment désagréable dans les situations où il n'est pas clair au préalable si le numéro sera traité par une machine, ou par un humain (ou les deux) ultérieurement. Par exemple, dans le cadre de la sortie d'un fichier journal. Dans de tels cas, il est probablement préférable de s'en tenir à la norme "neutre" consistant à ne pas utiliser de séparateur, à l'exception du séparateur décimal.

Une localisation correcte est assez difficile. La plupart des écosystèmes de programmation tentent de trouver des solutions pour la localisation, mais d'après mon expérience, ils sont tous plus ou moins brisés. Je suggérerais donc:

• N'essayez pas d'automatiser la localisation. Ça ne marchera pas toujours. Il est difficile pour vous de repérer les problèmes et frustrant pour vos utilisateurs.

• Soyez cohérent: ne mélangez pas différentes langues et conventions de formatage, par exemple des séparateurs décimaux de style brésilien dans le texte anglais.

• Prend explicitement en charge un ensemble donné de paramètres régionaux. Collaborez avec vos traducteurs pour déterminer le format approprié des dates et des chiffres. Vous allez probablement créer votre propre boîte à outils de localisation, bien que la plupart des problèmes (mais pas tous) puissent être délégués à une bibliothèque existante.

• Faites des choix simples de formatage configurables par chaque utilisateur: formats de date et d’heure, séparateurs décimaux, devise préférée,…. Ceci est particulièrement utile pour les voyageurs, les expatriés ou les autres personnes ayant besoin de mélanger plusieurs lieux ou cultures indépendamment de leur langue.

Une considération importante: vous devez décider combien est suffisant. Parce que si vous essayez de localiser parfaitement le lapin, cela deviendra de plus en plus complexe.

Prenez une étiquette typique du type "Vous avez sélectionné n éléments". Cela lit mal s'il n'y a qu'un seul élément sélectionné. La solution laide mais pragmatique consiste à écrire "Vous avez sélectionné n article (s)". Mais si vous voulez le faire correctement, vous avez besoin de deux textes différents selon n. Si vous essayez de le faire dans plusieurs environnements locaux, cela deviendra rapidement très complexe, car différentes langues ont une grammaire différente. Certaines langues ont des conjugaisons différentes pour un, deux et plusieurs éléments, etc. Pour cette raison, les connaisseurs se plaindront toujours de l’insuffisance des cadres de localisation existants.

Mais vous devez choisir vos batailles et décider quel niveau de sophistication est suffisant. Dans de nombreux cas, une bibliothèque de localisation standard pour le formatage des nombres et des dates devrait suffire.

Vous ne pouvez pas être au courant de toutes les mises en garde des langues. Vous parlez de chiffres, mais il y a des pluriels, des genres, des collations. Vous devez savoir qu'ils existent et compter sur le travail considérable effectué par d'autres personnes, notamment les projets ICU et CLDR.

La plupart des langages modernes implémentent tout ou partie des fonctionnalités de ces projets, mais même s’ils ne le font pas, la lecture de ces projets vous donnera une bonne idée de ce qu’il faut rechercher.

http://site.icu-project.org

http://cldr.unicode.org

Mise à jour

L'outil d'enquête CLDR donne accès à tous les modèles. Cela vous montrera comment formater un nombre dans certaines langues et régions. Par exemple, portugais (Portugal):

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

Et si vous voulez vraiment vérifier toutes les données (et peut-être les utiliser), vous pouvez télécharger le CLDR au format JSON à partir de GitHub:

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

Plus d'infos sur les téléchargements ici:

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

Bien que je sois satisfait de toutes les réponses ici, je ne suis pas vraiment satisfait de chacune d’elles séparément pour marquer l’une comme la bonne réponse.

Jusqu’à présent, c’est ce dont nous devrions être conscients lors de la localisation des nombres:

Pour les humains :

• Des milliers de séparateurs ne se séparent pas toujours par milliers. Voir le cas indien dans la question;
• Des milliers et des caractères décimaux varient de culture en culture. En allemand, des milliers sont divisés en utilisant des espaces, par exemple, alors qu'en anglais c'est commun et en portugais c'est des points;
• Nous ne disposons pas d'informations s'il existe une différence pertinente entre les langues de gauche à droite et de droite à gauche.
• Fournissez un ensemble spécifique de localisations prises en charge et expliquez-le clairement à vos utilisateurs;
• Permettez à vos utilisateurs de remplacer la localisation par défaut par l’une des localisations prises en charge. Ils se feront un plaisir de vous envoyer des gâteaux reconnaissants, car vous êtes un dieu généreux. :);

Pour les ordinateurs :

• N'oubliez pas que les machines ne sont pas indulgentes et qu'elles devraient toujours recevoir le même formatage lors de la sérialisation et de la désérialisation d'un nombre.
• S'en tenir à un seul format pour cela;
• Utilisez le format minimum nécessaire. Évitez les séparations de milliers, les décimales devraient suffire pour la sérialisation et la désérialisation.

Pour les développeurs :

• (comme suggéré par @hyde ci-dessous): Utilisez la bibliothèque existante pour la localisation;
• Si vous le pouvez, utilisez des testeurs natifs et spécifiez des cas de test de localisation / internationalisation, sinon faites confiance à la bibliothèque;
• Rappelez-vous que la localisation est un problème généralement résolu. Chaque langue principale possède une bibliothèque, native ou externe, capable de localiser des nombres, des dates et des heures;