globalizejs / globalizejs/globalize
Re: missing 'en-US' locale in cldr-data
- Dominant language
- JavaScript
- Stars
- 4.8k
- Forks
- 585
- PR merge metrics
- No merged PRs in 30d
Description
Regarding this issue: https://github.com/rxaviers/cldr-data-npm/issues/27
I would expect to be able to do `Globalize.locale('en-Latn-US')` or `Globalize.locale('en-US')`, which refer to perfectly valid locales, and have globalize understand internally to use `en`. As it stands, if I do `Globalize.locale('en-US')` having loaded 'en' data, I get an error (`this.xxxFormatter is not a function`) when trying to use a formatter e.g. `Globalize.formatNumber(5.55)`. Similarly, I'd like to pass those locales to `globalize-compiler` without error.
Right now, In order to load a locale like `en-US` in globalize I need to know ahead of time that `en` maps to `en-Latn-US` and that `en-US` maps to `en-Latn-US`.
Note that I'm compiling my formatters ahead of time using `globalize-compiler` so maybe this isn't an issue when loading CLDR and creating formatters at runtime. Either way, it would be handy if globalize added locale normalization at compile time so users of precompiled formatters who don't know about default content could still use them when specifying `en-US` as the locale, for instance.
Contributor guide
Assessment
This issue has not been assessed yet.