ibm ecma402 or intl.js

[ehartford]

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

[caridy]

For what I can tell (from the readme) this is a parallel effort. Will be great if @JCEmmons or @cjolif can clarify on this. Intl.js is what we have been recommending in TC39 when people ask for a 402 polyfill, and it is already used by many folks, including big companies to patch old browsers and safari when needed, and we are very open for contributions and improvements.

Aside from that, from what I can see in the code, this is not following the specs, or at least is not reflecting the specs information in the source code. I wonder if it is diverting from it in some degree.

[JCEmmons]

It is indeed a parallel effort. When I initially evaluted Andy's work on this, we decided that it was going to be too difficult to maintain in the long run and wouldn't meet our needs, so we decided to create what we believe is a superior package ( although ours it still not quite finished yet... ) Both projects have similar intent, i.e. to provide Intl.Numberformat and Intl.DateTimeFormat functionality for older browsers that haven't implemented ECMA402 yet, or for those browsers that have no plans to do so. What we really wanted to provide was:

1). A package that would load very quickly in the "majority" use case, which is "I only care about the locale that the browser is running in." 2). Would provide a robust set of locales and locale data to choose from. 3). Would be 100% based on CLDR data, and could be expanded and upgraded using the tools and data coming from the CLDR project ( which is why I was "volunteered" to write the bulk of the code. This was very important to us. 4). Would offer the option to leverage the native support in the browser if it exists. 5). As close to 100% compliance with ECMA402 as possible. I use the test402 suite developed by Norbert Lindenbert ( ported to intern and chai/assert, but still the same tests ) in order to test compliance with the spec.

Like I said, the project is currently in an "almost finished" state, and I certainly welcome people to try out what we have so far and report to us any problems you see...

Regards,

John C. Emmons Globalization Architect & Unicode CLDR TC Chairman IBM Software Group

[ehartford]

Thanks for the excellent information!

[caridy]

@JCEmmons there is nothing in that list that Intl.js is not providing, in fact we did the exact same exercise you guys are doing, but six months ago when we were looking to implement a 402 polyfill for yahoo, eventually Norbert mentioned the work that Andy was doing in this regards, and after a period of evaluation, we decided to help Andy to improve Intl.js for yahoo's needs, and since then, he has been a fantastic partner. Why don't we have a quick chat, it will be fantastic if you guys can align with us behind Intl.js to move this forward. /cc @ericf

[caridy]

FYI: @andyearnshaw provided more details about the differences between the two implementations here: https://github.com/andyearnshaw/Intl.js/issues/66#issuecomment-45685324

[andyearnshaw]

@JCEmmons: our goals are almost identical. Recently, I've been evaluating ways to break down the Intl.js code to make it more modular, in an effort to make it easier to extend and maintain, whilst keeping the library completely independent.

You're welcome to offer some suggestions for Intl.js. Like @caridy said, we're very open to contributions and improvements, and I'd like to make the process as simple as possible for everyone.

[JCEmmons]

Thanks, Andy, I appreciate it. I think the biggest sticking point for us at the time was the way Intl.js does its data, as I didn't have a clear understanding of how you got from CLDR's data to what Intl.js uses. I wanted to make it very easy for people to be able to extend the package, or update the data by simply either running the JSON generation utilities that are part of the CLDR distribution, or by copying the JSON data that we publish into place. We had a number of other requirements as well, but that one I didn't think we could get past at the time. It's definitely not a "competition" or anything, and I certainly welcome any suggestions you can offer for our ecma402 implementation.

[andyearnshaw]

@JCEmmons: it's a valid point about the data. Originally, I was using the data as it is in the CLDR, but I chose to pre-process it as an optimisation to keep the implementation fast. I've since realised that it does take a little flexibility out of it, particularly with the date patterns (mostly relating to your issue #39). It was mostly naivety on my part, and I've been considering changing back to using the raw CLDR data for a while now. Intl.js does have tools built-in to pre-process the data into the format it uses, however.

I don't see it as a competition, everyone has their own preferences and more choices are only a good thing, but it's great if we are able to help each other along the way. If there's anything you need from me, just let me know. :+1:

[JCEmmons]

Absolutely. Thanks so much, Andy, and likewise from me as well. Always glad to help as time permits.