Implement `require('intl').polyfill(['en', 'fr', 'pt'])`

[caridy]

Now that nodejs 0.12, and iojs ships with Intl by default, the polyfilling process becomes a little bit messy. For info about this here: http://formatjs.io/guides/runtime-environments/#polyfill-node

These is the piece of code that we are using today for polyfill Intl in node:

var localesMyAppSupports = [
    /* list locales here */
];

if (global.Intl) {
    // Determine if the built-in `Intl` has the locale data we need.
    var hasBuiltInLocaleData = localesMyAppSupports.every(function (locale) {
        return Intl.NumberFormat.supportedLocalesOf(locale)[0] === locale &&
                Intl.DateTimeFormat.supportedLocalesOf(locale)[0] === locale;
    });

    if (!hasBuiltInLocaleData) {
        // `Intl` exists, but it doesn't have the data we need, so load the
        // polyfill and replace the constructors with need with the polyfill's.
        require('intl');
        Intl.NumberFormat   = IntlPolyfill.NumberFormat;
        Intl.DateTimeFormat = IntlPolyfill.DateTimeFormat;
    }
} else {
    // No `Intl`, so use and load the polyfill.
    global.Intl = require('intl');
}

This is to guarantee that the polyfill is used if at least one of the locales supported by your app is not supported natively in nodejs, then it falls back to the polyfill.

As a new pattern is emerging in other polyfills when used thru NPM, the polyfill() method will normally patch the runtime when needed.

/cc @ericf

[caridy]

I will probably try to get this in by 1.0.0-rc-2.

[armandabric]

That's a good idea! :+1:

[caridy]

I don't have time to work on this these days, we need a brave soul to take it.

[0x6a74]

got a hint where to start - or even your concerns and plans how to implement that feature?

[caridy]

@johannestroeger we will need the input from @srl295 on this. Node 0.12 is definitely not the focus anymore. Ideally, we should have a quick and easy way to detect what are the locales supported by the node runtime without having to attempt to create instance and test for the respective resolvedOptions (@srl295 can help on this). Then we should provide an extra method, or maybe a extra module, thinking of require('intl/register') a la babel, to maintain backward compatibility, and that module should give us access to define a domain of locales that we want to support, and under the hood, it can test whether all of them are supported or not, and if there is something missing, most likely we will have to patch the Intl to provide shims for supported locales, and fallback to the polyfill for missing locales.

[ghostd]

According to the official documentation, we have to detect the supported languages ourself.