_()

[aubergine]

Does this have to be around the actual string literal, or can it be applied later when the string is used?

For example, if I had an array:

var baz = ["foo", "bar"];

And at some point later I want to output that to console, I can apply _() as follows:

console.apply( this, baz.map(_) );

I've got a file with lots of string definitions in it and I want to keep it readable (and cut down on the amount of typing I have to do) hence this desired approach.

I wasn't sure how _() is meant to work so thought I'd ask...

[Emdek]

aubergine, we need a way to mark strings to gettext can extract them, kind of QT_TR_NOOP() for JS API to only mark strings but not replace them yet would be useful in some cases.

[cybersphinx]

I've got a file with lots of string definitions in it and I want to keep it readable (and cut down on the amount of typing I have to do) hence this desired approach.

I wasn't sure how _() is meant to work so thought I'd ask...

a. Every string that should be translated needs to be inside _() somewhere for gettext to extract and put it into the string database the translators see (which - at the moment at least - means that only strings included in our official source can get translations).

b. A string that should be translated on the screen needs to be fed through gettext(), or _() for short. The code for qtscript is:

Code: Select all

return QScriptValue(gettext(context->argument(0).toString().toUtf8().constData()));

Not sure what arguments are valid for that.

[Per]

At the moment, you have to put _() around the actual strings that you use, and they will be replaced by that function call with a translated version (if one exists). Calling _() on variables will not work, since then the strings in question will not be fed to the translation tool, and translators will not see it. (Of course, if you know that the string is already in the translation database, then it will work...)

[Duha]

I wasn't sure how _() is meant to work so thought I'd ask...

Full cycle of _() usage:

Build:
You need to do 3 steps to prepare translations:
1. gettext program parse files and add strings inside _() to po file. # names.txt is created for this # check if it setupped in wz for js files.
2. Po files edited by text editor. # added translation
3. Compile to mo files.

Execute:
Game check if var inside _() present in mo file and returns translation from more file else return same string.

PS. Is it work in javascript code?

[aubergine]

Ah, so they are like markers for the gettext parser to say "this string needs to go in the po file", and then translators use that. That's good to know!

It might be worth updating the JS API docs for _() to make it explicit that the _() has to go around the string literal, the primitive string value, not a variable.

[aubergine]

Despite there currently being no way to handle localisation in scripts outside the main source, I was wondering if an additional feature could be added to _() in the JS API...

On the assumption that at some point in the future there will be a way to provide translations in addons, scripts (in particular AIs) have an interesting scenario where they might need to send chat messages to remote players, ie. in a multiplayer game.

Currently, in such AIs, if translations were implemented it would mean that they always localise to the language of the game host, which might not be the same language of other players in the game.

Would it be possible to add a second parameter to _(), which defines the language to translate to? And have players locale code exposed via playerData objects?

Rough example:

Code: Select all

var myLocale = playerData[me].locale;

playerData.forEach(function sayHelloTo(data, player) {
   chat( player, _( "Hello", data.locale || myLocale );
});

I assume gettext only looks for what's inside the quotes and would thus ignore the ', data.locale || myLocale' part of that code (and the whitespace next to brackets)?

Anyway, this would allow AI to send message in the right language for the remote player.

This would be particularly important if we ever reach a point where we can do multiplayer campaigns or challenges.

[Emdek]

aubergine, I guess that it should be send in raw form (untranslated) and be translated at other player end. This is one of scenarios where substitute of QT_TR_NOOP() would be useful (at least without using ugly methods to mark string as translatable).
Also I'm not sure if it's doable at all to ask gettext for translations from other locales.

[aubergine]

That sounds like a much better idea Emdek! So on receiving end, received chat messages would be passed through _() before being displayed, but only if they are from an AI player.

Problem then is that the human might reply in their language, and if the AI doesn't understand their language....??? I guess it could work in both directions though?

[Emdek]

Parsing replies will be hard anyway, even if user will be required to answer in English.
Unless AI will specify what kind of answers are acceptable...

[aubergine]

The API could state what replies it understands when it sends a message.

For example:

"Alliance? Reply: yes or no"

That got translated to Français, and the player replied "oui" or "non", because we already know what replies to expect those can be defined in _() so they can later be translated back in to English.

For example, in the AI script;

Code: Select all

chat(player, "Alliance? Reply: yes or no");

function eventChat(from, to, msg) {
   if (msg == _("yes")) {
     // form ally
   } else if (msg == _("no")) {
     // don't form ally
   }
}

Obviously, the fun part now is if the machine the AI is running in is in some other locale, things will get mighty confusing LOL.

[Duha]

The API could state what replies it understands when it sends a message.
For example:
"Alliance? Reply: yes or no"
That got translated to Français, and the player replied "oui" or "non", because we already know what replies to expect those can be defined in _() so they can later be translated back in to English.

In that case you should put "oui" and "non" to translation file by hands (if you do it in auto way it will be added to all languages (31 files)).

I hope devs add support of gettext for mods. (mod owner create its onw po file. Merge it with game file and this file used for translation. gettext works with all platforms and may be merging can be done on client side)


PS You can use gettext on any variable. It will not be collected but will be translated.

[Emdek]

aubergine, in that case you simply shouldn't translate yes and no and put them into translated string using placeholders.
That is easiest scenario, another would be to somehow compare answer on side of that player using translated "yes" and "no" answers for his locale, but there is always risk that one of the strings won't be translated or will be done in wrong way.
There is always possibility to add comments for translators to those question and state that it should be translated in the way so player will know that he should use "yes" or "no".
Yet another way would be to have dedicated way to ask users (like specify question and what generic answers are accepted, using enum values), handled by game in GUI form (maybe using buttons).

[aubergine]

Your idea about buttons is infinitely awesome!

A key thing I'd like to see is the ability for scripts to optionally return true from eventChat() to prevent message being echoed to player console. This would be applicable for both incoming and outgoing messsages. With this, chat commands become customisable. And would pave way to displaying yes/no buttons via chat response.