Giving mods special treatment and a different file format is unjustified and clunky

It seems you did not inform yourself about why a custom file format was chosen instead of gettext.

Additionally (quote):

In case you have a solution that allows to load dynamically gettext po files (and unload them again once one leaves the server), then I will switch to gettext asap. Without it, I can find no better way than having to recode gettext, which is way more complicated than what we currently have.

Do you have such a solution?

Don't get me wrong, there are good reasons to switch to the widely used .po format, but it's not as easy as it sounds.

Why not simply use PO files instead of compiled MO files and Gettext?

So both sides can have what they most want: Everyone creating mods and/or translations can have a super stable, widespread, and reliable toolchain and you devs can have weird plaintext parsing you seem to have a fetish for.

Nobody wants plaintext parsing, it's just that gettext does not expose the mechanisms needed to make it work for client-side translations.

Besides, parsing .po files is not enough. To get all gettext features such as plural handling you do need to reimplement gettext, which is -- as nore already said -- complicated.

Nobody wants plaintext parsing

Then all the plaintext parsing that happens in Minetest is there because …?

Besides, parsing .po files is not enough. To get all gettext features such as plural handling you do need to reimplement gettext, which is -- as nore already said -- complicated.

Then don’t replicate Gettext 1:1 but instead use the superior format and toolchain to get a PO file that then is used by the translation system instead of the stupid TR files that have no toolchain at all.

To me it’s not about the actual implementation but the workflow when translating stuff. And this is – of course – Gettext based because every more or less relevant project uses Gettext.

There are dozens and hundreds of tools, web services, and systems to get the untranslated strings, translate them, and return something (a PO file) that can be processed further (usually it is compiled to MO and then be used by Gettext, but that does not HAVE to be like that, the PO file can be used everywhere else).

Then all the plaintext parsing that happens in Minetest is there because …?

Go back to the forum post I linked above and read it again.

Then don’t replicate Gettext 1:1

????????

instead use the superior format and toolchain to get a PO file that then [...]

Yes I'm talking about that, doing that is complicated.

I'll say it again just in case: I am in favour of switching to gettext, but it's not easily possible at the moment.

Go back to the forum post I linked above and read it again.

You mean the part that basically reads “we use the format intlib once used before they switched to use PO files – but we don’t do that”?

And why cobble together and own weird system and not simply implement intlib?

????????

!!!!!!!!

Yes I'm talking about that, doing that is complicated.

Why exactly is parsing a PO file complicated? There are even parsers for the compiled MO files in plain Lua.

Can you please give a rough overview on how the client-side translations work in terms of network packets being exchanged between client and server?

I want to understand why there's a problem/difficulty.

You mean the part [...]?

No, I mean the part that says "gettext can't dynamically load and unload translations so we were forced to come up with our own system".

Why exactly is parsing a PO file complicated?

That's not what I said.
It's not, the complicated part is when you want to be 100% compatible to gettext (e.g. plural forms). Now if you only want similar functionaliry to intllib, that is doable.

Can you please give a rough overview on how the client-side translations work in terms of network packets being exchanged between client and server?

The gist of it is (for specifics ask nore):

• server sends translation files alongside media
• client loads the ones with correct language on startup
• when a translated string is found, the client looks it up (does substitution, etc.) and replaces it

I want to understand why there's a problem/difficulty.

The difficulty is not in the network protocol or what is sent to the client.
The difficulty is with what libgettext allows us to do, namely it can't (un-)load translations at runtime.

No, I mean the part that says "gettext can't dynamically load and unload translations so we were forced to come up with our own system".

Dude, you missed my whole point.

DO. NOT. USE. GETTEXT. ... Can't write it any clearer than that.

Use the PO file format so people can use their usual translation toolchain and do whatever is needed in order to provide translations as wanted.

I thought the whole point of this issue is that Wuzzy wanted gettext (the software) to be used.
In any case, supporting gettext (the file format) essentially requires re-implementing gettext, which is non-trivial and complicated.

I thought the whole point of this issue is that Wuzzy wanted gettext (the software) to be used.

Yes, but since Gettext can't be used easily it would be a good starting point to use plain PO files at least so the toolchain on user side (mod developers, translators, etc.) doesn't change.

In any case, supporting gettext (the file format) essentially requires re-implementing gettext

Then don't support 90 percent of the features then. Just plain strings with replacement variables. It is so inherently simple that even I was able to do it in plain Lua.

https://github.com/4w/xtend/tree/master/xtend_default/tools/convert_po_file_to_tr_file

But because of my Lua skills and willingness to completely dig into something stupid as this it does not support multi-line strings.

Yeah, I only care about adopting the PO file format, not about the exact implementation in Minetest.

I just found about this old (2007) code for parsing MO files: http://number-none.com/blow/code/mo_file/
I don't know whether it still works with the current gettext, but if it does, it would probably solve the current problems.

How easy would it be to modify gettext to expose or extract their file parser?

I couldn't make any sense of this thread here. There is something I might be missing in my understanding.
As for now I know intllib is implemented in many mods and it works, works as good as the former text translation (both lacking for dynamic loading).

Is it maybe the future plans to implement dynamic translation loading in future versions of minetest?
Which would be implemented with old format (because PO parsing is complicated?).

works as good as the former text translation

Works in the sense that a single language is forced on every single client on the server, yes.

dynamic translation loading

Suppose you join a server, it provides translation files for a certain mod, then you leave and join another server, which happens to provide a translation file for the same mod, but a different one.
Minetest needs to be able to unload the first translations after you leave, libgettext does not allow us to do this, which is why we aren't using it.

is it possible to sandbox libgettext to be able to reload it?

So basically to make this work, you actually have to write your own PO parser?
Ouch, now I understand why you are annoyed by this.

Maybe talk to the Gettext people about this. I still can't wrap my head around that you supposedly cannot unload catalogues.

Minetest needs to be able to unload the first translations after you leave, libgettext does not allow us to do this, which is why we aren't using it.

Besides, it seems like the other thing we need to do, loading translation files at runtime, is not possible either.

Is it possible to add basic support for PO files (without fancy features)?
So that it would be used same way as text files, but give developers/translators the chance to use the mighty toolchain ^^

This will require a very basic loader for PO files.

Is it possible to add basic support for PO files

inttlib does exactly that.