Creating a web-extension i18n tool

Add-ons Development
#1

I’m working on a tool to help ease the translation of my add-ons…
My majors points for doing this:

  • I want to be able to use markdown… and since json doesn’t allow multiline strings, it would be very hard to read in json itself.
    • A sidebar preview pane for the markdown is included
  • I want to easily add new messages and compare them side by side, spotting missing translations without too much hassle.
  • Adding new languages and having a side by side view to start with.
  • All json files will be reformatted so all messages appear in the same order.
    • Order can be changed via drag and drop

This is mainly for myself, but If everything goes as planned, it will be available on npm for everyone else. So if anyone has further ideas, please let me know.

Screenshot of the current state:

web-extension-translator
web-extension-translator.png1267×789 75.7 KB

1 Like
#2


This topic may also interest you :wink:

#3

I’ve seen it… not convinced though… I’m not gonna port my add-on to use weh, just to use this. Aside from that, I have tried it and found it was very ugly to use, especially if the translations where really long (set the filter dropdown to “all strings” and you’ll see).

I like the idea of users contributing translations, but I wonder how many will actually do this and maintain it.

#4

This user-provided translations mechanism in VDH is very new and this is my first feedback:

I asked in the general support forum people to submit contributions to a dedicated forum and so far i’m rather satisfied: i get locale updates for German, Spanish, Dutch and Italian, plus 2 new locales Upper/Lower Sorbian (local German dialects). At some point, i will advertise more about the feature and the way to share directly within the add-on, so more people are likely to contribute.

About weh translation being ugly :slight_smile: : well, yes, that’s not where the time was spent in priority. I’ll improve this when it will become the worst part of the add-on. Or maybe someone else will have done do (weh is open-source).

But, my strong feeling about this is that an equivalent mechanism should be implemented directly in Firefox. So no need for weh to support the feature. You can follow the related bugzilla bug about this and maybe write there you would like this feature.

#5

About the bugzilla request: I don’t wanna crush your hopes, but chances are it will either take a long time or stay open forever. I’ve seen feature requests open longer than 17 years.

I even have a few tickets myself, and while the discussion was active at first (even had a video conference/triage with the devs), nowadays all that is happening is flags being changed… like someone gets added or removed from the CC.

So a third party solution is probably the way to go for now (and quite some time into the future).

#6

What about a website for that? It could be a good idea to have a website were developpers are registered and have access to this tool. There, they can manage all their translations about different WebExtensions or other applications then export in json file. And when a user wants to contribute, he just has to make a proposal on the website about the specific app, which sends a notifcation to the developper. With such a service, we don’t need a third party tool integrated to the app.

#7

I don’t have too much expectations, there are a bunch of things that have been promised to me by Mozilla engineers, and this in a conference in front of a hundred folks, and never held. So, i have no much hope for something that have not been committed by Firefox developers.

As for myself, i don’t care too much. My principal add-on and the ones to come are based on weh, so i have the translation system i want (and yes it will be less ugly sometime). It’s just that if we think i18n is important in a product, then Firefox should move that way as it is useful and a differentiation from Chrome.

Back to your tool: is it something you intend to put online or is it a local application ? From my experience, many translators will give up as soon as you tell them they need to install the node.js suite. If it is installed on an add-on web site, they will be more likely to try it. They will probably ask for the ability to generate automatically an add-on with their translation, so they can test it. This was the way Babelzilla worked.

Also, do you handle placeholders ?

Nice tool by the way. And i like the idea of markdown.

1 Like
#8

Agreed, Something like this should be in Firefox, but it probably won’t be.

My tool is currently developed using HTML & JS, running inside a webkit container (using JavaFX) as a standalone application (since webpages have no way to access your filesystem and copying everything to a zip and back is not very comfy).

So porting the tool itself it to a webpage would not be much work.
But here’s the thing that will make it a bit more complex to have it on a webpage:
The backend part needs to be developed. There needs to be a REST API for listing, viewing, translations and changes, and some sort of way for develelopers to approve them.

But usually the developers don’t know all the languages, so they can’t really approve them. They either need to trust the contributors or add some sort of user-based rating system, which adds more work to the todo list.
There are also security issues to take into account. Especially with markdown, users could add links to malicious websites or worse.

If such a system was to be developed, I would probably add a similar approach to your weh layer, but instead of adding the editing gui to the add-on, I would keep it on the managing website and allow the website to communicate with the add-on, sending it the new translations to work with.
This would help keep the dependencies on the add-on side low, so any changes to the editor can be done without updating the add-on. This would also allow users to download and try translations live.

But as said, this would require more work and is beyond the scope of my tool at this point.

