Oolite Bulletins

Think the main difficulty with auto-translation is context. Even in my own native English I had to fiddle a lot with the random generator in Random Hits to get messages that make sense (in as much as deadly arts graduates and edible poets make sense) and at least have a semblance of grammar. Eg in English "precious" can mean well loved or valuable. In another context it can even mean pedantic or pretentious "a precious arts graduate" could mean someone who is always going on about the meaning of modern art works! So in English I can use this word in multiple contexts "wanted for hurling my precious daughter into a massive food blender" and "suspected of slashing my precious glove puppet with a nine-bladed sword" both make sense. But if you translated precious as "valuable" then it works in one context but not the other. An / a are also tricky in English when your trying to do somthing procedurally "an edible poet" as against "a deadly goat" but other languages don't have an equivilent rule or the rule is different. Plurals are also a problem. In English you can generally get away with just adding s, but they're are still loads of exceptions to the rule "wolves" not "wolfs" "fish" not "fishs" etc. "The" as well need s the computer to know what word is coming next. In English it doesn't matter as "the Lavian Grand Inquisitor" or "the Getevian Arch Bishop" both use "the". In French though it would need to be le or la. Always fun to fiddle though, so best of luck!

Well spoken, LittleBear. And this is indeed why I'm currently toasting my brain, searching for clever solutions for the planet-descriptions.

And a "correct" literal translation is only the starting-point, anyway. In many cases it would be wrong and/or nonsense, e.g. with idiomatic phrases (one simple example from the beginners-course: in German it isn't "raining cats and dogs", but "es schüttet wie aus Kübeln" (something like "it pours like emptying buckets")).

It get's even more complex and complicated when we come to mission-texts, because in the best of all worlds the translation would not only transfer the direct meaning of a word or a sentence, but also (and more important!) the allusions and puns contained in that sentence. And Oolite is quite rich of these! So, if there is for instance somewhere in a text a pun referring to a phrase from a popular English TV-series of the 70's that happens to be completely unknown in Germany, it makes no sense to "translate" the words. The translator would have to find a similar pun referring to a phrase in German popular culture. Chances are (at least in my case; I have mentioned my lack of familiarity with English popular culture several times) that he misses the pun completely.

if we put ALL texts (from core) to a plist, we could edit this texts (the WHOLE text). so we had a multilingual core program. then we could all translate our favourite OXPs.

Well give it a go, but you may run into context problems and end up "looking a bit of a Smeghead". Try auto-translating that and you'll get some very strange (and highly misogynistic / gynaecological) results that the phrase does not have in its native (Liverpool) dialect!

sorry, but the source doesnt compile at my Linux.
i cant try it.

@zimmermic: Putting all texts into plists and translating them is exactly what we are doing right now. So, please, just shut up if you don't understand anything, and let us just do our work.

Or, to put it into a German phrase that has become famous: Wenn man keine Ahnung hat, einfach mal die Fresse halten!

McLane wrote:

So, if there is for instance somewhere in a text a pun referring to a phrase from a popular English TV-series of the 70's that happens to be completely unknown in Germany, it makes no sense to "translate" the words. The translator would have to find a similar pun referring to a phrase in German popular culture.

The same is valid for a French comic book like "Asterix and Obelisc". The text writer often uses words with double meaning. But that is in French and on translating a lot of those jokes are just left out, as in the new language the word-game was impossible. Only some translators (like the English) added new word games on places were the original had none. Just to compensate for other placed he could not make one in English.

Those types of translations are the best (and the most difficult). Not literally translating but translating in the sense of the original. Such a thing is only possible by hand.

An extra problem arises with completely filled screens. The new translation must also fit on that screen. English is a more compact language than Dutch or German. It is likely that a computed translation will be longer.

ok. i didnt understand the meaning of the first posts, but thats what i thought too.

With Ahruman's latest 8-bit text encoding improvements, this can really take off. See below some examples of Commander McLane's work-in-progress German version of Oolite. Note that to go from the Italian version to the German one, all I had to do was remove the Italian.oxp from AddOns and replace it with the German.oxp one. Easy. Game translated.



So, do we have any takers for other languages?

I remember something bothering me about this thread when I first read it, but I got distracted. This discussion seems to have been dropped, but it’s important:

Commander McLane wrote:

And sorry if I'm annoying you with insisting on the commodities issue. But it is an issue. We have to distinguish between cosmetics and gameplay.

I strongly agree here. Requiring scripts to use localized names to identify commodities is unacceptably bad design.

However, I don’t agree with the idea of putting the user-readable name at the top of the commodities.plist entry; this would introduce unnecessary backwards-compatibility issues. A better approach would be to add a "misc stuff" dictionary as an optional last entry, in the same way as done in equipment.plist. However, I think it’d be simpler to put the localized names in descriptions.plist, with keys like "COMMODITY_Food" = "Food", and have a CommodityName() function to look these up as necessary. (The function should also be exposed to JavaScript.)

I think the most simple approach is the best, and I am indeed also concerned with backwards compatibility. The suggestion of a seperate entry in the commodities-array was made mainly in order to raise the issue.

Having the localized names in descriptions.plist is obviously the better solution - and perfectly analogous to the way another_commander has handled everything else. I support it whole-heartedly.

*****

By the way: I got distracted from my work on the German version a bit, because this week I wanted to wrap up Anarchies.oxp. I succeded . Now I am busy writing wiki-pages for everything in it, but as soon as I'm done with that I will return to German Oolite.

Test of localizable commodity names (via descriptions.plist). Also a start on a Swedish localization.


The OXP description.plist looks like this (XML due to copy&pasting): Edit: syntax change

Are there going to be Cyrillic and Greek letters in the font as well? I seem to remember seeing a beginning of a russian translation at some point.


PS: I love the swedish translation so far! It's only missing 'two points!'... :D
Ahhh, the muppet show, great stuff!;)

