JavaScript/Objekte/Intl/Locale
Die Konstruktorfunktion Intl.Locale erzeugt ein Objekt, das die Eigenschaften eines vom Browser unterstützten Unicode-Locale beschreibt.
Syntax
const locale = new Intl.Locale(tag, optionen);
Ein Locale-Tag (engl. tag=Etikett, Beschriftung) besteht aus einem oder mehreren Sub-Tags. Eins davon ist Pflicht: das Sprachkürzel, z. B. de für Deutsch oder en für Englisch. Für viele Sprachen gibt es mehr als ein Locale. Zur Unterscheidung dieser Locales gibt es weitere Subtags, die man nach bestimmten Regeln in das Locale-Tag einbauen kann – aber nicht muss. Wenn Subtags verwendet werden, werden sie durch das Zeichen - (das Minus-Zeichen im ASCII-Code) voneinander getrennt. Der Unicode-Standard für Locales erlaubt als Trennzeichen auch das Unterstrich-Zeichen _, das wird von JavaScript aber nicht verstanden.
Das bekannteste Subtag ist die Region, vielleicht hast du schon einmal Sprachangaben wie de-DE oder en-US gesehen. Welche Sprache welche Regionen unterstützt, kannst du im CLDR-Projekt im Ordner /common/main herausfinden. Allgemeine Informationen zur Konstruktion von Locale-Tags finden sich im RFC 5646 und auf den Seiten von unicode.org.
Die Reihenfolge der Subtags ist vorgegeben. Sie lautet:
- Sprache
- Schrift
- Region
- Varianten (mehr als eine möglich)
- Erweiterungen
RFC5646 sieht vor, dass Erweiterungen mit einem Subtag eingeleitet werden, das aus einem einzelnen Buchstaben besteht und bei der IANA registriert ist. Unicode Locales verwenden das Erweiterungs-Subtag u. Hinter dem u folgen die Erweiterungsangaben in Form eines zweistelligen Schlüssels und dem Wert für diese Angabe. Mehrere u-Erweiterungen sind möglich (das u wird aber nicht wiederholt). Welche Erweiterungen für welche Intl-Funktion relevant sind, ist bei den jeweiligen Funktionen angegeben. Ein einfaches Beispiel für ein Locale-Tag mit Erweiterung folgt.
Sowohl die Region wie auch die übrigen Subtags lassen sich einfacher angeben, indem man das Optionen-Objekt verwendet. Wenn du beispielsweise das Locale-Objekt für österreichisches Deutsch mit Telefonbuch-Sortierung (Erweiterungsschlüssel ca mit dem Wert phonebk) erstellen möchtest, dann kannst du "de-AT-u-co-phonebk" als Tag übergeben, du kannst es aber auch so machen:
const at_Telbu = new Intl.Locale("de", { region: "AT", collation: "phonebk" });
console.log(at_Telbu.toString();
und auf diesem Weg zum Locale und zum vollständigen Tag gelangen. Die übrigen Optionen, die man angeben kann, sind im nächsten Abschnitt beschrieben, aber zunächst folgt die Übersicht der Eigenschaften und Methoden eines Locale-Objekts:
Eigenschaften
Methoden
Pre-Standard Methoden (Stand: Nov. 2023)
Inhaltsverzeichnis
Optionen für die Erzeugung eines Locale
Gibt man eine Option an, die bereits im Tag spezifiziert ist, so wird die Angabe im Tag überschrieben. Lässt man eine Option weg, erhält man ein Locale, das den sprachspezifischen Defaultwert für diese Option verwendet.
- language
- Eigentlich unnötig, denn die Sprache übergibt man bereits im Tag. Gibt man diese Option an, überschreibt sie die Sprachangabe im Tag. Eine Sprachangabe muss 2, 3 oder 5 bis 8 Zeichen lang sein.
- script
- Gibt an, welche Schrift für die Sprache verwendet wird. Das Subtag für die Schrift besteht immer aus 4 Buchstaben und wird für die deutsche Sprache nicht gebraucht. In China gibt es hingegen mehrere Schriften:
Hans(vereinfacht) undHant(traditionell). - Das script-Subtag lässt sich im Locale-Tag angeben, indem man es direkt hinter der Sprachangabe notiert. Traditionelles Chinesisch wäre beispielsweise
zh-Hant. - Eine Liste aller Schriftkürzel findest du zum Beispiel im
de.xml-Locale im CLDR-Projekt (Vorsicht, große Datei), und welche Sprache welche Schriftkürzel kennt, erfährt man darüber, dass es dort eine entsprechende XML Datei gibt. Diese XML-Dateien enthalten immer auch eine Region (also zum Beispiel zh-Hant-CN für traditionelles Chinesisch in der VR China, oder pa-Arab-PK für arabisch geschriebenes Punjabi in Pakistan). - region
- Gibt die Region an, für die ein Locale einer Sprache benötigt wird. Für Deutsch kann das DE für Deutschland sein, AT für Österreich, es gibt aber auch noch BE (belgische Ostkantone), CH (Schweiz), IT (Südtirol), LI (Liechtenstein) und LU (Luxemburg). Auch hier hilft wieder das CLDR weiter, wenn man unterstützte Regionen für eine Sprache sucht.
- Grundsätzlich finden sich die Regionskürzel in der ISO3166-1 Norm, JavaScript unterstützt die Formen aus zwei Buchstaben oder drei Ziffern.
- Um eine Region im Locale-Tag direkt zu verwenden, notiert man sie als Subtag hinter der Sprache und der optionalen Schrift. Beispiele wären de-DE oder das vorhin schon genannte zh-Hant-CN.
- calendar
- Bezeichnet den Kalender, der für Datumsfunktionen (beispielsweise Intl.DateTimeFormat) zu verwenden ist. Welche Kalender ein Locale unterstützt, findest du über die getCalendars()-Methode* eines Locales heraus. In Europa findet der Kalender
gregoryVerwendung. - Der Kalender lässt sich im Locale-Tag als Unicode-Erweiterung mit dem Schlüssel
caangeben, z. B.zh-CN-u-ca-chinesefür ein Locale mit chinesischem Kalender. - collation
- Die Collation definiert die Sortierreihenfolge für Text. Für Deutschland ist die
phonebk-Collation als Alternative zur Default-Sortierungeorrelevant. Mehr dazu findest du auf der Intl-Übersichtsseite. - Die Collation lässt sich im Locale-Tag als Unicode-Erweiterung mit dem Schlüssel
coangeben, z. B.de-DE-u-co-phonebk. - numberingSystem
- Das verwendete Zahlensystem. Deutschland verwendet
latn- was leicht irreführend ist, weil wir arabische Zahlen verwenden, nicht römische. Gemeint sind aber hier die „westlichen Ziffern“ aus dem "Latin" Zeichensatz. Insgesamt listet CLDR 81 Zahlensysteme auf. Welche von einem bestimmten Locale unterstützt werden, findest du über die getNumberingSystems()-Methode eines Locales heraus. - Das Zahlensystem lässt sich im Locale-Tag als Unicode-Erweiterung mit dem Schlüssel
nuangeben, z. B.de-DE-u-nu-fullwide(was zu einer Ausgabe mit den Unicodezeichen für vollbreite Formen führt). - caseFirst
- Eine Sortieroption. Näheres dazu findest du beim Konstruktor für Intl.Collator.
- Die caseFirst-Option lässt sich im Locale-Tag als Unicode-Erweiterung mit dem Schlüssel
kfangeben. - hourCycle
- Welches Zeitformat soll verwendet werden. Näheres dazu findest du beim Konstruktor für Intl.DateTimeFormat.
- Die caseFirst-Option lässt sich im Locale-Tag als Unicode-Erweiterung mit dem Schlüssel
hcangeben. - numeric
- Eine Sortieroption. Sie gibt an, ob versucht werden soll, Zahlen in zu sortierendem Text zu erkennen und dann an Hand des Zahlenwertes zu sortieren. Näheres dazu findest du beim Konstruktor für Intl.Collator.
- Die numeric-Option lässt sich im Locale-Tag als Unicode-Erweiterung mit dem Schlüssel
knangeben.
Eigenschaften eines Locale-Objekts
Locale-Optionen
Alle Locale-Optionen, die über das Optionsobjekt beim Konstruktoraufruf gesetzt werden können, finden sich unter diesem Namen auch im erzeugten Locale-Objekt wieder. Für Optionen, die du nicht gesetzt hast, wird der Defaultwert des Locales verwendet, dieser Defaultwert wird aber nicht im Locale-Objekt eingetragen. Statt dessen enthält die betreffende Eigenschaft den Wert undefined.
Wichtig zu wissen ist auch, dass die Konstruktorfunktion die Optionen nur darauf prüft, ob sie die richtigen Zeichen verwenden und die richtige Länge haben. Ein Locale-Tag wie "tlh-Wiki-QO-Selfhtml" würde als „klingonisch“ (sic!), mit Schrift „Wiki“, Region „QO“ (Qo'noS) und Variante „Selfhtml“ akzeptiert. Davon weiß dein Computer höchstwahrscheinlich nichts, und er würde für alle praktischen Zwecke auf dein Default-Locale zurückfallen, aber er würde dieses Locale-Tag akzeptieren.
baseName
Die baseName-Eigenschaft erstellt aus dem Locale ein Locale-Tag, das die Eigenschaften language, script, region darstellt. Falls dem Konstruktor eine Variante übergeben wurde, wird auch sie hinzugefügt.
Methoden eines Locale-Objekts
maximize()
Diese Methode versucht, ein Locale-Tag mit den wahrscheinlichsten Werten für Schrift und Region zu ergänzen, sofern diese nicht angegeben wurden. Welche Werte die wahrscheinlichsten sind, wird durch die <likelySubtags> Auflistung im CLDR-Projekt festgelegt. Für die deutsche Sprache findet sich dort lediglich der Eintrag, dass "de" wahrscheinlich zu "de-Latn-DE" zu erweitern ist, also deutsch in Deutschland mit lateinischer Schrift.
Wenn für die angegebenen Werte von Sprache, Schrift und Region kein likelySubtags'-Eintrag existiert, wird versucht, ohne Region oder Schrift einen Eintrag zu finden. Das Locale wird dann um die so gefundenen Werte von Schrift und Region ergänzt.
und (undefiniert) erstellt und maximize() auf dieses Locale angewendet, erhält man die wahrscheinlichste Sprache für die angegebene Region oder Schrift.minimize()
Diese Methode versucht, unnötige Angaben von Schrift oder Region aus dem Locale-Tag zu entfernen. Dazu bildet sie zunächst ein Maximal-Locale, indem sie die maximize()-Methode auf das gegebene Locale-Tag anwendet. Im nächsten Schritt wird zunächst nur mit der Sprache, dann mit Sprache+Region und schließlich mit Sprache+Schrift ein Minimal-Locale gebildet und darauf maximize() angewendet. Wenn einer dieser Schritte ein Locale findet, das mit dem anfangs gebildeten Maximal-Locale übereinstimmt, so ist dieses Minimal-Locale das Ergebnis von minimize. Ergibt sich kein Treffer, so ist das Maximal-Locale das Ergebnis.
console.log((new Intl.Locale("de")).maximize()); // Maximal-Locale zu "de"
// --> "de-Latn-DE"
console.log((new Intl.Locale("de-DE")).minimize()); // --> "de"
console.log((new Intl.Locale("de-AT")).minimize()); // --> "de-AT"
console.log((new Intl.Locale("de-Latn-DE")).minimize()); // --> "de"
console.log((new Intl.Locale("de-Hant-DE")).minimize()); // --> "de-Hant"
In "de-DE" ist die Regionenangabe überflüssig, um zum Maximal-Locale zu kommen. In "de-AT" hingegen nicht, das Maximal-Locale zu "de-AT" ist "de-Latn-AT", was von "de-Latn-DE" abweicht. Die Angabe der Standardschrift für deutsch wird ebenfalls entfernt. Eine Schriftangabe wie "Hant" (traditionelles Chinesisch) bleibt hingegen erhalten.
Abfrage von verfügbaren Werten
Die Spezifikation dieser Abfragen ist noch in der Entwurfsphase (Stand: November 2023) und kein Teil der ECMA402-Spezifikation. Dennoch wurde sie sehr früh von Chromium-Browsern implementiert, mit der Folge, dass die Implementierung nun nicht dem letzten Entwurfsstand entspricht.
Der Entwurf sieht vor, dass es in jedem Locale-Objekt es für die Eigenschaften calendar, collation, hourCycle, numberingSystem und timeZone Methoden gibt, die die möglichen Werte liefern, die dieses Locale für diese Eigenschaft unterstützt.
Die Namen dieser Methoden beginnen mit get, gefolgt vom Namen der Eigenschaft und einem s. Beispielsweise liefert getCollations() ein Array mit allen Collations, die ein Locale anbietet. Die Chromium-Implementierung basiert auf einem älteren Stand, in dem noch Eigenschaften wie collations oder timeZones verwendet wurden. Weil diese Eigenschaften aber durch Getter realisiert werden und mit jedem Abruf ein neues Array erzeugen, sind sie nicht idempotent (mehrere Abrufe liefern das gleiche Ergebnis) und wurden deshalb als Methoden neu spezifiziert.
Wenn du diese Methoden verwenden möchtest, musst du deshalb zunächst prüfen, ob die Methode existiert, und wenn sie fehlt, auf die Eigenschaft zurückgreifen. Beachte auch, dass sie möglicherweise auch gar nicht unterstützt werden (Firefox).
const kalender = locale.getCalendars ? locale.getCalendars() : locale.calendars;
}}
getTextInfo()
In Chromium als textInfo-Eigenschaft implementiert.
Diese Methode liefert "ltr" oder "rtl", je nachdem, ob die Schreibrichtung für dieses Locale von links nach rechts oder von rechts nach links geht. Eine senkrechte Schreibrichtung ist mit getTextInfo() nicht erkennbar.
getWeekInfo()
In Chromium als weekInfo-Eigenschaft implementiert.
Diese Methode liefert ein Objekt mit Informationen darüber, wie eine Kalenderwoche strukturiert ist. Dieses Objekt besitzt 3 Eigenschaften:
firstDay- Eine Zahl von 1 (Montag) bis 7 (Sonntag), die angibt, welcher Wochentag als erster Tag der Woche angesehen wird
weekEnd- Ein Array mit den Wochentagsnummern, die als Wochenende angesehen werden
minimalDays- Eine Ganzzahl von 1 bis 7, die angibt, wieviele Tage die erste Woche eines Monats oder Jahres mindestens haben muss (sind es weniger, gehört die Woche zum Vormonat/Vorjahr). Für unseren gregorianischen Kalender ist das nur für die erste Woche des Jahres relevant.
