Foreign language support in GRFs

[minime]

In the past month, we (the members of Tycoonez.com:munity) have been working on GRF based localization of TTD.

In the process, I've made a set of files that can be used to set the game locale (using action 0D, variable 9F). They are mostly intended for set developers, to allow them to switch between languages while the game is running.

To use them, put

Code: Select all

newgrf/locale/locale_us.grf 1 !
newgrf/locale/locale_de.grf 1 !
newgrf/locale/locale_fr.grf 1 !
newgrf/locale/locale_es.grf 1 !
newgrf/locale/locale_ru.grf 1 !
newgrf/locale/locale_cz.grf 1 !
newgrf/locale/locale_sk.grf 1 !
newgrf/locale/locale_no.grf 1 !
newgrf/locale/locale_en.grf 1 !

at the top of your GRF (the 1 turns off forced activation in title screen), and then switch the languages on the fly. Nice example is the DBSetXL, where the names of vehicles change to reflect the current language (for the 5 originally supported languages).

And this brings me to a problem I have discovered while playing with this. I have found that if I switch the language to, let's say czech, the names of DBSetXL's trains revert to original TTD vehicle names, which as you may imagine is rather confusing.



Even though it may seem so, it is not a DBSet specific problem. While the old method of defining the language [for which the string is intended] used a bitmask, the new one uses a single value - hence it is no longer possible to easily set the same string for multiple languages (like what you could with 0x1F).

Two possible workarounds (solutions not requiring modifications of patch) come to mind:

1. Redefine the generic strings of the corresponding vehicle IDs. While it may take a little work finding the right string IDs, this seems to be the simplest solution.
2. Use some combination of loops and calculations to set the default string for all the language IDs that you do not have a translation for. This could get pretty complex, and possibly have performance issues (there are 64 languages after all). Doesn't look too good.

The first one actually looks fairly decent.
Other possibility could be using an extra GRF to supply the strings/translation.

What are your opinions about this? I'm concerned, since now I can't really use the new language features (i.e. I have to pretend it's an english game, although the interface is all in czech) without breaking most of the existing sets.

[Patchman]

Actually, using a loop around generic action 4 sprites is not going to work correctly.

I think possibly the easiest way would be for me to introduce a language check that always succeeds. Then you'd first set all strings using this, and later override the language specific ones if they exist.

That would be easy for me to code too.

[minime]

Actually, using a loop around generic action 4 sprites is not going to work correctly.

Ok. The more I thought about that option, the less I liked it anyway.

I think possibly the easiest way would be for me to introduce a language check that always succeeds. Then you'd first set all strings using this, and later override the language specific ones if they exist.

That would be easy for me to code too.

That's certainly the best solution. If you'd be willing to do that, that would be wonderful.

EDIT: Ooops, missed a slash there.

[Patchman]

Done.

[minime]

Thank you.

I have seen you have updated the wiki, and I added a note mentioning that this feature is available from version alpha 73. I hope I guessed the version number right, if not, feel free to change it.