rxaviers/cldrjs

Simple CLDR traverser

cldrjs's Issues

Remove left comment on path/normalize

This comment might have been left. Need to be removed.
https://github.com/rxaviers/cldr/blob/master/src/path/normalize.js#L24-L25

Empty message content throws E_MISSING_MESSAGE

Hi,
cldrjs get method throws E_MISSING_MESSAGE error when message content is an empty string.
{ "someProp": "" }.
I'm aware that an empty string is a "falsy" value, but still, it is a valid message content and it should be returned.

Wrong cached resolved object node (non-leaf node)

Cldr.get() (the dist/cldr/unresolved one) gets wrong cached resolved object node (non-leaf node), as shown below. Steps to reproduce:

Cldr = require( "cldrjs" );
Cldr.load({a: {i: 1, j: 2}})
en = new Cldr( "en" );
en.get( "a/i" ); // 1
en.get( "a" ); // { i: 1 }, expected {i: 1, j: 2}

Improve error handling

• Validate parameters (presence and type).

Retrieving rules with language+territory locales (e.g. en-US)

When loading CLDR JSON data into cldr.js, I have my number formatting rules inside a language+territory locale code, like so:

{"main":{"en-US":{"identity":{"version": ...

This is found in the main/en-US/*.json files of the full CLDR JSON data set.

Calling Cldr.main(path) causes a problem, because at https://github.com/rxaviers/cldrjs/blob/master/src/main.js#L137
I believe it's trying to lookup the path solely by language, and not the language+territory locale (in this case, en-US).

I've had to hack my code to duplicate the 'en-US' branch of the JSON into 'en' in the meantime, but this won't scale if we need to support more than one locale.

Mixed case in the attributes

The minLanguageId has a lowercased 'l' in the attributes while maxLanguageId is uppercased

Here : https://github.com/rxaviers/cldrjs/blob/master/src/core.js#L95

Drop Cldr.loadUnresolved() in favor of Cldr.load()

There should be one only Cldr.load() for simplicity.

How to get CLDR data? Needs more detailed information.

In my quest to resolve

E_MISSING_CLDR: Missing required CLDR content 'supplemental/likelySubtags'.

I've stumbled across various questions that ask the same thing. None of the answers seems exhaustive. Sorry to open yet another topic, but I think it's needed to have a basic tutorial.

I want two switch between formatting numbers in "en-US" and "nl-NL". So I need both languages configured.

I have found https://github.com/unicode-cldr/cldr-json.

1. What do I download? Is cldr-core and cldr-numbers enough?
2. Which version do I get? cldrjs NuGet package is version 0.4.8, but clrd-json has latest version 31.0.1. Does that work together?
3. Where do I put it, in my project folder structure?
4. Exactly what JavaScript do I write to bootstrap this in each language?

Clone returned .get() data?

The returned data from .get() or any of its aliased functions (eg. .main()) return the original data from the internal resolved/unresolved tree. It means that if the returned data is not a leaf, but an object; and caller function changes it, it will get permanently changed and it will affect further calls.

Should we return a clone instead? util/json/merge could be used to perform the clone and we could offer an option to bypass cloning if the caller needs full performance and knows what he's doing.

Do not concat Arrays on JSON merge

On a JSON merge, Arrays are concatenated: https://github.com/rxaviers/cldrjs/blob/master/src/util/json/merge.js#L20-L24. This should be removed. Arrays should be replaced instead.

coreLoad() E_INVALID_PAR_TYPE error

I am loading 9 CLDR JSON data files. During the call to Globalize.load, when cldrjs.load is called, the validateTypePlainObject check is failing. Each $.getJSON call returns an array containing three items. Items at index positions 0 and 2 are objects, the item at index position 1 is a string of, in this case, "success". Therefore, when the second iteration of the loop occurs, and the isPlainObject function is called within the validatePlainTypeObject call, "success" obviously causes the validation to fail because it's not an object.

What am I doing incorrectly?

Handle unicode variant subtags on likelySubtags and removeLikelySubtags

Since variant subtags are not being handled on likelySubtags, the minlanguageId of en-US-POSIX is wrongly en instead of en-POSIX leading to wrong bundle lookup. Similarly for maxLanguageId.

cldr.locale has wrong trailing _

If variant is empty here, locales are assigned with something like "en_".

Problem with babelify: Uncaught TypeError: Cannot read property 'EventEmitter' of undefined

I have the same problem as here: metafizzy/isotope#976

There seem to be two options:

• fix version of eventemitter to 4.2.0
• use ev-emitter

If you don't want to downgrade eventemitter I can try to create a pull request with ev-emitter

Edit: another option could be upgrading eventemitter to the latest version (5.1.0)

Use CLDR v25 as test fixtures

A simple example

Hi,

Firstly, thanks to the work accomplished.

I'm trying to test your API and it's difficult to understand how to load JSON data.

In fact, I've downloaded the generated JSON files (http://www.unicode.org/repos/cldr-aux/json/24/), put in a directory called "cldr" in my public directory.

There, I'm trying to implements some of your examples, like:

cldrLang = new Cldr("pt_BR")
console.log cldrLang.supplemental.minDays

But my first question is how we can tell to cldr runtime script to get the JSON files in the right directory?

I prefer to inform you that I'm using Node + Brunch + Bower.

Thanks a lot.

Automate release process

Should avoid #47

npm install invalid

Steps to reproduce:

1. npm init
2. npm install cldrjs
3. check node_modules/cldrjs/dist/ directory (no node_main.js file existing)

Therefore require fails

Latest release on jsdelivr?

Hi,
cdn.jsdelivr.com does not have the latest releases. Can someone get the recent versions posted?

https://www.jsdelivr.com/?query=cldrs

Thanks.

Regex pattern used for region tag

There are region subtags with 3 letter numeric code (such as 419) according to ibm-js/ecma402#69

Where can I find the ECCN classification for cldr 0.5.0 ?

Or can I assume that the statement "there is no ECCN classification for Globalize 1.3.0" also holds for cldr 0.5.0 ? See [https://github.com/globalizejs/globalize/issues/786] for more info.

pathNormalize is not JSON compatible

In case a path contains /{[a-zA-Z]+}/, dist/clrd.js/pathNormalize tries to globally replace /{[a-zA-Z]+}/ and replaces the first occurrence with the language parameter as intended, but also tries to replace the second and the other occurences of /{[a-zA-Z]+}/ which came from the message JSON key.

According to the JSON spec, http://www.json.org/, /{[a-zA-Z]+}/ is allowed to be included in JSON keys.

Do we really need to replace /{[a-zA-Z]+}/ globally? Removing the 'g' works for me.

Why cldr NuGet package does not include likelySubtags.json?

Without this file I get:

Uncaught Error: E_MISSING_CLDR: Missing required CLDR content `supplemental/likelySubtags
when trying to set a locale.

when trying to set a locale with Globalize library.

I thought it would be included in the package automatically.

New version has empty dist directory

Tried npm install cldrjs, but got an empty directory. package.json says it's version 0.4.6

Support throwing error on missing item data

Cldr.js should not throw Error on missing item data by default. Because, data fallback is a common thing on CLDR, eg. "If short day names are not explicitly specified, abbreviated day names are used instead" (link). But, it's very handy if it optionally could.

On globalizejs/globalize#251, missing CLDR is validated. In order to make its code simpler, it expects cldr.js to throw on missing data.

One solution is to include a throw option on all functions that retrieve data, eg.:

en.get( path ); // undefined
en.get( path, { throw: true } ); // Error is thrown

Cldrjs circular dependency errors

I have decided to use globalize with ReactNative and faced the same errors as in joshswan/react-native-globalize#3. As far as I have understood a problem in cyclic dependences. The author of react-native-globalize has solved it in his fork cldrjs.

grunt task fails because of missing intro_supplemental

Running "requirejs:bundle" (requirejs) task
{ [Error: Error: Malformed wrap config: Error: ENOENT, no such file or directory '/home/iskren/src/cldr/src/build/intro_supplemental.js'
    at normalizeWrapConfig (/home/iskren/src/cldr/node_modules/grunt-contrib-requirejs/node_modules/requirejs/bin/r.js:26647:19)
]
  originalError: [Error: Malformed wrap config: Error: ENOENT, no such file or directory '/home/iskren/src/cldr/src/build/intro_supplemental.js'] }

Also, IMHO intro_unresolved is wrong, because the variables it depends on are not the one created in the intro (only jsonMerge matches).

E_INVALID_PAR_TYPE is triggered during the page load (cldr, globalize)

Original post on StackOverflow: http://stackoverflow.com/questions/40605416/e-invalid-par-type-is-triggered-during-the-page-load-cldr-globalize

---

We are trying to use cldr/globalize, unfortunately, an error is triggered during the load of the page.

Debugging the code does not help at all, I can't figure out which input field generates the issue

Do you need further info? Do you need more code? Just let me know

---

JavaScript, load cldr data, set locale to 'en'

$(document).ready(function () {
  // http://stackoverflow.com/questions/35863853/using-jquery-globalize-with-mvc-5
  // download json files on https://github.com/unicode-cldr?page=2
  // how to setup globalize, cldr and json data: http://johnnyreilly.github.io/globalize-so-what-cha-want

  var locale = 'en'; // TODO: manage the localization based on user preferences (browser)

  // http://stackoverflow.com/questions/32586551/what-is-the-best-way-to-handle-validation-with-different-culture
  $.when(
      $.getJSON("/Scripts/plugins/cldr-core-30.0.2/supplemental/likelySubtags.json"),
      $.getJSON("/Scripts/plugins/cldr-numbers-full-30.0.2/main/" + locale + "/numbers.json"),
      $.getJSON("/Scripts/plugins/cldr-core-30.0.2/supplemental/numberingSystems.json"),
      $.getJSON("/Scripts/plugins/cldr-core-30.0.2/supplemental/plurals.json"),
      $.getJSON("/Scripts/plugins/cldr-core-30.0.2/supplemental/ordinals.json"),
      $.getJSON("/Scripts/plugins/cldr-numbers-full-30.0.2/main/" + locale + "/currencies.json"),
      $.getJSON("/Scripts/plugins/cldr-core-30.0.2/supplemental/currencyData.json"),
      $.getJSON("/Scripts/plugins/cldr-dates-full-30.0.2/main/" + locale + "/ca-gregorian.json"),
      $.getJSON("/Scripts/plugins/cldr-dates-full-30.0.2/main/" + locale + "/timeZoneNames.json"),
      $.getJSON("/Scripts/plugins/cldr-core-30.0.2/supplemental/timeData.json"),
      $.getJSON("/Scripts/plugins/cldr-core-30.0.2/supplemental/weekData.json"),
      $.getJSON("/Scripts/plugins/cldr-dates-full-30.0.2/main/" + locale + "/dateFields.json"),
      $.getJSON("/Scripts/plugins/cldr-units-full-30.0.2/main/" + locale + "/units.json"),
      console.log("JSONs loaded")
      ).then(function () {
        console.log("start slicing");
        return [].slice.apply(arguments, [0]).map(function (result) {
          console.log("slicing done");
          return (typeof result === 'undefined' ? null : result[0]);
        });
      }).then(Globalize.load).then(function () {
        Globalize.locale(locale);
        console.log("Locale set to " + locale);
      }).then(console.log("LOADED EVERYTHING"));


});

HTML , load the javascripts

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>StratEx | Project management</title>
  <meta http-equiv="X-UA-Compatible" content="IE=EDGE">
  <link href="http://fonts.googleapis.com/css?family=Open+Sans:400,300,600,700" rel="stylesheet" type="text/css">
  <link href="/Scripts/plugins/jquery-ui-1.11.4/jquery-ui.css" rel="stylesheet">

  <link href="/Content/font-awesome/css/font-awesome.css" rel="stylesheet">

  <link href="/Content/bootstrap-3.3.7/css/bootstrap.css" rel="stylesheet">

  <link href="/Content/animate.css" rel="stylesheet">
  <link href="/Content/style.css" rel="stylesheet">

  <link href="/Content/themes/redmond/jquery-ui-1.10.3.custom.min.css" rel="stylesheet">

  <script type="application/javascript" async="" defer="" src="https://by2.uservoice.com/t2/ID/web/ID/track.js?_=TIMESTAMP&amp;s=1&amp;c=__uvSessionData0&amp;d=HASH"></script>
  <script type="text/javascript" async="" src="//widget.uservoice.com/CODE.js"></script><script async="" src="//www.google-analytics.com/analytics.js"></script>
  <script
    src="/Scripts/jquery-2.2.1.js"></script>

    <script src="/Scripts/plugins/cldrjs-0.4.7/dist/cldr.js"></script>
    <script src="/Scripts/plugins/cldrjs-0.4.7/dist/cldr/event.js"></script>
    <script src="/Scripts/plugins/cldrjs-0.4.7/dist/cldr/supplemental.js"></script>
    <script src="/Scripts/plugins/globalize-1.1.2/dist/globalize.js"></script>
    <script src="/Scripts/plugins/globalize-1.1.2/dist/globalize/number.js"></script>
    <script src="/Scripts/plugins/globalize-1.1.2/dist/globalize/plural.js"></script>
    <script src="/Scripts/plugins/globalize-1.1.2/dist/globalize/message.js"></script>
    <script src="/Scripts/plugins/globalize-1.1.2/dist/globalize/currency.js"></script>
    <script src="/Scripts/plugins/globalize-1.1.2/dist/globalize/date.js"></script>
    <script src="/Scripts/plugins/globalize-1.1.2/dist/globalize/relative-time.js"></script>
    <script src="/Scripts/plugins/globalize-1.1.2/dist/globalize/unit.js"></script>
    <script src="/Scripts/plugins/jquery-validation-1.15.1/dist/jquery.validate.js"></script>
    <script src="/Scripts/plugins/jquery-validation-unobtrusive-3.2.6/jquery.validate.unobtrusive.js"></script>
    <script src="/Scripts/plugins/jquery-ajax-unobtrusive-3.2.4/jquery.unobtrusive-ajax.js"></script>
    <script src="/Scripts/plugins/jquery-validation-globalize-1.0.0/jquery.validate.globalize.js"></script>

    <script src="/Scripts/plugins/jquery-ui-1.11.4/jquery-ui.js"></script>

    <script src="/Content/bootstrap-3.3.7/js/bootstrap.js"></script>

</head>

Retrieve available locale name

In the cldr-data packages is availableLocales.json. This tells users what locales are available within the data. I would like to use this to determine which locale files to load on the fly, however I don't see a way to seed the Cldr available locales or use an array of locale names to get the effective locale name based on the user's locale. Essentially, I'd like to do something like this:

Promise.all([
    request.get('path/to/cldr-data/availableLocales.json'),
    request.get('path/to/cldr-data/supplemental/likelySubtags.json'),
    request.get('path/to/cldr-data/supplemental/parentLocales.json') // not sure I need this, but including it anyway
]).then(function ([ localesResponse, subtagsResponse, parentResponse ]) {
    Cldr.load(subtagsResponse.data, parentResponse.data);
    let locale = Cldr.determineLocale(navigator.langugage, response.data.availableLocales);

    return Promise.all([
        request.get(`path/to/cldr-data/main/${locale}/numbers.json`),
        request.get(`path/to/cldr-data/main/${locale}/currency.json`)
    ]).then(function ([ numbersResponse, currencyResponse ]) {
        Cldr.load(numbersResponse.data, currencyResponse.data);
        return new Cldr(locale);
    });
}).then(function (cldr) {
    // use cldr.get()
});

Using this technique, I could use this to see the globalize data as well and create a promise-based API for loading only the locale information needed at any given time.

IE8 Support

Yes I know.. I know.

It is listed as one of the supported browsers however. Currently we're hitting errors as it does not support array.indexOf(). This was apparently added in IE9. This is being hit here:

cldrjs/src/core/set_available_bundles.js

Line 22 in d862808

availableBundleMapQueue.indexOf( bundle ) === -1 ) {

Add `publishConfig` to eliminate the chance for private/internal publish

main.js not properly initializes likelySubtags

Initializing new Cldr( "pt_BR" ) on main.runtime.js (Runtime version) works just fine. It produces attributes.maxLanguageId = "pt_Latn_BR". Although, using main.js doesn't. It produces attributes.maxLanguageId = "pt_BR".

Improve get performance via Function

Instead of iterating over the path tree (e.g a/b/c) when getting an item, is it faster to generate a Function() of the form below and to use its result?

try {
  return Cldr._resolved[a][b][c];
} catch() {}

Parameterize locale separator "-" | "_"

Let user choose a locale separator ("-" | "_") for input data to be loaded with Cldr.load().

Note: locale separator should be consistent across CLDR data set:
http://unicode.org/cldr/trac/ticket/6786 -> http://unicode.org/cldr/trac/ticket/6780

The ZIP file of JSON data from unicode.org isn't available any more

http://www.unicode.org/Public/cldr/latest/json.zip
http://www.unicode.org/Public/cldr/latest/json-full.zip

Both invalid now.

Wrong attributes for language az_cyrl

Hello,

when I load cldr with the locale "az_cyrl" I receive the following attributes:

{ 
    bundle: 'en',
     minLanguageId: 'en',
     maxLanguageId: 'en-Latn-US',
     language: 'en',
     script: 'Latn',
     territory: 'US',
     region: 'US',
     variant: undefined
}

From what I could find, the problem is in the function coreSubtags which doesn't find the subtags for this locale, but I don't know why. The regexp is probably wrong.

edit: it fails for other languages as well, such as ar_ye

Please update simple example

Hi, it looks the example of this #6 it very old, it doesn't work now. The module name are changed. Could you please update the example which can work?
Thanks!

CLDR data as versioned “peer” dependency

Goal

1. Libraries should be able to define what CLDR versions (the data, not cldrjs itself) they are compatible with.
2. Tools should assist on (a) fetching the data and (b) dependency management.

Winner approaches

npm + custom-downloader

Ideal for backend applications.

An npm module that uses a custom downloader. See npm's cldr-data npm module. The implementation of these modules have been inspired by phantomjs.

bower + post-install hook (or grunt task)

Ideal for frontend applications.

A bower module that contains CLDR data zip urls only (really light). It works as follows. A project foo depends on a variety of libraries that have different CLDR data requisites, which define that by using cldr-data bower module in their respective bower.json. When bower install is executed on project foo, it will resolve and flat the cldr-data versions of each dependencies and it will come up with a cldr-data that accommodates them all. A bower postinstall hook (e.g., cldr-data-downloader) or a grunt task (grunt-cldr-data-downloader) can be used in the sequence to download and populate the bower_components/cldr-data skeleton.

See bower's cldr-data.

Unsuccessful approaches

npm mirror

❗ npm fails publishing the whole mirror. See comment below.

An npm module (e.g., cldr-data) contains all the CLDR JSON data. It follows the same version numbers of Unicode CLDR, for example cldr-data v26 has the same data served by http://www.unicode.org/Public/cldr/26/json-full.zip.

Usage, a library defines the cldr-data dependency in its package.json:

"dependencies": {
  "cldr-data": "26"
}

Pros

• Simplest solution using existing npm.

Cons

• Big download size. CLDR v26 zipped is 51M big. If the module offers JS (that wraps JSON using cldrjs) along with the JSONs themselves, size is even increased.
• No flat dependency tree.

npm + cherry-pick fetch

❗ fetching everything remotely takes way too long, see comment below.

An npm module (e.g., cldr-data) that follows the same version numbers of Unicode CLDR, but the module itself has no CLDR data. It has an install.js script that will be executed by npm during installation (the scripts/install directive), which will fetch the needed files during installation. A kinda of variant of phantomjs, see https://gist.github.com/rxaviers/87e089c35d46fd3a1492.

Usage, a library defines the cldr-data dependency in its package.json, plus it needs to define which CLDR data set to fetch.

"dependencies": {
  "cldr-data": "26"
},
"_cldr": {
  "locales": [ "en", "zh", "es", "ar" ]
  "jsons": [
    "main/ca-gregorian",
    "supplemental/likelySubtags"
  ]
}

Pros

• Saner CLDR data download size;

Cons

• The need to whitelist CLDR sets. Obviously, we could also allow blacklists with "!", e.g. "!supplemental".
• No flat dependency tree.

Question

• Is "_cldr" property on package.json the best place to keep that information?

bower mirror

❗ installing a whole mirror works. But, it takes awhile. Tedious. See comment below.

A cldr-data repository that contains all the CLDR JSON data. It follows the same version numbers of Unicode CLDR, for example cldr-data v26 has the same data served by http://www.unicode.org/Public/cldr/26/json-full.zip.

Usage, a library defines the cldr-data dependency in its bower.json:

"dependencies": {
  "cldr-data": "26"
}

Pros

• Simplest solution using existing bower.

Cons

• Big download size. CLDR v26 zipped is 51M big. If the module offers JS (that wraps JSON using cldrjs) along with the JSONs themselves, size is even increased.

Localization of Messages Module

@rxaviers,

I am hoping that I am just missing something simple but... How do you provide strings specific to a locale if the likely subtags are removed? For example, Is it possible to have "buenos días" show up if I try to create messages as follows?:

        var messages = {
            "root":
            {
                "actions": "Actions",
                "activityNotes": "Activity Notes",
                "add": "Add",
                "addAGroup": "Add a group",
                greeting: "Hello"
            },

            "es": {
                "actions": "Acciones",
                "activityNotes": "Notas sobre la actividad",
                "add": "Añadir",
                "addAGroup": "Añadir un grupo",
                greeting: "hola"
            },

            "es-419": {
                greeting: "buenos días"
            }
        };

Michael Fischer

Unresolved: Instances should always be assigned a bundle for convenience

A bundle is assigned null in case there's no main data loaded for such locale (ref #17, PR #26), which is perfectly precise. Although, for unresolved data, it's safe to consider that a bundle always exists at least with empty data.

Trailing underscores in languageId

Hi,

When attempting to use a locale such as Lakota ("lkt"), we get a language of ("und"). We then call to likelySubtags which finds a match based on CLDR locale matching data...

    var match, matchFound,
        language = subtags[ 0 ],  // language = "und"
        script = subtags[ 1 ], // script is undefined
        territory = subtags[ 2 ]; // territory is undefined
        .
        .
        .
    if ( typeof cldr.get( "supplemental/likelySubtags" ) === "undefined" ) {
        return;
    }
    // match occured!
    // matchFound = true
    // match = "en_Latn_US"

That is a correct break down. After that, we attempt to split this match into its language script and territory...

    if ( matchFound ) {
        // [3.2 .. 3.4]
        match = match.split( "_" );
        return [
            language !== "und" ? language : match[ 0 ],
            script !== "Zzzz" ? script : match[ 1 ],
            territory !== "ZZ" ? territory : match[ 2 ]
        ];
    }

Since the language was originally "und", we do set it to "en", which is great. The script and territory were originally undefined; so, they stay undefined. They are, however, returned as additional items in the array. Therefore, maxLanguageId contains these undefined entries...

    maxLanguageId = likelySubtags( this, [ language, script, territory ], { force: true } ) || unicodeLanguageId.split( "_" );

When we attempt to get the succinct languageId, we pass maxLanguageId through to removeLikelySubtags. Since there are no subtags on the maxLanguageId, we don't get a match and we just get the maxLanguageId array returned back to us. At that point, we attempt to make the languageId attribute...

languageId = removeLikelySubtags( this, maxLanguageId ).join( "_" );

We are doing a join here on an array of three items, one defined and two undefined. As a result, we get a languageId of "en__". This seems erroneous. Can you please confirm that I should be expecting a languageId of just "en" (without underscores), and that this is indeed an issue? Please let me know if you need any more information, and thank you for your time and effort on this!

Locale attribute "minlanguageId" property is populated with wrong case (should be "minLanguageId")

You populate the locale attribute "minLanguageId" with an incorrect case for the "L" of Language, i.e. "minlanguageId". See line 617 of cldr.js version 0.4.4 (current release version in NuGet):

    // Set attributes
    this.attributes = attributes = {
        bundle: bundleLookup( Cldr, this, minLanguageId ),

        // Unicode Language Id
        minlanguageId: minLanguageId,    <-- ERROR!
        maxLanguageId: maxLanguageId.join( sep ),

Please update your package with the latest CLDR code, which does not have this issue (no problem when using the NPM packages).

I wanted to use your NuGet version together with my own minified JSON CLDR-Data modules on my older solutions, which works if I can read the "minLanguageId" (effectively the CLDR bundle name) from the specific culture I get in .NET. Can imagine this could cause other failures as it's a pretty key piece of information which effectively becomes "undefined" when the case is wrong (JavaScript addressing of JSON objects being case sensitive of course).

languageId Succinctness

Hello, again!

It appears that, after 0.3.3, languageId is more verbose. For example, instantiating with a locale of "fr-FR" yields a languageId of "fr-FR" as opposed to the expected succinct "fr". Is the use of languageId something that I am misunderstanding, or should it be as documented in the table still?

Thank you!

Don't include minified modules on dist/

For more info: http://bugs.jqueryui.com/ticket/10674

Bug? No bundle for certain otherNumberingSystem locales

Summary

I'm seeing a null bundle when specifying an otherNumberingSystem in certain locales. For example, 'zh-Hans-HK-u-nu-native' has a null bundle, with 'main/zh-Hans-HK/numbers.json' explicitly loaded. And the numbers.json file does seem to have a proper otherNumberingSystems entry, for native, traditional and finance.

Using cldr-data v28.0.3 and cldr-data-coverage: full, null bundles occur for otherNumberingSystems of: sr-Cyrl-ME, sr-Latn-BA, sr-Latn-XK, zh-Hans-HK and zh-Hans-MO. Other locales work fine.

I originally ran into this problem when using Globalize('zh-Hans-HK-u-nu-native').numberFormatter(). This threw an E_MISSING_BUNDLE error, which pointed back to cldrjs.

Thanks!

Replicating the bug

The test program below outputs (new Cldr(locale)).attributes.bundle for a locale, and the locale with a particular otherNumberingSystem.

For the working 'zh-Hant-HK' case, we get:

Locale: zh-Hant-HK
Bundle: zh-Hant-HK

Locale: zh-Hant-HK-u-nu-native
Bundle: zh-Hant-HK

Locale: zh-Hant-HK-u-nu-finance
Bundle: zh-Hant-HK

Locale: zh-Hant-HK-u-nu-traditio
Bundle: zh-Hant-HK

for the broken 'zh-Hans-HK' case, we get:

Locale: zh-Hans-HK
Bundle: zh-Hans-HK

Locale: zh-Hans-HK-u-nu-native
Bundle: null

Locale: zh-Hans-HK-u-nu-finance
Bundle: null

Locale: zh-Hans-HK-u-nu-traditio
Bundle: null

test.js program:

var Cldr, cldrData, locale, localeCldr, shortLocale, i, len, locales;

cldrData = function(cldrFilePath) {
    return require("cldr-data/" + cldrFilePath);
};

Cldr = require('cldrjs');
Cldr.load(cldrData('supplemental/likelySubtags.json'));
Cldr.load(cldrData('supplemental/numberingSystems.json'));

//Broken for otherNumberingSystems
shortLocale = 'zh-Hans-HK';
//Works for otherNumberingSystems
// shortLocale = 'zh-Hant-HK';

Cldr.load(cldrData("main/" + shortLocale + "/numbers.json"));

locales = [shortLocale, shortLocale + "-u-nu-native", shortLocale + "-u-nu-finance", shortLocale + "-u-nu-traditio"];
for (i = 0, len = locales.length; i < len; i++) {
    locale = locales[i];
    localeCldr = new Cldr(locale);
    console.log("\nLocale: " + locale);
    console.log("Bundle: " + localeCldr.attributes.bundle);
}

package.json

{
  ...
  "dependencies": {
    "cldr-data": "28.0.3",
    "cldrjs": "0.4.4"
  }
  ...
}

Cldr.load( data, data, ... )

Discussing with eemeli on eemeli/make-plural#3, he suggested an API I enjoyed: .load() to allow multiple data parameters...

export name

It looks like the export name under AMD is cldr, under CommonJS is cldr.js and the global variable is named Cldr. Can it be a bit more consistent?

Getting inexistent raw data wrongly sets resolved cache

Steps to reproduce:

Cldr = require( "cldrjs" );
en = new Cldr( "en" );
en.get( "a/b" ); // -> undefined
Cldr.load({a: "something"});
en.get("a"); // -> {b: undefined}, expected: "something"

npm install invalid

Steps to reproduce:

1. npm init
2. npm install cldrjs
3. check node_modules/cldrjs/dist/ directory (no node_main.js file existing)

Therefore require fails

Remove cldr-data as peer dependency

Ref globalizejs/globalize#638