ibm-js / ecma402 Goto Github PK

in particular how to import the module and reference any official ECMA402 usage documentation.

Maybe wait for #20 to be implemented before documenting as this will impact how you can force inclusion or not of the shim at build time.

From looking at the code and tracing in the debugger, IntlShim.js always loads Intl.js, whereas the goal is to only load it conditionally.

IntlShim.js has this code:

define(["./features!intl-api?:./Intl"]

as though features were a plugin. But it is not.

Also, there is no test file that just loads IntlShim.js, which makes it hard to see whether or not Intl.js is getting loaded unnecessarily or not.

I did a git clone and then bower install and saw the following messages. Not sure if they are fatal errors or not, but "invalid-meta" has a bad sound to it.

bower not-cached    git://github.com/jrburke/requirejs-bower.git#>=2.1.14
bower resolve       git://github.com/jrburke/requirejs-bower.git#>=2.1.14
bower not-cached    git://github.com/requirejs/text.git#>=2.0.12
bower resolve       git://github.com/requirejs/text.git#>=2.0.12
bower not-cached    git://github.com/ibm-js/requirejs-dplugins.git#>=0.2.2-dev
bower resolve       git://github.com/ibm-js/requirejs-dplugins.git#>=0.2.2-dev
bower download      https://github.com/jrburke/requirejs-bower/archive/2.1.14.tar.gz
bower download      https://github.com/ibm-js/requirejs-dplugins/archive/0.2.2-dev.tar.gz
bower download      https://github.com/requirejs/text/archive/2.0.12.tar.gz
bower extract       requirejs-text#>=2.0.12 archive.tar.gz
bower extract       requirejs#>=2.1.14 archive.tar.gz
bower invalid-meta  requirejs-text is missing "main" entry in bower.json
bower invalid-meta  requirejs-text is missing "ignore" entry in bower.json
bower extract       requirejs-dplugins#>=0.2.2-dev archive.tar.gz
bower resolved      git://github.com/requirejs/text.git#2.0.12
bower invalid-meta  requirejs is missing "ignore" entry in bower.json
bower resolved      git://github.com/jrburke/requirejs-bower.git#2.1.14
bower invalid-meta  requirejs-dplugins is missing "main" entry in bower.json
bower resolved      git://github.com/ibm-js/requirejs-dplugins.git#0.2.2-dev
bower install       requirejs-text#2.0.12
bower install       requirejs#2.1.14
bower install       requirejs-dplugins#0.2.2-dev

requirejs-text#2.0.12 ../requirejs-text

requirejs#2.1.14 ../requirejs

requirejs-dplugins#0.2.2-dev ../requirejs-dplugins

The goal of this the locale preload feature is that the application code below (specifically the ... section) doesn't run until the specified locales have been loaded:

require.config({
      baseUrl: '/ecma402',
      config: { 'locales' : /^(ar-(TN|SA)|en|es|hi|ja|de)$/ }
});
require([ "Intl", "IntlShim"], function(Intl,IntlShim) {
          ...

Unfortunately, it doesn't work correctly. In locales.js you just fire off a require() call and don't wait for it to complete. As I've said before, to get this to work correctly you'll need to write a plugin, specifically locales.js needs to be a plugin.

bower.json and package.json still have version: 0.2.1-dev while the latest release is 0.2.2-dev.

To solve this situation you can either:

• delete the 0.2.2-dev tag, update bower.json and package.json to 0.2.2-dev, then re-tag 0.2.2-dev
• update bower.json and package.json to 0.2.3-dev and tag a new 0.2.3-dev release.

EDIT: I will wait until this is solve to publish ecma402-build as I don't want to propagate the issue to another repo.

Currently the dependency on require in locales.js and preload.js are not correct.
Indeed, require is a special keyword as module and export.

The correct way to use require inside a module is:

define(["require"], function (require) {
    require([....]);
});

Currently the script tags are direct children of the html tag instead of being under body or head.

Also, I think the variables could have names more significant than the current x, x1, y or y1.

And to be consistent with the other projects of ibm-js the samples should be in a /samples directory.

The current ECMA402 test suite has a number of tests that alter Object.prototype and then try to do something. This type of test, such as test 12.2.2.b, are hanging on some platforms, while giving us very little value other than a red herring to chase. Dissussed with @cjolif and we agreed to comment out this test for now.

ecma402 includes CLDR data. The license should accompany it, makes clearing the component easier.
http://unicode.org/cldr/trac/browser/tags/release-25/unicode-license.txt

See also 9267dc0#commitcomment-6744219

So that the name in the require.config is more obvious to people about what it is supposed to used for.

The root directory contains a lot of implementation classes not meant to be used by the application developer. Those classes should probably be moved to a "utils" (or any better name) directory so that root contains what is directly usable (Intl, IntlShim?). This would avoid people looking at the source and wondering what to use in there.

Since the package requirejs-text is not bundled with ibm-js/ecma402, its path cannot be hardcoded on the dependency list (as in ../requirejs-text/...).

Instead the dependency should be specified with just the package name (requirejs-text/...) and the user will specify where to find this package using require.config().

See http://requirejs.org/docs/api.html#packages for more information on packages.

It would be good if README had a section explaining how to run the tests.

I've assumed it's:

npm install
grunt test

But, a few hitters I got were:

• test:local fails with ECONNREFUSED.
• test:remote fails asking for Sauce username or access key.

A has! plugin should be used. Although as far as I know, there is no has plugin for requirejs.
An issue has been created to address this on ibm-js/sdk (ibm-js/sdk#8) but I open a ticket here so we don't forget to change that when we get a standalone has! plugin.

Hey, maintainer(s) of ibm-dojo/g11n4js!

We at VersionEye are working hard to keep up the quality of the bower's registry.

We just finished our initial analysis of the quality of the Bower.io registry:

7530 - registered packages, 224 of them doesnt exists anymore;

We analysed 7306 existing packages and 1070 of them don't have bower.json on the master branch ( that's where a Bower client pulls a data ).

Sadly, your library ibm-dojo/g11n4js is one of them.

Can you spare 15 minutes to help us to make Bower better?

Just add a new file bower.json and change attributes.

{
  "name": "ibm-dojo/g11n4js",
  "version": "1.0.0",
  "main": "path/to/main.css",
  "description": "please add it",
  "license": "Eclipse",
  "ignore": [
    ".jshintrc",
    "**/*.txt"
  ],
  "dependencies": {
    "<dependency_name>": "<semantic_version>",
    "<dependency_name>": "<Local_folder>",
    "<dependency_name>": "<package>"
  },
  "devDependencies": {
    "<test-framework-name>": "<version>"
  }
}

Read more about bower.json on the official spefication and nodejs semver library has great examples of proper versioning.

NB! Please validate your bower.json with jsonlint before commiting your updates.

Thank you!

Timo,
twitter: @versioneye
email: [email protected]
VersionEye - no more legacy software!

I will go ahead and add necessary CLDR JSON data for islamic, persian, hebrew, and umalqura calendars.

Let's see if we can use the navigator.languages list from Mozilla and Chrome. The navigator.languages list is the same as the list of languages in the HTTP Accept-Language header.

I didn't investigate this much, but it looks like the library can't load under node (define is not defined). Is it possible?

As you can see in the code here (https://github.com/jrburke/requirejs/blob/master/require.js#L588), the default for a module config is an object.

Also I think it will be more future proof to use an object instead of the regexp directly as it will allow to add more options without breaking the backward compatibility.

I would suggest using something like this:

requirejs.config({
    config: {
        "ecma402/locales": {
            locales: /^(ar-(TN|SA)|en|es|hi|ja|de)$/
        }
    }
})

Calendars.js loads the modules for every single calendar type (japan, hebrew, islamic, arabic, roc, etc.). This is bad because it downloads lots of unnecessary code to the browser, slowing down page load/render time.

Can you change the API so it only loads the calendar it needs? Or is this something you are stuck with to match the spec's API?
Just in AhmedMustafa@d0d69a3 I see 10 pages of unneeded code being downloaded.

PS: The switch() statement in calendars.js is also a red flag; in OO programming that's typically done by having various subclasses (one for each case in the switch statement), and calling the method directly on the subclass.

Could you enhance load.js to just load the appropriate Calendar module(s)?

Right now, it is hard coded as a big "if" statement in load.js. The right set of calendar data to load can be determined directly from CLDR's calendar preference data.

deliteful/ProgressBar widget fails to load on IE9 and android stock browser when trying to load ecma/IntlShim

IE9 error:

See PR #74

Test requires installing sibling projects (i.e., it leaks files outside of its root) with specific names or it fails (e.g., if you name your local ecma402 directory my-ecma402, tests will fail).

The suggestion is to use AMD paths mappings, which is more a flexible approach (and less error prone).

Currently TravisCI is just checking JSHINT, it should run the tests.

The README.md doc should have a couple of changes made:

1). The link to MDN should point to the English version, not the French version.
2). It should also mention that if you want to force the IBM implementation, you can just require ecma402/Intl instead of ecma402/IntlShim, instead of having to set

config: {
"requirejs-dplugins/has": {
"intl-api": false
}

Need to fix style errors found by jshint. Not sure why my Eclipse jshint integration isn't working properly.

As mentioned in ibm-js/deliteful@258b3dd#commitcomment-6347592, new Intl.NumberFormat("") fails to initialize. It should probably do the same thing as new Intl.NumberFormat().

After the latest check in of IntlShim.js I see multiple issues.

First, this line needs to execute the function, not just define the function. As you have it now __globalObject points to a function:

var __globalObject = (function(){return this;});

Thusly, this if condition is always true:

if (__globalObject.Intl === undefined) {
    dependencies.push("./Intl");
}

Finally, most importantly, the way to load modules conditionally is with the has! plugin. See requirejs doc for details. This method is non-standard and will break builds and cause other bad things to happen:

define(dependencies, ...

The git tag is 0.0.1-dev when the bower.json specify 0.1.0-dev. Bower is complaining about that when installing ecma402.

Full Hebrew calendar support requires algorithmic formatting of numbers (especially the year) into Hebrew instead of using regular digits. Will probably need to leverage RBNF data from CLDR for a generalized solution, or else write a formatter specifically for the Hebrew calendar.

The CLDR project has just released version 26, which is a major new release. Need to update the JSON data in the ECMA-402 package to the newly released CLDR 26.

In CanonicalizeLanguageTag:

[https://github.com/ibm-js/ecma402/blob/master/impl/common.js#L183]

var regionTag = /(?:-)([a-z]{2})(?=(-|$))/g;

This regex pattern would not be sufficient to parse a region subtag with 3 letter numeric code (such as 419).

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

https://github.com/rxaviers/cldrjs

Need to improve general code coverage on unit tests. Current stats show our total unit test coverage at about 78%.

Need to add some unit tests for the Islamic calendar support.

config instanceof Object (l. 53 of locales.js) is not a test specific enough to tell objects and arrays apart.

So all the locales are built no matter what the ecma402/locales config says.

At some point, it would be a good idea to clean up all jshint errors in the unit tests.

the calls to require() are missing their closing ); (3 instances)

Trying to access navigator without checking first if it's defined will fail on node.js.
This is (at least) done in ecma402/common.js l.165,167,169,171.

Intl.sh and IntlShim.js are calling require.config(). As mentioned multiple times before, this is not allowed. Only the application can call that.

Here are two examples of date format for which the shim does not returns the same string than a native implementation:

{weekday: 'long'}

=> The native implementation returns "Monday" (if the date is a monday), while the shim returns "14 Mon" (if the date is a monday 14th)

{year: 'numeric', month: 'numeric', day: 'numeric', hour:'numeric', minute: 'numeric', second:'numeric', hour12: false}

=> The native implementation returns "10/21/2014, 14:18:34" while the shim returns "Tue, Oct 21, 2014 at 14:18:34"

I think it is more natural to require Intl if you want to pick any available Intl implementation (ie: the one from the browser or the polyfill) and to require IntlShim if you specifically want the polyfill.

Right now, our implementation will only match date skeletons that are an exact match of what's in CLDR. We should at least do the somewhat "safe" extension of including a MMMM format ( long month name ) whenever we find a MMM format ( abbreviated month name ) in the CLDR data, assuming that an explicit MMMM format does not exist. There are some locales in CLDR where it does indeed exist.

As @cjolif wrote in 5a2f51c#commitcomment-6348191, if you don't define a config for the locales plugin (using require.config()) it gets an exception.

I guess you just need a check for if (config.forEach { or if (config instanceof Array) around the config.forEach() call, and then also you need a test case.

What's the difference between ibm ecma402 and intl.js?