Page 1 of 1

self::_(...) doesn't work with some strings

Posted: 20 June 2021, 15:04
by BaronFraser
Has anyone experienced anything like this: I had reports that some BgaUserException messages are not going back to the clients translated, so started methodically experimenting and discovered that in my X.game.php, self::_(...) simply does not translate some strings.

This is best explained with some code that reproduces the problem:

Code: Select all

echo("<div>");
echo(self::_("My play area"));
echo("</div>");
echo("<div>");
echo(self::_("Available Drivers"));
echo("</div>");
echo("<div>");
echo(self::_("There are no white spaces available to move into"));
echo("</div>");
echo("<div>");
echo(self::_("Empty"));
echo("</div>");
echo("<div>");
echo(self::_("Car Chief"));
echo("</div>");
echo("<div>");
echo(self::_("Surprise me!"));
echo("</div>");
These are various strings used throughout the game. All of them have been translated into French (amongst other languages) at translatehq, yet when I run the game with French as the language and trigger the above code, I see:

Code: Select all

Ma zone de jeu
Pilotes Disponibles
There are no white spaces available to move into
Empty
Chef de Voiture
Surprenez-moi !
So, 4 out of the 6 are displaying the French but (the middle) 2 are not, even though the translations exist in all cases. For example:
Image

It's completely consistent: some of the strings always return the translated version through self::_(...), and others never do.

Does anyone have the slightest clue or experience as to what could be causing a different result for different strings even within the same block of code?

To head off the first and obvious question of "do your strings match the translation sources perfectly?" the answer is: I've checked that dozens of times, but more importantly if they weren't then these near duplicates would have turned up as separate strings in the translation system, which they haven't.

Is there anything potentially obvious I'm missing?

Re: self::_(...) doesn't work with some strings

Posted: 20 June 2021, 20:08
by Tisaac
A non-answer : I never use self::_ and always construct interface in js using _() to have translation.
Your result are weird Indeed.

Re: self::_(...) doesn't work with some strings

Posted: 20 June 2021, 22:16
by BaronFraser
Well this is for BgaUserException, so Javascript isn't applicable, BUT... if I can't figure out what's going on then the workaround is going to be not using BgaUserException and just sending a Notify that manually displays an error on the client side...

EDIT: I have just implemented using Notify as a workaround, because I'm keen to get this moving, but would still love to hear if anyone's come across this before. Notify is suboptimal because it winds up in the log and, therefore, the alert unnecessarily appears on replays.

It's doubly strange that the translation works 100% fine on the client, but not on the server for certain select strings...

Re: self::_(...) doesn't work with some strings

Posted: 21 June 2021, 08:18
by Een
Most likely there is a generation issue for po/mo gettext ressources for this project. We'll have to check this. It's clearly not the intended behaviour to have to double the error with a notify.
It's doubly strange that the translation works 100% fine on the client, but not on the server for certain select strings...
Server and client translation rely on a different logic and different libraries, so that is not strange at all :)

Re: self::_(...) doesn't work with some strings

Posted: 21 June 2021, 14:45
by Een
The files were correctly generated, but not propagated daily to the gameservers due to a migration last Thursday. This affected all the games. It has been fixed now, and server-side translation files have been updated on all gameservers. Thanks for reporting the issue!

Re: self::_(...) doesn't work with some strings

Posted: 24 June 2021, 01:46
by BaronFraser
Thanks! Will try again!