Wie kann man Zahlen richtig lokalisieren?

38

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?

Machado
quelle
3
Wird noch interessanter im Umgang mit Geld! :-)
Stephan Bijzitter
4
Ich spreche nicht über das Mars-Nummerierungssystem, das die Basis 6 hat (zwei mal drei Finger) ;-) Aber Japanisch hat auch eine Seltsamkeit: man = 10.000 geschrieben als 1.0000, oku = 100.000.000 geschrieben in Japan als 1.0000.0000 und chō. ..
rate
6
Warum musst du dir darüber Sorgen machen? Können Sie die Betriebssystemeinstellungen nicht verfolgen?
Jan Doggen
3
@JanDoggen, weil das eines der interessanten Probleme der Software-Engineering-Domäne ist, "wie man Daten den Menschen richtig präsentiert". Worüber ich beim Entwerfen eines Systems besorgt sein sollte, ist die Domäne dieser Frage. Und ich spreche nicht mal über Geld, wie unser Freund Stephan sagte, noch über Datum und Uhrzeit. Nur rohe Zahlen.
Machado
5
@JanDoggen, das wird im Umgang mit Online-Software viel komplexer. Der Benutzer befindet sich möglicherweise in Indien auf einem Computer in US-Englisch, liest jedoch eine Webseite in brasilianischem Portugiesisch. Ihr Server ist möglicherweise chinesisch. Ihre App muss verstehen, was der Benutzer möchte, unabhängig davon, welches Betriebssystem er verwendet oder wo sich Ihr Server befindet. So werden Ihre 1.000,00 Dollar zu 67.545,00 Rupien: eine US-Währung, die zum lokalen Wechselkurs umgerechnet, aber im portugiesischen Format angezeigt wird.
Noderman

Antworten:

87

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.

Robert Harvey
quelle
2
Mir sind System.Globalization und andere Frameworks bekannt, die für mich mit dieser Komplexität umgehen. Ich weiß nicht, welche Probleme sie lösen. Beispielsweise verwenden einige Anwendungen, die ich sehe, eine spezielle Maskierung für ToString, wie .ToString ("#, ## 0.00", Gebietsschema), aber diese Maske per se ist ungültig, wenn ich diese Nummer einer indischen Person zeige. Was sollte ich außer "Keine bestimmten Masken verwenden" noch beachten?
Machado
7
Nichts, von dem ich weiß. Wenn Sie das Framework ordnungsgemäß verwenden, sollte es nur funktionieren. Es gibt bestimmte, spezielle Fälle von Internationalisierungsproblemen, aber eine umfassende Liste dieser Probleme erstellen wir hier nicht. Siehe dieses Beispiel .
Robert Harvey
5
Dies ist die einzig richtige Antwort: Legen Sie Ihr Gebietsschema fest, und verschieben Sie dann Ihre Werte durch die i18n-Ebene, bevor Sie dem Benutzer angezeigt werden, und lassen Sie die Framework-Autoren damit umgehen. Dies gilt für Zahlen, Währungswerte, übersetzte Zeichenfolgen, Datumsangaben und alles andere.
2
Perfekte Antwort. "Das Rad nicht neu erfinden" sollte immer berücksichtigt werden, wenn es um häufig auftretende Probleme wie dieses geht. Schade, dass ich nicht mehr als einmal dafür stimmen kann.
BgrWorker
3
@Machado "Beispielsweise verwenden einige Anwendungen, die ich sehe, eine bestimmte Maskierung für ToString, wie .ToString (" #, ## 0.00 ", Gebietsschema), aber diese Maske per se ist ungültig, wenn ich diese Nummer einer indischen Person zeige . " - Es ist möglicherweise nicht klar, aber beachten Sie, dass die Position von ,in der Formatzeichenfolge weitgehend irrelevant ist und "#, 0.00" den gleichen Effekt haben würde. ,bedeutet einfach "Nummerngruppentrennzeichen in der vom Gebietsschema angegebenen Weise verwenden".
HDV
23

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.

