Creating a web-extension i18n tool

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