Wie kann man Zahlen richtig lokalisieren?

Welche Vorsichtsmaßnahmen sollten beim Lokalisieren von Nummern in meiner Front-End-Anwendung beachtet werden?

Beispiel: Im brasilianischen Portugiesisch (pt-BR) teilen wir Tausende mit Punkten und Dezimalstellen mit Kommas. In US-Englisch (en-US) ist das Gegenteil der Fall. In pt-BR präsentieren wir die durch Tausender getrennten Ziffern, genau wie in en-US. Aber als ich heute über indisches Englisch (en-IN) las, stieß ich auf dieses Juwel:

Das indische Nummerierungssystem wird für die Zifferngruppierung bevorzugt. Zahlen unter 100.000 / 100.000 werden, wenn sie in Worten geschrieben oder gesprochen werden, genauso ausgedrückt wie in Standard-Englisch. Zahlen, die 100.000 / 100.000 enthalten und darüber hinausgehen, werden in einer Teilmenge des indischen Nummerierungssystems ausgedrückt.

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

Was bedeutet:

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

Neben Kommas und Punkten und anderen spezifischen Trennzeichen scheint auch die Maskierung ein berechtigtes Anliegen zu sein.

Welche weiteren Einschränkungen sollten beim Lokalisieren von Nummern in meiner Front-End-Anwendung beachtet werden? Vor allem, wenn ich Zahlen für nicht-lateinische Zeichensätze zeige?

Die meisten Programmiersprachen und Frameworks verfügen bereits über einen sinnvollen Arbeitsmechanismus, den Sie hierfür verwenden können.

Das C # -Ökosystem verfügt beispielsweise über den Namespace System.Globalization , mit dem Sie die gewünschten Werte angeben können Culture:

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

Dies ist nicht etwas, das Sie neu erfinden möchten. Verwenden Sie die Internationalisierungsfunktionen, die von Ihrer bevorzugten Sprache oder Ihrem bevorzugten Framework bereitgestellt werden.

Einige ausgezeichnete Antworten hier bereits, aber sie haben eine Sache nicht erwähnt, die ich für wichtig halte, um nicht zu vergessen: Stellen Sie sicher, dass überall, wo eine Zahlenformatierung stattfindet, klar ist (oder gesteuert werden kann), wofür die Ausgabe verwendet wird:

• Wenn es sich um die Benutzeroberfläche handelt, muss die lokalisierte Formatierung angewendet werden

• Wenn die Nummer in eine Datei geschrieben oder über das Netzwerk oder eine andere Form gesendet wird, in der die Nummer in maschinenlesbarer Form benötigt wird, stellen Sie sicher, dass sie nicht gemäß der aktuellen Kultur, sondern gemäß einer festen Einstellung formatiert ist (Verwenden Sie beispielsweise in der .NET-Umgebung InvariantCulture).

Andernfalls treten Probleme auf, wenn Zahlen mithilfe von Kultur A geschrieben oder gesendet und mithilfe von Kultur B gelesen oder empfangen werden.

Nach meiner Erfahrung ist dies eine der größten Hürden bei der korrekten Lokalisierung von Zahlen: Bei dem Versuch, die Zahlenformatierung und -konvertierung zu zentralisieren, beginnen die Benutzer, allgemeine, wiederverwendbare Funktionen für die Formatierung zu erstellen und diese dann in der gesamten Datenbank zu verwenden Ort. Sobald man die Zahlen jedoch auch in einem maschinenlesbaren Zeichenfolgenformat an einer anderen Stelle im Programm benötigt, werden zwei Varianten benötigt: eine lokalisierte und eine nicht lokalisierte Formatierung. Dies birgt ein hohes Risiko, die beiden Konvertierungsarten zu verwechseln (insbesondere, wenn die Standardeinstellungen für das Gebietsschema der Entwickler und Testcomputer ähnlich der "festen" Einstellung für Nicht-UI-Formatierungen sind, ein Teil der Benutzerbasis dies jedoch nicht tut).

Nachtrag: Dieses Problem kann sehr schlimm werden, wenn vorher nicht klar ist, ob die Nummer später von einem Computer oder von einem Menschen (oder beiden) verarbeitet wird. Zum Beispiel als Teil der Ausgabe einer Protokolldatei. In solchen Fällen ist es wahrscheinlich am besten, sich an den "neutralen" Standard zu halten, kein Trennzeichen außer dem Punkt als Dezimaltrennzeichen zu verwenden.

Die richtige Lokalisierung ist ziemlich schwierig. Die meisten Programmier-Ökosysteme haben Versuche, Lösungen für die Lokalisierung zu finden, aber meiner Erfahrung nach sind sie alle mehr oder weniger kaputt. Ich würde daher vorschlagen:

• Versuchen Sie nicht, die Lokalisierung zu automatisieren. Es wird nicht immer funktionieren. Es ist schwierig für Sie, die Probleme zu erkennen, und für Ihre Benutzer frustrierend.

• Seien Sie konsistent: Mischen Sie nicht verschiedene Sprachen und Formatierungskonventionen, z. B. brasilianische Dezimaltrennzeichen in englischem Text.

