Extract lang/po to a git submodule

[BrettDong]

Put lang/po to a separate repository and make a bot (can be a GitHub Action workflow in the subrepo) to automatically synchronise (pull) translations from Transifex and commit to lang/po repo daily.

Pros:

• Users who don't need multi-lingual support doesn't need to download language files
• Users who need multi-lingual support can always have up-to-date translations
• Shorten the time of "translate this string first time -> player feedback -> correction/polish <-> player feedback" cycle
• I don't need to update translations manually every weekend
• No longer needs the -dirty hack in Makefile to suppress changes in lang/po folder causing -dirty suffix in the version string, because currently automatic translations synchronization is done on Jenkins build server when building experimental versions:

1. Checkout master branch
2. Pull current translations from Transifex
3. lang/po are modified in the working tree so there is a -dirty suffix
4. Cannot commit these changes or commit hash in the version string will differ
5. This is suppressed by a hack in Suppress dirty flag on changes in lang/po #46937
6. Compile and make bundle

Cons:

• Will need to update build process

[anothersimulacrum]

Maybe not as relevant here, but here's some past discussion on submodules. #43986 (comment)

[Qrox]

Even if lang/po is moved to a submodule, we still need to periodically update the refered submodule commit in the main repo, either manually or using a bot, so apart from the advantage of making downloading the translation files optional, it's not so different from just creating a bot that periodically pushes (or PRs) the new translation files to the main repo.

The best I can think of that resembles what you want to accomplish with a submodule is to create an orphaned i18n branch to which a bot periodically pushes new translation files, and when building the game, copy the files from the i18n branch (without checking out the branch). The files may be added to .gitignore of the master branch to prevent the -dirty problem. The i18n branch doesn't have to be checked out by anyone but the bot so the possibility of messing up the directory structure when switching branches can be avoided.

Pros:

• We can have fully automated updates to an independent branch from master that does not interfere with PR merging.
• We don't need to commit a submodule reference to the master branch.
• All of the pros mentioned in the OP.

Cons:

• People building from source have to pull the i18n branch along with the master branch, similar to having to pull a submodule separately.
• Some extra steps may be needed to ensure stable releases are built with the correct translations.
• I just came up with this idea on the spot so nasty unknown issues may arise.