globalizejs / globalizejs/globalize

Re: missing 'en-US' locale in cldr-data

Open
#758 19 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.