Board Game Arena

I got readonly access to Hive and have checked this; the i18n array contains "mosquito" and "pillbug".

DrKarotte wrote:causing the variable names not to be translated at all - that's the reason that there does not appear the "English" string but the completely non-translated original (which is, of course, English, too)

This turns out to be true.
Constant variables like ${mosquito} and ${pillbug} are not translated at all.

As mentioned above, yesterday on 09/09/2017 at 06:19 FanCarcassonne changed the English translation of ${pillbug}
from "Pill bug" to "Pillbug".

Over night this change takes effects.

And today BGA expands
“moves the ${type_name} using a ${mosquito} copying a ${pillbug}”
to
"moves the Pillbug using a Mosquito copying a Pill bug".

Thus ${pillbug} is not translated at all. What we see is the completely non-translated original "Pill bug".

Since the 'i18n' array contains "mosquito" and "pillbug" there must be some other reason why constant placeholders are not translated at all.

I have no idea atm, but one question: Do you play turn based or live?
I sometimes had the mpression that there is something not ok with translation of arguments when playing turn based, but have never investigated this further.

Sorry for the length - got a bit behind.

twistytroll wrote: And today BGA expands
“moves the ${type_name} using a ${mosquito} copying a ${pillbug}”
to
"moves the Pillbug using a Mosquito copying a Pill bug".

Thus ${pillbug} is not translated at all. What we see is the completely non-translated original "Pill bug".

In other words, it's doing the exact same thing it did to start with. It's not translating Mosquito and Pill bug (or pillbug). Because they're written as variables, and the (human) translators aren't supposed to mess with variables so they didn't get translated. (Except there's no reason for them to be variables since only those bugs can make those moves.)

I also said in my first post (i.e. it's not news) there were two references to pillbug in the strings, well, actually three total:
Pillbug
Pill bug
the Pill bug

That third one is supposed to be there, cause all the bugs have a version with "the" on them that are used in a specific circumstance. But the first two seem to be the same thing to me and I don't know why there are two references, or which one it picks up. But, now there are two "Pillbug"s and one "the Pillbug," due to the changes that were just made, making it the one-word spelling. While it's consistent, a machine translator won't translate the one-word one. (At least, google and bing won't.) But that's a different issue and not really what is causing the current problem. (Side note to DrKarotte: what you are seeing as an English to English translation was only done on the 9th, after this conversation started.)

Since the 'i18n' array contains "mosquito" and "pillbug" there must be some other reason why constant placeholders are not translated at all.

If I were to make a guess, perhaps because that's "instructions" so to speak, to whatever is printing up the game log and action lines, etc. And if the game is initially done in English, it might need to have that in English. "${type_name}" is giving an instruction to pull up the bug name that is needed there, and if it were translated, it might not understand it. By being in English, it knows to dig up the string for, say, Queen Bee, if that's the bug just played. It understands "type name" but doesn't understand it in German. However, when it goes to grab the variable, Queen Bee, it pulls it from the correct location, and that word has been translated, and gets filled in with the correct translated word. OTOH, I could be full of it, because maybe it's just reading original instructions and not trying to read translated instructions. We need someone to explain this, in plain English. (Not in "code speak.")

Everything else is just text and the programming doesn't have to "read" that. It just needs to print it, and then fill in variables with appropriate words. This makes a kind of sense because it's like using a cell reference in Excel. And it's also a bit like the difference between using a formula vs something you want as just text. Excel doesn't care what text you write - it just prints it as is.

However, it's a good idea to have variables like ${mosquito} and ${pillbug}.
The reason is the following:
Suppose ${pillbug} is translated by "Kellerassel" in German. Later on it is realized that this word is way too long and that "Assel" should be used instead. If there was no variable ${pillbug} changing it to "Assel" would require a great amount of typing. With the variable a change at one single place is sufficient.

Except that ${pillbug} isn't being translated, so going to the source where "pillbug" is translated isn't doing the trick. Fix that (easy) source and it won't fix it, because it'll still say ${pillbug} and not be translated. And there isn't going to be a great amount of typing to fix that. This problem is only in two places, so basically two extra times to type it as Assel.

