Displaying different graphics depending on selected translation

[Cone Arex]

Hello.
I have a problem regarding the use of translations. Up to now, I have used

Code: ags

if (Game.TranslationFilename == "English")
{
        // Do stuff
}

to check for translation and display different graphics for different translations. But this doesn't seem to work all the time. There were people who saw the untranslated graphic of note despite having an active translation. While testing, I've noticed that the above checking never works when playing the game with the Linux, Android or ScummVM ports of AGS.

Someone told me to first use IsTranslationAvailable() and then compare strings to check which translation is used.

Code: ags

if (IsTranslationAvailable())
{
        if (GetTranslation("Bertholds Rückkehr") == "Berthold's Return")
        {
                // Do stuff
        }
}

I can confirm this works all the time or least I've yet to encounter problems with it. Thing is, that it isn't really good coding style.

Any advice? What is the "correct" way to display graphics depending on the selected translation?

[Crimson Wizard]

But this doesn't seem to work all the time. There were people who saw the untranslated graphic of note despite having an active translation. While testing, I've noticed that the above checking never works when playing the game with the Linux, Android or ScummVM ports of AGS.

To clarify, are you saying that this works on Windows, but not on other ports? If so then this sounds like a bug with certain ports.

Could you tell which version of AGS are you using? Is "English" translation not default one, and present as a TRA file with your game?

[Cone Arex]

To clarify, are you saying that this works on Windows, but not on other ports?

Yes. But I must point out that other people als had the issue that graphics weren't translated. I don't know if they were using windows or not.

Could you tell which version of AGS are you using? Is "English" translation not default one, and present as a TRA file with your game?

I'm using AGS 3.5.0. Yes, English isn't the default one and present as TRA file.

[Crimson Wizard]

There have been a bug once where Game.TranslationFilename would always return an empty string, making check in scripts impossible. But I don't remember exactly where it was introduced (it was fixed in 3.5.1 - Patch 1).

If you or another user know the actual case where graphic is not changed for translation, and have a save made around that moment in game, I could perhaps test this under debugger and see what's happening.

[Crimson Wizard]

[REDACTED], sorry, nevermind.

[heltenjon]

But I must point out that other people als had the issue that graphics weren't translated. I don't know if they were using windows or not.

I used windows when I got the "German graphics".

[Cone Arex]

But I don't remember exactly where it was introduced (it was fixed in 3.5.1 - Patch 1).

I upgraded my game to 3.5.1. Patch 4 but it doesn't change anything.

I used windows when I got the "German graphics".

Thx for your information. Do you happen to remember if the name in the title screen (not in the title window) was also untranslated? There are only these two graphics that are checked for translation.

If you or another user know the actual case where graphic is not changed for translation, and have a save made around that moment in game, I could perhaps test this under debugger and see what's happening.

Doesn't need a save. The titlescreen itself has a translated graphic. I also know that the same problem exist with another game in the titlescreen and the packing list as it used the same method to check for the translation.

[Khris]

I checked the available download (June 24, 2020) on Windows and translating the title screen worked fine for me.

[Crimson Wizard]

There's a potential reason that may cause this problem. The way AGS works, the translation name will be set to whatever is passed to ChangeTranslation command in script, or whatever is set to "translation" option in config which it reads on startup. That is, if you pass "English" then the translation name will be "English", but if you pass "english" then it will be "english".

Comparing two strings using "==" operator in script uses case sensitive comparison. Which will fail if translation is initialized as "english" and compared to "English".

To avoid such problems you may try using case insensitive comparisons using String's CompareTo function, which is case-insensitive by default:

Code: ags

if (Game.TranslationFilename.CompareTo("English") == 0)
{
     // change to english gfx
}

This code may of course be simplified by testing translation only once at startup, or when the language is changed in game (if you have such option), and storing result in your own global variable. Then you may check your variable instead.

[Cone Arex]

I've already had the idea that the problem is case-sensitivity. 
I've now tried your code with CompareTo and in the past tried by just checking all lower case "english" as well as with an initial upper case. Nothing changes. It still works with Windows but nothing else. Interestingly (at least for me): The .tra file is spelled with all lower case, but the check only works with an initial upper case "English". Checking for "english" will not work with the case-sensitive == operator despite the file's name.

[heltenjon]

I used windows when I got the "German graphics".

Thx for your information. Do you happen to remember if the name in the title screen (not in the title window) was also untranslated? There are only these two graphics that are checked for translation.

From the other thread:

