-
Notifications
You must be signed in to change notification settings - Fork 604
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re: missing 'en-US' locale in cldr-data #758
Comments
That should work, please could you share your complier code too? |
Looks like this:
and the compiled output looks like this:
If I import this code and then do |
I also recently had troubles loading the Problem was, the directory in the |
@ray007 |
I have the problem only with |
@casey-speer, when you're using regular globalize, any given locale is processed and normalized (via cldrjs): deducing bundle, minLanguageId, etc. On the compiled version, that result is kept in the compiled data (processed during compilation) and therefore if you import the compiled code, that will only work for the locale string you used during compilation. It isn't able to normalize different locale strings. |
@ray007, you shouldn't need to create any symlinks. Please, what globalize and cldrjs version are you using? |
As I read this issue, I don't see anything that needs to be fixed or improved. If you believe so, please propose a solution :). Thanks |
EDIT: please explain the problem briefly and optionally/ideally propose a solution. |
@rxaviers I'm using the |
@ray007 what about |
@rxaviers currently installed modules:
|
@ray007 I could not reproduce your issue...
var Globalize = require( "globalize" );
Globalize.load( require( "cldr-data" ).entireSupplemental() );
Globalize.load( require( "cldr-data" ).entireMainFor( "en" ) );
Globalize('en-US').formatNumber(Math.PI);
// > '3.142'
Globalize('en').formatNumber(Math.PI);
// > '3.142' PS: Note I loaded the |
@rxaviers I see what you're saying. But this is what happens if I pass 'en-US' as the locale to the compiler:
Would it be possible to add a compiler step to map the given locale, e.g. |
It may have to do with the fact I don't use |
@casey-speer Ok, I see the issue you're saying too, which is related to this globalizejs/globalize-compiler#30. This needs fix |
@ray007 Ok, got it. Basically, it's not @ray007 and @casey-speer, please read https://github.com/rxaviers/cldrjs/blob/master/doc/bundle_lookup_matcher.md We need to come up with a way to make this process easier, probably by improving the documentation and API. This is somehow related to rxaviers/cldrjs#30. Any thoughts? |
I'm dealing with this exact issue myself and have resorted to using a lookup table. Was frustrated in that I could not understand why there was not a pt-BR /cldr-data/main/ folder until I read this:
Makes logical sense but is not machine friendly. +1 for a more flexible interface. |
Now that I think about it, I am finding the setting of default locales for a language based on the number of speakers to be especially troubling. If locale YY is assigned as default for lang xx, then due to conflict, environmental or economic collapse, or choice there is a mass migration of xx speakers to locale ZZ, then would the default locale assignment change? I would suggest always defining CLDR data under locale specific folders (xx_YY) and then aliasing them internally. Locale aliasing could be extended to allow aliasing by number of speakers, locale of origin, or utilisation context such as colloquial or corporate. |
Regarding this issue: rxaviers/cldr-data-npm#27
I would expect to be able to do
Globalize.locale('en-Latn-US')
orGlobalize.locale('en-US')
, which refer to perfectly valid locales, and have globalize understand internally to useen
. As it stands, if I doGlobalize.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 toglobalize-compiler
without error.Right now, In order to load a locale like
en-US
in globalize I need to know ahead of time thaten
maps toen-Latn-US
and thaten-US
maps toen-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 specifyingen-US
as the locale, for instance.The text was updated successfully, but these errors were encountered: