Investigate using Weblate for translations

[Ortham]

Raised by sibir in Discord here. It looks like it would reduce the barrier to entry for translators, but we need to work out how it would integrate with this repository. Weblate does support gettext, which is what LOOT uses.

I wouldn't want to require that translations go through Weblate, i.e. it should be possible to make changes to translations in Git and in Weblate without issues (aside from potentially conflicts if you edit the same lines).

[Ortham]

I've created a project for LOOT on Weblate. I'm still in the process of setting it up, but:

• I've set the license to the Creative Commons Zero v1.0 Universal, for similar reasons to why we relicensed the masterlists to the same license. Also because if Weblate encourages more "drive by" translation contributions, if they contributed under the GPL having to track down the authors years later if we need to (like we did for the masterlists) would be even more difficult than it was for the masterlists. This does not change the license of the existing translations, but I think that relicensing them would also be a good idea, so I'll probably create an issue to track that.
• The version control system is set to "GitHub pull request", so hopefully translations will come through as pull requests rather than directly pushing commits. Perhaps once we have more confidence in the system that could be changed to be directly pushing commits if PRs seem like unnecessary overhead.
• The repository branch is set to master. I saw that Wrye Bash have their project set up with a dedicated branch for Weblate, we might want to do something similar.
• Push on commit is enabled, and commit happens 24 hours after changes are made.
• The merge style is rebase to keep history clean, but we may want to change this.
• The LOOT component is configured to be locked on repository errors (I think that refers to Weblate's repository).

I've noticed that Weblate checks strings for various things, and there are many errors:

The punctuation spacing errors seem to be false positives due to the format string placeholder syntax, so it looks like I'll need to configure Weblate to recognise that. There may also be other false positives, I haven't gone through the lists of failing checks.

[RacerBG]

Could you also disable the reused translations check?

[Ortham]

Could you also disable the reused translations check?

I'll look into it, if it's complaining about the message being the same as English then I think it would be better to just leave that translation out, as if there's no translation for some text it'll just use the original English anyway.

---

Capturing other input from Discord:

• IllusiveMan, RacerBG and 3v recommended using a manual review process on Weblate, as some translations they've seen there are not good, bordering on destructive. There's a setting for enabling reviews.

[Ortham]

I've configured the Weblate webhook in this repository, enabled reviews in Weblate, and added placeholders:r"{\d+}" to the LOOT component's translation flags to hopefully stop Weblate complaining about the placeholder syntax, as it doesn't support Gettext's relatively new c++-format flag.

[pStyl3]

I'll look into it, if it's complaining about the message being the same as English then I think it would be better to just leave that translation out, as if there's no translation for some text it'll just use the original English anyway.

I would advise against leaving out translations if the translation is the same as the English one. Not only wouldn't the translation progress be able to reach 100% that way, it also is helpful to make a statement, that "yes, the translation is indeed identical to the original, it is exactly right this way". That information is sort of not given, if the translation has been removed. Also future translators might think that they need to add the translation back in.

[Ortham]

Right, that makes sense where the translated text is unchanged, I was thinking about if we've still got any cases where untranslated text was just copied across (I think that has happened in the past?).

[pStyl3]

Might be, though I can't recall any specifics in that regard right now. I'll look into it later in the evening.

[Ortham]

I've hooked up translation of the Inno Setup custom messages to Weblate. This required the custom messages to be split out into separate files (which Weblate requires all translation formats to do) and to simplify the non-Weblate translation flow the English strings appear in all translations where there's not a translated string, so that the message names appear in all translation files (as just having Name= causes Inno to display a blank string).

I've gone through the strings in Weblate and approved those that are translated and marked those that are just copies of the English strings as needing edits.

---

I've also had a look at if we could use Weblate for translating the prelude, and:

• The prelude format is not one that Weblate understands
• As mentioned, Weblate needs each language's translation in a separate file

Adopting an existing translation file format is out of scope for this ticket, so we can't use Weblate to translate the prelude directly, but I think it's possible to use it to replace the Google spreadsheet that we currently use to manage the prelude translations. The way that would work is that we'd have a similar setup to how the installer translations now work:

• A translations folder (name TBC) that holds one file per language, e.g. translations/messages.en.yaml.
• Each translation file would be a YAML file that contains a map of message IDs to translated text strings. We could use the anchor names in the prelude as the IDs to make them obvious. E.g. alreadyInX: Delete. Already included in {0}. for English.
• When these translation files are changed (through Weblate or otherwise), we'd need to manually update the strings in prelude.yaml to match.

@pStyl3 does that sound like a worthwhile improvement over the current workflow?

EDIT: I've created loot/prelude#65 and the Prelude component on Weblate to demo this approach.

[pStyl3]

I've registered myself an account on Weblate now. While I'm new to Weblate and as such am still learning how it works, the suggested changes regarding the Prelude should have the following effects:

• No longer the need to manually manage the access/edit rights of the Google Spreadsheet
• In the Google Spreadsheet it was always necessary that after a translator added some translation(s), that they informed me directly about this circumstance. If they didn't, it could've happened that the new translation wasn't noticed for quite some time, as I can't check every day all of the different sheets of the document (one per message anchor). There's no easy way to have that information in one sheet (there was in the Excel document, but that's only an offline document), and even then there was no automatic notification for me, that someone had changed something within the document. If weblate automatically informs us about changes being made, through PRs against the prelude repo on GitHub for example or otherwise, than this should be a definite improvement.

Overall, strictly spreaking about the weblate adaptation for the prelude, the proposed workflow still seems a bit clunky, as there will still be the need to manually sync translations between prelude.yaml and the different files in the new translations folder. If someone uses weblate to translate some missing string, we will need to add that to the prelude. And if someone adds a translation to the prelude, we then will need to add that to the individual file in the translations folder.

That being said, with weblate the workflow seems to be a bit less clunky as with the Google spreadsheet, so I'd say we should try to implement it and see how it goes.

[Ortham]

@pStyl3 I've invited you to the Administrators group for the LOOT project on Weblate.

It might be possible to have a script that syncs between prelude.yaml and the Weblate translations files, and have that run by a pipeline that's triggered by commits, but that's complicated enough that it might not be worth it.

For now, I'll continue with that PR for the prelude.

[pStyl3]

@pStyl3 I've invited you to the Administrators group for the LOOT project on Weblate.

Thanks, I've accepted the invitation.

[Ortham]

Unfortunately I can't find any YAML parser that will give access to anchors or round-trip them and comments, so automatically updating the prelude is probably not feasible. I did write a script to extract the strings from the prelude using regexes, but it does make assumptions about the layout of the file and its formatting, so I don't think it would be a good idea to automate applying that script.

The script assuming that messages are single-quoted did help me spot one Danish translation that was incorrectly quoted (it was using double quoted but had a '' inside it), and now Weblate and the spreadsheet are in agreement on what's translated and what isn't.

EDIT: I've also added a script for writing message text from translations/ to prelude.yaml.

[Ortham]

I've made some changes to the settings on Weblate, as strings that are "waiting for review" still get included in PRs to this repo. The relevant settings are:

• "Turn on suggestions" enabled (was already the case)
• "Suggestion voting" enabled (new)
• "Automatically accept suggestions" set to 0 (was already the case)
• "Enable reviews" disabled (new)

See this PR comment for the context.

Disabling reviews means that translations have effectively two states:

• Suggested translations are not committed and so don't appear in PRs made to this repo
• Otherwise, translations are committed and will appear in PRs made to this repo

I've created a second account that is not in the LOOT project to test the suggestions, and found some bizarre behaviour:

• If "Automatically accept suggestions" is 0, then the test user is able to save translations and apply and reject suggestions, despite the settings text saying otherwise:

  

• If I set "Automatically accept suggestions" to > 1, then the UI disables the save translation and accept suggestion buttons and shows a message saying "This translation only accepts suggestions, and these are approved by voting." for the test user. The admin user still has those buttons enabled and does not see that message. However, the test user is still able reject suggestions made by the admin user! It appears that the default team for all users is Users, which grants the "Power user" role by default (and that can't be changed on hosted Weblate), which adds many more permissions than you'd expect.

• The suggestion voting is just a single number that starts at one, an upvote increments it by one and a downvote decrements it by one, so there's no visibility (aside from reading through the history tab) about how many votes there were either way.

So:

• It's possible to restrict people not granted explicit access to only make, vote on and reject suggestions, but:
  • You cannot enforce that restriction without allowing suggestions with enough votes to be automatically applied (but you can set that threshold to something unachievable like 10000)
  • By default users can delete other users' suggestions and there's no way to disable that.
• On hosted weblate, every user is given the Power user role by default, and there's no way to downgrade their permissions from that. The power user role includes the following surprising permissions:
  • Add glossary entry
  • Delete glossary entry
  • Edit glossary entry
  • Upload glossary entry
  • Accept suggestion (can be suppressed by allowing automatic acceptance by voting)
  • Delete suggestion (that's why they can delete other users' suggestions)
  • Add language for translation
  • Dismiss failing check
  • Edit strings (again, suppressed by allowing automatic acceptance by voting)
  • Overwrite existing strings with upload (again, suppressed by allowing automatic acceptance by voting)
  • Upload translations (again, suppressed by allowing automatic acceptance by voting)

Frankly, I'm amazed that projects on hosted Weblate aren't inundated with spam and abuse with such permissive defaults, and I'm now pretty hesitant to start using Weblate for LOOT and open myself up to dealing with that.