Internationalisierung und Datenformate

Der folgende Artikel ist der Rohentwurf für einen Magazin-Artikel. 

Babylon war gestern!?

Verschiedene Sprachen gab es schon immer! Bereits im Alte Testament hatte ein Sprachgewirr den Stopp des Turmbaus zu Babel zur Folge. Diese Zeiten sind dank Normierungsgremien schon lange vorbei – allerdings beherbergen unterschiedliche Sprachen oft auch unterschiedliche Darstellungsformate was bei einer Konvertierung wiederrum auch heutzutage noch zu den unterschiedlichsten Fehlern führen kann.

Neben der eigentliche Sprache unterscheiden sich auch Datenformate (Zahlen, Uhrzeiten, Datum, …). Hier gibt es unterschiedliche Formate und jedes Land macht es irgendwie anders… Es ist noch nicht mal gesagt, dass wen die gleiche Sprache gesprochen wird, dass dann die Formate gleich sind.

Ein Datum im englischsprachigen Kanada schaut anders aus als in den USA. So wird bspw. der 14. November 2011 in kurzer Form in Kanada als 14/11/2011 geschrieben und in den USA als 11/14/2011 (Monat und Tage genau andersherum).

Es ist durchaus ganz interessant, zu schauen wie unterschiedlich hier die Formate zum Teil sind (dies geht sogar so weit, dass unterschieden wird an welchem Tag die Woche beginnt)

An einem Windows-PC kann man hier ganz einfach recherchieren:

Windows à Systemsteuerung à Region und Sprache:

Noch detaillierte Informationen bekommt man zu den jeweiligen Länderspezifikas wenn sich die „Weiteren Einstellungen“ anschaut.

Anbei eine kurze Aufzählung von Elementen die sich je Ländereinstellung alleine bei den Zahlenformaten unterscheiden können:

Zahlen	Beispiel 1 (de)	Beispiel 2
Dezimaltrennzeichen	,	.         [USA][fs1] [mre2]
Anzahl der Dezimalstellen	2	2        [USA][fs3] [mre4]
Symbol für Zifferngruppierung	.	<blank>       [Frankreich]
Zifferngruppierung	123.456.789	123456.789  [Grönland: einmalige Gruppierung]
Negatives Vorzeichen	-	-         [USA][fs5] [mre6]
Format für negative Zahlen	-1,1	1.1-    [persisch, minus nachgestellt]
Führende Null anzeigen	0,7	.7 [Thai]
Listentrennzeichen	;	,         [USA]
Maßsysteme	Metrisch, z.B. Zentimeter	US-Maße, z.B. inch         [USA]

Neben den Zahlen gibt es noch weitere Kategorien wie etwa Währung, Uhrzeit, Datum und Sortierung die sich je nach Land unterscheiden können.

Nach dieser kleinen Aufzählung von Besonderheiten überrascht es vermutlich auch nicht, dass dies in der IT manchmal zu Problemen führen kann.

 

Interpretation

Sind die richtigen Werte erst mal in einem IT-System wie einer Datenbank gelandet, hat man schon einen Großteil richtig gemacht. Eine Datenbank verwaltet Zahlen, Uhrzeiten und Datumswerte in einer internen Darstellung.

Die größte Fehlerquelle tritt daher meist bei der Konvertierung der Werte in das interne Format auf. Die entsprechenden Werte müssen von den Systemen korrekt interpretiert werden.

Im folgendem einige Szenarien bei denen es bei der Interpretation von Werten oft zu Problemen kommen kann:

Datenerfassung auf Webseiten / Spracheinstellungen

Ein Webbrowser kann ebenfalls eigene Spracheinstellungen haben.

Dies ist besonders dann interessant wenn eine Webanwendung in mehrere Sprachen verfügbar sein soll.

Die eingestellte Länderkennung wird dann an den Server mitgegeben und ermöglich es bestehenden Web Frameworks eine Konvertierung vorzunehmen in die entsprechenden Datentypen (Number, Date, String).

Dies klappt solange gut, solange man auch mit den korrekten Datentypen arbeitet. Wird ein Datumswert in einem Textfeld (String) gespeichert, kann ein Framework hier nicht mehr unterstützen. Eine anschließende manuelle Konvertierung ist oft schwierig oder sogar unmöglich.

àsaubere Datenformate, nichts selber machen; die meisten Frameworks (Struts, JSF, ASP.NET) können / besitzen NLS (i18n).

CSV - Importdateien

Häufig werden CSV-Dateien aus Excel zum Import in IT Systeme verwendet.

Auch dies kann zu Problemen führen.

Wenn man eine CSV Datei mit einem Texteditor ansieht, sieht man das dort meist Strichpunkte als Trennzeichen verwendet werden und keine Kommas. Dies liegt daran, dass in Nordeuropa als Listentrennzeichen ein Strichpunkt verwendet wird, in den USA dagegen ein Komma.

Dies hat zur Folge, dass bei der Erstellung einer CSV Datei aus Excel heraus die Ländereinstellungen des Betriebssystems abgefragt werden. Werden diese nicht überschrieben kann daher eine CSV Datei auf einem Rechner mit deutschen Einstellungen anders aussehen als auf einem amerikanischen Rechner.

Wenn die CSV Datei in ein System hochgeladen wird, kann man das entsprechende Format ggf. noch an der Ländereinstellung des Clients erkennen. Falls ein System allerdings eine CSV Schnittstelle hat, empfiehlt es sich das Format im Vorfeld fest mit allen Beteiligten  zu vereinbaren.

àNicht die Defaulteinstellung des Listentrenners nehmen, sondern ein festes Format dafür vereinbaren.

Das gleiche Problematik beim Import tritt nicht nur bei den Listentrennern ein sondern auch bei den Datentypen einzelner Spalten (Zahlen, Datum). Hier empfiehlt es sich wiederrum das genau Format mit allen beteiligten im Vorfeld zu definieren!

Batchverarbeitung

Bei der Batchverarbeitung treten die gleiche Probleme auf wie bereits oben beschrieben, nur dass diese manchmal schwerer zu testen sind.

Die meisten Programmiersprachen konvertieren Zahlen und Datumswerte mit den Defaulteinstellungen des Systems auf dem sie gerade laufen. Im Client-Bereich ist dies auch sehr nützlich; läuft das Programm allerdings auf dem Server kann das zu Problemen führen.

Leider kommt es immer wieder vor, dass sich die lokalen Einstellungen nicht von denen auf der Stagingumgebung unterscheiden. Hier funktioniert dann immer noch alles…

Wenn sich dann allerdings die Stagingumgebung von der Produktion im Bereich der Region- und Ländereinstellungen unterscheidet, kann es zu ungewünschten Problemen führen.

Aufgrund von mangelnden Serverresourcen kommt der Fall, dass die Testumgebung nicht identisch mit der Produktionsumgebung ist, in der Praxis leider öfters vor.

àNicht die Defaulteinstellung nehmen, sondern ein festes Format. bspw. immer mit der Angabe „de“

Summary

Mit Tests können natürlich auch hier viele Fehler vermieden werden. Aufgrund von unterschiedlichen Default-Einstellungen der Test- und Produktivserver kann es aber trotzdem immer wieder zu unerwünschten Formatproblemen kommen.

Problem ist erkannt und in der Java Welt versucht man diese Problematik ein bisschen zu bekämpfen mit dem neuen Datumstyp „Joda-Time“.

Letztendlich ist das Themenfeld Zahlen- und Datuminterpretation immer ein Fehlerpotential, das man nur mit entsprechenden Know How sauber bewältigen kann.