The Cyrillic font is already included as an example in the tests folder in the trunk tree. The Greek font is not there yet, but you could probably use the fonttexgen utility in tools to build it. I cannot give any more details on this, as I have not tried building the utility yet and it looks like the code is Mac-specific. Maybe Ahruman can shed some light on how to actually generate new fonts.

Here is what it looks like. Check out the Condition: Docked text.

Anyone interested in the structure of the fonts can look in http://svn.berlios.de/svnroot/repos/ool ... rilic.oxp/ (Edit: moved, see below). The font is defined in oolite-font.plist, which specifies a texture (oolite-font-cy.png), an encoding (currently the magic number 11, I’ll change that to a string), a substitution table (which allows certain strings to be replaced with other strings; previously this was hard-coded) and a list of the widths of each symbol (glyph).

As another_commander guessed, this was mostly generated with the “fonttexgen” tool, which is a hacked-together Mac-only app. (The original font was generated by hand by Giles, by laying it out on a grid in a graphics package and, apparently, measuring in place.)

The Cyrillic font OXP works, but would benefit from a better substitution table to work well. For instance, in the “Docked” text in the screen shot, the “d” is actually a “Latin small letter d”, not a “Cyrillic small letter komi de”.

The useful 8-bit encodings supported by both Mac OS X and GNUStep appear to be: Windows Latin 1 (the default), Windows Cyrillic, Windows Greek and Windows Turkish. (Why the Windows ones? Because they’re strict supersets of the corresponding ISO encodings, which each have 32 unassigned code points.) I’ll generate “starter packs” for Greek and Turkish as well as Cyrillic.

While we’re talking about the fonts, I should mention that I’ve switched to a higher resolution for 1.70. Despite being eight times as big as the old font, it will only use twice as much memory (1 MB) since it uses one channel instead of four. I think this is fair, given that it has twice as many glyphs. :-)

Edit: I’m not sure I mentioned this anywhere else, but the new credits symbol (actually a Brazilian cruzeiro symbol, ₢) replaces the Euro symbol (€) in the new Oolite fonts. either character can be used in text to generate a credits symbol on the screen.