Multilingual Oolite

[Commander McLane]

Still working on the planet-description strings. It's a real headache to transfer everything into another language.

In your descriptions.plist add the following lines (preferably under the Intro1 screen section, to keep things referring to the same screen together)

I would love to keep things together, but I'm using PlistEdit Pro, which automatically sorts the keys alphabetically, even if it reads a plist created by another program for the first time.

Anyway, I'll keep you informed on my progress.

[Commander McLane]

@another_commander: In your italian descriptions.plist there are a lot of entries with leading and closing SPACE, like this:

Code: Select all

	<key>gameoptions-back</key>
	<string> Indietro </string>

For what reason? Is it to make them align centered?

[another_commander]

Mostly cosmetics, really. This is the text that appears on the game options screen, so when you select it, it looks better if the red selection bar "surrounds" it completely. This is what the spaces do. It was hardcoded with the spaces before and after, so I just kept it consistent.

[Commander McLane]

Okay, thanks. And perfectly understandable.

[zimmemic25]

i dont understand anything!

is it an OXP, a new version, or what???

i think if you could make plists with pairs of english and any other language like:

Code: Select all

<key>Food</key>
    <string>Essen</string>

(german example), you could make a plugin/OXP/new version which can read this "dictionaries" and translate every text which wants to be printed. this would include words like "a" (ein) and "the" (der/die/das), so it could real-time translate EVERYTHING. it would solve the OXP problem and the identifiers (stations/goods) would be the same like before, they would just been translated if they are shown to the user.

you could make a new folder ("Langs") and a config-screen selection, then the users could make OXPs with new translations (eg. into ORB language "fhu dku shiu nbz guh grb!")

[another_commander]

@zimmemic25: I invite you to try it and see for yourself why it does not work the way you describe

This entire project is a work in progress, targetting Oolite version 1.71 and above, i.e. the next major - currently only on SVN - version. It involves changing quite a few things in the internal structure of the game and adding the capability of completely translating the entire game to a pre-selected language using revised plist files grouped in OXP folders. There is currently an Italian version (almost complete) and a German one by Commander McLane (in progress). This entire attempt is a combination of code modification + heavy plist editing and is a much more laborious process than it may appear at first.

[Commander McLane]

Actually it's not yet decided in which form language localization will be implemented. It seems that another_commander has a running Italian version, as far as the game itself is concerned. He has achieved this by simply replacing all plists that contain I/O-text with plists that are essentially the same, but the I/O-text is Italian.

Well, it's actually not that simple, as some of the text is hard-coded. So he had to remove these text bits (page titles, column titles and things like that) from the code itself and replace them with variables, which are now defined in plists. And as plists in the AddOns-folder will be read after the plists in Oolite itself, you can force Oolite to use strings in the language you prefer instead of the English ones. There is one notable exception to this, equipment.plist, whose copy in AddOns does not replace the copy in Oolite, but instead the two are merged together, but another_commander is working on that.

So the direction we are going into right now is to have one OXP per language, that will be put into the AddOns-folder as any other OXP, and replace all strings in Oolite with strings in a new language. Obviously you will be able to install only one language OXP at the time.

Remember also that we are talking exclusively about the strings that come with the original Oolite distribution. Translating OXPs would be a completely new task.

Anyway, your suggestion is surely worth considering. We could have (and each OXP could have) a Language-folder, containing multiple copies of the relevant plists (mainly missiontext.plist, descriptions.plist and equipment.plist) in different languages, with a precisely defined naming-scheme. Then the only thing we would have to do is to tell the engine which files to use. And this could be done on the options-screen. If the requested language is not present in a certain OXP, the engine could automatically fall back to the default (English).

@another_commander: Is something like this doable? I find the possibility it opens for scripters charming. The only question is: Is it worth the required re-writing of the engine? How many scripters would make use of the possibility of translating their texts? Or how many volunteers would do it for them (and for the existing OXPs)?

[another_commander]

I believe it could be done, but at least for now, I would rather not attempt any further major changes in the code. I prefer to first check that the changes we have up to this moment are actually working and do not break anything. And then, as you note, it may just end up being one of these features that take a lot of time and resources to create, but used by very few. So, I would say that it is an idea to keep in mind, but a low priority one.

Oh, and the equipment.plist merging issue is now resolved on SVN. I have completely replaced all original equipment pieces with their Italian-named counterparts in my version and it works just fine.

[zimmemic25]

with my method nobody has to translate anything.
you just have to set a replace-function on every text, which wants to be displayed.

the game text, OXPs and all other things will stay english, and ONLY the screen-output will be filtered (realtime) through the translation-plist.

so the strings stay the same, you just have to add a function like str_replace(in PHP) to all print-commands which will parse the plist and replaces all words.

[another_commander]

so the strings stay the same, you just have to add a function like str_replace(in PHP) to all print-commands which will parse the plist and replaces all words.

