Creating a web-extension i18n tool

Add-ons Development
#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.

#21

Never mind! :slight_smile: No problem.

#22

My tool is on npm now:

1 Like
#23

Not yet, sorry. I’ll post on this forum when things become tangible.

#24

@Lusito: Well, WET looks good, translations are saved. Three things:

  • Is it possible to import a messages.json not being in the WE _locales folder?
  • Usually basic locale is en-US, not en. You use en - VDH, for instance, en-US - therefore no English strings are shown for the en locale.
  • It seems that WET takes the locales of the WE to be translated. If I want to add a new locale, I would need to add it manually to the _locales directory that it will be loaded in WET. It would be better that WET includes a list of locales so the translator just needs to select the requested locale. The list should be as complete as possible.
#25

BTW, I’m milupo. There are 4 ways to log in but for any reason the way via Google worked only now. Therefore the other username.

#26

@michawjelk:

  • Currently no, can you give me a reason why it should? afaik web-extensions require you to use _locales
  • Could you explain your problem with en vs en-US a bit more? WET should not care about the locale… Unless I have some leftover code, en should only be used in two places:
    • when creating a new language it’s the example locale in the input field.
    • when en is available it will be used as first language.
  • You can add new languages from within WET without touching the filesystem manually. It’s the globe with a plus (hover them to see a tooltip). Currently you need to know the locale key to proceed, but there is validation in place telling you the readable name… en-US will be named “English, United States”, etc.
    • I guess it would be possible to create a searchable dropdown instead, but since you can - in theory - combine every language with every country, it would either be a huge list or two separate lists… one for the language, one for the country…

Thanks for the feedback.