Oolite Bulletins

Posted: **Mon Jan 14, 2008 8:59 am**

How would you like your favorite game to be portable to other languages, apart from its native English? With most game strings already in external files, it is a great opportunity to try. I have started a mini-project of making Oolite fully multilingual-capable and the first attempts are more than encouraging. People building from SVN should already have seen the changes involved. The idea is that by just using a few modified plists (standard stuff like descriptions, equipment, shipdata.plist etc.), which will contain all the strings that the game is displaying, and packaging them as an OXP, Oolite will be able to switch languages on the fly. Removing the oxp would return you back to the original English, of course. As proof concept, I am currently porting the game to the Italian language.

However, since Italian is not my native language, my translation is kind of... lets say sub-standard

. If there is any native Italian speaker on the board, I would appreciate very much them checking the plists once they are done and correcting any mistakes they find. Other volunteers for other languages would be welcome to contribute too. The only thing I am worried is that it may not be possible to accomodate all syntactical idiosyncracies of every language, although an attempt to make the system as flexible as possible has been made.

Posted: **Mon Jan 14, 2008 3:26 pm**

I can volunteer for a German language version.

Although I'd like to draw your attention to a small problem: OXPs. While it is relatively easy to translate all strings in the original game, it would be a huge undertaking to do the same for all OXPs. Think of Random Hits!

So in the end for all non-English players the result would be truly multi-lingual, if they play with any OXP that gives out messages, although in another sense than you intended here. Desirable?

Posted: **Mon Jan 14, 2008 3:40 pm**

Yes, I know about the issue with OXPs. Unfortunately there is not much that can be done about it. Lets say the aim of this whole exercise would be to give a chance to players who don't speak English (very well), but would still like to have a go at the Oolite experience, even at the expense of OXPs, to enjoy the game. So, basically I am targeting the core game only with this.

As for volunteering for the German version, I really appreciate it. I would like to finish doing the Italian one first, just to be sure that it is doable. So far the biggest problem has been the planet description strings. I had to add some variations of the original ones myself for words in plural, masculin/feminin references etc., but at the end it seems to be pretty ok. I imagine for German things can be even more difficult, but if it works out, it will be worth all the effort it could take.

Posted: **Tue Jan 15, 2008 7:12 am**

I've run into another problem: commodities. We cannot translate them, as they are identified and called for by their names. So if I rename Firearms to Waffen, they're no firearms anymore.

Only solution to that: the current name of the commodities would have to be converted into a mere identifier. Then in a second step a freely choosable namestring would have to be attached to this identifier.

A similar problem arises with entity-names. A query of e.g. dockedStationName_string equal rockhermit doesn't work anymore, if I have in shipdata.plist renamed it to Einsiedlerfels or something like that.

Posted: **Tue Jan 15, 2008 7:19 am**

Both these are resolved in the version I'm working on. I can send you the files I currently have, as an example, if you want. The idea is that you are not replacing the definition keys, but only the strings containing the names displayed in the game.

But now, I've bumpled into another problem: I cannot replace original equipment items. The problem is similar to Cmdr Maegil's oxp missiles. The translated equipment items are not replacing the standard ones, they are added on top of them. So, I have both the English and Italian version of all standard equipment. This is due to the way Oolite is building the equipment list. I am looking into it at the moment.

Posted: **Tue Jan 15, 2008 7:23 am**

another_commander wrote:
Both these are resolved in the version I'm working on. I can send you the files I currently have, as an example, if you want. The idea is that you are not replacing the definition keys, but only the strings containing the names displayed in the game.

Nice!

My email is Commander underscore McLane squiggle planet point ms

But now, I've bumpled into another problem: I cannot replace original equipment items. The problem is similar to Cmdr Maegil's oxp missiles. The translated equipment items are not replacing the standard ones, they are added on top of them. So, I have both the English and Italian version of all standard equipment. This is due to the way Oolite is building the equipment list. I am looking into it at the moment.

Oh, yes. I should've been aware of this. Very nice if you can solve it.

Posted: **Tue Jan 15, 2008 9:10 am**

Be aware that the offering text of the JS version of the Trumble mission is currently hardcoded in the script. I already wondered when I saw this programming first. I should have reacted then, but better move the text for the 1.71 release to the missiontext.plist were it was.

Posted: **Tue Jan 15, 2008 11:05 am**

See this thread for my experience when working on this.

I recall finding a suitable font and having to rework the UI text routines being the biggest problems.

Regards,
David.

Posted: **Tue Jan 15, 2008 7:03 pm**

It seems to be going quite well. I think I have sorted out the handling of the arrays that was giving me headaches with the equipment lists, but want to test a bit more. Just a couple of things missing and we are there with the Italian version. I can get all that is shown below by just droppiing 5 or 6 small files in an oxp folder. The problem I see would be the languages using non standard Latin characters. Not sure how to go about that. We'll have to see.

Anyway, enough words. Screenshot time. A few words (like, marauder) has not been translated yet, anyone know how it is called in Italian?). But even things like the planet descriptions don't look that bad.

BTW, dajt, thanks for the link. Unfortunately, it looks like a font library or something like that will have to be incorporated to get the non Latin character sets in.

Posted: **Tue Jan 15, 2008 10:57 pm**

You could try "saccheggiatore" (a plunderer or reiver) -- "Il Saccheggiatore" is the title of the Italian translation of "The Wrecker" by Robert Louis Stevenson and Lloyd Osbourne.

