Proposal: i18n-system-languages

[carlosjeurissen]

This PR adds the proposal for both i18n.getPreferredSystemLanguages() and i18n.getSystemUILanguage() previously called i18n.getOSLanguage(), which all vendors are supportive on as discussed in https://github.com/w3c/webextensions/issues/252

[carlosjeurissen]

@xeenon Thanks for reviewing and the willingness to implement this.

@rdcronin Thanks for reviewing and your comments. Most feedback has been implemented in the proposal. Thanks for offering to sponser the feature as browser.

@Rob--W Reading from your comment in the reading notes of Today's (2024-03-28) meeting:

This proposal doesn’t follow the new process. One of the aspects of the new process template is that there should be at least one browser committing to implementing the API.

It was under my impression there was general support for this feature across browsers and the next step would be a proposal. However I understand your concerns regarding ending up with many proposals without browsers moving forward to actually implement them. So I went ahead and created a patch for Firefox. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1888486

[Rob--W]

@Rob--W Reading from your comment in the reading notes of Today's (2024-03-28) meeting:

This proposal doesn’t follow the new process. One of the aspects of the new process template is that there should be at least one browser committing to implementing the API.

It was under my impression there was general support for this feature across browsers and the next step would be a proposal.

Part of the proposal template includes an item about the "sponsoring" browser. As Devlin commented elsewhere in the PR, the purpose of that is to encourage proposals that reflect APIs that have a path towards realization rather than just being aspirational.

However I understand your concerns regarding ending up with many proposals without browsers moving forward to actually implement them. So I went ahead and created a patch for Firefox. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1888486

Thanks for the bug and patch!

[hanguokai]

As the discussion deepens (#252), I think there are four concepts here:

1. The Browser UI Language
2. The Browser Accept Languages
3. The OS UI Language
4. The OS Accept Languages

So, ideally there should be four functions:

1. i18n.getBrowserUILanguage()
2. i18n.getBrowserAcceptLanguages()
3. i18n.getOSUILanguage()
4. i18n.getOSAcceptLanguages()

And deprecate the current i18n.getUILanguage() and i18n.getAcceptLanguages().

Or using another design:

// return a single string for UI language
i18n.getUILanguage(
    prefer: "browser" // or "os"
);

// return an array for accept languages
i18n.getAcceptLanguages(
    prefer: "browser" // or "os"
);

[carlosjeurissen]

Updated the proposal which addresses the following: i18n.getOSLanguage() has been renamed to i18n.getSystemUILanguage() to better indicate it is supposed to be the user interface of the operating system. Not the first preferred language specified in the operating system.

i18n.getPreferredSystemLanguages() has been added which returns the above mentioned preferred languages specified in the operating system. This aligns with the same API and name available in Electron apps.

For i18n.getPreferredSystemLanguages(), a patch for Firefox has been made, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1888486

[xeenon]

@carlosjeurissen There seems to have been a rebase issue, where this PR picked up a bunch of other changes from the repo outside of your proposal.

[carlosjeurissen]

@xeenon Thanks for noting! Has been addressed.