Proposal: deprecate i18n.getAcceptLanguages

[carlosjeurissen]

Currently you can get a list of accepted languages using the i18n.getAcceptLanguages method. This returns an array with the languages found in Accept-Language headers. See MDN doc and Cr doc.

Since the introduction of this API, the web now provides the same using the navigator.languages property. As it seems we want to favor web technologies instead of also providing a webExtension API, I suggest to deprecate i18n.getAcceptLanguages.

One could consider keeping this as it could still be useful in the potentially required service_worker background script. However navigator.languages is now also available in serviceworkers. See MDN doc.

Related issues:
https://bugs.chromium.org/p/chromium/issues/detail?id=101138
https://bugs.chromium.org/p/chromium/issues/detail?id=1258498

[carlosjeurissen]

After doing additional tests, I found the following:

If using chrome.webRequest to change the value of the Accept-Language header, both in Firefox and Google Chrome, the value of navigator.languages and the i18n.getAcceptLanguages does not change. Is this intended?

If overwriting the value of navigator.languages in the main world of the page using defineProperty with a getter, the value of navigator.languages or i18n.getAcceptLanguages does not change.

If overwriting the value of navigator.languages in the isolated content script world, the i18n.getAcceptLanguages outputs the original list of acceptLanguages.

This all confirms the equivalence between navigator.languages and i18n.getAcceptLanguages. So this pretty much confirms we can deprecate it if using navigator.languages within the content script does not interfere with the privacy budget of the page in Google Chrome @dotproto .

[hanguokai]

Chrome is trying Intent to Experiment: Reduce Accept-Language Origin Trial. It will cause navigator.languages only has one language which is the same as navigator.language. I don't think this will soon become a reality, but just in case, i18n.getAcceptLanguages() should be kept for now.

[carlosjeurissen]

@hanguokai that is a very valid point. I have opened an issue in the relevant github repository to further discuss this:
explainers-by-googlers/reduce-accept-language#6

For now it seems best to keep the i18n.getAcceptLanguages.

[carlosjeurissen]

In Safari, browser.i18n.getAcceptLanguages returns the full list while navigator.languages returns the restrictive list.

Considering this and previous discussions it is best to keep browser.i18n.getAcceptLanguages around. This will allow extensions to use navigator.languages as it would appear to any other JS code and if it wants the full list, use browser.i18n.getAcceptLanguages. Best of two worlds. Closing this issue.