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