1323440 - WebExtensions: helping add-on developers providing locales

Status: UNCONFIRMED

(WebExtensions :: General, defect, P5)

Description

[Michel Gutierrez]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161114144739

Steps to reproduce:

Firefox has a huge number of locales available and WebExtensions is currently a big deal at Mozilla. BUT there is nothing done to help add-on developers to get their extensions translated.

The idea would be to modify the browser.i18n API implementation in such a way that when an add-on requests a string translation using browser.i18n.getMessage(), the system would transparently first search for a user-provided local translation for the corresponding key. If none is provided, the regular method from file _locales/xx/messages.json would be used. In the meantime, Firefox would provide a UI for the user to modify her own string translations for any given WebExtensions add-on using i18n (i.e having a _locales directory), from a link/button at the extension entry in about:addons.

This done, the user can modify any string displayed to her by the addon. Next thing would be to allow the user to share her translation to a server, so that, after validation, this can be integrated as a regular locale in the next add-on release.

Shane Caraveo suggested using Pontoon to receive and manage translations. Another option would be Babelzilla.org where there is already a large community of add-on translators. Certainly, one good way to go would be to define the format for the HTTP export and let to the add-on developer the choice of the server through a new property in manifest.json, say "custom_strings_upload_url".

To get an idea of how user custom strings could look like, it is possible to install the weh toolkit from https://github.com/mi-g/weh , create a new skeleton project and use the "Translation" link in the popup. Of course in this case, it implies the add-on uses the weh build system (to get the locales keys) and weh libraries (to override browser.i18n.getMessage), and there is no sharing implemented. This proposal is about getting this natively into Firefox.

Simplifying the localization for the add-on developers => more add-on locales available => more add-on users.
And as far as i know, this is a feature Chrome does not offer...

Comment 1

[:shell escalante]

andy is going to pursue discussing with Michel

Comment 2

[Andy McKay]

Adding any Firefox UI is not a small project that requires work and maintenance and that gives me a good deal of reluctance on this suggestion.

As an add-on developer I first have to specifically set up my project to be localised by ensuring all the components are localisable. Once that's done there are multiple other ways I get it localised, through existing services like pontoon or babelzilla or others. Then I can take those translations and re-add them to my project.

This change to Firefox makes the step of soliciting translations easier. But it still means that the developer has to get the translations, add them to their project, maybe cope with collisions and so on.

I would rather see a process in place that involved no Firefox changes at all and support that in the add-on community at large. Could we make it easy and provide a path for developers to do translations? For example, add in features to the web-ext command line tool to generate .po files or whatever is the format these days. Then see how popular that is and evaluate this proposal then.

I'll note that transifex already supports the existing i18n format, maybe others do: https://docs.transifex.com/formats/chrome-json. Also about 5k of 58k Chrome extensions use the i18n API.

Comment 3

[noitidart]

BabelZilla is a great resource. I used them for years. Their beta site is nice but it got stagnant. Mozilla should support BabelZilla with a cash grant. Their admin team is so awesome, they hang in there doing what they can while waiting for the community there become alive again.

Comment 4

[Michel Gutierrez]

As an add-on developer, managing locales has always been an issue for me. I've always had locales that were far behind, even if the popularity of my main add-on attracts translators on Babelzilla (currently 90 people are registered to the project). So my guess was that other developers with less known extensions must have this problem in worse.

I did not realize that only 5k of 58k Chrome extensions were using i18n. But i guess the "greatest" extensions are much more likely to be localized than the others, so this ratio is probably biased regarding the end-users common interest.

When i will port Video DownloadHelper to WebExtensions, the user-customized strings feature will be there and i'll code something server-side to receive the locale uploads. I'll see then if i can connect this to Babelzilla or Pontoon, or use the Google translate API to verify manually and filter out the "**** you" that will show up.

The idea was that if we have this kind of thing in the browser, this would be a great incentive for Chrome add-ons developers: "port your add-on to Firefox and get your locales for free !". Plus, that was a feature that is non-present on Chrome and helps differentiate and communicate about.

Sure having some locale-oriented utilities in web-ext might help, but quite frankly, add-on developers are first of all developers, so manipulating organized data, whether it is in json or .po is not a big deal anyway.

Regarding transifex, i sincerely doubt many add-on developers can afford their services.

Comment 5

[Michel Gutierrez]

(In reply to noitidart from comment #3)
> BabelZilla is a great resource. I used them for years. Their beta site is
> nice but it got stagnant. Mozilla should support BabelZilla with a cash
> grant. Their admin team is so awesome, they hang in there doing what they
> can while waiting for the community there become alive again.

i totally agree !

Comment 6

[Markus Jaritz [:markus] (UX)]

If we would have such a feature in Firefox we could assume that a larger number of people than now would become translators. So how about making it easier to do translations of extensions before integrating it into Firefox?
I noticed that for extension you only always see the original string without much context, which strikes me as a big hurdle to easily understand how to translate strings.
Pontoon for example shows the real website next to working on the translation which brings the individual strings in context and therefor helps in understanding how to translate. This does not exist for extensions and I imagine that makes it more complicated to come up with good translations.

Comment 7

[Michel Gutierrez]

I agree that the context is very important when translating. And here, we are talking about add-ons, i.e. applications, where the content is much more dynamic than a regular web site.

But the beauty of user-customized strings is that people translate for their own needs and can test their work in real before deciding to share. It's far different from only having a list of strings to translate blindly.

Comment 8

[Michel Gutierrez]

Not giving up on this.

That feature can be tested on Video DownloadHelper 7.0.0 https://addons.mozilla.org/en-US/firefox/addon/video-downloadhelper/versions/#version-7.0.0

Open VDH settings > More > Translation

Implementation available in Weh: https://github.com/mi-g/weh