Posted: **Wed Jan 16, 2008 2:55 am**

Very cool.

Posted: **Wed Jan 16, 2008 7:46 am**

Me wrote:
I've run into another problem: commodities. We cannot translate them, as they are identified and called for by their names. So if I rename Firearms to Waffen, they're no firearms anymore.

Only solution to that: the current name of the commodities would have to be converted into a mere identifier. Then in a second step a freely choosable namestring would have to be attached to this identifier.

another_commander wrote:
Both these are resolved in the version I'm working on. I can send you the files I currently have, as an example, if you want. The idea is that you are not replacing the definition keys, but only the strings containing the names displayed in the game.

I don't think you have resolved this. In case of the commodities the "strings containing the names displayed in the game" are the "definition keys". That's why I made the point that you have to create a definition key, which then in the second step gets a namestring attached to it. This means a reprogramming of the code, a new commodities.plist isn't enough!

With your new commodities.plist any "awardCargo: <amount> <commodity-name>"-method doesn't work anymore. In a script there will be the line awardCargo: 1 Gold. Your player gets nothing, because there is no commodity "Gold" anymore in your commodities.plist. And the engine cannot translate "Gold" into "Oro", until you have programmed it to do so. Have you done this?

To make clear what I'm talking about: Currently an entry in commodities.plist looks like this:

Code: Select all

		<array>
			<string>Food</string> <-- Name
			<integer>0</integer>  <-- Quantity at market
			<integer>0</integer>  <-- Price at market
			<integer>19</integer> <-- Base price
			<integer>-2</integer> <-- Price adjustment
			<integer>-2</integer> <-- Quantity adjustment
			<integer>6</integer>  <-- Base quantity
			<integer>1</integer>  <-- Price mask
			<integer>1</integer>  <-- Quantity mask
			<integer>0</integer>  <-- Units
		</array>

In the current game the first entry is both: Name and identifier (or definition key). Commodities are only identified by this exact string.

What we need is an additional entry in the list, in order to seperate name and identifier. So the Italian version would look like this:

Code: Select all

		<array>
			<string>Food</string> <-- Identifier
			<string>Cibo</string> <-- Name
			<integer>0</integer>  <-- Quantity at market
			<integer>0</integer>  <-- Price at market
			<integer>19</integer> <-- Base price
			<integer>-2</integer> <-- Price adjustment
			<integer>-2</integer> <-- Quantity adjustment
			<integer>6</integer>  <-- Base quantity
			<integer>1</integer>  <-- Price mask
			<integer>1</integer>  <-- Quantity mask
			<integer>0</integer>  <-- Units
		</array>

The identifier has to be the same in all language versions. This is what a script uses to award a cargo. The name would be what is displayed, and would be Cibo in Italien, Lebensmittel in German and Chakula in the Swahili version (if there will be any

).

So the commodity-handling in the engine has to be reprogrammed, in order to seperate commodity names from identifiers.

Posted: **Wed Jan 16, 2008 8:09 am**

I have tried the award gold example you used by adding the awardCargo: <amount> Oro line to the deathactions script of the treasuroid in Cargo Wrecks oxp and it works fine. Going to ship manifest lists the awarded cargo in Italian, as expected. It is the responsibility of the scripters who want to create a script in a different language to use the correct commodity types for that language. The engine does not need to translate anything, as the commodity name will be provided by the scripter in the language being used. Remember that the target here is the core game only anyway. Existing OXPs will require translation, not only for commodities, but also for almost every script action or message they generate. But once done, they do work also in the internationalized version.

But it's good you mentioned it, because I had forgotten the line awardCargo:100 Gold in the italian version of the cloaking device script in shipdata.plist. This would never award gold to the player. Has to be changed to awardCargo:100 Oro.

Posted: **Wed Jan 16, 2008 8:32 am**

another_commander wrote:
...It is the responsibility of the scripters who want to create a script in a different language to use the correct commodity types for that language. The engine does not need to translate anything, as the commodity name will be provided by the scripter in the language being used.

No. This is utterly user-unfriendly. Who is taking care of backward compatibility? Your Italian user won't be able to use any existing script anymore. (At least none that does anything with cargo.) He would be confined to those scripts only whose creators choose to do an Italian language version as well. Completely unrealistic.

The commodities.plist-problem is not just about cosmetics. It ruins playability. And also back then in the thread dajt was mentioning, Draco_Caeles raised the problem and suggested basically the same solution as I do now. Unfortunately nothing has come out of it.

Posted: **Wed Jan 16, 2008 8:58 am**

Commander McLane wrote:
Your Italian user won't be able to use any existing script anymore. (At least none that does anything with cargo.) He would be confined to those scripts only whose creators choose to do an Italian language version as well. Completely unrealistic.

Any script outside the core game ones will need to be redone, because any existing messages will have to be translated, so script editing will occur one way or another. If one will have to edit anyway, might as well edit the commodities. As a first step in the attempt I have made, I have set a target to get the standard game working. OXPs are a secondary target. But I will consider the solution you are proposing. Although it would defeat the purpose of localizing the game, I can see that a non-English speaking user might not care about messages and might just want to try out an oxp regardless of the language used. I'll have a look into the feasibility of the solution you are suggesting and will apply it if possible. But not before I've taken a couple of days off

In the meantime, please let me know if there are any other situations like this that should be looked at. Better do everything in one go, if possible.

Oolite Bulletins

Multilingual Oolite

Multilingual Oolite

Some work was done on this