Which is what we are doing. Have a look at the DESC macro in the trunk source code, Universe.h:

Code: Select all

#define DESC(key)	([UNIVERSE descriptionForKey:(key)])

This is what is used to parse the plist containing the translation strings.

[Commander McLane]

with my method nobody has to translate anything.
you just have to set a replace-function on every text, which wants to be displayed.

the game text, OXPs and all other things will stay english, and ONLY the screen-output will be filtered (realtime) through the translation-plist.

so the strings stay the same, you just have to add a function like str_replace(in PHP) to all print-commands which will parse the plist and replaces all words.

Forgive me for being rude again, but this is complete and utter nonsense! It shows a really poor understanding of how languages work, if you think translating is just replacing words. Even your own small examples a few posts above show that it's far more complicated than that. Even if we just would go word by word (which we can't, because also word-order is different in different languages!), how would you translate "a" or "the" into German? Would you like to read "der/die/das" on your screen for each "the"? So how shall your real-time translator choose the correct one? And what about the infamous "food blender"? Would you understand "Essen Mischer"? The outcome of the method you are proposing here would be something like the results of babelfish (or any other internet translator) in the very beginning of its existence: Purely ridiculous and completely useless!

And by the way: What proportions do you imagine for your translations.plist? In order to match all OXPs that are going to be developed it would have to be quite complete, don't you think? Containing every English word and its translation into any other language. How many words are we talking about here? 50.000? 100.000? Half a million? And even if we confine ourselves to the simplest simple-speak, we wouldn't get below 10.000 or 20.000 entries.

So, please think twice before you propose something really stupid. We won't come around carefully translating sentences and pages of text, which is hard work. There are no shortcuts here.

[another_commander]

Further to Commander McLane's comment, I wanted to add that right now, we have something that works in the trunk and seems to work quite well, too (apart a few things that need ironing out, but that is a different story). Under no circumstances am I to scratch out the entrire lot and restart just to accomodate the personal preferences or ideas of any individual, especially ones that do not seem to be properly or carefully thought out. Thankfully, Oolite is open source, so zimmemic25, I will give you the benefit of the doubt and let you know that if you want this changed to your way, and feel you can do it, please feel free to submit a patch (my email is nikbar2004 at yahoo point com), and I will review it, test it and IF it is deemed working well enough and IF it does not break anything in the current game state, THEN I will consider commiting it to the code base.

[zimmemic25]

with my method nobody has to translate anything.
you just have to set a replace-function on every text, which wants to be displayed.

the game text, OXPs and all other things will stay english, and ONLY the screen-output will be filtered (realtime) through the translation-plist.

so the strings stay the same, you just have to add a function like str_replace(in PHP) to all print-commands which will parse the plist and replaces all words.

Forgive me for being rude again, but this is complete and utter nonsense! It shows a really poor understanding of how languages work, if you think translating is just replacing words. Even your own small examples a few posts above show that it's far more complicated than that. Even if we just would go word by word (which we can't, because also word-order is different in different languages!), how would you translate "a" or "the" into German? Would you like to read "der/die/das" on your screen for each "the"? So how shall your real-time translator choose the correct one? And what about the infamous "food blender"? Would you understand "Essen Mischer"? The outcome of the method you are proposing here would be something like the results of babelfish (or any other internet translator) in the very beginning of its existence: Purely ridiculous and completely useless!

And by the way: What proportions do you imagine for your translations.plist? In order to match all OXPs that are going to be developed it would have to be quite complete, don't you think? Containing every English word and its translation into any other language. How many words are we talking about here? 50.000? 100.000? Half a million? And even if we confine ourselves to the simplest simple-speak, we wouldn't get below 10.000 or 20.000 entries.

So, please think twice before you propose something really stupid. We won't come around carefully translating sentences and pages of text, which is hard work. There are no shortcuts here.

its not any other language, but ONE language per translation.plist!
and i WOULD translate Food to Essen, but food blender BEFORE!
so when we begin with the largest text and our plist ends with the smallest word (eg "a") we could search for the first hit and replace it.
so if we have a grammatically problem, we could add sentences, like "ship" to "Schiff" and "the ship" to "das Schiff" and "a ship" to "ein Schiff"!

we dont have to translate ALL the text, we translate sentences, phrases and words. and if something fails, we add a new translation to the plist.

i wrote words before, but we can also replace 2 words, sentences or whole pages!

and by the way: if i had the souce-code for the 1.70 LINUX version, i could try it out and test a few methods, before i post more NONSENSE!

[another_commander]

and by the way: if i had the souce-code for the 1.70 LINUX version, i could try it out and test a few methods, before i post more NONSENSE!

This is the link to the 1.70 source code for all platforms:
http://prdownload.berlios.de/oolite-lin ... 70.tar.bz2
You are more than welcome to give it a go.

[zimmemic25]

thanks