search

w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
576 stars 50 forks source link

Proposal: Per-extension language preferences #641

Open hanguokai opened 1 week ago

hanguokai commented 1 week ago

This proposal has been discussed a lot in #258 and is supportive by all browsers. This is the formal version of the proposal. I followed the latest proposal template.

Welcome everyone to review this proposal. I suggest focusing on the main issues first, followed by minor issues, and finally fixing textual typos.

xPaw commented 1 week ago

Looks good to me, although I would like this proposal to also cover a getMessage overload (or separate method) to get a message in a specific language.

hanguokai commented 1 week ago

Another potential syntax would be accepting an object for setCurrentLanguage which accepts a tabId.

There is no "per-tab" demand. It complicates the design.

carlosjeurissen commented 1 week ago

Another potential syntax would be accepting an object for setCurrentLanguage which accepts a tabId.

There is no "per-tab" demand. It complicates the design.

Seems @xPaw has potentially such use case. From my own experience in a content-script I sometimes want to match the language of the page instead of the extension when injecting elements to the DOM to prevent mixed-language situations.

xPaw commented 1 week ago

Seems @xPaw has potentially such use case.

I'd be just fine with an overload that accepts a language. Is it even possible to get current tab id without having the tabs permission?

carlosjeurissen commented 1 week ago

@xPaw Can you describe your use-case in detail? Getting the current tab id can always be achieved without the tabs permission using chrome.tabs.getCurrent(). This would not work in an extension popup as it is technically not a tab.

xPaw commented 1 week ago

Can you describe your use-case in detail?

To be specific, I have this extension, which lists a bunch of content scripts for various pages on Steam Store/Community, it adds some extra buttons/blocks to the page like 'lowest recorded price' for example. Since I added localization support, people are getting mismatching languages on the page (like the page may be in English, but their browser is in Japanese, so they get messages added by the extension in the browser language). Users are asking to change the extension's language because of this.

If I was able to pass a specific language to getMessage, I would be able to match the messages to the current page language (I am able to figure out the page's current language).

The content scripts simply use i18n.getMessage (I have a helper function _t), other extensions solve this by loading the locale json to get messages manually.

carlosjeurissen commented 4 days ago

@hanguokai and others. Let me know if you feel https://github.com/w3c/webextensions/issues/274 should fit in this proposal. As the use case of @xPaw and others are not covered by all the methods in this proposal. If so I will write up suggested additions. Otherwise I could write a formal proposal as promised during the San Diego meetings.

hanguokai commented 4 days ago

Let me know if you feel #274 should fit in this proposal.

I think #274 should be a separate proposal. These use cases are different from setting the user's preferred language for this extension, they are more dynamic scenarios. However, if users want to use the same language in various places, they should use this proposal's APIs.