What happens to `preferredLocale` on non supported browsers?

[wopian]

What happens to `preferredLocale` on non supported browsers?

[mattlo]

Wow thank you for this great answer. Good to know about Safari, we still have a ton of users using versions lower than 14, but navigator fallback should be fine (Safari is the new IE). That was going to be my original impl until I found your lib anyways.

Great work on this project!

[wopian]

Thank you for becoming a sponsor too! 🎉

[wopian]

preferredLocale will not throw an exception and will fallback in various ways.

When checking for a client's supported languages:

• It uses the window.navigator API on browsers, which is supported by all (>= IE 4) browsers
• It uses the Intl.DateTimeFormat API on Node.js environments, which is supported by Node.js 0.12 and newer
• If for some reason neither of these are available, it falls back to using the provided fallback locale as the users' locale

The main functionality makes use of Intl.Locale (Chrome 74/Firefox 75/Safari 14/Node.js 12 or newer). When this API is not available it will match the expected behaviour where possible.

The only difference in behaviour between an environment that supports Intl.Locale and one that doesn't is that unsupported environments will not be able to expand a locale that only has a language code to one that also has a region (e.g en to en-US) as the package does not contain a lookup table of all (~8,000) ISO 639 language codes to match the behaviour of Intl.Locale#maximise. This difference in behaviour is not present when the options.languageOnly parameter is enabled.

However, in reality this is not much of a problem as Intl.DateTimeFormat always provides a language-region locale on Node.js environments and browsers typically include both in window.navigator (e.g ['es-ES', 'en-US', 'es', 'en']) - I have not come across one that only returned a language code.