The JavaScript Intl library (ECMA 402) has used strings to identify locales since the beginning. This works well for many simple cases, and is lightweight and user-friendly. ICU uses a Locale class instead. Defining a Locale class allows the following:
- Parsing and manipulating the language, region and script of a locale
- Reading or writing the Unicode extension tags in a locale
- A serializable, standard format to store user locale preferences for use in Intl APIs rather than a combination of language and options bag.
- In follow-on proposals, a Locale class can be used for an interface to get at various kinds of locale data, including likely subtags, first day of the week, various display names, etc.
Intl.Locale has a toString method which represents the complete contents of the locale. This method allows Locale instances to be provided as an argument to existing Intl constructors, serialized in JSON, or any other context where an exact string representation is useful.
Intl.Locale is proposed to be the class that HTML uses to expose the current locale to the Web. Currently, HTML supports only navigator.languages, but with navigator.locales, an Array of Intl.Locale instances, browsers may expose user preferences for calendar, numbering system, and more to Progressive Web applications.
The following example shows how to use Intl.Locale
let loc = new Intl.Locale("pl-u-hc-h12", {
calendar: 'gregory'
});
console.log(loc.language); // "pl"
console.log(loc.hourCycle); // "h12"
console.log(loc.calendar); // "gregory"
console.log(loc.toString()); // "pl-u-ca-gregory-hc-h12"Stage 4
Implementation Progress
- Shipping in Chrome 74 / V8 v7.4
- Shipping behind the flag in Firefox 70
- Polyfill: https://github.com/zbraniecki/Intl.js/tree/intllocale
Backpointers
- Zibi Braniecki (@zbraniecki)
- Daniel Ehrenberg (@littledan)
TBD
You can view the spec text or rendered as HTML.
npm install
npm run build
open index.html