search

ibm-js / ecma402

ECMA-402 JavaScript Internationalization API "shim"
Other
34 stars 21 forks source link

Investigate if cldr.js can be used to load the CLDR #66

Open cjolif opened 9 years ago

cjolif commented 9 years ago

this would allow to share the CLDR between various globalization projects without downloading it several times.

https://github.com/rxaviers/cldrjs

rxaviers commented 9 years ago

Please, just let me know on any questions.

JCEmmons commented 9 years ago

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.

rxaviers commented 9 years ago

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.

Please, use cldr-data. :)

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 bower install it? I had made quite a few experiments before and using a bower mirror was tedious. It takes so long to install... A solution to that was a module that doesn't actually mirror any Unicode CLDR JSON data, but has information on how to fetch it. That's how cldr-data bower module was created. It's quick and still practical (more information).

JCEmmons commented 9 years ago

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.

rxaviers commented 9 years ago

@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 package.json dependencies definitions of his local copy of ibm-js/ecma402? Second, if we have a different custom-fine-tuned module specified in each i18n libraries, how will bower (or npm) resolve the CLDR peer dependency among them?

What I was thinking here was that CLDR publish 3 packages

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?

rxaviers commented 9 years ago

Anyway, cldr-data allows end user to choose between current json.zip or json-full.zip. It would support just fine the addition of a third intermediate package cldr-modern.

On #68, I've made the necessary changes to adopt cldr-data. What do you think?