This is a documentation for Board Game Arena: play board games online !
Ero sivun ”Translations” versioiden välillä
(9 välissä olevaa versiota 2 käyttäjän tekeminä ei näytetä) | |||
Rivi 21: | Rivi 21: | ||
However, there is one difference on BGA: notifications. The server is sending notifications to players, and most of the time the notifications are the same for every players, no matter what language each player is using. This is why notifications are translated on client side in the proper language, even if the strings are defined on server side. | However, there is one difference on BGA: notifications. The server is sending notifications to players, and most of the time the notifications are the same for every players, no matter what language each player is using. This is why notifications are translated on client side in the proper language, even if the strings are defined on server side. | ||
== WARNING: how to make sure your strings will be translated == | |||
For each game, our translation tool is doing a full scan of the code, looking for translator markers like "_()" or "clientranslate()"... (see below the list of translation markers). | |||
If your original string is not "physically" inside one of this marker, it won't be translated. | |||
<pre> | |||
// Examples: the following strings will be translated: | |||
var mystring_translated = _("my string"); // JS | |||
$mystring_translated = self::_("my string"); // PHP | |||
$mystring_translated = sprintf( _("my string with an %s argument"), $argument ); // PHP | |||
// Examples: the following strings WILL NOT be translated: | |||
$my_string = "my string"; | |||
$not_translated = self::_( $my_string ); // The original string is not bordered by a translator marker => no translation | |||
$not_translated = self::_( sprintf( "my string with a %s argument", $argument ) ); // Same thing | |||
</pre> | |||
== How to not make translators crazy ;) == | |||
* When you need the same string twice, try to reuse exactly the same string (with the same case) to minimize the number of strings. | |||
* Do not mark as translatable a game element that does not have to be translated (ex: if the name of a monster on a card is "Zzzzz", maybe there's no need to translate it). | |||
* Words does not come in the same order in each language. Thus, when you have to translate a string with an argument, do not write something like: | |||
<pre>_("First part of the string, ").$argument.' '._("second part of the string")</pre> | |||
Write instead: | |||
<pre>sprintf( _("First part of the string, %s second part of the string"), $argument )</pre> | |||
(or the equivalent "dojo.string.substitute" in Javascript) | |||
* When translators are going to translate your game, the most difficult task for them is to get the context of the string to be translated. The more the string is a short insignificant string, the more difficult is the task for them. As a rule of thumb, try to avoid insignificant short strings. | |||
* The BGA translation policy is to be flexible on grammar... We prefer to write "player gets 1 coin(s)" than write two versions of the same string for plural and singular - it reduces the number of strings to translate. | |||
* Instead of writing nice strings like "With the effect of ZZZ, player XXX gets a new YYY", which is very difficult to translate, write strings like "ZZZ: XXX gets YYY". | |||
== On client side (Javascript) == | == On client side (Javascript) == | ||
Rivi 38: | Rivi 69: | ||
</pre> | </pre> | ||
'''WARNING:''' in Javascript strings to translate, you should never use '\n', '\t' or such, as it will break the translation bundle and result in all the Javascript translation to fail. In any case, the strings will result in HTML code, and such character codes won't have any impact on the HTML rendering. You should use HTML markup instead. | |||
== On server side (PHP) == | == On server side (PHP) == | ||
Rivi 50: | Rivi 81: | ||
In general, you use clienttranslate: | In general, you use clienttranslate: | ||
* On your states.inc.php, for field "description" and "descriptionmyturn". | * On your states.inc.php, for field "description" and "descriptionmyturn". | ||
<pre> | |||
"description" => clienttranslate('${card_name}: ${actplayer} must discard 4 identical energies'), | |||
</pre> | |||
* On "material.inc.php", when defining texts for game material that must be displayed on client side. | * On "material.inc.php", when defining texts for game material that must be displayed on client side. | ||
<pre> | |||
$this->card_types = array( | |||
1 => array( | |||
'name' => clienttranslate("Amulet of Air"), // Thus, we can use "_( card_name )" on Javascript side. | |||
</pre> | |||
* When sending a notification with "notifyAllPlayers" or "notifyPlayer", for the game log string and all game log arguments that need a translation. | * When sending a notification with "notifyAllPlayers" or "notifyPlayer", for the game log string and all game log arguments that need a translation. | ||
<pre> | |||
// A game log string with no argument: | |||
self::notifyAllPlayers( 'pickLibraryCards', clienttranslate("Everyone draw cards from his library"), array() ); | |||
</pre> | |||
Translating arguments is a little bit more complex. It is using the "i18n" special argument as below: | |||
<pre> | |||
// In the following example, we translate the game log itself, but also the "card_name" argument: | |||
self::notifyAllPlayers( 'winPoints', clienttranslate('${card_name}: ${player_name} gains ${points} point(s)'), array( | |||
'i18n' => array( 'card_name' ), // <===== We specify here that "card_name" argument must be transate | |||
'player_id' => $player_id, | |||
'player_name' => self::getActivePlayerName(), | |||
'points' => $points, | |||
'card_name' => $this->card_types[8]['name'] // <==== Here, we provide original English string. | |||
) ); | |||
</pre> | |||
'''self::_( "my string to translate" ):''' | '''self::_( "my string to translate" ):''' | ||
Rivi 59: | Rivi 121: | ||
Most of the time, you don't need to translate strings on server side, except on the following 3 situations: | Most of the time, you don't need to translate strings on server side, except on the following 3 situations: | ||
* When throwing an exception because the player did a forbidden move. | * When throwing an exception because the player did a forbidden move. | ||
<pre> | |||
// This will display a translatable red message to the player that just do some wrong action: | |||
throw new BgaUserException( self::_('You must choose 3 cards') ); | |||
// ... notice the use of BgaUserException that signals that this exception is "expected". In theory, all exception that are expected should be translated. | |||
</pre> | |||
* In "yourgame.view.php", when creating the labels for the game interface used in your template (.tpl) file. | * In "yourgame.view.php", when creating the labels for the game interface used in your template (.tpl) file. | ||
<pre> | |||
$this->tpl['CARDS_FOR_YEAR_2'] = self::_("Your cards for year II"); | |||
</pre> | |||
* Eventually, in your material.inc.php, if for example you need to use some string elements in your exceptions. | * Eventually, in your material.inc.php, if for example you need to use some string elements in your exceptions. | ||
<pre> | |||
// In material.inc.php, $this->energies[n]['nametr'] has been created with the self::_() method. This we can do this: | |||
throw new BgaUserException( self::_("To execute this action you need more: ").' '.$this->energies[$resource_id]['nametr'] ); | |||
</pre> | |||
* Eventually, in your "getAllDatas" PHP method, as the data return by this method is used only by current user. | * Eventually, in your "getAllDatas" PHP method, as the data return by this method is used only by current user. | ||
Nykyinen versio 21. toukokuuta 2013 kello 22.36
Using BGA Studio, the game you create is ready to be translated to each language by the BGA community. To make this possible, you only need to specify which string must be translated and how to combine them.
How translation works?
When developing your game, all strings must be in English. Strings must be coherent with the English version of the game.
Before the release of the game, BGA team will do the French translation of the game.
After the release of the game, the BGA players community will translate the game in every language.
What should be translated?
Every text that can be visible by the player when the game is running normally. This includes tooltips, texts on cards, error messages, ...
This does NOT include error messages that are not supposed to happened (unexpected errors).
Focus on translating notifications
Usually, translating a website is simple: you just call a function on every string you have to translate, and the string is translated in the player's language. On Board Game Arena, this is exactly the same with the "_( string )" function.
However, there is one difference on BGA: notifications. The server is sending notifications to players, and most of the time the notifications are the same for every players, no matter what language each player is using. This is why notifications are translated on client side in the proper language, even if the strings are defined on server side.
WARNING: how to make sure your strings will be translated
For each game, our translation tool is doing a full scan of the code, looking for translator markers like "_()" or "clientranslate()"... (see below the list of translation markers).
If your original string is not "physically" inside one of this marker, it won't be translated.
// Examples: the following strings will be translated: var mystring_translated = _("my string"); // JS $mystring_translated = self::_("my string"); // PHP $mystring_translated = sprintf( _("my string with an %s argument"), $argument ); // PHP // Examples: the following strings WILL NOT be translated: $my_string = "my string"; $not_translated = self::_( $my_string ); // The original string is not bordered by a translator marker => no translation $not_translated = self::_( sprintf( "my string with a %s argument", $argument ) ); // Same thing
How to not make translators crazy ;)
- When you need the same string twice, try to reuse exactly the same string (with the same case) to minimize the number of strings.
- Do not mark as translatable a game element that does not have to be translated (ex: if the name of a monster on a card is "Zzzzz", maybe there's no need to translate it).
- Words does not come in the same order in each language. Thus, when you have to translate a string with an argument, do not write something like:
_("First part of the string, ").$argument.' '._("second part of the string")
Write instead:
sprintf( _("First part of the string, %s second part of the string"), $argument )
(or the equivalent "dojo.string.substitute" in Javascript)
- When translators are going to translate your game, the most difficult task for them is to get the context of the string to be translated. The more the string is a short insignificant string, the more difficult is the task for them. As a rule of thumb, try to avoid insignificant short strings.
- The BGA translation policy is to be flexible on grammar... We prefer to write "player gets 1 coin(s)" than write two versions of the same string for plural and singular - it reduces the number of strings to translate.
- Instead of writing nice strings like "With the effect of ZZZ, player XXX gets a new YYY", which is very difficult to translate, write strings like "ZZZ: XXX gets YYY".
On client side (Javascript)
On client side, things are quite simple: you just have to use the "_()" function for all strings you want to translate.
Examples:
// Get a string in player's language: var translated = _("original english string"); // Get a string in player's language with parameter: var translated = dojo.string.substitute( "You can pick ${p} cards and discard ${d}", { p: 2, d: 4 } );
WARNING: in Javascript strings to translate, you should never use '\n', '\t' or such, as it will break the translation bundle and result in all the Javascript translation to fail. In any case, the strings will result in HTML code, and such character codes won't have any impact on the HTML rendering. You should use HTML markup instead.
On server side (PHP)
On PHP side, you can use 3 different functions to specify that a string must be translated.
clienttranslate( "my string to translate" ):
This function is transparent: it will return the original English string without any change. It's only purpose is to mark this string as "must be translated", and to make sure the translated version of the string will be available on client side.
In general, you use clienttranslate:
- On your states.inc.php, for field "description" and "descriptionmyturn".
"description" => clienttranslate('${card_name}: ${actplayer} must discard 4 identical energies'),
- On "material.inc.php", when defining texts for game material that must be displayed on client side.
$this->card_types = array( 1 => array( 'name' => clienttranslate("Amulet of Air"), // Thus, we can use "_( card_name )" on Javascript side.
- When sending a notification with "notifyAllPlayers" or "notifyPlayer", for the game log string and all game log arguments that need a translation.
// A game log string with no argument: self::notifyAllPlayers( 'pickLibraryCards', clienttranslate("Everyone draw cards from his library"), array() );
Translating arguments is a little bit more complex. It is using the "i18n" special argument as below:
// In the following example, we translate the game log itself, but also the "card_name" argument: self::notifyAllPlayers( 'winPoints', clienttranslate('${card_name}: ${player_name} gains ${points} point(s)'), array( 'i18n' => array( 'card_name' ), // <===== We specify here that "card_name" argument must be transate 'player_id' => $player_id, 'player_name' => self::getActivePlayerName(), 'points' => $points, 'card_name' => $this->card_types[8]['name'] // <==== Here, we provide original English string. ) );
self::_( "my string to translate" ):
This function returns a string translated in the language of CURRENT user (ie: player who send the request to the server) (be careful, this is NOT the active player).
Most of the time, you don't need to translate strings on server side, except on the following 3 situations:
- When throwing an exception because the player did a forbidden move.
// This will display a translatable red message to the player that just do some wrong action: throw new BgaUserException( self::_('You must choose 3 cards') ); // ... notice the use of BgaUserException that signals that this exception is "expected". In theory, all exception that are expected should be translated.
- In "yourgame.view.php", when creating the labels for the game interface used in your template (.tpl) file.
$this->tpl['CARDS_FOR_YEAR_2'] = self::_("Your cards for year II");
- Eventually, in your material.inc.php, if for example you need to use some string elements in your exceptions.
// In material.inc.php, $this->energies[n]['nametr'] has been created with the self::_() method. This we can do this: throw new BgaUserException( self::_("To execute this action you need more: ").' '.$this->energies[$resource_id]['nametr'] );
- Eventually, in your "getAllDatas" PHP method, as the data return by this method is used only by current user.
totranslate( "my string to translate" ):
This function works exactly like 'clienttranslate', except it tells BGA that the string is not needed on client side.
You should not use this function, except on the following cases:
- Statistics name in stats.inc.php
- Option names and option values name in gameoptions.inc.php