Client-side translations

User avatar
Linuxdirk
Member
Posts: 3216
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Client-side translations

by Linuxdirk » Post

Nore wrote:This is not a solution: strings in the translation file still need to use the numerical arguments.
Sigh ... Seems like the client-side translations are broken by design :(

Well then. Maybe at least make it so that newlines can be escaped and don't have to be real newlines. I guess that's the best we can get when it comes to client-side translations.

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Post

Linuxdirk wrote:Well then. Maybe at least make it so that newlines can be escaped and don't have to be real newlines. I guess that's the best we can get when it comes to client-side translations.
There is already a pull request doing that.

User avatar
Linuxdirk
Member
Posts: 3216
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Client-side translations

by Linuxdirk » Post

Is it possible to provide colorized strings as parameters for the variables?

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Post

Linuxdirk wrote:Is it possible to provide colorized strings as parameters for the variables?
Yes.

User avatar
Wuzzy
Member
Posts: 4786
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy
Contact:

Re: Client-side translations

by Wuzzy » Post

a: Sending "The value: @foo" and a table {foo = "the value"} in,and getting the translated "Der Wert: the value" out.
This sounds suspiciously similar to minetest.translate. I am confused.
b: Sending "An Item made of +x from +y" in, and getting "Ein Gegenstand aus +x von +y" out being able to use result:gsub('*.', {['*x'] = 'whatever', ['+y'] = 'something'}) with the return value of the translation value
Again, this sounds like what minetest.translate does for you, but with multiple parameters. I am still confused.
c: Not having to write the following to get a translation of a string with a line break:
OK, I agree this is indeed stupid.
As long as the translator has limited possibilities to actually translate the string the result has to be post-processed.
There is a fix and the fix is called Gettext. :D
This is not a solution: strings in the translation file still need to use the numerical arguments.

Sigh ... Seems like the client-side translations are broken by design :(
No, the system is definitely not BROKEN because of numeric arguments. There is nothing wrong with that, it's just a different syntax than the syntax you desire.
If we call the first argument “@1” or “@whatever” really doesn't make a difference to me.

I seriously don't understand why you make such a big deal about this. Not even Gettext has this feature, and I don't miss it.

I am a major translator of other software projects (including Cataclysm: Dark Days Ahead. If you know this game, you know the crazy amount of text). My voice definitely has weight here. From my years of work, I can tell you that, frankly, that “numeric parameters” were NEVER a problem to me. Actual string problems are very different, like string concatenation, etc.
unhandy, and limited, and non-standard
Unhandy: Yes, because the toolchain is missing. I talked with nore about that and nore agreed to fix this; probably by adapting the intllib toolchain or whatever (because the format is very similar).
Limited: Well, yeah. Having no proper plural support sucks.
Non-standard: I have to agree because it's not Gettext or any other widespread system (well, there aren't many, actually, the only other one which comes to mind would by Qt but this does not apply to Minetest, of course). I hope the switch to Gettext will be made eventually.

The switch to Gettext will fix all 3 of “unhandy”, “limited” and “non-standard” in one go.
Can I at least insert "@5@2@8@9@4@4@4@4" and get what I expect (having @N replaced with the corresponding value, multiple times, mixed)?
I don't know, I haven't tested it. I only tested whether a different order from the original works (and it works). But why don't you test for yourselves? This is a valid use case. If it doesn't work, I'd consider it a bug.

User avatar
Linuxdirk
Member
Posts: 3216
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Client-side translations

by Linuxdirk » Post

Wuzzy wrote:I am confused.
Ever used gsub()’s awesome table-based replacement functionality? You define what to search for and provide a table to replace the matches with the values. In the example the search string is a literal+ directly followed by one or more letters from a-z. It allows for named variables of all types. It does not crash, it is unlimited.
Wuzzy wrote:I hope the switch to Gettext will be made eventually.

The switch to Gettext will fix all 3 of “unhandy”, “limited” and “non-standard” in one go.
Plus: You’ll get an already established and widely used toolchain, and thus maximum acceptance, a shit-ton of already accepted collaborative translation tools, a rock-solid translation format, and the best problem support possible when it comes to translations.

Right now we have a weird key-value store and a conversion script (at least I have, because I wrote it by myself) to use a PO source and convert it to a TR file.

User avatar
BrunoMine
Member
Posts: 1082
Joined: Thu Apr 25, 2013 17:29
GitHub: BrunoMine
Location: SP-Brasil
Contact:

Re: Client-side translations

by BrunoMine » Post

How does derived language detection work?
For example, if my client is in "pt-br", but some server mods have only "pt.tr" and "en.tr". In that case, the translation will be pt or en?

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Post

For now, derived language detection needs to be exact. Thus, the server needs to provide "pt_BR.tr" or there will be no translation. It might be a good idea to change that, indeed.

User avatar
Wuzzy
Member
Posts: 4786
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy
Contact:

Re: Client-side translations

by Wuzzy » Post

By the way. Which standard for the language codes do you use?

User avatar
Linuxdirk
Member
Posts: 3216
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Client-side translations

by Linuxdirk » Post

Nore wrote:For now, derived language detection needs to be exact. Thus, the server needs to provide "pt_BR.tr" or there will be no translation. It might be a good idea to change that, indeed.
... by adding an advanced configuration option for that instead of misusing local Gettext.

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Post

Wuzzy wrote:By the way. Which standard for the language codes do you use?
The languages codes used are exactly the same as the folder names in po/.
Linuxdirk wrote:
Nore wrote:For now, derived language detection needs to be exact. Thus, the server needs to provide "pt_BR.tr" or there will be no translation. It might be a good idea to change that, indeed.
... by adding an advanced configuration option for that instead of misusing local Gettext.
What do you mean? If you want a way to force a specific language, this already exists and will work. As to "misusing local Gettext": if you provide a reliable, cross-platform way to detect the language being used, I'll gladly accept it.

User avatar
Linuxdirk
Member
Posts: 3216
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Client-side translations

by Linuxdirk » Post

Nore wrote:
Linuxdirk wrote:... by adding an advanced configuration option for that instead of misusing local Gettext.
What do you mean?
I mean this. Setting a variable using Gettext-based translations.
Nore wrote:if you provide a reliable, cross-platform way to detect the language being used, I'll gladly accept it.
There is none. So have an option for that.

Btw. You statement applies to locales as well.

On a daily basis I work with different machines. One has de_DE.utf-8 set as locale, one has set de-DE, another has set de_DE.ISO-8859-15@euro. As result all of them set the system language to German.

Since ...
Nore wrote:For now, derived language detection needs to be exact. Thus, the server needs to provide "pt_BR.tr" or there will be no translation.
... applies: What do I name my German translation file?

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Post

As I said earlier, the name you need to give corresponds to the lang code used by minetest with that specific locale. In your case, if will be "de". As for having a configuration option to set the language, as I said, *it already exists*.

User avatar
Linuxdirk
Member
Posts: 3216
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Client-side translations

by Linuxdirk » Post

Nore wrote:As for having a configuration option to set the language, as I said, *it already exists*.
But will it be *used* for determining the client-side translations language?

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Post

Yes.

xisd
Member
Posts: 54
Joined: Sun Oct 02, 2016 22:38

by xisd » Post

This feature is great news !
Wuzzy wrote: In the long run, the switch to Gettext should be done for various reasons.
Just to be sure that I understood this gettext situation :
Mods that were using inttlib for their translation and have finally converted all translation file from earlier files format (<string to translate> = <string stranslated>) to the newly supported .po format, will need to convert them back to use the new "minetest.get_translator", until the switch to gettext (wich has to be made) is made and require to re-re-converting them to .po format ?

That seems messy and totally discouraging... at least until Gettext format is used

User avatar
Hamlet
Member
Posts: 766
Joined: Sat Jul 29, 2017 21:09
IRC: H4mlet
In-game: Hamlet
Location: Lombardy, Italy

Re: Client-side translations

by Hamlet » Post

Nore wrote:As a new feature in the 0.5 branch, we now have client-side translations! That means that you can have a mod on a server, with texts translated by each client according to their locale. Translations are documented here.
I have a question that isn't strictly in topic, but it's related to it:
will it be possible to have support for localized settingtypes.txt ?

I think that it would make sense if the client would do something easy (?) as:

IF locale == English THEN load settingtypes.txt
ELSE IF locale == Spanish THEN load settingtypes.es
ELSE IF locale == French THEN load settingtypes.fr

and so on; of course falling back to settingtypes.txt if the localized file isn't available.

Mods' settings should be intelligible to everyone, just like the Minetest Engine's settings.
My repositories: Codeberg.org | My ContentDB's page

User avatar
Fixer
Member
Posts: 904
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

Re: Client-side translations

by Fixer » Post

So we can translate minetest_game now?

Reedych
Member
Posts: 58
Joined: Wed Aug 03, 2016 08:09
GitHub: SlackCoyote
In-game: SlackCoyote

Re: Client-side translations

by Reedych » Post

Fixerol wrote:So we can translate minetest_game now?
Not now. Caŭse I think this feature will be reworked a lot before release. There are some bugs and missing examples (i really don't understand how to use it)
Slackware64 14.2, MT 0.4.16. My best mod.

hajo
Member
Posts: 606
Joined: Thu Oct 13, 2016 10:45
Location: DE
Contact:

Re: Client-side translations

by hajo » Post

(How) could this be used for multi-language signs ?

Eg. I have a sign with text

Code: Select all

EN: exit
DE: Ausgang
FR: Sortie
and I want it to be shown to the user in his selected language
(or english, if no match) ?

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Post

Unfortunately, it can't, for 2 reasons:
- the translated parts must be known statically
- it won't work with signs showing text with sign_lib or things like that (but it will work with infotexts), due to how sign_lib or other similar mods work.

User avatar
Wuzzy
Member
Posts: 4786
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy
Contact:

Re: Client-side translations

by Wuzzy » Post

One thing which bothers me the most at the moment:
Why did you use a non-standard format for the translations instead of just Gettext / PO? I mean, is there really any reason for that? Honestly, this seems like a stupid decision.

Gettext has a WAY better toolchain AND it's readily available. With the decision of not using a standard format (like PO) you basically just cause more work for everyone (including yourself). :-(

Will a switch to Gettext eventually be made?

User avatar
BrunoMine
Member
Posts: 1082
Joined: Thu Apr 25, 2013 17:29
GitHub: BrunoMine
Location: SP-Brasil
Contact:

Re: Client-side translations

by BrunoMine » Post

I already foresee a lot of rework because of this format for translations. Gettext/PO is realy better.

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Post

Wuzzy wrote:One thing which bothers me the most at the moment:
Why did you use a non-standard format for the translations instead of just Gettext / PO? I mean, is there really any reason for that? Honestly, this seems like a stupid decision.
The format used was the same as intlib used, although now intlib uses gettext/po. However, the main reason was double: first, I had been told that gettext didn't work on the Android builds (although I didn't check); second, because I could find no way to dynamically load gettext files that were sent by the server.
Will a switch to Gettext eventually be made?
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.

bell07
Member
Posts: 604
Joined: Sun Sep 04, 2016 15:15
GitHub: bell07

Re: Client-side translations

by bell07 » Post

Is it possible to automatically convert a pot/po file on load to the internal format on load? The file format in transfer to the client does not matter but the files should be stored in mod's "locale" folder in po format. Maybe the pot file could help to organize the translations.
Second idea is to convert the files on first usage to "tr" files and store them in a cache folder, with timestamp so the cache could be updated on change. If cache is used, maybe the "mo" format could be used in cache and transferred to the client instead of "tr"-files?

Locked

Who is online

Users browsing this forum: No registered users and 2 guests