Die Lokalisierungsunterstützung in älteren Browsern ist schlecht. Ursprünglich lag dies an Phrasen in der ECMAScriptSprachspezifikation, die so aussehen:
Number.prototype.toLocaleString ()
Erzeugt einen Zeichenfolgenwert, der den Wert der Nummer darstellt, die gemäß den Konventionen des aktuellen Gebietsschemas der Hostumgebung formatiert wurde. Diese Funktion ist implementierungsabhängig und es ist zulässig, aber nicht empfohlen, dass sie dasselbe wie toString zurückgibt .
Jede in der Spezifikation definierte Lokalisierungsmethode ist als "implementierungsabhängig" definiert, was zu vielen Inkonsistenzen führt. In diesem Fall geben Chrome Opera und Safari dasselbe zurück wie .toString(). Firefox und IE geben Zeichenfolgen mit Gebietsschema-Format zurück, und IE enthält sogar ein Tausendertrennzeichen (perfekt für Währungszeichenfolgen). Chrome wurde kürzlich aktualisiert, um eine durch Tausende getrennte Zeichenfolge ohne feste Dezimalstelle zurückzugeben.
Für moderne Umgebungen bietet die ECMAScript Internationalization API-Spezifikation , ein neuer Standard, der die ECMAScript Language-Spezifikation ergänzt, eine viel bessere Unterstützung für den Zeichenfolgenvergleich, die Zahlenformatierung sowie die Datums- und Uhrzeitformatierung. Außerdem werden die entsprechenden Funktionen in der Sprachspezifikation festgelegt. Eine Einführung finden Sie hier . Implementierungen sind verfügbar in:
- Chrome 24
- Firefox 29
- Internet Explorer 11
- Oper 15
Es gibt auch eine Kompatibilitätsimplementierung, Intl.js , die die API in Umgebungen bereitstellt, in denen sie noch nicht vorhanden ist.
Das Ermitteln der bevorzugten Sprache des Benutzers bleibt ein Problem, da es keine Spezifikation zum Abrufen der aktuellen Sprache gibt. Jeder Browser implementiert eine Methode zum Abrufen einer Sprachzeichenfolge. Diese kann jedoch auf der Betriebssystemsprache des Benutzers oder nur auf der Sprache des Browsers basieren:
// navigator.userLanguage for IE, navigator.language for others
var lang = navigator.language || navigator.userLanguage;
Eine gute Problemumgehung besteht darin, den Accept-Language-Header vom Server auf den Client zu übertragen. Wenn es als JavaScript formatiert ist, kann es an die Internationalization API-Konstruktoren übergeben werden, die automatisch das beste (oder zuerst unterstützte) Gebietsschema auswählen.
Kurz gesagt, Sie müssen einen Großteil der Arbeit selbst erledigen oder ein Framework / eine Bibliothek verwenden , da Sie sich nicht darauf verlassen können, dass der Browser dies für Sie erledigt.
Verschiedene Bibliotheken und Plugins zur Lokalisierung:
Fühlen Sie sich frei, hinzuzufügen / zu bearbeiten.