Skip to content
Advertisement

When does the Intl locale negociation fall back to the browser’s default?

I’m trying to understand Intl locale negociation but I am struggling with a simple use case. My browser’s (firefox) default locale is french (fr-FR), and I have also installed fr, en-US and en (prioritized in the stated order).

The following happens:

>> new Date().toLocaleDateString("en-US", { day: "numeric", month: "short" })
"Oct 20" // OK, I have "en-US" installed

>> new Date().toLocaleDateString("en", { day: "numeric", month: "short" })
"Oct 20" // OK, I have "en" installed

>> new Date().toLocaleDateString("en-XX", { day: "numeric", month: "short" })
"Oct 20" // OK, the negociation falls back to "en" which is installed

>> new Date().toLocaleDateString("en-GB", { day: "numeric", month: "short" })
"20 Oct" // ???

>> new Date().toLocaleDateString("en-UK", { day: "numeric", month: "short" })
"20 Oct" // ???

Why do the last instructions output "20 Oct" (which is the french version of the date, so probably the browser’s default)? Shouldn’t the locale negociation algorithm choose en? The behavior is consistent with Firefox and Chrome, so I must be missing something…

Advertisement

Answer

en-XX doesn’t exist and falls back to en.
en-GB and en-UK both exist and both refer to British English, which uses DD MMM format.

This has nothing to do with what you have “installed”. The browser supports all those locales without them having to “be installed”.

Likely what you mean by “installed” is just the list of your preferred languages; this is just a list of languages you prefer to see content in, which will be sent to the server so the server can decide what language to return, if several options exist. It plays no role in this date formatting.

User contributions licensed under: CC BY-SA
6 People found this is helpful
Advertisement