Client-side translations

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

Re: Client-side translations

by Linuxdirk » Fri Aug 25, 2017 14:22

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: 493
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Fri Aug 25, 2017 14:28

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: 1629
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk
 

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

Re: Client-side translations

by Nore » Fri Aug 25, 2017 15:49

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

Yes.
 

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

Re: Client-side translations

by Wuzzy » Fri Aug 25, 2017 20:12

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.
My creations. I gladly take any bitcoins you have lying around: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH
 

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

Re: Client-side translations

by Linuxdirk » Fri Aug 25, 2017 21:37

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: 1017
Joined: Thu Apr 25, 2013 17:29
Location: SP-Brasil
GitHub: BrunoMine

Re: Client-side translations

by BrunoMine » Sun Aug 27, 2017 20:24

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: 493
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Sun Aug 27, 2017 20:59

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: 3232
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: Client-side translations

by Wuzzy » Sun Aug 27, 2017 21:07

By the way. Which standard for the language codes do you use?
My creations. I gladly take any bitcoins you have lying around: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH
 

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

Re: Client-side translations

by Linuxdirk » Mon Aug 28, 2017 04:45

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: 493
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Mon Aug 28, 2017 05:33

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: 1629
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk

Re: Client-side translations

by Linuxdirk » Mon Aug 28, 2017 06:43

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: 493
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Mon Aug 28, 2017 07:24

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: 1629
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk

Re: Client-side translations

by Linuxdirk » Mon Aug 28, 2017 07:47

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: 493
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs
 

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

by xisd » Fri Oct 20, 2017 15:03

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: 461
Joined: Sat Jul 29, 2017 21:09
Location: Italia
IRC: H4mlet

Re: Client-side translations

by Hamlet » Tue Oct 24, 2017 16:31

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.
 

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

Re: Client-side translations

by Fixer » Wed Oct 25, 2017 22:36

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 » Sun Nov 12, 2017 08:10

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: 595
Joined: Thu Oct 13, 2016 10:45
Location: DE

Re: Client-side translations

by hajo » Fri Jan 26, 2018 16:56

(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: 493
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: Client-side translations

by Nore » Sat Jan 27, 2018 07:48

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: 3232
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: Client-side translations

by Wuzzy » Fri Feb 02, 2018 15:56

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?
My creations. I gladly take any bitcoins you have lying around: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH
 

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

Re: Client-side translations

by BrunoMine » Fri Feb 02, 2018 16:54

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

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

Re: Client-side translations

by Nore » Fri Feb 02, 2018 17:01

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: 534
Joined: Sun Sep 04, 2016 15:15
GitHub: bell07

Re: Client-side translations

by bell07 » Fri Feb 02, 2018 21:12

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?
 

PreviousNext

Return to News



Who is online

Users browsing this forum: No registered users and 4 guests