Board Game Arena

I have a few strings in game options that are just Arabic numerals (e.g. "1", "2", "3", etc.). Since they are displayed to the user, I wrapped them in "totranslate" like everything else. But, I got a (reasonable) suggestion to remove these from the translation system, since Arabic numerals are recognized in all modern languages (even in languages that also have alternate symbols).

I remove the "totranslate" wrappers from these strings (in gameoptions.inc.php), but the change didn't seem to have any effect. The items are still in the translation system after nearly a week.

Is this expected? Is there some trick to cause these to go away? Or should I just give up and let them stay?

The game is Letter Tycoon.

Example can be found here (for the numeral "4"):
https://boardgamearena.com/translation? ... _US&find=4

See this bug/suggestion:
https://boardgamearena.com/bug?id=28251

And this thread in the Translation forum:
viewtopic.php?f=11&t=18304

Just to make sure the issue is not comming from here : you commit & build a new version and deploy it right after, right ?

Yes, good question. I've committed, built, and pushed more than one version since changing this. And I also clicked the "Reload game options configuration" button (more than once).

Although, it's still possible that something isn't going right at these steps, I suppose. It's hard to confirm what configuration is actually being used in production. I've double-checked that my change is in the commit log (and viewed the diff), but that's not quite the same as production.

jephly wrote: ↑27 November 2020, 09:56 Yes, good question. I've committed, built, and pushed more than one version since changing this. And I also clicked the "Reload game options configuration" button (more than once).

Although, it's still possible that something isn't going right at these steps, I suppose. It's hard to confirm what configuration is actually being used in production. I've double-checked that my change is in the commit log (and viewed the diff), but that's not quite the same as production.

Ok so in this case, have you tried the button "display dummy translations" to see if the strings are displayed with << >> on studio ?

Just tried this, and the numeral strings display without "<<" and ">>" as hoped/expected. (Everything else, including the "None" and "Unlimited" options in the same dropdown, display with "<<" and ">>".)

(I didn't realize that button worked for game options, since they're displayed only during setup - good to know it does!)

Game options are a specific case for translations, probably they don't get disabled like other translations for some reasons.
There are multiple small things to check on translations when possible. One more on the list

I checked this, and we made sure when packaging that the to_translate was added if missing, because the value name should in general be, well, a name to translate

I have added a check not to do that if the name is numeric, so it will be solved next time you deploy your game.

Still, looking at your gameoptions files, I would suggest to use the same value for the name as you use for tmdisplay, as it is more descriptive and doesn't create more work for translators since it already has to be translated for the tmdisplay. It's in general better not to have just a number in an option choice, as it's not very descriptive.