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.

Well, first of all, you do not directly load any files with Gettext. Then, as far I understand, it's not the PO files which are loaded into memory, but the MO files (compiled PO files for better efficiency).The Gettext interface is basically just textdomain and gettext. I'm oversimplifying, of course, but there's no function to just “load a PO file”. The loading is probably done internally.I guess you are worried about memory leaks, right?I don't know exactly if Gettext ever unloads stuff. I hope it does. Maybe Gettext is clever and already does this automagically whenever needed. Since there's no way to explicitly unload stuff.Sadly, the official Gettext docs don't say anything about its memory usage.Probably the only way to find out for sure is too dig deep into Gettext source code or to ask Gettext developers.

Rewriting Gettext doesn't sound like a good idea. Talking to the Gettext devs would make much more sense. Our use case is quite an interesting and unusual one.

The problem isn't memory usage per se, but rather that translations specific to a server should be unloaded once the server is left. The translations also need to be loaded when the server is joined, and I never found how to do that, unfortunately. (I'm not even sure it is possible with the gettext API).

Okay then. So it’s a technical limitation. But why not take a raw PO files and manually parse them? Everyone creating translations would benefit from it because there are literally (and figuratively) hundreds of well documented and tested, widely supported and accepted, tools to create them.

I’m pretty sure it’s not specifically about passing a MO file to Gettext and have it processed (the technical side is important to core devs, of course, but why should mod devs care how the created translations are processed by the engine as long as it works as intended?) but about the missing tools to properly create translation bases from the code and the tools to write translations.

following the steps described here, I've translated two strings in minetest_game:https://0bin.net/paste/x-4gIQZ0fzdkSN0w ... pAhKNERtZiIf the mouse is in my inventory above a block the raising hint is still english. Is there any library needed?I've tested this with 0.4.15 on Debian and 0.4.16 on Fedora.

You have made the translation code way more complex than it has to be. Delete translator.lua, Minetest Game does not need this backwards-compability.And no, no library is needed.

I think your mistake was that you did not put the TR files into a directory named “locale”.

EDIT: I just realized this little fact was well hidden in lua_api.txt. >_>

Also, I like to warn you to not repeat the German translation which has already been done.Note the link is an unofficial translation and uses the superior PO file format used by Intllib. Whenver Minetest Game devs get around to implement this system in Minetest Game, I guess they will simply import these strings, which also means it will have to be converted to the inferior Minetest-only TR format. :-(

EDIT 2: OH! And of course this does not work in either 0.4.16 and 0.4.15. This is a feature in 0.5.0-dev.

Wuzzy wrote:You have made the translation code way more complex than it has to be. Delete translator.lua, Minetest Game does not need this backwards-compability.

This code was copied from the first Post of this Thread.viewtopic.php?f=18&t=18349Finally, if you want your mod to still be compatible with older versions of Minetest, you can add this at the beginning of your mod:

Wuzzy wrote:I think your mistake was that you did not put the TR files into a directory named “locale”.

Wuzzy wrote:You have made the translation code way more complex than it has to be. Delete translator.lua, Minetest Game does not need this backwards-compability.And no, no library is needed.

I think your mistake was that you did not put the TR files into a directory named “locale”.

EDIT: I just realized this little fact was well hidden in lua_api.txt. >_>

Also, I like to warn you to not repeat the German translation which has already been done.Note the link is an unofficial translation and uses the superior PO file format used by Intllib. Whenver Minetest Game devs get around to implement this system in Minetest Game, I guess they will simply import these strings, which also means it will have to be converted to the inferior Minetest-only TR format. :-(

EDIT 2: OH! And of course this does not work in either 0.4.16 and 0.4.15. This is a feature in 0.5.0-dev.

What are the plans with this? Will there be a system-independent toolchain to get and translate the strings and will there some sort of collaborative translation tools support?

Will the devs stay with this cobbled-together translation solution or will they use the superior PO file format (not gettext or all of it's features because this might not be possible currently, but the file format that then will be parsed and processed as needed to fit the current technical limitations) so all common translation tools can be used?