Placeholders: Good point, I forgot about them, since in the very rare cases I replace stuff, I use the unnamed placeholders ($1, …). It is on my todolist now.

As for having to install node: It will be available as a jar file, so anyone with java installed can run it even without node.js

1 Like
#9

One nice feature you could add: a tool to call the Google Translate API on a concatenation of all translated strings back to English (or the default language). The idea is for the developer to verify the translator did not write insanities before validating the locale. I do that manually for translators i don’t know.

I don’t want to start a war here, but saying you don’t have to install node.js, only java, doesn’t make me more comfortable :slight_smile:

#10

I actually did think about using google translate to even start new languages (so translators have even less work). But I found out, that the google translation API is being deprecated and I don’t want to put effort into this if it’s going offline soon.

Well for non-developers it’s actually less of a hurdle if it’s just java. I’ve thought about using electron or similar, which don’t need java, but they have a huge weight (above 100MB download for a hello world, which is even less acceptable). There are java executable wrappers, which remove the need for java, but I don’t think they’ll improve the size problem much.

So I’m guessing the only solution for you would be an online service. :stuck_out_tongue:

#11

If anyone wants to try, here’s the first prototype: http://lusito.info/web-ext-translator.jar
It should keep placeholders as they are, but you can’t yet edit them.
I would recommend you make a backup of your locales, just in case.

#12

Well for non-developers it’s actually less of a hurdle if it’s just java. I’ve thought about using electron or similar, which don’t need java, but they have a huge weight (above 100MB download for a hello world, which is even less acceptable). There are java executable wrappers, which remove the need for java, but I don’t think they’ll improve the size problem much.

So I’m guessing the only solution for you would be an online service. :stuck_out_tongue:

One alternative to Java or Electron is a Web Extension backed up with a node.js native app to provide the missing APIs. The native app can come with its own installer, whatever the platform, and it weights ~ 30MB. This is the solution i chose for my add-on.

#13

could you explain that a little further? The native app I mean. I can’t seen to find anything else than electron or node webkit.

#14

WebExtensions provide a native messaging API, i.e. a clean way to dialog with an application running on the computer. So you can have your add-on providing the user interface of your translation app, and whenever you need to do something that cannot be done using the regular WebExtensions add-ons API, like say creating a ZIP file, the add-on uses the services provided by the native app.

An example of this is the Video DownloadHelper addon. The latest version uses a companion app to provide services missing from Firefox Quantum, like a file manipulation/writing API, or unrestricted downloads. The companion app that works with DownloadHelper is available in open-source, based on node.js, and provides the full build procedure to generate an .exe installer for Windows, .pkg and .dmg packaging for Mac, .deb and .targz for Linux.

#15

Thanks. That, however, doesn’t make me more comfortable.

#16

The mozilla l10n team is currently thinking about two paths to enhance the l10n/i18n story of web extensions.

One is a translation platform, which would have pontoon as a significant part of it. We’ll get more clarity about that over the next two weeks.

The other is about the i18n api, and we’ll be proposing something to bring Fluent into the localization story of web extensions. Also, I expect conversations next two weeks here.

1 Like
#17

Are there bug tickets or any other pages where one could find more information?

#18

Hi mig, Upper and Lower Sorbian are West Slavic languages, related to Czech, Slovak and Polish, not German dialects. They are spoken in Germany only.

#19

…, plus 2 new locales Upper/Lower Sorbian (local German dialects).

… Upper and Lower Sorbian are West Slavic languages, related to Czech, Slovak and Polish, not German dialects. They are spoken in Germany only.

My most humble apologies !

#20

I am the Mozilla translator for Upper Sorbian and Lower Sorbian and I translate all what should be translated. A central website like pontoon.mozilla.org is a good thing if you have a driver team that prepares all for translations and if it has convenient features which make the translation work easier. The VDH solution of mig is a good idea as well, because you have a live preview and you can see immediately if the translation works. Babelzilla was good as well but it was buggy and had a very small team only. The issues that add-on developers had on Babelzilla we translators often were not aware of. Babelzilla’s advantage was that it was specialized in add-ons. I think, from the view of an add-on developer, a central solution like a localization website would be the best. One common place for all add-on developers and localizers. Mig’s solution leaves the add-on developer the discretion if he will include this feature and I’m afraid that many developers won’t make use of it. The current issue is that many add-on developers do not include localizability, they simply hardcode the webextensions. I understand that programming webextensions is work enough for them now. In XUL extensions we translators could hack the .xul-file and make the corresponding strings localizable. Mig’s solution is an ad hoc way. If I think I want to translate into a new language, I do it inside the extension, let me show the preview, export the strings and can send the completed translation to Mig. The same way I can complete an incomplete translation. A special tool should be easy to handle and easy to learn for a localizer.