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.