> I would not duplicate games names under different language sections. This will be a > horrid nightmare to support on frontends because there's no way to know what is the > correct language for those games.
Actually it's the other way around. As-is it'll be more complex than it should be.
You are looking at the problem backwards. In other words you are expecting the user to already know the clone name in question and then read it's language value. Well in most cases if you know the clone name, you already know the language as it's abbreviated in the rom name. That's like when your teacher at school would tell you to look up a word in the dictionary if you didn't know it's spelling... that's a little hard considering you don't know how to spell it!
What I'm proposing is that a front-end would only list the parent roms. The front-end would also have a region setting. When the user went to get more info on the game/and or launch the game, it would read the ini in the region section selected and automatically be re-routed to the rom the user actually wants instead of just the parent rom. That means no more manually adding pacman to a gamelist, ect...
And you would still need the language.ini that you've currently built. That's how you ultimately determine the language once you've figure out which rom the user wants. I'm saying there needs to be a region.ini as well.
With my method you make a single call to get the proper rom and an additional call to get the language. With yours you would have to first get a list of a parent's clones, then read the language for each clone, then pick the best match.
Edited by HowardC (05/07/12 08:43 AM)
|