^{Originally posted by ignotus666 July 26, 2022}
@jamulussoftware/maindevelopers @jamulussoftware/translators

In #2675 the use of Weblate for translations was proposed. It basically means moving the translation process to an online tool where translators can login, do their work, and need not worry about using GitHub, PRs, forks, etc. as Weblate can be configured to take care of that, removing what is often a big barrier. If you’ve never used GH before and are not technologically minded, just reading through the TRANSLATING.md file is enough to make you faint. With Weblate, that document could practically be reduced to “Log in to Weblate, click on a doc and translate it. The End”. If for whatever reason a translator prefers to continue using the current workflow, there is nothing stopping them – no one would be forced to use Weblate.

So far the response by translators to the proposal has been positive. However, such a move would involve some changes on the admin side, mainly:

• PRs would arrive by doc, not by author/language. For the app, this would mean all translations would go into the same PR (unless they are merged as they arrive, though this could still mean more than one language in the same PR).
• Language reviews should preferably happen on Weblate. They could theoretically take place on the PR here, but it'd be better if the language could be corrected before getting to that stage - and less complicated for translators.
• As @BLumia commented:

we'll need to pay more attention to the source strings that contains arguments (e.g. "About %1") and make use of the 2nd disambiguation argument in QObject::tr() to tell translator what's the argument means, since unlike using QtLinguist with full source code fetched, the translation platform won't show the related source code in the translation page.

• Preferably, the .nsi files should also be included, but that involves creating .po files for them. The question is, where should these .po files live and what process do we follow to reconvert them into .nsi files? There is already the po4a script 'infrastructure' for doing these conversions on the website repo. Could they live there and we push the converted files from there to the main repo?
• … possibly other stuff I can't think of now.

All in all, this would vastly reduce complexity for (in particular new) translators, but would require some changes, mainly on the main repo. For the website repo, aside from how PRs are submitted, it would be quite seamless. An option could be to first use it for the website docs and over time include the app stuff (and meanwhile explore in more depth the best way to go about it).

BTW: In order to qualify for free hosting, one the requirements is that the main devs give the go-ahead to use Weblate. I'm not sure how that happens but saying so on this thread (so it can be later linked back to) might suffice. Once the project has been created, we have 14 days to actually set it up - and once that's done we submit a request for libre hosting.

Anyway - please share your thoughts, questions, etc.