minetest
Builtin: Convert TR files to gettext PO
This PR converts the TR locale files in builtin to gettext PO to make them easier to work with in the future.
How the files were converted
The conversion was automated using the Luanti Translation Tools https://codeberg.org/Wuzzy/Luanti_Translation_Tools, using a two-step process:
- Update TR files with
ltt_update.py(to start with a consistent base; many TR files only had 2 strings, also a new string arrived: "DM sent to @1: @2") - Convert files with
ltt_convert.py(0.2.1)
All *.tr files and template.txt are deleted, in favor of *.po files and the *.pot file. Yes, changing the file format was literally enough, no code needs to be touched. :-)
How to test
- Start Luanti in any langauge that builtin supports
- Test the game if the translation of builtin stuff works (chat commands, etc.)
- Test if it works in online play, too
Open questions
Please check the special header at the beginning of each PO file and the POT file.
In particular, I wonder what we should fill into Report-Msgid-Bugs-To. This is where people should report bugs in the source strings. If I remember correctly, this is for an e-mail address (The xgettext manpage makes it seem like it). But other projects seem to have filled in an URL. So I wonder if we could just get away by filling in an URL to the issue tracker instead.
Future work
Once this PR is merged, this unlocks the following benefits:
- All the benefits of the gettext toolchain
- Can upload builtin locale files to Weblate
- Can introduce plural forms support. I’ve found 5 strings that would benefit from this. I’m ready to post another PR after this one
- Can add translator comments
Won't this cause builtin translations to stop working for clients 5.9.1 and older?
Idk, I don’t know about the internals. But I fear for the worst … It seems the most reasonable assumption because the old clients only "speak" TR. As I said, this PR touches no code.
Damn, that’s really unfortunate. So we’re stuck with TR forever (or until 6.0.0)? Meh …
Maybe a (crappy) solution would be to redundantly generate the TR files from the PO files right before each release, but with a big giant ALL-CAPS warning on top of each TR file that these files were generated. It would work, I guess, but it's redundant (needs to be tested to be sure tho).
Another solution that avoids redundancy could be that Luanti generates TR text on-the-fly for the old clients; not sure if the extra code is worth the effort.
A small downside of both workarounds would be that we lose plural-forms support again; I guess that’s unavoidable until we decide to drop old client support :-/
But at least we’d reap the benefits of Weblate, which is the main reason for this PR.
Won't this cause builtin translations to stop working for clients 5.9.1 and older?
Given that Debian is moving to 5.10 soon it is IMO acceptable to break older clients once Debian 13/trixie is released.
(Note that we unfortunately shouldn't use plural forms yet because #15518 was only fixed in 5.11, but this should not prevent us from first transitioning to PO files.)
Maybe a (crappy) solution would be to redundantly generate the TR files from the PO files right before each release, but with a big giant ALL-CAPS warning on top of each TR file that these files were generated. It would work, I guess, but it's redundant (needs to be tested to be sure tho).
Another solution that avoids redundancy could be that Luanti generates TR text on-the-fly for the old clients; not sure if the extra code is worth the effort.
Some years ago I wrote this simple script (i.e. it is "good enough" for what I needed) for Advtrains to convert PO files to TR files at init time. Although IMO such a script belongs (if possible) to a separate mod instead of builtin.
Just to clarify: Is this a "WONT ADD"?
If yes, it should be closed. If compatibility with 5.9 or other versions is important, I’m afraid I can’t do anything about it in the short term.