Client-side translations
Re: Client-side translations
Well, basically, that would be as much work as parsing the po files. The question is, how to do this without rewriting gettext?
- Wuzzy
- Member
- Posts: 4804
- Joined: Mon Sep 24, 2012 15:01
- GitHub: Wuzzy2
- IRC: Wuzzy
- In-game: Wuzzy
- Contact:
Re: Client-side translations
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).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.
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
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).
- Linuxdirk
- Member
- Posts: 3219
- Joined: Wed Sep 17, 2014 11:21
- In-game: Linuxdirk
- Location: Germany
- Contact:
Re: Client-side translations
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.
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
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.
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.
- Wuzzy
- Member
- Posts: 4804
- Joined: Mon Sep 24, 2012 15:01
- GitHub: Wuzzy2
- IRC: Wuzzy
- In-game: Wuzzy
- Contact:
Re: Client-side translations
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.
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
This code was copied from the first Post of this Thread.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.
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:
Please check my diff file:Wuzzy wrote:I think your mistake was that you did not put the TR files into a directory named “locale”.
+++ 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)
Last edited by Chris on Wed May 16, 2018 08:03, edited 1 time in total.
- Phoenixflo44
- Member
- Posts: 639
- Joined: Fri Jul 28, 2017 15:01
- In-game: EvilPhoenix
- Location: Behind my PC, in Germany
Re: Client-side übersetzung
Finally you have everything you write down in your own language.
You did well.
Greeting Phoenixflo44
You did well.
Greeting Phoenixflo44
Spoiler
I hate my life
-
- Member
- Posts: 58
- Joined: Wed Aug 03, 2016 08:09
- GitHub: SlackCoyote
- In-game: SlackCoyote
Re: Client-side translations
Wow, how germans are so fast translating.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.
Slackware64 14.2, MT 0.4.16. My best mod.
- Linuxdirk
- Member
- Posts: 3219
- Joined: Wed Sep 17, 2014 11:21
- In-game: Linuxdirk
- Location: Germany
- Contact:
Re: Client-side translations
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?
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?
Who is online
Users browsing this forum: Bing [Bot] and 8 guests