Comment localiser correctement les numéros?
Quelles mises en garde dois-je savoir 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 des décimales par des 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, les mêmes qu'en-US. Mais en lisant sur l'anglais indien (en-IN) aujourd'hui, je suis tombé sur ce joyau:
Le système de numérotation indien est préféré pour le regroupement des chiffres. Lorsqu'ils sont écrits avec des mots ou prononcés, les nombres inférieurs à 100 000/100 000 sont exprimés exactement comme ils le sont en anglais standard. Les nombres 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 autres séparateurs spécifiques, il semble que le masquage soit également une préoccupation valable.
Quelles autres mises en garde dois-je savoir lors de la localisation de numéros dans mon application frontale? Surtout si je montre des nombres à des jeux de caractères non latins?
La plupart des langages de programmation et des frameworks ont déjà un mécanisme de travail sensé 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 le Culture que vous souhaitez:
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 votre framework préféré.
D'excellentes réponses ici déjà, mais elles ne mentionnent pas une chose qu'il est important de ne pas oublier: assurez-vous que partout où un formatage de nombre a lieu, 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 où le numéro est nécessaire sous forme lisible par machine , assurez-vous qu'il est pas formaté selon 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 à l'aide de la culture A, et lus ou reçus à l'aide de la culture B.
D'après mon expérience, c'est l'un des plus grands obstacles à la localisation correcte des nombres: pour tenter de centraliser la mise en forme et la conversion des nombres, les gens commencent à créer des fonctions générales et réutilisables pour la mise en forme, puis commencent à les utiliser partout dans le endroit. Cependant, dès que l'on a également besoin des nombres dans un format de chaîne lisible par machine ailleurs dans le programme, deux variantes sont nécessaires: un formatage localisé et un formatage non localisé. Cela présente un risque élevé de mélanger les deux formes de conversions (en particulier lorsque les développeurs et les machines de test ont leurs paramètres régionaux par défaut similaires au paramètre "fixe" utilisé pour le formatage non UI, mais qu'une partie de la base d'utilisateurs ne l'a pas).
Addendum: ce problème peut devenir vraiment désagréable dans des situations où il n'est pas clair à l'avance si le numéro sera traité par une machine, ou par un humain (ou les deux) plus tard. 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" de n'utiliser aucun séparateur sauf le point comme séparateur décimal.
Une bonne localisation est assez difficile. La plupart des écosystèmes de programmation ont tenté de trouver des solutions de localisation, mais d'après mon expérience, ils sont tous plus ou moins brisés. Je proposerais donc:
N'essayez pas d'automatiser la localisation. Cela ne fonctionnera pas toujours. Il est difficile pour vous d'identifier les problèmes et frustrant pour vos utilisateurs.
Soyez cohérent: ne mélangez pas différentes langues et conventions de formatage, par exemple Séparateurs décimaux de style brésilien en texte anglais.
Prise en charge explicite d'un ensemble donné de paramètres régionaux. Travaillez avec vos traducteurs pour déterminer la mise en forme appropriée des dates et des nombres. Vous finirez probablement par créer votre propre boîte à outils de localisation, bien que la plupart (mais pas tous) des problèmes puissent être délégués à une bibliothèque existante.
Faites des choix de mise en forme simples configurables par chaque utilisateur: formats de dates et d'heures, séparateurs décimaux, devise préférée,…. Cela est particulièrement utile pour les voyageurs, les expatriés ou d'autres personnes qui ont besoin de mélanger plusieurs lieux ou cultures indépendamment de la langue.
Vous ne pouvez pas être au courant de toutes les mises en garde des langues. Vous parlez de nombres, mais il y a des pluriels, des genres, des collations. Vous devez savoir qu'ils existent et compter sur un travail approfondi effectué par d'autres personnes, notamment les projets ICU et CLDR).
La plupart des langages modernes implémentent certaines ou toutes les 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.
Mise à jour
L'outil d'enquête CLDR permet d'accéder à 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 depuis GitHub:
https://github.com/unicode-cldr/cldr-json#cldr-json
Plus d'informations sur les téléchargements ici:
Une considération importante: vous devez décider combien est suffisant. Parce que si vous descendez dans le terrier du lapin pour essayer de localiser parfaitement, cela deviendra de plus en plus complexe.
Prenez une étiquette typique comme "Vous avez sélectionné n éléments". Cela ne va pas s'il n'y a qu'un seul élément sélectionné. La solution laide mais pragmatique est d'écrire "Vous avez sélectionné n élément (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 régions, 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 ces raisons, les personnes au courant se plaindront toujours que les cadres de localisation existants sont insuffisants.
Mais vous devez choisir vos combats et décider du niveau de sophistication suffisant. À de nombreuses fins, une bibliothèque de localisation standard pour le formatage des nombres et des dates devrait suffire.
Eh bien, 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 en marquer une comme la bonne réponse.
Jusqu'à présent, c'est ce que nous devons savoir 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 décimales varient d'une culture à l'autre. Par exemple, en allemand, des milliers sont divisés en utilisant des espaces, tandis qu'en anglais, ce sont des virgules et en portugais, ce sont des points;
- Nous n'avons pas d'informations s'il y a 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 changer la localisation par défaut pour l'une des localisations prises en charge et ils seront heureux et vous enverront 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 doivent toujours recevoir le même formatage lors de la sérialisation et de la désérialisation d'un numéro;
- Restez avec un seul format pour cela;
- Utilisez le format minimum nécessaire possible. Évitez la séparation des 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;
- N'oubliez pas que la localisation est un problème principalement résolu. Chaque langue principale possède une bibliothèque, native ou externe, qui peut localiser les nombres, les dates et les heures;