Why is this translation not working?

[Idsky]

in quantum material.inc.php I have

Code: Select all

 'name'           => self::_('Gamma sector (5) - Basic map')

for maps.

But when I try to use that string in-game, it isn't translated.

The translation system has it:

Code: Select all

Gamma sector (5) - Basic map

->

Code: Select all

Secteur Gamma (5) - Carte débutant

But I'm just getting the English when my language is set to French.
It's not just this one string, all the map names from material.inc.php are the same.

What is wrong?

[Idsky]

Yikes.

It seems that BGA has 1 translation file for in-game strings, e.g: lang_quantum-20200814.js

And one ginormous one for everything else on the site, including every gameoption for every game! lang_mainsite-20200814.js !! 350KB for en.
That is a bit nasty. Quantum (for example) has a lot of game options and Everyone who has never played it is loading a translation list of them all with each BGA page.

I actually got 2 of each of these files (2 x 350K for mainsite strings, one all English, one in your preferred language -- possibly both the same).

To avoid string conflicts in the everything mainsite file, it prepends a gameoptions id. 'gameoptions_1018_' for Quantum.

So I *guess* if I wanted to show a gameoption string translated within the game…

Code: Select all

gameoptions_1018_Gamma sector (5) - Basic map

would get translated, but I must be missing something, is there a right way to do this??

Maybe because Quantum had map names duplicated in material.inc.php *and* gameoptions.inc.php, the material translations have been disabled??

[Idsky]

I'm sure I saw something on here a while ago about a way to test if a string is being translated on studio (where there are no real translations).
Can anyone point that out to me?

[A-dam]

Hi,

you can test translation in sutido now if you go to control panel -> check your project section -> display dummy translations

The part in your material.inc.php might be ok, maybe the answer lies in how you use this text... it wont be bad to see the usage in your code

In most cases insted of

Code: Select all

 'name'           => self::_('Gamma sector (5) - Basic map')

you need

Code: Select all

 'name'           => clienttranslate('Gamma sector (5) - Basic map')

to mark the string for translation..

Adam

[Idsky]

Thanks.

Yes, if I use clienttranslate… in material.inc.php then I'm sure it will get translated… BUT I already have every map name in gameoptions.inc.php, translated, and this I believe would get all 71 map names translated a second time and maybe both different! Unless the system is smart enough to see that the gameoption name and the in-game string are the same and only do the translation once. I'm scared to try it. I guess I'll try it on ONE map and see.

I'm not sure if there is any way to get the translated *name* of a selected gameoption value in the game, but even if there were it wouldn't help, as players can choose the 'random map' option and then the game chooses the actual map.

To rephrase my question, can I get the translated name for a gameoption (say gameoption 101, value 45)?

I can see it (and all the other options) right there in the lang_mainsite-20200815(1).js include with the gameoption prefix, e.g:

Code: Select all

"gameoptions_1018_Gamma sector (5) - Basic map":"Secteur Gamma (5) - Carte débutant"

But prefix issue aside, it appears the normal _() translation function only checks the lang_quantum-20200815(1).js strings, not the mainsite strings.

[fafa-fr]

... and this I believe would get all 71 map names translated a second time and maybe both different! Unless the system is smart enough to see that the gameoption name and the in-game string are the same and only do the translation once.

I think the translation system does this. Quote from the Studio Doc:

When you need the same string twice, try to reuse exactly the same string (with the same case) to minimize the number of strings.

(https://en.doc.boardgamearena.com/Trans ... azy_.3B.29)

So I think you can, and you should, use clienttranslate(), since you need this string in-game.
(https://en.doc.boardgamearena.com/Trans ... _.28PHP.29)
And if you look at the bottom of this doc page, it seems that for game options, you should use totranslate(), not _().

[Idsky]

I think the translation system does this. Quote from the Studio Doc:

When you need the same string twice, try to reuse exactly the same string (with the same case) to minimize the number of strings.

(https://en.doc.boardgamearena.com/Trans ... azy_.3B.29)

Yes, hopefully it will do that across the boundary of the two separate contexts (global mainsite / gameoptions string file and the string file for the game) -- I imagine the same string translation will end up duplicated in both of these files, but only show up in the translation system once for translators. Unless someone can confirm this for certain I'll still test it with one string in my next live update before I do them all.

And if you look at the bottom of this doc page, it seems that for game options, you should use totranslate(), not _().

I do that (gameoptions have been translated for years on Quantum), I was just saying that on the js side, _() cannot find translations for gameoptions. It only finds in-game (server-clienttranslate) strings, even though both string files are loaded. It kind-of makes sense, otherwise you could pull out translations from any other game gameoption on BGA (you still could but it'd be an undocumented hack).

The names need translating but I do hate how my map option descriptions end up in the global BGA translation file, even though (A) they are only used on the table setup for Quantum and (B) they don't need any translation as they are just a grid of numbers! (description fields get translated no matter what, even without the totranslate function). Any time I edit them I need to get an admin to manually remove them from the global translations.

[fafa-fr]

And if you look at the bottom of this doc page, it seems that for game options, you should use totranslate(), not _().

I do that

Oh excuse me, I mixed things up, since you're talking about these strings in gameoptions in your second post, I thought that self::_('Gamma sector (5) - Basic map') was in this file, but it's in material.inc.php. Sorry.

[quietmint]

BUT I already have every map name in gameoptions.inc.php, translated, and this I believe would get all 71 map names translated a second time and maybe both different! Unless the system is smart enough to see that the gameoption name and the in-game string are the same and only do the translation once. I'm scared to try it. I guess I'll try it on ONE map and see.

If it's the same string literal, you can use it many times in different files and with different methods _() / totranslate() / clienttranslate() and the community only needs to provide ONE translation for it.

[Idsky]

If it's the same string literal, you can use it many times in different files and with different methods _() / totranslate() / clienttranslate() and the community only needs to provide ONE translation for it.

Yes, I've updated it and all working correctly. Thanks.