About this particular issue, I was talking to @ericf while integrating the polyfills into Flickr last week, and it seems that we made a bad decision on IntlPolyfill. It seems that if we are changing Number and Date prototypes when posible, we should be also defining Intl when posible. It facilitates greatly the adoption, and if there is a way were Intl is in place, we could always add the IntlPolyfill for users who want to bypass the native implementation for whatever reason (normally bugs in native, which are very uncommon for ever-green browsers). What do you guys think?

So, you're saying define Intl in environments that don't have it native, but IntlPolyfill otherwise? That sounds like a decent enough proposal. As I've said before, I would like to make using Intl.js as transparent as possible, so that coders don't need to adjust their code to allow for it.

Generally, people should be advised to include it only if they need it. I'd even be fine with overriding native Intl if Intl.js is included, but for some reason the v8 team decided to make Intl non-configurable, which is one of the reasons for us going with IntlPolyfill.

Yeah, my concrete proposal is:

1. always set global.IntlPolyfill = factory();
2. conditionally set global.Intl = global.IntlPolyfill;

that will cover the case of transparent inserting the polyfill in the page (conditionally or not), but also the case where you want to use the polyfill over the native implementation for a particular runtime.

It seems that the toLocaleString method is only overriden if the browser already has a native Intl implementation. I guess it should be the other way around.
Thank you