Doc Brown
quelle
2
Und schlimmer noch, viele moderne Programmiersprachen, die offensichtlichen / Standardfunktionen in der Standardbibliothek sind "lokalisiert". Wenn der Entwickler die Lokalisierung nicht kennt oder sich nicht darum kümmert, ist es wahrscheinlich, dass die resultierende Anwendung nicht nur auf fremden Systemen hässlich ist, sondern auch nicht funktioniert.
Peter Green
4
Ich bin nicht einverstanden ebenso schlecht. Ein Tool, das in seiner Benutzeroberfläche nicht den lokalen numerischen Konventionen folgt, kann weiterhin verwendet werden. Ein Tool, das seine eigenen Datendateien nicht liest oder aufgrund von Nichtübereinstimmungen mit numerischen Konventionen nicht mit dem Server kommuniziert, ist mit größerer Wahrscheinlichkeit unbrauchbar.
Peter Green
5
Eine Anekdote dazu: Der Dezimaltrenner für en-ZA wurde zwischen Win 7 und Win 8 geändert. Zuvor lokal gespeicherte Werte konnten nicht deserialisiert werden
Caleth,
1
@PeterGreen: ein Werkzeug , das nicht lokale numerische Konventionen in UI es folgt möglicherweise noch brauchbar sein, oder es kann für bestimmte Anwendungsfälle völlig unbrauchbar. Ich würde sehr vorsichtig sein, solche Annahmen zu treffen. Der Grund, warum so viele Entwickler die Lokalisierung von Zahlen falsch verstehen, ist genau das - was diese Art von Annahmen betrifft.
Doc Brown
1
@DocBrown Ich habe den schrecklichsten zu wartenden Legacy-Code, der unter den lokalisierten Integer / Float-Parsing-Routinen der Standardbibliothek leidet. Ich denke, es ist fair zu sagen, dass ein Programm, das ohne Rücksicht auf die Lokalisierung geschrieben wurde, wenn die Standardroutinen für diese Jobs nicht lokalisiert sind , für einige Situationen unbrauchbar sein kann, aber wenn die Standardroutinen lokalisiert sind, wird das Programm immer in dem Moment unterbrochen, in dem es ist wird auf einem Computer ausgeführt, auf dem das globale Gebietsschema nicht Englisch ist.
Sebastian Redl
9

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.

amon
quelle
18
Beachten Sie auch, dass eine große Anzahl von Benutzern die Konvention hasst , die als "für ihr Gebietsschema korrekt" eingestuft wird, sie für eine abscheuliche Legacy-Praxis hält und überhaupt keine Gruppierung oder eine andere Art der Gruppierung wünscht. Als solches sollte es wahrscheinlich Optionen geben, um es auszuschalten oder manuell zu überschreiben.
R ..
2

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.

JacquesB
quelle
Dies wird durch ICU (MessageFormat) gelöst. Der Nachteil ist, dass die Akzeptanz der Intensivstation in vielen Sprachen noch schwach ist. Der Entwickler muss die Nachricht jedoch noch richtig konstruieren. Es ist wirklich mehr als der technische Aspekt. userguide.icu-project.org/formatparse/messages
noderman
Dies wird auch durch die weiter verbreitete Funktion ngettext in GNU gettext gelöst , aber die MessageFormat-Klasse scheint auch einige zusätzliche Probleme zu lösen, die ngettext nicht löst.
HDV
2

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

Noderman
quelle
Danke für die Eingabe, aber ich interessiere mich mittlerweile hauptsächlich für Zahlen. :)
Machado
Sicher. Ich habe die Antwort soeben bearbeitet, dass sie einen Link zum Umfragetool enthält, mit dem Sie Ihre Suche eingrenzen können.
Noderman
Ich habe versucht, do Brazil zu ändern, um die Unterschiede zu überprüfen, aber es scheint keine Visualisierung dafür zu ermöglichen: st.unicode.org/cldr-apps/v#/pt_BR/Number_Formatting_Patterns Ansonsten scheint das Tool ziemlich gut zu sein.
Machado
Das liegt daran, dass Brasilien die Stammsprache ist. Das Umfragetool wird tatsächlich zum Ändern der CLDR-Daten verwendet, sodass für die Stammdaten spezielle Konten erforderlich sind. Sie können zu GitHub gehen und alle Informationen direkt erhalten: github.com/unicode-cldr/cldr-numbers-modern/tree/master/main Brasilien ist hier: github.com/unicode-cldr/cldr-numbers-modern/ blob / master / main / pt /…
noderman
0

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.
Machado
quelle
1
Fehlendes Element: Für Entwickler: Verwenden Sie die vorhandene Bibliothek zur Lokalisierung. Verwenden Sie nach Möglichkeit native Tester und geben Sie Lokalisierungs- / Internationalisierungstestfälle an, andernfalls vertrauen Sie der Bibliothek.
Hyde