search

tc39 / proposal-intl-locale

`Intl.Locale` specification [draft]
https://tc39.github.io/proposal-intl-locale/
33 stars 17 forks source link

Use Intl.Locale as the first step of instantiating formatters #31

Open littledan opened 6 years ago

littledan commented 6 years ago

In the April 2018 Intl call, the group decided to attempt to base Intl formatters on creating an Intl.Locale object. This would have a few observable changes to existing functionality, for example resolvedOptions().locale would be fully canonicalized and not leave out unsupported options. Given the diversity of behavior of existing implementations, we're hoping this change will be web compatible. Patch to come to make the details more clear.

littledan commented 6 years ago

Aside from including unsupported options, resolvedOptions().locale is currently pretty strict about only including the extensions that are in the locale itself, and not things that are specified via the options bag. I wonder if this might come up in practice, e.g.,

let formatter = new Intl.DateTimeFormat("zh", { calendar: "chinese" });
if (formatter.resolvedOptions().locale !== "zh") alert("Please upgrade to a browser supporting Chinese");

This code would "break" if locale switched to being zh-u-ca-chinese, while it currently "works".

So, I'm thinking to try to preserve the current semantics of resolvedOptions().locale (modulo bugs) for formatters (including new formatters) while simultaneously organizing the specification to be based around creating inner Intl.Locale objects (to remove the multiple parallel paths for locale processing).

littledan commented 6 years ago

Oops, that above example doesn't actually apply because calendar as something in the options bag isn't supported yet (see https://github.com/tc39/ecma402/pull/175). There are other extension keys in options which do make it in, like kf, but those differ across browser in their level of support (as the spec explicitly allows) so they may not be so useful.

Aside from how minimal the string is, there's another mismatch: ResolveLocale uses locale data to determine things like the default calendar, and this shows up in resolvedOptions. Presumably we don't want to do this for Intl.Locale by default (though it could be a feature of maximize()). It's looking a bit tricky to refactor the specification code to be one thing in terms of the other while actually reducing duplication.