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

[cjolif]

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

https://github.com/rxaviers/cldrjs

[rxaviers]

Please, just let me know on any questions.

[JCEmmons]

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]

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]

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]

@JCEmmons, I'd be interested to see an example. A good test to exercise the idea is implementing these two use cases:

• How does it change the current development and tests of this library?
• How does it look like for an end user?

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]

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?