I'm not even convinced that DrKarotte's method of "marking" them would work. (But that's based on my interpretation of "marking" them and I could be wrong.) If it's marked as a string to be translated, if the ${} isn't removed, the translators still won't translate it. Unless of course someone directly tells them to.

I basically see 3 solutions:
*Remove the ${} - and I didn't necessarily mean in the translation string itself when I suggested that before. I would think you'd do that wherever the original comes from, which would then automatically change it in the translator. (Of course, I don't really know how that is done.)
*Change them all to "type_name" - I am assuming this should work. I don't think they need to be variables, but they could be made that way and then the correct words should be inserted for both mosquito and pillbug.
*Just let everyone deal with reading those words in English.

I should add one reason that removing ${} makes sense is because there are other places that refer to specific bugs that are just written out and not used as variables:

You can't move a piece under a beetle.
In tournament play you can't move the queen bee first.
The queen bee is surrounded.

Not exact quotes, but "beetle" and "queen bee" are used there, not ${type_name}, because they only refer to those bugs under specific circumstances. Those should be translating OK.

I don't see why the mosquito/pillbug situation is any different. It almost seems like it was just an error in consistency? Maybe there was a reason for it. Be nice to have the developer on this and see what the reasoning was on this.

Boy, we are an anal bunch.

I do not see any reason to work with variables in this string, too, from the point of view of a developper.

There is another string: "You cannot move a piece that was just moved by the Pillbug, or move with the Pillbug a piece that just moved" - working fine without variables.

It would be interesting to know why the translation of "mosquito" and "pillbug" is not working here. The kind of reference is just the same as with "type_name".

I do not see any reason to work with variables in this string

The main advantage of constant placeholders like ${pillbug} is CONSISTENCY:

If the game was properly set up from the very beginning all string would read like
"You cannot move a piece that was just moved by the ${pillbug}, or move with the ${pillbug} a piece that just moved"
and there would be one single variable
${pillbug} = "Pillbug".

If it was done this way no one could ever break consistency by editing a translation string.

(At present we do have LOTS of inconsistencies since many strings got translated in a different manner.)

DrKarotte wrote:It would be interesting to know why the translation of "mosquito" and "pillbug" is not working here. The kind of reference is just the same as with "type_name".

No, it is not.
${type_name} is handled by the game logic.
If the actual piece moved happens to be a grasshopper the game logic replaces ${type_name} by something like ${grasshopper?}.
It then manages to translate the variable to something like ${grasshopper-French}.

On the other hand ${moscquito} and ${pillbug} are not translated to ${mosquito-French} and ${pillbug-French}. That's the trouble.

At the end all variables are just expanded: ${pillbug-French} to "Cloporte" and ${pillbug} to the (old and hard coded) "Pill bug". That's what we see.

I would have a look at the source code of the game logic to see what it actually does with ${type_name}. It does it the right way.

twistytroll wrote:The main advantage of constant placeholders like ${pillbug} is CONSISTENCY:

If the game was properly set up from the very beginning all string would read like
"You cannot move a piece that was just moved by the ${pillbug}, or move with the ${pillbug} a piece that just moved"
and there would be one single variable
${pillbug} = "Pillbug".

If it was done this way no one could ever break consistency by editing a translation string.

I get what you're saying there. It gets written Pill bug in one place and pillbug in another. (Which already happened.) But trying to do ${pillbug} = "Pillbug" - it seems to me that would have to be programmed individually, where as ${type_name} already works and only has to be programmed once to pick up the name from the "database of bug names." If anything, maybe they should all be like that. (Which is a solution.) Keep in mind, ${pillbug} is not translating, so that is obviously not working.**

(EDIT: **It occurs to me that maybe that should work, i.e. putting a bug name into a variable should still copy it out of the "database of bug names." It'd be a bit like f(x) where x can = 1, 2, 3 or 4 (your database), then if you write f(2), it should still pull up the 2 from the database. But, that depends on whether it can work that way or not, and I wouldn't have a clue.)

(At present we do have LOTS of inconsistencies since many strings got translated in a different manner.)

Yeah, I'm totally aware of that. Even the English isn't consistent, and sometimes just due to carelessness, and randomly changing things without really taking the time to look at it. Or even just not having time to get through it all, especially one with lots of pages of strings. And some of the non-English translation inconsistencies may be due to the English not being consistent to start with.

Part of the trick is finding all related things. I think this is actually one of the dangers of "fixing as you happen to see something," because then everything related to it doesn't necessarily get fixed. (I usually don't even do that except for obvious typos and such. I try to find the time to go through it more carefully and find related pieces.)

DrKarotte wrote:It would be interesting to know why the translation of "mosquito" and "pillbug" is not working here. The kind of reference is just the same as with "type_name".

No, it is not.
${type_name} is handled by the game logic.
If the actual piece moved happens to be a grasshopper the game logic replaces ${type_name} by something like ${grasshopper?}.
It then manages to translate the variable to something like ${grasshopper-French}.

Yes, this. In those two strings it doesn't have ${type_name}.

Someone definitely needs to look at the code itself. I can only look at strings and use logic. (Though I do have a decent sense of logic.) And DrKarotte has done developing here, but doesn't know the rules of this game. Though there's really only a couple of things you need to know. What we really need is an original developer. I know it's difficult to look at someone else's stuff.

Well, this thread got quite lengthy quite fast

1) Machine translation is used only for news posts (for languages other than English and French. So no machine translation issues here.
2) For consistency, the rules should be referred to in order to see if spelling should be "Pill bug" or "Pillbug".
3) When a string isn't correctly translated, it is a game bug that should be reported in the bugs for this game in order to catch the attention of the developer. There is a 'translation missing' category when reporting a new bug.

Use of variables or direct use of Pillbug/Mosquito in the strings to translate is more a matter of development style than something else. I probably would have used directly Pillbug/Mosquito rather than using variables, but there were many successive developers taking part in the development/maintenance of Hive, so the style can be different here and there.

As I already have written: I have got access to the hive code. But I cannot change anything there, of course.

For the BGA framework, ${type_name} and ${pillbug} are 100% the same thing: arguments in a string which have to be replaced by a value. What this is is NOT chosen by the framework but by the dev. The dev also names the placeholders; this could also have been ${kellerassel} or ${dajkhkjashakjshsjadhasdh}

In our case ${type_name} is replaced like this

'type_name' => $this->token_types_untranslated[$type]

and ${pillbug} like this:

'pillbug' => $this->token_types_untranslated[7]

(Don't care that there is written "untranslated")

Both refer to the same array defined at another place which contains the names of all the critters. The difference is that the pillbug refers to the same "box" (no. 7) all the time while "type_name" can take the value of different animals.

As the i18n array contains all arguments used and the critter array is set up properly there must be something wrong at another place.

I have just 2 more ideas:

1) There is a problem with namespace. The string "pillbug" is used at different places. Someone with write access could test this and change ${pillbug} to ${pillbug_tr}
2) The code running on the dev site I have access to is not the same version as the code running on BGA.

About using variables with constant values: I have written: From the dev point of view.