I wonder if there's any good reason the main OpenTTD binary can't simply load translations in text format itself. The compiled format has some advantages in loading time, but all the code to load a language file is basically already compiled in, since the language files for AI/GS are loaded from text format at runtime.

WT only knows master branch (used for nightly builds), so it may be very hard to get compiled lang file for other versions from it.
Also the lang file you can download is only valid for master branch (most of the time it should work in other versions too unless some strings format differ in english.txt between master and other version).

I wonder if there's any good reason the main OpenTTD binary can't simply load translations in text format itself.

Yeah, that would be helpful. The game could even auto-detect the format if provided manually or as .txt/.lng and load .lng as default if both are present.

WT only knows master branch (used for nightly builds), so it may be very hard to get compiled lang file for other versions from it.

While that's perfectly understandable, generally speaking translators only need two versions of the language file: one for the stable version and one for the latest development release. If WT could provide both, great. If not, the compiled version would still be useful for the latest beta/rc testing, especially as changes in locale support are uncommon.

This is basically a feature-request hiding as a bug :D

We have learnt over the years that making strgen available isn't any solution, and allowing .lng files to be downloaded via the translator tool is neither. It is very confusing to most users that they are tightly coupled to a version of OpenTTD; and the errors shown when you make a mistake are not really helping either.

A solution like @nielsmh is much more robust in that sense. I once also made a coupling between OpenTTD and the (now offline) WT3, where changes in WT3 would show up live in the game. It was a fun gimmick, but a lot of problems came from it (windows don't resize etc etc). In the end, it was not all that useful.

By classifying this as feature-request, and changing the title a bit, it allows for a broader scope of solutions. Hope you don't mind :)

PS: the flow I found easiest, to help in your workflow: changes you make are committed daily, and show up in the next nightly. So showing a friend to see if the translation is an improvement often means waiting for the nightly and ask them to validate that. It makes iterations a bit slow, but resolves all of these problems.
And as we publish nightlies to Steam, those using Steam can get the latest and greatest without any fuzz.

Not disagreeing that this can use some improvement btw, but just making sure you are aware of this process :)

If the game can load translations from the text format, then it won't be a (big) problem if the language file doesn't match the game version exactly, because there no longer needs to be a direct correspondence between the string ordering and such from the english.txt strings to the translated strings. Any mismatches are already detected by strgen and so it would be possible for text string loading in the game itself to detect those too, and ignore the problematic strings. (For example, wrong number/ordering of inserts.)

Another idea could be to include a tool in-game to help you find a problematic string in the translation data. Dream scenario would be, you see some poorly formed text in the game, point at it, and get the StringID(s) involved.

I guess the super-fancy solution would be to have a "run now" link on WT which launches an emscripten version with the current language (maybe as txt) injected into.