-
Notifications
You must be signed in to change notification settings - Fork 21
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
Investigate if cldr.js can be used to load the CLDR #66
Comments
Please, just let me know on any questions. |
Did some preliminary looking at this, at least from the packaging perspective. Some of my thoughts: 1). it's pretty easy to take the CLDR data and decouple it from the ecma402 package. I was able to do that, and create a cldr-ecma402 package, which (for now) would a dependency of ecma402. See https://github.com/JCEmmons/cldr-ecma402 and https://github.com/JCEmmons/ecma402/tree/t66-cldr-split 2). There's nothing sacred about the way we distribute JSON from the CLDR project, and I think I could probably make a case that it really doesn't add very much (if any) additional work on our part to publish CLDR's JSON as bower installable packages instead of just as a plain zip file. I have opened a CLDR ticket at http://unicode.org/cldr/trac/ticket/7968 to discuss this issue. If I am successful at convincing the CLDR TC that this is a good thing, then CLDR would just distribute these packages as outlined in the ticket, and people could download and install them. Next steps: 1). Rafael, if you could take a look at what I've done so far as outlined in step #1 and see if I made any mistakes. If all is OK then I'll create a PR for the ecma402 package. 2). I'm assuming that we would also need to create ibm-js/cldr-ecma402 . Christophe? 3). I'll do some more work to see how Rafael's cldr.js fits into all of this. |
Please, use cldr-ecma402 cannot be used by any other i18n libs, since it's a "minimum set filtered specifically for use with ibm-js/ecma402", which is not what we want. We want any i18n library to be able to share the same module (we want peer dependency management). Another reason is: even being a minimum set, have you tried to |
cldr-ecma402 is just a starting point, not the ultimate solution ( remember I did this in just one afternoon ). The ultimate solution would be to use a package published from the CLDR project itself ( see my previous comments ). What I was thinking here was that CLDR publish 3 packages, and then we can have ecma402's dependencies set up in a way that it can use any of the "common" packages ( see http://unicode.org/cldr/trac/ticket/7968 ) for an initial proposal, or the filtered cldr-ecma402 for the minimum configuration. I understand that cldr-ecma402 may not be consumable by other i18n libs ( although it might be, we just don't know ). I'll try doing some more testing with bower install on this today. |
@JCEmmons, I'd be interested to see an example. A good test to exercise the idea is implementing these two use cases:
The first obstacle, beyond the ones I've mentioned in my opinion, is how will someone switch from the common package (the default) to the filtered cldr-ecma402 one? Does it require someone to change the
It is not very clear to me the difference between the cldr-core and cldr-modern. Are all three packages sequentially increasing in locale coverage? cldr-core < cldr-modern < cldr-full? Does anything else change? |
this would allow to share the CLDR between various globalization projects without downloading it several times.
https://github.com/rxaviers/cldrjs
The text was updated successfully, but these errors were encountered: