Automate import and export of translations from/to Weblate

[Ortham]

Weblate uses the message text strings in the translations directory, but LOOT uses the strings in prelude.yaml. There are a couple of helper scripts in scripts that can convert between the two, but running them is currently a manual process that needs to be done after changes have reached the default branch (currently v0.21).

Ideally the process would be fully automated, so that:

• an update to prelude.yaml triggers the export translations script to be run and any changes committed to the branch that the update is on (so if the update is pushed straight to the default branch, so are any export changes, but if the update commit is in a PR then the PR branch gets the export changes)
• if Weblate opens a PR containing changes to any files in translations, that triggers the import translations script to be run and any changes committed to the PR's branch. It might also be worth then running the export translations script as Weblate appends new translations while the export script outputs translations in lexicographical anchor order.

A starting point could be to implement GitHub Actions workflows that can be run manually, one for import and one for export, so that no local env is required and the only manual action needed is a button press.

[Ortham]

I've managed to get an import workflow working that is triggered on PRs opened by a certain user and will import-then-export translations and commit the results to the source branch.

Unfortunately this only works if the GitHub Actions app is given write repository permissions, so a PR could provide untrusted code that uses that access maliciously. At the moment I'm only allowing the job to run for PRs opened by my own user, but I need to work out a way of allowing GitHub Actions to push to the source repo without giving write access to this repo.

Alternatively, I could try chaining workflows with different permissions as described here.

[Ortham]

I took the chaining workflows approach and it looks like that's working now, see PR #74 for an example of it in action.

I've changed my mind slightly on the export translations flow: if a change to prelude.yaml is pushed to the default branch, I don't think that should add another commit to the branch, in case the export mangles something. Instead, I think it should open a PR and push to that branch, so that it can then be reviewed.

[Ortham]

I've found that if a workflow that triggers on pull_request adds a commit to a PR, that doesn't trigger any other workflows to run that would otherwise run on the PR. However, if I then

For example:

• import-translations is triggered by changes to translations and changes prelude.yaml
• export-translations is triggered by changes to prelude.yaml and changes translations

If import-translations runs on a PR and results in a commit getting pushed to the PR, that doesn't trigger export-translations to run. However, if I then make an unrelated change (e.g. to the readme) and push that, both workflows run because the PR now contains changes to both prelude.yaml and translations. That time around, import-translations has no effect because the translations were already imported, while export-translations would update the translations.

Based on that, I think it's best for import-translations to keep doing the import-then-export that it currently does, rather than relying on export-translations to do the latter.

---

In the auto-export branch I've got a workflow that will run for all PRs that modify prelude.yaml. It'll do nothing if the PR is from Weblate, but otherwise it will export the translations from prelude.yaml and if there are any changes it will then push a commit containing those changes to the PR.

As this would affect PRs coming from people, it could be confusing and unexpected for them to receive commits, so I'm not really sure how to proceed.