jamulussoftware
Using Weblate for translations
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.
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?
Not a fan of mixing App related stuff in the website repo. We could probably re use it, but probably it would be better to have them at a shared place. Other repo, …
BTW: In order to qualify for free hosting, one the requirements is that the main devs give the go-ahead to use Weblate.
I‘d certainly be ok with that even though it might mean a change in the workflow and maybe the release process.
Ok, so I've gone ahead and created a Jamulus project on Weblate here. The app files have not been added, only the website files are there for now. It will be in trial mode for two weeks; we have within that period to request libre hosting, but before I do so I'd like to get the thumbs-up from all the main devs if possible. These are the requirements (I don't think we have any problem meeting them):
Translated content has to be released under a license approved by OSI or recognized as libre by FSF. All the source code has to be publicly available in a supported version control system. Translations have to be in the same repository as the source code, or under the same project/organization as the source code repository. Using Weblate has been approved by the upstream project. Mention you use Weblate for translations in the README. It’ll attract new translators and also help Weblate to be free for more projects. The project has had active development for at least three months.
Also: we have to enable a webhook on the repo so Weblate can keep files updated. I can do that but just so you know. Some READMEs describing the translation process would also need updating (pretty much simplified, I hope).
@jamulussoftware/maindevelopers vould you please approve/comment on the use of weblate? They need our OK.
Oooh, it'll make reviewing things easier if the reviewer is allowed to mark things like the {% include_relative Include-Shared-Commands.md %} strings as not requiring translation. Then the (real) untranslated bits will stand out.
(Interestingly, the default is that Dismiss failing check is granted to the Translate role.)
Can the project be "Protected" whilst in "demo mode"?
I guess it'll take a little readjustment for those familiar with the existing translations process to get acquainted with the new UX but it looks pretty nice to me (as I won't have to start installing a bunch of tools to make reviews easy).
(That's a "Yes, subject to it being as good as it initially looks.")
I don't think strings can be marked as "non-translatable" in .po files other than via a comment that has to be added to the relevant string (it can be done to any language in Weblate and the comment is visible in all other languages). In any event, I don't think this has proven to be an issue up until now - translators have generally managed to identify strings that do not require translation.
The checks are informative and do not actually block a translated string from getting published. They can be customised by adding/removing them from a list or by creating your own. I haven't really explored them that much but I think it can be potentially interesting.
Can the project be "Protected" whilst in "demo mode"?
I've locked it while things get set up. Hadn't found that before ;)
I think the main advantage is the removal of all the GitHub kerfuffle for translators. The UX is like Poedit on steroids but fairly easy to get used to. A thing to watch out for I think is how easily (or not) conflicts arise and how to pace merges of PRs coming in from Weblate. It kind of encourages a "rolling release" model where translators log in and work away at stuff at their own pace - unless we lock it in between freezes.
There was talk recently about a website update at some point in the near future - it would be a good chance to test it out.
@ignotus666 Thanks for leading this effort! I'm OK with it, so YES for Weblate from me as well.
Personally, I hadn't heard about Weblate before. I'm always a bit skeptical about introducing more reliance on "free" services (we already rely heavily on Github, of course), but I guess it's fine in this case as other notable Open Source projects do rely on Weblate as well. It also seems that multiple active translators do like that change so I guess it's mainly their votes which should be heard! :)
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.
Such a fall back or secondary path is always good to have. :)
This seems to be my cue to start a pt_BR for website as well :) Looking forward for it BTW, I'm already watching the project there. Just waiting for the notification get started.
There's just a couple of things that need doing first (didn't have time today...) and then we should be good to go.
@melcon that would be great! Also to test how adding a new language works out with weblate - make sure you open an issue first as explained here. Just open the issue and disregard everything about forking and PRs as that shouldn't be needed any more... hopefully!
@ignotus666 I think the only problem I see with the PR from Weblate is that our E-Mails are exposed now. I think that should change - we might want to open an issue on the weblate repo.
Actually, there's an issue on the weblate Repo: https://github.com/WeblateOrg/weblate/issues/6508
Yes. While that gets addressed by weblate, maybe we could have a script that deletes that line or replaces it leaving the email empty. It'll still be there in the commit history though...
It'll still be there in the commit history though...
Unless we do nasty force-pushes...
Does this "big" issue still need to be open or can it be closed as "done" and any problems with Weblate addressed separately / through discussions / other channels?
I think it should probably stay open until we have set up weblate for the App too?
@ignotus666 would you say it’s feasible to set up weblate for the app repo too?
I've set something up, but it still needs some investigation
Looks nice to me. Guess we need something for the windows installer as well.
Ok. Windows installer is also set up partly. We might need to rename the .nsi files to fit to some standard.
@ignotus666 I think now I know why I'm still not 100% happy with the commit message on the website: It should follow imperative style: "Update language web translation from Weblate"
See https://www.theserverside.com/video/Follow-these-git-commit-message-guidelines
Do it for 'Index-1' and I think it will apply to all of them as it's the "parent" component.
Edit: oh wait, that'll change the PR message for all of them, but I'm not sure if it'll work for commit messages.
We also have to look at why it forked from my repo. We might need to merge what we have, delete the component and try again.
I'm going to all components and change the commit message manually now. For the other problem, yes, probably that's the easiest way.