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

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.

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Comments: 19 (9 by maintainers)

Most upvoted comments

@casey-speer Ok, I see the issue you’re saying too, which is related to this https://github.com/globalizejs/globalize-compiler/issues/30. This needs fix