Fix: Consistently use settings.AUTH_USER_MODE in all languages

[adamantike]

settings.AUTH_USER_MODE was already being used in many languages, but not all of them. This PR changes the pending languages still using the old way to reference the User model.

[das-g]

We maintain translations on Crowdin. Can you also make these changes there?

(I'm probably going to merge this PR as a quick-fix, but if it isn't changed in the translations on Crowdin, the problem would be re-introduced when we next update a translation from there.)

[adamantike]

@das-g, for code snippets, do you think it'd be simpler to maintain if they were hidden in Crowdin, so the original (English) copy is always used? https://support.crowdin.com/enterprise/common-questions-managers/#how-to-hide-a-string-from-displaying-in-the-editor

[das-g]

do you think it'd be simpler to maintain if they were hidden in Crowdin, so the original (English) copy is always used?

I'm unsure about that. Not all of our translations are updated as frequently as the English original. Having a translation show old and new content that may be inconsistent to each other might be very confusing.

On the other hand, it's also confusing when a multi-lingual user switches between translations and gets different information in different languages.

Ideally, all of our translations would always be completely up to date, but as all of our translations are done by volunteers (just like maintenance of the tutorial itself), that's probably not something we can achieve without removing languages from the published tutorial as soon as the respective translation falls behind, which also wouldn't be very nice.

[adamantike]

In that case, would enabling Crowdin's GitHub integration be good to improve the feedback loop for translators, while also having Crowdin as the source of truth for language folders besides en/?

Being completely new to this codebase, I was a bit confusing when reading the Readme:

Crowdin platform is used to manage translations. If you want to join an existing translation team or launch a new translation, send an email to the translation managers or contact support team. If you want to propose some small changes or fix typos in existing translations, please create a Pull Request.

Specifically about:

• When and how are translation fixes made in Crowdin reflected in the repository?
• Which changes are allowed to have a Pull Request when the affected files are in language folders?
• As part of the previous one, should changes to those language folders fail during the CI? Or should the folders be moved to a root folder like autogen/?
• If any of those decisions take place, a clearer way on when you need to fork the repo, and when you can just make the change in Crowdin would be really useful.

[das-g]

In that case, would enabling Crowdin's GitHub integration be good to improve the feedback loop for translators, while also having Crowdin as the source of truth for language folders besides en/?

I think we already use that integration of en/ on GitHub → Crowdin original (to be translated).

For the other direction, we AFAIK had the problem, that it will sync all languages without any regard whether they've been proofread. But maybe more fine-grained control over the automation is possible by now?

[das-g]

Being completely new to this codebase, I was a bit confusing […]

Yeah, I was/am confused, too. See #1271

While @magul has shared what he was and is doing w.r.t. this, nobody defined what we should be doing.

[…] when reading the Readme:

Crowdin platform is used to manage translations. If you want to join an existing translation team or launch a new translation, send an email to the translation managers or contact support team. If you want to propose some small changes or fix typos in existing translations, please create a Pull Request.

Let's change that, as it doesn't reflect our current practices. #1755

Specifically about:

* When and how are translation fixes made in Crowdin reflected in the repository?

Usually when the respective language reaches (or re-reaches after the English original has changed) 100% translated (for "beta" translations) or 100% approved (for non-"beta" translations).

This happens exporting the respective translation from Crowdin and making a pull request with the content thus acquired. This is usually done by @magul, but doesn't need to be limited to him. Those PRs also get reviewed. Depending on the language and reviewer availability only for sanity checks (Is the markup still valid and reasonable? Did Crowdin mess up anything?) or also again for proofreading (in-context sometimes some translation mistakes not apparent when translation individual sentences will be noticed).

* Which changes are allowed to have a Pull Request when the affected files are in language folders?

I'd say

• Changes that change only the English original.
• Changes that are trivial to translate (or adopt in the translations) when the English original is also changed accordingly. (As we can expect the translation in Crowdin to make the same change anyway, if/when it ever gets updated. Changes that can reasonably be translated / adopted in more than one way should however be made to the English original only, so that translation changes in the repo and translation changes on Crowdin don't diverge into different directions.)
• Changes bringing in the current version of a translation from Crowdin as per above.

* As part of the previous one, should changes to those language folders fail during the CI?

How then would be bring in changes from Crowdin?

Or should the folders be moved to a root folder like autogen/?

That's something we could probably do, if we adapt our continuous delivery to cope with that.

* If any of those decisions take place, a clearer way on when you need to fork the repo, and when you can just make the change in Crowdin would be really useful.

I hope that for our current process #1755 already improves on that. For what the process shall be in the future, please discuss in #1271.