Creating a web-extension i18n tool

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

#27

@Pike Any news from the mozilla l10n team?

#28

Hi,
I also developed a concept of i18n like @Lusito but I chose a different approach.

  1. It is a web page (Github), so you don’t have to install anything and you can start translate within the browser.
  2. Messages.json file are fetched over internet (Works with GitHub repository). You can provide a link to the app that will automatically fetch some files for your translators.
  3. Add feedback about the translations to do. (Need to add the messages.json from the previous translation.)

I would gladly accept any feedback about it. :slight_smile:

App

https://morikko.github.io/translate-web-extension/help

App auto-config

https://morikko.github.io/translate-web-extension/translate?headoriginal=https://github.com/Morikko/sync-tab-groups/blob/master/extension/_locales/en/messages.json&baseoriginal=https://github.com/Morikko/sync-tab-groups/blob/94bc92b129c3a1e363ddc9fa5a0e91ca4aeed369/_locales/en/messages.json&basetarget=https://github.com/Morikko/sync-tab-groups/blob/94bc92b129c3a1e363ddc9fa5a0e91ca4aeed369/_locales/fr/messages.json

Example on how I provide all the translation contexts for my extension

Git Repository

#29

Any news here? I’d really like if https://pontoon.mozilla.org/ could be used for translating WebExtensions?

Apart from this: Do you know any (not-WIP as https://github.com/Morikko/translate-web-extension) websites, which allow you to translate JSON files? It can’t be such an unsupported format for translations.

#30

I personally use transifex.com to translate my extensions, however it has the downside of dropping placeholders in the generated translations, so you have to use some tool to add the placeholders from your source locale to the translated versions.

#31

We talked about this in the meantime, including in our Munich meetup. One thing we decided is that hosting a version of pontoon for the add-ons community will require support for Organizations in addition to supporting the file type. The work on either hasn’t been put on the short term roadmap.

There’s a good template in the bug I filed for Android’s strings.xml to see what the file-format support will take. I filed a placeholder for now, 'cause it’s Sunday.

#32

I’ve just released an updated version that can be used online, can import from Github or ZIP file and exports ZIP files:
https://lusito.github.io/web-ext-translator/

It’s also possible to enhance the editor with groups like in this example:
https://lusito.github.io/web-ext-translator/?gh=https://github.com/lusito/forget-me-not/tree/feature/wet

And as can be seen with the above urls, extensions can easily create a link that automatically imports a github branch.

The NPM version can still be used, as it now uses the same code-base… Since this is a full rewrite, a lot of features have been lost in the process, but most of them were not relevant to translators anyway.

I’m already enhancing the messages.json with a hash value, so that I can soon display what messages have changed in the main locale, so that translators can easily spot the things to update.

Let me know what you think

2 Likes
#33

Another update:
Changes and missing entries are now marked as red bar on the right side of an edit field.

See: https://lusito.github.io/web-ext-translator/?gh=https://github.com/lusito/forget-me-not/tree/develop

Changes can now be submitted as a github issue (with a little work by the user).

Now it’s possible to apply the translations live in web-extensions that support it (using wet-layer).

My Web-Extension Forget Me Not is the first to support this kind of live-update, in case you want to see it in action.

I’m now using it actively in Forget Me Not and it looks like a good approach. I already got 5 new translations. I’ll keep you posted on how this affects my user statistics.

Other extension developers have started to show interest. There are still some issues to work out, but so far I’m happy with the results.