Page 3 of 3

Re: Client-side translations

Posted: Fri Feb 02, 2018 22:18
by Nore
Well, basically, that would be as much work as parsing the po files. The question is, how to do this without rewriting gettext?

Re: Client-side translations

Posted: Fri Feb 02, 2018 22:46
by Wuzzy
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.

Re: Client-side translations

Posted: Fri Feb 02, 2018 22:55
by Nore
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).

Re: Client-side translations

Posted: Sat Feb 03, 2018 13:22
by Linuxdirk
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.

Re: Client-side translations

Posted: Tue May 15, 2018 10:06
by Chris
following the steps described here, I've translated two strings in minetest_game:
https://0bin.net/paste/x-4gIQZ0fzdkSN0w ... pAhKNERtZi
If 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.

Re: Client-side translations

Posted: Tue May 15, 2018 13:04
by Wuzzy
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.

Re: Client-side translations

Posted: Tue May 15, 2018 14:10
by Chris
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=18349
Finally, 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”.
Please check my diff file:

+++ default/locale/default.de.tr 2018-05-11 09:44:59.671014622 +0200
@@ -0,0 +1,4 @@
+# textdomain: default
+
+Stone=Stein
+Cobblestone=Pflasterstein

The full path is /home/chris/.minetest/games/minetest_game/mods/default/locale
The name of my file is default.de.tr (as discribed in the initial post)

Re: Client-side übersetzung

Posted: Tue May 15, 2018 18:00
by Phoenixflo44
Finally you have everything you write down in your own language.
You did well.

Greeting Phoenixflo44

Re: Client-side translations

Posted: Wed May 23, 2018 10:02
by Reedych
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.
Wow, how germans are so fast translating.

Re: Client-side translations

Posted: Fri May 25, 2018 16:33
by Linuxdirk
The last official statement was ~4 months ago.

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?