Add a job to automatically update translations

[ekohl]

This job runs weekly (or explicitly manual). It lists the languages in a way that GitHub Actions can reuse it in a matrix. Then for every language it updates the translations and creates a PR in a branch for every language.

I believe it doesn't create a PR if it's up to date, but I'm not certain.

Example outputs (disregard the unrelated commits):

• https://github.com/ekohl/tutorial/runs/8251377015?check_suite_focus=true (the actual run)
• Update bg translations from Crowdin ekohl/tutorial#3
• Update cs translations from Crowdin ekohl/tutorial#4

[ekohl]

This job runs weekly (or explicitly manual).

I changed my mind. Let's start with explicitly manual first and then move to cron.

[ekohl]

Note that this removes any commits in update_translations and rebases it back to master. So this isn't good if you want to work on the branch.

[das-g]

For automatically scheduled PR, I think we'd want to only consider languages for which the translation of Crowdin is complete (=has 100% "translated" coverage). For languages not marked "(beta)" in our language overview, we might even want 100% proofread on Crowdin.

[ekohl]

I think we can use an input to select beta or non-beta. However, I have found that the codes we use do not map straight to the codes on Crowdin. For example, where we use zh, the project code on Crowdin is zh-CN. Similar, pt is pt-PT.

[ekohl]

@das-g I'm leaning to maintaining a langs.json file. We can also write a simple converted to generate LANGS.md based on it. That avoids parsing and allows the additional metadata of the exact code. Thoughts?

[das-g]

Similar, pt is pt-PT.

Are you sure?

tutorial/LANGS.md

Line 15 in 50d6da3

* [🇧🇷 Português-brasileiro](pt/)

seems to indicate our pt corresponds to pt-BR. IIRC, the efforts to translate the tutorial to pt-PT, too, are more recent and the result hasn't been released, yet.

I'm leaning to maintaining a langs.json file. We can also write a simple converted to generate LANGS.md based on it. That avoids parsing and allows the additional metadata of the exact code. Thoughts?

As soon as we have two variants of the same language, we should probably switch to the language variant abbreviations (that's what Crowdin seems to use) instead of the language abbreviations for our directory names, anyway. But yes, it makes sense not to have to parse (beta) out of a markdown file, so having that information in JSON and generating the Markdown file might be a good idea.

[ekohl]

I found that https://crowdin.com/backend/download/project/django-girls-tutorial/pt.zip is a 404. See https://github.com/ekohl/tutorial/runs/8251377015?check_suite_focus=true (ignore en, I skipped that explicitly).

[matthieugouel]

Hey, I recently came across Crowdin and added some translations.

I see from Crowdin contribution page that people frequently make some translations here and there.
I'm trying to understand how the work on Crowdin is merged on the repository. Do you do manual PRs from time to time? I quickly looked at the recent commits and didn't seem to see that so I was wondering if the Crowdin project was still used (before I spend some time on it).

[ekohl]

AFAIK right now people submit PRs manually. AFAIK CrowdIn has some GitHub integration, but we don't have that enabled. The intent behind this PR was to start submitting PRs automatically so maintainers only need to press the merge button.