Pasted from: https://github.com/Financial-Times/polyfill-service/issues/712#issuecomment-224348918
In addition, I just checked that for: https://cdn.polyfill.io/v2/polyfill.js?flags=gated&features=Intl.~locale.it-IT running in Safari, we get the following result:
/* Polyfill service v3.6.1
* For detailed credits and licence information see http://github.com/financial-times/polyfill-service.
*
* UA detected: safari/9.1.0
* Features requested: Intl.~locale.it-IT
*
* - Intl, License: MIT (required by "Intl.~locale.it-IT")
* - Intl.~locale.it-IT, License: MIT */
(function(undefined) {
if (!('Intl' in this)) {
// Intl
/* rest of the code */
}
While the 'official' polyfill checks the following:
var areIntlLocalesSupported = require('intl-locales-supported');
var localesMyAppSupports = [
/* list locales here */
];
if (global.Intl) {
// Determine if the built-in `Intl` has the locale data we need.
if (!areIntlLocalesSupported(localesMyAppSupports)) {
// `Intl` exists, but it doesn't have the data we need, so load the
// polyfill and patch the constructors we need with the polyfill's.
var IntlPolyfill = require('intl');
Intl.NumberFormat = IntlPolyfill.NumberFormat;
Intl.DateTimeFormat = IntlPolyfill.DateTimeFormat;
}
} else {
// No `Intl`, so use and load the polyfill.
global.Intl = require('intl');
}
The locale support check made the difference throwing an unexpected error, while if we remove the gated flag, since it's not gated anymore, the polyfill then gets loaded correctly. Therefore Safari doesn't get the exception.
I don't think we can update the detect.js file with this suggestion as each application would want a different set of locales, we can't cater for this with how we currently serve polyfills.
If we could build the detect.js file on demand and had a whitelist of all locales as to avoid remote code injection then we could take the locales passed in the url to the polyfill-service and place them in the detect.js file however, that is possibly a lot of work to be done and I'm not sure if we would accept such a feature.
Since we have separate polyfills for each locale, don't we already solve this with individual detects?
Yep, we do, silly me, we can definitely add this in.
Most helpful comment
Since we have separate polyfills for each locale, don't we already solve this with individual detects?