Skip to content
This repository was archived by the owner on Apr 14, 2021. It is now read-only.

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

Open
caridy opened this issue Apr 2, 2015 · 6 comments
Open

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

caridy opened this issue Apr 2, 2015 · 6 comments
Labels
enhancement

Comments

@caridy
Copy link
Collaborator

caridy commented Apr 2, 2015

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
Copy link
Collaborator Author

caridy commented Apr 2, 2015

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

@ericf ericf mentioned this issue Apr 2, 2015
Closed
@armandabric
Copy link

That's a good idea! 👍

@caridy caridy self-assigned this Jul 8, 2015
@efkan efkan mentioned this issue Aug 3, 2015
Closed
@caridy caridy removed their assignment Feb 11, 2016
@caridy
Copy link
Collaborator Author

caridy commented Feb 11, 2016

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

@0x6a68
Copy link

0x6a68 commented Feb 12, 2016

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

@caridy
Copy link
Collaborator Author

caridy commented Feb 12, 2016

@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.

@caridy caridy mentioned this issue Feb 28, 2017
Open
@ghostd
Copy link

ghostd commented Aug 13, 2018

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@0x6a68 @caridy @armandabric @ghostd