navigator.languages reduction

[birtles]

If navigator.languages begins returning just one language, it would be nice if apps can continue to provide the best possible first-run experience. That is, they should still be able to do a best possible first guess of the user's preferred language.

If they cannot, they may need to obfuscate the UI with a first-run CHOOSE YOUR LANGUAGE-type screen (i.e. yet another annoying banner--and simply storing that setting may necessitate a GDPR banner!), or force the user to hunt through the app in an unfamiliar, possibly incomprehensible language, for the language setting.

What could we do to fix this?

Thinking aloud, one idea might be a <meta> tag that declares the set of available languages such that navigator.languages tries to return one of the the available languages.

For example, suppose the user's preferred languages are:

• zh-CN
• zh-TW
• zh
• ja

They load an app which has:

<meta name="languages" content="en, ja">

Then when the app queries navigator.languages:

// Prior to language reduction
navigator.languages; // [ 'zh-CN', 'zh-TW', 'zh', 'ja' ]

// When no <meta> tag is available
navigator.languages; // [ 'zh-CN' ]

// With <meta name="languages" content="en, ja">
navigator.languages; // [ 'ja' ]

Just a thought to get the ball moving.

Another alternative might be a JS API such as navigator.getPreferredLanguage(availableLanguages) where the browser returns the preferred language from the provided list. To avoid abusing the API to deduce the set of languages, perhaps the browser would return the same result for 24 hours 1 minute per origin. It's pretty crude, but perhaps some iteration on that approach might work.

(Edit Nov 3: Made the suggested cache time for the latter approach 1 minute)

[Tanych]

@birtles thanks for your suggestion, those are possible. I will dig into it to figure out the potential solution.
In practical, we probably will split the roll-out the accept-language header and js interface into different phases since people has more concerns about the JS interface.

[birtles]

Great, thanks @Tanych. That's good to hear. I got the impression from the Intent to Experiment on blink-dev that the JS interface might be shipping soon so I wanted to get the discussion started so we can avoid usability regressions there.

[KratosGemini]

@Tanych Is this confirmed to not be releasing in Chome 109? As discussed, changing the JS interface without a workaround for client-side content negotiation could cause users frustration if a site depends on client-side code to redirect to the preferred language.

Thank you.

[Tanych]

@KratosGemini, we are not going to release in M109, we just provide the origin trial in M109 to collect feedback from developers.