1401506 - API to change extensions UI language individually

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement, P5)

Description

[Salar]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622




Expected results:

Because not everyone use their browser in their own language internationalizing extensions in not really useful and the end users won't feel any difference. Many of these users still want to be able to have extensions in their language.

It would be really great to have an API to let the extensions change their UI language.
The changes should be limited to the caller extension only.
My proposal is an API like this:

browser.i18n.setLocale("fa-IR");
browser.i18n.setLocale("fa");

Comment 1

[Bob Silverberg [:bsilverberg]]

Added to the design-decision-needed triage and marked as wontfix for 57.

Comment 2

[Caitlin Neiman [:caitmuenster]]

Hi Salar, this has been added to the agenda for the October 3 WebExtensions APIs triage. Would you be able to join us? 

Agenda: https://docs.google.com/document/d/1X5RmNq2tGC5Aw3npIKqxB2vhnVhg9uOoXh2TggduTPU/edit#

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Comment 3

[Andy McKay]

We talked about this in the meeting and we couldn't quite understand the use case. There's absolutely nothing stopping the extension author providing this capability if they wanted to do, since an extension author can control all the translation machinery in their extension anyway.

Comment 4

[Kris Maglione [:kmag]]

(In reply to Andy McKay [:andym] from comment #3)
> We talked about this in the meeting and we couldn't quite understand the use
> case. There's absolutely nothing stopping the extension author providing
> this capability if they wanted to do, since an extension author can control
> all the translation machinery in their extension anyway.

Not all. Localization in CSS files and manifest.json files, for instance, is outside of extensions' control. And re-implementing all of the i18n machinery could be non-trivial (especially in places like content scripts, where it may be needed synchronously).

But I still agree that there isn't a strong case for implementing this.

Comment 5

[Salar]

Sorry for not attending the IRC, it was bad timing for me.
I know this is late but here are my thoughts about use case.
According to the some stats that I have from the sites that I own or are an admin of, and also from an extension that I have (SmartProxy), most users do not care about the browser UI features itself. These stats shows that in my country Iran, 100% of users use English (en-US) locale and in other parts of the world at most 50% of people use the browser in their own language. This is understandable since there is little interaction with browser ui compared to what they do in the sites they vist (apart from browser's address bar).
In addition, the user may use extension features more than browser features itself, this is at lease true for my extension (SmartProxy) which users tend to change the preferences quite often.

To summarize, I conclude that users want to have the locale of the UI that they care most in their own language. The ability of changing UI language of extensions is what makes sense in this scenario.
This is what is happening to most users from my understandings:
User Step 1: Lets install a browser in my fresh new OS. I like Firefox. lets go for it. (user doesn't care about language)
User Step 2: Oh I like what this extension does, but I don't understand these advanced features. I wish they were in my language. (User doesn't know this is because of it's browsers language)
The proposed API would solve the issue.

Comment 6

[YF (Yang)]

(In reply to Salar Khalilzadeh from comment #5)
> Sorry for not attending the IRC, it was bad timing for me.
> I know this is late but here are my thoughts about use case.
> According to the some stats that I have from the sites that I own or are an
> admin of, and also from an extension that I have (SmartProxy), most users do
> not care about the browser UI features itself. These stats shows that in my
> country Iran, 100% of users use English (en-US) locale and in other parts of
> the world at most 50% of people use the browser in their own language. This
> is understandable since there is little interaction with browser ui compared
> to what they do in the sites they vist (apart from browser's address bar).
> In addition, the user may use extension features more than browser features
> itself, this is at lease true for my extension (SmartProxy) which users tend
> to change the preferences quite often.

This is surprising for me, the users uses an unfamiliar language for the browser interface (including options) and needs a familiar language for extensions options.

> To summarize, I conclude that users want to have the locale of the UI that
> they care most in their own language. The ability of changing UI language of
> extensions is what makes sense in this scenario.
> This is what is happening to most users from my understandings:
> User Step 1: Lets install a browser in my fresh new OS. I like Firefox. lets
> go for it. (user doesn't care about language)
> User Step 2: Oh I like what this extension does, but I don't understand
> these advanced features. I wish they were in my language. (User doesn't know
> this is because of it's browsers language)
> The proposed API would solve the issue.

You should tell the users to install the correct language version for the browser, or just change the general.useragent.locale in about:config. Install the correct version will also get the correct intl.accept_languages, otherwise the users may be forced to read non-native sites.

If you can prove that this is a general problem for a locale, tell Mozilla to provide a special interface / decision (like bug 1311472) for the user interface, rather than implementing language switching in individual extensions and got the uncoordinated interface.

Comment 7

[Salar]

> You should tell the users to install the correct language version for the
> browser, or just change the general.useragent.locale in about:config.
> Install the correct version will also get the correct intl.accept_languages,
> otherwise the users may be forced to read non-native sites.

Anyone knows how to change a setting in about:config know that they can download proper version! Here I'm talking about general user base, not power users.

> If you can prove that this is a general problem for a locale, tell Mozilla
> to provide a special interface / decision (like bug 1311472) for the user
> interface, rather than implementing language switching in individual
> extensions and got the uncoordinated interface.
This is a problem not for a locale, in fact this is not a problem at all. This suggestion is to make life easier in some ways.
And you know changing extension language for users is easier than reinstalling the whole browser.

Comment 8

[Mindaugas <LA-MJ>]

Let me add my perspective.

I live in a country where a lot of people learn English as a second language and prefer it for IT things, including me. The reason why is out of the scope of this discussion. Suffice it to say that browser language <> native tongue most of the time and your argument/wish that this should not be the case is plainly invalid/out of your/my control. /discussion

It does not mean, however, that local media or popular sites post their content in English only. Quite the contrary, people like their native tongue for non-IT things and content for both languages is hosted. User can migrate between languages via a language switcher widget (subdomain/subfolder/session cookie/etc). 

Suppose I create an extension for such a site. The said extension would contain a preferences page and inject some content scripts with extra content. Ideally you would want this extra content to adopt the locale of the media site as chosen by the user and adapt accordingly when user decides to switch the content language.

Such use case(s) render available L10n APIs so inadequate as to the point of being useless. Consequently, you have to roll your own localization engine. 

That was my attempt at generalizing a use case. The actual case is that I maintain a cross-browser extension for an internet game portal in ~40 languages available via language switcher. I haven't done any statistics but I have historical evidence (i.e. bug reports) that
a) browser language is an unreliable indicator for the user-chosen language (vanilla portal content)
b) some users use the switcher daily

And yes, I use a custom localization engine, accordingly. This is not an insurmountable problem, just like OP says. However, having this feature would lift this burden from developers.

Comment 9

[erosman]

I also think it would be a useful addition.

Here is an example that I came across in one of my own addons:

> https://discourse.mozilla.org/t/support-foxytab/11518/176
> 
> Lobuno: Hi. Spanish translation is wrong, and it’s very annoying. Also there’s no option to change the language.
> In the Refresh tabs options, more precisely “Refresh to the right” and “Refresh to the left” the translation is interchanged.
> The arrow pointing left “<-” should read “Las de la izquierda” and the one pointing right “->” should be “Las de la derecha”.
> 
> erosman: Thank you. I did not do the translation
> There is no option in WebExtension to change the language at the moment.

As a practical point, people may want to choose a different language for clarity (many use/prefer English to their native language) and/or in case of poor translations to have a fall back language.

In addon reviews, I have also come across many addons that implement their own not-so-efficient language switching which results in very large number of translation JS files.

For example:
> https://reviewers.addons.mozilla.org/editors/review/583250/
> 
> erosman: Please use the "Internationalization" API rather than using strings in JS file and/manually parsing localising data.
> https://developer.mozilla.org/Add-ons/WebExtensions/Internationalization
> 
> Oleksandr: how to switch language on the fly using "Internationalization"? there is no mechanism for switching the language on the fly.
> so if you do not mind, I'll leave my current algorithm


Finally, it will also help developers at the developing stage to be able to visually check the result of translations (sometime the length of translated sentences have a bearing on the visuals).