Globalization API Feedback - moar!

Brendan Eich brendan at
Wed Nov 30 21:53:22 PST 2011

On Nov 30, 2011, at 9:08 PM, Rick Waldron wrote:

> Speaking on behalf of real world web developers, the opposition to "Globalization" is that it's unnecessarily long. This is a long standing problem with APIs that are designed by people that don't have to use them everyday.

Yeah, but shorter names are likelier to collide, unless hideous (e.g., G11n). Which brings us to the built-in modules idea where the importer lexically names the "@globalization" module or imports exported bindings from it.

To get beyond the module vs. predefined-in-global-scope-namespace-object sideshow (I called it that; I agree it's not the main show, but it ain't a mater of indifference either), we could talk about how some of the additions will show up as methods in Date.prototype, e.g. This should happen without any import statement, and it's very unlikely that such built-in prototype extensions will break existing web content. Whatever formatting, collating, etc. object APIs live behind the scenes, this seems worth getting agreement on sooner rather than later.

The namespace or module contents, e.g. the DateTimeFormat constructor, need sorting out independent of the way you access the namespace object or module, too. We should get back to those API details, if any controversies remain. I'm not sure Norbert convinced everyone that localeList must be an independent parameter from options, for example.

I suspect controversies remain. Using ICU in the Google implementation is not enough to ensure that Apple will go along, and without those shiny iOS devices supporting the Globalization API, developers will probably not polyfill the whole thing. IE10 won't have a ton of market share up front, and who knows how market share ends up on phones and tablets, so pressure on Apple to implement by using the Google code may well be limited.

Really, in addition to covering the sideshow issue of module vs. object, and the more significant "main show" API form and function issues, we need to get all the players on board. The last time Ecma produced an at-most-two-vendors-really-wanted-it spec was E4X, and that was a big mess. I don't think Globalization will be that kind of mess, but the precedent is there. We need to get all the significant market players on the same page.


More information about the es-discuss mailing list