search

rxaviers / cldr-data-npm

Npm module for Unicode CLDR JSON data
MIT License
42 stars 28 forks source link

Docs: What's the diff between this and cldr-data-full? #2

Closed rxaviers closed 10 years ago

rxaviers commented 10 years ago

cldr-data-full has been deprecated in favor of this module (cldr-data) + the use of environment variables to set its "coverage behavior".

The default is to install the JSON from http://www.unicode.org/Public/cldr/<version>/json.zip.

npm install cldr-data

In order to install the full JSON http://www.unicode.org/Public/cldr/<version>/json-full.zip, use:

CLDR_URL_KEY="json-full" npm install cldr-data

In order to pass a different url host and path, use:

CLDR_URL="http://foo.bar/my/path/to/Public/cldr" npm install cldr-data
mlmorg commented 9 years ago

How does an author provide a library that uses the full data set without requiring the consumer to pass the environment variable when installing?

rxaviers commented 9 years ago

Hi @mlmorg, CLDR data can be thought of being sliced into two orthogonal dimensions: functionality (numbers, dates, ...) and locale coverage (tier-1 < all). Any locale coverage (e.g., tier-1) is complete on regard of its functionality (has numbers, dates, ...).

Usually (considering the use cases I've experienced), libraries define its functionality needs (number formatters need number data). But, locale coverage is a decision left to applications. Application A using your library may need en-US only. But, application B may need the whole available locale coverage. Therefore, the design approach taken here was to let applications to define its locale coverage needs (not the library). Anyway, If you could share a little more details of what you need, I could be able to help. Why does your library require the full locale coverage (instead of requiring functionality slices)?

mlmorg commented 9 years ago

That's a good point that I didn't think of. My use-case was to provide a library with the translated names of all languages. I always wanted to have the full set so it was standardized across projects; but, you're correct, in that then that is determining locale coverage instead of functionality.

rxaviers commented 9 years ago

Do you deduce that information from CLDR or do you maintain the content?

mlmorg commented 9 years ago

All the applications will use the same set of locales, which is specified and stored in a completely separate service that would necessitate the use of the full CLDR set. So, I was simply going to provide the full set by default for all applications instead of still giving them the option of deciding for themselves... but I agree with your caveat so will probably rearchitect that.

rxaviers commented 9 years ago

Cool. Just let me know if you need anything from cldr-data.