There is also a note on the kitchen door that is still in German.

I did translate the note on the door, but I also had the issue that doesn't load the correct graphic sometimes. Is the title screen graphic also untranslated ("Bertholds Rückkehr" instead of "Berthold's Return")?

Yes. The intro "types" in German at first, and then switches to the English text. Mind you, I didn't touch the setup, so I may have neglected to do something.

I can't remember the details more than that.

EDIT: Downloaded again and retried. The title screen says "Ruckkehr", the typing right after pressing start is in German, but switches to the finished English text when the typing is done, and the note on the door is in German.

[Cone Arex]

Ah, I now understand what meant with "typed". You mean the introtext that is typed after you pressed Start. (The text is hardcoded because it's created dynamically.) I always thought the meant the title in the window.  Thx again.

[Crimson Wizard]

The .tra file is spelled with all lower case, but the check only works with an initial upper case "English". Checking for "english" will not work with the case-sensitive == operator despite the file's name.

AGS complicates this in many places. The filename's case is not important, what's important is how it is written in the config file. Winsetup.exe has an additional quirk: it always capitalizes the first letter of the translation name, probably for backward compatibility reasons (because people in the past used to spell translations with capital letter in scripts). This means that if you are using winsetup, then the language will be set with first capital letter.

You may test this by setting up language in user config file by hand in small letters (on windows user config is located in %USERPROFILE%\Saved Games\<name of game>).
Alternatively it's also possible to test using Game.ChangeTranslation command in script.

[Crimson Wizard]

Oh, Cone Arex, another thing that I forgot to mention, you may display the value of Game.TranslationFilename on screen, either with Display command or on a label.
If it has unexpected value, then we'd have to find out why. If it has a proper value, then there might be something wrong with the game script.

[Cone Arex]

Finally, some progress. I displayed the output of both Game.ChangeTranslation("English") (which doesn't change anything regarding graphics) and Game.TranslationFilename.CompareTo("English"). ChangeTranslation correctly returns 1, while TranslationFIlename returns -101 under ScummVM, which is the same value that is returned under windows if no translation is selected/the default language is used.

[Crimson Wizard]

while TranslationFIlename returns -101 under ScummVM, which is the same value that is returned under windows if no translation is selected/the default language is used.

Sorry, i am bit confused; TranslationFilename is a string, how do you get "-101"? ...or is this a result of Compare?

What I meant, it could be displayed as:

Code: ags

Display("translation = %s", Game.TranslationFilename);

[Cone Arex]

Oh, yes I misunderstood. -101 is of course the output of CompareTo.
The output of Game.TranslationFilename is indeed an empty string if played under ScummVM, but "English" when played under windows.

[Crimson Wizard]

The output of Game.TranslationFilename is indeed an empty string if played under ScummVM, but "English" when played under windows.

ScummVM is not precisely 1:1 with ags engine, and it may have its own bugs (also it's likely more in sync with some wip stage of 3.6.0 engine now).

I think it's best to try ags ports first to see how they behave.

[Cone Arex]

I tried it again with the Linux port and it has the same output. An empty string for TranslationFileName. (I used ScummVM for it ease of use. As itt has all the exact same issues as the Linux and Android ports of AGS.)

[Crimson Wizard]

Okay, I tested this on linux now with "Bernhold's revenge", and see the issue: the game's subtitle on a intro screen is displayed in german but the character speech etc texts are in english.

Changing "translation" option in config file from "english" to "English" fixes it though... I'd suppose this is the case sensitivity problem that I mentioned above, but since you said that Game.TranslationFilename becomes empty, not sure what is going on at this point.

Could you also tell, what version of a linux port are you using and where did you get it, to make sure we're testing same thing?

[Khris]

Here's a way that doesn't require awkward string comparisons and works with ScummVM:

Code: ags

function room_Load()
{
  String slotString = GetTranslation("2 English language sprite in room 1");
  oLanguage.Graphic = slotString.AsInt;
}

In the translation file you use (text translation optional obviously)

Code: ags

2 English language sprite in room 1
3 Deutsches Sprach-Sprite in Raum 1

Since this only relies on existing and working textual translations, this is 100% guaranteed to work with any environment that supports them.

(If there's going to be dozens of translation specific sprites it's probably better to store the sprite numbers in your code and do the language determination in a function using the above mechanism and a single line)

[Crimson Wizard]

In regards to the Game.TranslationFilename, to be certain I did another test with a dummy game that displays TranslationFilename on screen. Tried Linux ports for the latest builds of 3.5.0, 3.5.1 and 3.6.0, and all of them work correctly, displaying the selected language...

[Cone Arex]

Could you also tell, what version of a linux port are you using and where did you get it, to make sure we're testing same thing?

I just build the game for Linux and then executed the ags64 file. (Is this the right way? I always run into issues with ags and linux.) Version is ACI version 3.5.1.11.

In regards to the Game.TranslationFilename, to be certain I did another test with a dummy game that displays TranslationFilename on screen. Tried Linux ports for the latest builds of 3.5.0, 3.5.1 and 3.6.0, and all of them work correctly, displaying the selected language...

Strange. I did the same thing and it doesn't.

[Crimson Wizard]

Could you also tell, what version of a linux port are you using and where did you get it, to make sure we're testing same thing?

I just build the game for Linux and then executed the ags64 file. (Is this the right way? I always run into issues with ags and linux.) Version is ACI version 3.5.1.11.

I think you should run the script with the game's name located one directory above "data", but I don't know if there's much difference.
I usually compile linux engine from the source, but now tried to use editor's feature, and has same (correct) result as before.

Could you upload your game you made for linux for me to check?

[heltenjon]

I tried Crimson Wizard's method on the Windows version - changed "english" to "English" manually in the config file, confirmed it in setup, and then I got the correct English title screen plus the two other instances. So that fixed it, it seems. However, afterwards I changed it back to "english" in order to reproduce the error again, but now it keeps working correctly, both in German and in English, even with the lower case spelling in config. Go figure. (Windows 10 Enterprise.)

[Crimson Wizard]

However, afterwards I changed it back to "english" in order to reproduce the error again, but now it keeps working correctly, both in German and in English, even with the lower case spelling in config. Go figure. (Windows 10 Enterprise.)

Are you changing default config in the game dir, or user config in the %USERPROFILE%/Saved Games/<game name>? If you save in winsetup at least once then translation is written to the user config.

[heltenjon]

However, afterwards I changed it back to "english" in order to reproduce the error again, but now it keeps working correctly, both in German and in English, even with the lower case spelling in config. Go figure. (Windows 10 Enterprise.)

Are you changing default config in the game dir, or user config in the %USERPROFILE%/Saved Games/<game name>? If you save in winsetup at least once then translation is written to the user config.

Ah! I did it i the game dir.

[Cone Arex]

Could you upload your game you made for linux for me to check?

https://storage.conequest.de/mmm/ConeArex_TranslationTest_Linux.zip
I can also upload the source if needed.

[Crimson Wizard]

Could you upload your game you made for linux for me to check?

https://storage.conequest.de/mmm/ConeArex_TranslationTest_Linux.zip

Well... This starts without translation, but if I set up "english" in acsetup.cfg, run ags64, and it displays "Translation Output: english". If i set it as "English" with capital E, then the title also switches to "Berthold's Return".

[Cone Arex]

Ahh, now it works. If I set the language manually in acsetup it works with the Linux port. The whole thing was just a mistake of the language not being set correctly. I set the language by Building the exe and then running winsetup through the editor. So the selected language was not written in the acsetup.cfg that the Linux (and probably Android) port use. And I guess ScummVM is using it's own set configs. So, for the foreseeable future I will use a method like Khris suggested, as that should work everywhere.

If i set it as "English" with capital E, then the title also switches to "Berthold's Return".

Yeah, I was still using case-sensitive check in the dummy game.  So that should be an easy fix.

What I still not get is why the actual translated text is still loaded without the language being set correctly in acsetup and how heltenjon got the error under Windows. 

In any case, thank you so much for your help!

[Crimson Wizard]

I set the language by Building the exe and then running winsetup through the editor. So the selected language was not written in the acsetup.cfg that the Linux (and probably Android) port use.

What you probably need to do instead is use Default Setup page in the editor, available since 3.5.0 also. That specifies the contents of the default config found with the compiled game.
Winsetup only saves user config, which is personal for current OS user (this is how it works since 3.3 or 3.4, the reason is that game may be installed in a read-only location, or where current user does not have write permissions, so winsetup now saves in common user document folders).

But of course this will only create initial config. For having their own players should either edit config file by hand using instructions, or a third-party setup program (I heard some people already made crossplatform ones in the past, but sadly they are not part of AGS distribution still).

What I still not get is why the actual translated text is still loaded without the language being set correctly in acsetup

Yes, this confuses me too.