Comment localiser correctement les nombres?

38

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?

Machado
la source
3
Obtient encore plus intéressant lorsqu'il s'agit d'argent! :-)
Stephan Bijzitter
4
Ne parlons pas du système de numérotation martien qui a la base 6 (deux fois 3 doigts) ;-) Mais le japonais a aussi une étrangeté: man = 10.000 écrit à 1.0000, oku = 100.000.000 écrit au Japon à 1.0000.0000 et chō. .. suppose que
qwerty_so
6
Pourquoi devez - vous vous inquiéter à ce sujet? Ne pouvez-vous pas suivre les paramètres du système d'exploitation?
Jan Doggen
3
@JanDoggen parce que c'est l'un des problèmes intéressants du domaine du génie logiciel, "comment présenter correctement les données à des personnes". Ce qui devrait me préoccuper lors de la conception d’un système, c’est le domaine de cette question. Et je ne parle même pas d'argent, comme l'a dit notre ami Stephan, ni de date ni d'heure. Juste des chiffres bruts.
Machado
5
@ JanDoggen, cela devient beaucoup plus complexe lorsqu'il s'agit de logiciels en ligne. L'utilisateur peut se trouver en Inde, sur un ordinateur anglais américain, mais en train de lire une page Web en portugais brésilien. Votre serveur peut être chinois. Votre application doit comprendre ce que l'utilisateur souhaite, quel que soit le système d'exploitation utilisé ou l'emplacement de votre serveur. Ainsi, vos 1 000,00 dollars deviennent 67 545,00 roupies: une devise américaine convertie au taux de change local, mais affichée au format portugais.
Noderman

Réponses:

87

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é.

Robert Harvey
la source
2
Je suis conscient de System.Globalization et d'autres frameworks qui gèrent ce genre de complexité pour moi. Ce que je ne sais pas, c'est quels problèmes ils résolvent. Par exemple, plusieurs applications que je vois utilisent un masquage spécifique sur ToString, tel que .ToString ("#, ## 0.00", paramètres régionaux), mais ce masque en tant que tel n'est pas valide si je montre ce numéro à un Indien. Donc, à part "n'utilisez pas de masques spécifiques", de quoi d'autre devrais-je être conscient?
Machado
7
Rien que je sache. Si vous utilisez le cadre correctement, cela devrait fonctionner. Il existe certains cas spécifiques de problèmes d'internationalisation, mais nous ne faisons pas ici une liste exhaustive de ceux-ci. Voir cet exemple .
Robert Harvey
5
C'est la seule réponse correcte: définissez vos paramètres régionaux, puis transmettez vos valeurs à travers la couche i18n avant de les afficher à l'utilisateur et laissez les auteurs de la structure s'en charger. Cela est vrai pour les nombres, les valeurs monétaires, les chaînes traduites, les dates, tout.
2
Réponse parfaite. "Ne réinventez pas la roue" est une chose à toujours prendre en compte lorsque vous traitez des problèmes courants comme celui-ci. Dommage que je ne puisse pas voter plus d'une fois.
BgrWorker
3
@Machado "Par exemple, plusieurs applications que je vois utilisent un masquage spécifique sur ToString, tel que .ToString (" #, ## 0.00 ", paramètres régionaux), mais ce masque en tant que tel n'est pas valide si je montre ce numéro à un Indien . " - Cela n’est peut-être pas clair, mais notez que la position de ,dans la chaîne de formatage est en grande partie hors de propos et que "#, 0.00" aurait le même effet. ,signifie simplement "utiliser des séparateurs de groupes de numéros de la manière spécifiée par les paramètres régionaux".
hdv
23

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.

Doc Brown
la source
2
Et pire encore, de nombreux langages de programmation modernes, les fonctions évidentes / par défaut de la bibliothèque standard sont "localisées". Donc, si le développeur ne connaît pas la localisation ou ne se préoccupe pas de la localisation, l'application résultante risque d'être dysfonctionnelle plutôt que simplement laide sur des systèmes étrangers.
Peter Green
4
Je suis en désaccord sur tout aussi mauvais. Un outil qui ne suit pas les conventions numériques locales dans son interface utilisateur sera toujours utilisable. Un outil qui ne parvient pas à lire ses propres fichiers de données ou à communiquer avec son serveur en raison de différences de convention numérique est beaucoup plus susceptible d'être inutilisable.
Peter Green
5
Une anecdote à ce sujet: le séparateur décimal de en-ZA a changé entre Win 7 et Win 8. Les valeurs précédemment stockées localement ont commencé à ne pas se désérialiser
Caleth
1
@ PeterGreen: un outil qui ne suit pas les conventions numériques locales dans son interface utilisateur peut toujours être utilisable ou peut être totalement inutilisable pour certains cas d'utilisation. Je ferais très attention de faire de telles hypothèses. La raison pour laquelle tant de développeurs se trompent dans la localisation des nombres, c’est exactement cela: faire ce genre d’hypothèses.
Doc Brown
1
@ DocBrown J'ai le code le plus horrible à maintenir qui soit affecté par les routines d'analyse d'entiers / flottants localisés de la bibliothèque standard. Je pense qu'il est juste de dire qu'un programme écrit sans souci de localisation lorsque les routines par défaut pour ces tâches ne sont pas localisées peut être inutilisable dans certaines situations, mais si les routines par défaut sont localisées, le programme sera toujours interrompu dès qu'il sera disponible. exécuté sur un ordinateur dont les paramètres régionaux ne sont pas anglais.
Sebastian Redl
9

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.

Amon
la source
18
Sachez également qu’un grand nombre d’utilisateurs n'aiment pas la convention jugée "correcte pour leur pays", le considèrent comme une pratique héritée du passé et ne souhaitent aucun groupement, ni un type de groupement différent. En tant que tel, il devrait probablement y avoir des options pour le désactiver ou le remplacer manuellement.
R ..
2

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.

JacquesB
la source
Ceci est résolu par ICU (MessageFormat). L'inconvénient est que l'adoption de l'unité de soins intensifs dans de nombreuses langues est encore faible. Cependant, le développeur doit toujours construire le message de la bonne manière. C’est vraiment plus que l’ingénierie. userguide.icu-project.org/formatparse/messages
noderman
Ceci est également résolu par la fonction plus largement disponible de ngettext dans GNU gettext, mais la classe MessageFormat semble également résoudre certains problèmes supplémentaires que ngettext ne résout pas.
hv
2

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

noderman
la source
Merci pour votre contribution, mais les chiffres m'intéressent surtout maintenant. :)
Machado
Sûr. Je viens de modifier la réponse pour inclure un lien vers l'outil de sondage, dans lequel vous pouvez affiner votre recherche.
Noderman
J'ai essayé de changer le Brésil pour vérifier les différences, mais cela ne semble pas permettre la visualisation: st.unicode.org/cldr-apps/v#/pt_BR/Number_Formatting_Patterns Sinon, l'outil semble plutôt bon.
Machado
C'est parce que le Brésil est la langue racine. L'outil d'enquête est en fait utilisé pour apporter des modifications aux données CLDR, les racines nécessitent donc des comptes spéciaux. Vous pouvez aller à GitHub et obtenir toutes les informations directement: github.com/unicode-cldr/cldr-numbers-modern/tree/master/main Spécifiquement, le Brésil est ici: github.com/unicode-cldr/cldr-numbers-modern/ blob / master / main / pt /…
noderman
0

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;
Machado
la source
1
Élément manquant: Pour les développeurs: 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.
Hyde