search

batocera-linux / batocera-emulationstation

MIT License
316 stars 244 forks source link

Region "jp" and lang "en" gives unexpected md_flag setting compared to other lang/region combinations #1637

Open rallyrabbit opened 9 months ago

rallyrabbit commented 9 months ago

Concerned project

Batocera

Distribution Version

Batocera v38

Architecture

Linux

Issue description

Unexpected behavior for md_flag for themes.

As an example: if region=us, lang=en then md_flag will load american flag for "us" if region=uk, lang=en then md_flag will load uk flag for "uk" you can even go a step further and get expected behavior of region="de" and lang="en" to get a german flag, french flag, etc. Which is expected behavior.

For the japanese flag, it seems to required region=jp and lang=jp, unless it is region=jp and lang=en which shows the us flag. This seems to be a problem, is it does not allow hacks or translations which are source japan games to show japanese flag. The japanese region has an override that doesn't seem to apply to other lang/region pairs which feels wrong. Also some japanese released games are in english.

This seems related to LangInfo::getFlag if (region == "jp" && langs.size() == 1 && lang != "jp") { if (lang == "en") return "us";

    return lang;
}

Logs and data

No longs, completely repeatable and predictable

fabricecaruso commented 9 months ago

Can't help without having the full file name & the system name.

rallyrabbit commented 9 months ago

Gosh sorry, es-app/src/LangParser.cpp

fabricecaruso commented 9 months ago

full file name = name of the file of the game !!!!!!!!!!!!!!!!!!!

fabricecaruso commented 9 months ago

Well.. What's the name of the concerned files ?

rallyrabbit commented 9 months ago

I'm going to be honest, I am not sure why the game matters. This is why I haven't responded. There's a gamelist.xml for any game which is where you can set region and language. The fact of the matter is LangInfo::getFlag has unpredictable output. Sometimes it's response results in md_flag being based upon the lang tab in the xml, sometimes it has overrides for region and lang tags (this makes sense considering there are multiple regions for English, Spanish, French, Portuguese, Arabic). I reported the inconsistency.

For instance:

None of this is wrong so far.

None of this is wrong so far.

- region=jp, lang=en; results in md_flag for us

This is the one that is wrong, this is easily testable by modifying a gamelist.xml and using the variations on the region/lang tags.

fabricecaruso commented 9 months ago

It's intentional. See the original commit : https://github.com/batocera-linux/batocera-emulationstation/pull/785/commits/dfae3bef364fe9545ecae46347add546a725e07c I can't remember the context and who reported this but I can understand the logic : A jp game should be in jp lang. If lang is en, it's because it was probably converted/is a translation, then the flag correspond to the language the game shows.

Do you have concrete exemple of games ( including filenames ) where it's a problem ?

geogolem commented 8 months ago

It's intentional. See the original commit : dfae3be I can't remember the context and who reported this but I can understand the logic : A jp game should be in jp lang. If lang is en, it's because it was probably converted/is a translation, then the flag correspond to the language the game shows.

Do you have concrete exemple of games ( including filenames ) where it's a problem ?

There is an NES game one would expect to have this problem: Zunou Senkan Galg (Japan) (En)

However, this game does not have the problem because in the code, it first adds jp to the language string, and sets region to jp (as hard region)... then adds language en to the language string,

so langs.size() would be 2 in this case, and not 1... So the correct Japanese flag is returned.

Looking through the code it seems the only possible cases where this situation could arise, is if the filename itself doesn't specify a region at all, and only specifies En for the language and the rom in question falls into one of the categories where LangInfo::parse sets the region to jp for some other reason (JapanDefaults or file ends in j.zip etc.) --> I'm not too familiar with these cases and so I don't really have any input on if this is how it should be or not but I have been investigating a similar but unrelated issue which led me to investigate this and I just thought I would post/share what I found in case it might benefit this discussion or anybody who falls upon it.

fabricecaruso commented 8 months ago

Honestly, I don't really care about all this.

Having a perfect detection based on file names will never be possible anyway as there is no clean convention.

Plus, region and languages metadatas. can be edited manually and are only used to display a flag in the UI. If you are not fine with what was detected, you still can edit yourself manually.

Or, if you are convinced you can write a perfect algorithm, then propose a PR.

I personnally don't really care.