Never mind! No problem.
My tool is on npm now:
Not yet, sorry. I’ll post on this forum when things become tangible.
@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.
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.
- 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.
I also developed a concept of i18n like @Lusito but I chose a different approach.
- It is a web page (Github), so you don’t have to install anything and you can start translate within the browser.
- 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.
- 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.
Example on how I provide all the translation contexts for my extension
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.
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.
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.
I’ve just released an updated version that can be used online, can import from Github or ZIP file and exports ZIP files:
It’s also possible to enhance the editor with groups like in this example:
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