• Unterstützen Sie explizit einen bestimmten Satz von Gebietsschemas. Arbeiten Sie mit Ihren Übersetzern zusammen, um die richtige Formatierung für Datums- und Zahlenangaben zu finden. Sie werden wahrscheinlich Ihr eigenes Lokalisierungs-Toolkit erstellen, obwohl die meisten (aber nicht alle) Probleme an eine vorhandene Bibliothek delegiert werden können.

• Nehmen Sie einfache Formatierungsoptionen vor, die von jedem Benutzer konfiguriert werden können: Formate für Datums- und Uhrzeitangaben, Dezimaltrennzeichen, bevorzugte Währung usw. Dies ist besonders nützlich für Reisende, Expats oder andere Personen, die mehrere Orte oder Kulturen unabhängig von der Sprache mischen müssen.

Ein wichtiger Gesichtspunkt: Sie sollten entscheiden, wie viel ausreicht. Denn wenn Sie versuchen, das Kaninchenloch perfekt zu lokalisieren, wird es immer komplexer.

Nehmen Sie ein typisches Etikett wie "Sie haben n Artikel ausgewählt." Dies liest sich falsch, wenn nur ein Element ausgewählt ist. Die hässliche, aber pragmatische Lösung lautet: "Sie haben n Artikel ausgewählt." Aber wenn du es richtig machen willst, brauchst du zwei verschiedene Texte, abhängig von n. Wenn Sie versuchen, dies in mehreren Sprachumgebungen zu tun, wird es schnell sehr komplex, da verschiedene Sprachen unterschiedliche Grammatik haben. Einige Sprachen haben unterschiedliche Konjugationen für ein, zwei oder mehrere Elemente und so weiter. Aus diesem Grund beklagen sich Fachleute immer, dass die vorhandenen Lokalisierungsrahmen nicht ausreichen.

Aber Sie müssen Ihre Schlachten auswählen und entscheiden, welcher Grad an Raffinesse ausreicht. Für viele Zwecke sollte eine Standardlokalisierungsbibliothek zum Formatieren von Zahlen und Datumsangaben ausreichen.

Sie können sich nicht aller Vorbehalte von Sprachen bewusst sein. Sie sprechen von Zahlen, aber es gibt Pluralformen, Geschlechter, Zusammenstellungen. Sie müssen wissen, dass sie existieren, und sich auf umfangreiche Arbeit anderer verlassen, insbesondere auf die ICU- und CLDR-Projekte.

Die meisten modernen Sprachen implementieren einige oder alle Funktionen dieser Projekte. Wenn Sie diese jedoch nicht verwenden, erhalten Sie beim Lesen dieser Projekte eine gute Vorstellung davon, wonach Sie suchen müssen.

http://site.icu-project.org

http://cldr.unicode.org

Aktualisieren

Das CLDR-Vermessungstool bietet Zugriff auf alle Muster. Hier erfahren Sie, wie Sie eine Nummer in einer bestimmten Sprache und Region formatieren. Zum Beispiel Portugiesisch (Portugal):

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

Und wenn Sie wirklich alle Daten überprüfen möchten (und sie vielleicht verwenden möchten), können Sie die CLDR im JSON-Format von GitHub herunterladen:

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

Mehr Infos zum Download hier:

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

Nun, obwohl ich mit all den Antworten hier zufrieden bin, bin ich nicht wirklich mit jeder einzelnen zufrieden, um eine als die richtige Antwort zu markieren.

Bisher sollten wir Folgendes beachten, wenn wir Zahlen lokalisieren:

Für Menschen :

• Tausende Separatoren trennen sich nicht immer zu Tausenden. Siehe indischen Fall in der Frage;
• Tausende und Nachkommastellen variieren von Kultur zu Kultur. In Deutschland werden Tausende beispielsweise durch Leerzeichen getrennt, in Englisch durch Kommas und in Portugiesisch durch Punkte.
• Wir haben keine Informationen, wenn es einen relevanten Unterschied zwischen der Sprache von links nach rechts und der Sprache von rechts nach links gibt.
• Stellen Sie einen bestimmten Satz unterstützter Lokalisierungen bereit und machen Sie ihn Ihren Benutzern klar.
• Erlauben Sie Ihren Benutzern, die Standardlokalisierung in eine der unterstützten Lokalisierungen zu ändern, und sie freuen sich und senden Ihnen Kuchen, weil Sie ein großzügiger Gott sind. :);

Für Computer :

• Denken Sie daran, dass Maschinen nicht nachsichtig sind und beim Serialisieren und De-Serialisieren einer Nummer immer die gleiche Formatierung erhalten sollten.
• Bleibe dabei bei einem einzigen Format;
• Verwenden Sie das minimal notwendige Format. Vermeiden Sie Tausendertrennungen. Dezimalstellen sollten für die Serialisierung und Deserialisierung ausreichen.

Für Entwickler :

• (wie von @hyde unten vorgeschlagen): Vorhandene Bibliothek zur Lokalisierung verwenden;
• Verwenden Sie nach Möglichkeit native Tester und geben Sie Lokalisierungs- / Internationalisierungstestfälle an, andernfalls vertrauen Sie der Bibliothek.
• Denken Sie daran, dass die Lokalisierung ein größtenteils gelöstes Problem ist. Jede Hauptsprache verfügt über eine Bibliothek (muttersprachlich oder extern), in der Zahlen, Datumsangaben und Uhrzeiten lokalisiert werden können.