Translators wanted for help localising Oolite
Moderators: winston, another_commander
-
- Quite Grand Sub-Admiral
- Posts: 364
- Joined: Tue Aug 17, 2004 7:05 am
- Location: Orange, NSW, Australia
The unicode build is pretty recent, something like r457. I think there is a problem with descriptions.plist, but I haven't had to time or energy to figure out what it is.
I've just posted a screenshot of the market screen in Russian using Draco's commodities.plist file. Looks good!
I know about the title's underline. I've changed the way the UI is drawn quite a bit to account for the new text routines (and because I didn't really understand the old ones properly) and haven't got that quite right yet.
I've just posted a screenshot of the market screen in Russian using Draco's commodities.plist file. Looks good!
I know about the title's underline. I've changed the way the UI is drawn quite a bit to account for the new text routines (and because I didn't really understand the old ones properly) and haven't got that quite right yet.
Regards,
David Taylor.
David Taylor.
- Draco_Caeles
- Dangerous
- Posts: 105
- Joined: Sat Apr 15, 2006 11:40 pm
- Location: North-west England
Heh. That does look pretty good, doesn't it?
There does seem to be something odd going on with the descriptions.plist text. Some of it, which has been rendered into Russian, is coming up as questions marks on the screen.
Also, the fact that 'Human Colonials' is hard-coded into the game means it's impossible to change. Can/should anything be done about this?
One other thing that troubles me is that some of the words will change depending on context and I'm not quite sure how best to solve this. Frex: "Food" -> "Пища"; "Bought Food" -> "Купал Пишу". It may be as simple as sticking a colon in there and not worrying too much... ^_^
There does seem to be something odd going on with the descriptions.plist text. Some of it, which has been rendered into Russian, is coming up as questions marks on the screen.
Also, the fact that 'Human Colonials' is hard-coded into the game means it's impossible to change. Can/should anything be done about this?
One other thing that troubles me is that some of the words will change depending on context and I'm not quite sure how best to solve this. Frex: "Food" -> "Пища"; "Bought Food" -> "Купал Пишу". It may be as simple as sticking a colon in there and not worrying too much... ^_^
- Draco_Caeles
- Dangerous
- Posts: 105
- Joined: Sat Apr 15, 2006 11:40 pm
- Location: North-west England
Skalakala! I know what the problem is (I -think-).
Most of the text is probably just dumped to screen by printf() or some similar, whereas I suspect that the text that the HUD produces is generated by using the text in oolite.app\Contents\Resources\Textures\asciitext.png. Am I right, Giles, or totally barking?
If this is the case, it would explain why all the static-screen text displays properly but not the HUD reports.
Having said that, I've noticed that when I quit the game and reload it, the Cyrillic text for the Commodities market list is all wrong. I'll generate a screenshot next time. But I have a feeling that it's being split into high/low byte, since there are two characters printed for each character of text: a Ð and then another.
I'm saving the files in UTF-8 format, just so you know.
Most of the text is probably just dumped to screen by printf() or some similar, whereas I suspect that the text that the HUD produces is generated by using the text in oolite.app\Contents\Resources\Textures\asciitext.png. Am I right, Giles, or totally barking?
If this is the case, it would explain why all the static-screen text displays properly but not the HUD reports.
Having said that, I've noticed that when I quit the game and reload it, the Cyrillic text for the Commodities market list is all wrong. I'll generate a screenshot next time. But I have a feeling that it's being split into high/low byte, since there are two characters printed for each character of text: a Ð and then another.
I'm saving the files in UTF-8 format, just so you know.
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
All of the text drawn on screen in Oolite is drawn via OpenGL. In standard Oolite, it uses asciitext.png. In the Unicode branch, it uses the FTGL library, but it’s possible not all text-rendering is up-to-date on this - dajt?
The two-character thing sounds as though UTF-8 text is being treated as something else, presumably latin-1 or the corresponding Windows code page. The reccomended format for non-XML plists containing non-ASCII text under OS X is UTF-16. Don’t know about GNUStep.
The two-character thing sounds as though UTF-8 text is being treated as something else, presumably latin-1 or the corresponding Windows code page. The reccomended format for non-XML plists containing non-ASCII text under OS X is UTF-16. Don’t know about GNUStep.
E-mail: [email protected]
-
- Quite Grand Sub-Admiral
- Posts: 364
- Joined: Tue Aug 17, 2004 7:05 am
- Location: Orange, NSW, Australia
There are 3 instances of the UI class used in Oolite - one to draw the status page, local system info, etc, one to draw the comms messages as they happen, and one to draw the comms history.
The only one of these I have changed is the one that draws the status page etc.
So comms messages and comms history can't yet draw non-latin characters because they still use the existing routines that use the ASCII texture.
I have not converted all three because the current text handling in Oolite can resize it's text pretty well, so can handle all the different text sizes easily, whereas the FTGL text drawing isn't so flexible. It requires you to open a font at a particular size and draws everything in that size. Even for the main UI I need two fonts - one for the title and one for the normal text.
This is the biggest problem with the FTGL idea at present. The SDL_ttf version didn't have this issue because it just gave you the text on an SDL surface which you could then convert to a texture and put it on a rectangle of whatever size Oolite wanted (roughly). It was a bit hard to figure out exactly what size rectangle to use, and the rescaling made the text damned ugly, and you had to create and free a texture every time you drew a string, so it wasn't an ideal solution either.
As for why your strings for commodities are getting corrupted, I don't know. UTF-8 or UTF-16 encoding in the plist makes no difference, as long as the encoding attribute at the top is correct. It's still storing unicode strings in the file. FWIW, the symtom you describe is what I saw in your e-mail when I said something terrible had happened with the encoding. If you're seeing two characters where there should just be one, it sounds like the encoding in the file was changed back to a code-page at some point.
I don't know if GNUstep correctly reads UTF-16 encoded plists, but I know it reads UTF-8 ones okay.
The only one of these I have changed is the one that draws the status page etc.
So comms messages and comms history can't yet draw non-latin characters because they still use the existing routines that use the ASCII texture.
I have not converted all three because the current text handling in Oolite can resize it's text pretty well, so can handle all the different text sizes easily, whereas the FTGL text drawing isn't so flexible. It requires you to open a font at a particular size and draws everything in that size. Even for the main UI I need two fonts - one for the title and one for the normal text.
This is the biggest problem with the FTGL idea at present. The SDL_ttf version didn't have this issue because it just gave you the text on an SDL surface which you could then convert to a texture and put it on a rectangle of whatever size Oolite wanted (roughly). It was a bit hard to figure out exactly what size rectangle to use, and the rescaling made the text damned ugly, and you had to create and free a texture every time you drew a string, so it wasn't an ideal solution either.
As for why your strings for commodities are getting corrupted, I don't know. UTF-8 or UTF-16 encoding in the plist makes no difference, as long as the encoding attribute at the top is correct. It's still storing unicode strings in the file. FWIW, the symtom you describe is what I saw in your e-mail when I said something terrible had happened with the encoding. If you're seeing two characters where there should just be one, it sounds like the encoding in the file was changed back to a code-page at some point.
I don't know if GNUstep correctly reads UTF-16 encoded plists, but I know it reads UTF-8 ones okay.
Regards,
David Taylor.
David Taylor.
- Draco_Caeles
- Dangerous
- Posts: 105
- Joined: Sat Apr 15, 2006 11:40 pm
- Location: North-west England
- Draco_Caeles
- Dangerous
- Posts: 105
- Joined: Sat Apr 15, 2006 11:40 pm
- Location: North-west England
I've found out what the problem is.
I've also uncovered another little quirk/fault that's causing another problem.
Since I'd like to play in English again for a bit, I've the commodities.plist file back to English, but the text for commodities remains in Russian after I load my commander file. So I do a little bit of poking, and find that the settings for the current station are saved in that file, together with the names (in Russian) of the commodities.
Hence the problem.
Edit the file, all should be well, in theory (I haven't tried it yet).
I think, if localisation is going to be a go in any way, this needs to be looked at. Could a constant name be used instead of the actual commodity name, in the same way that constants are used for equipment? So, say, GOODS_FOOD, GOODS_NARCOTICS, GOODS_ALIEN_ITEMS, etc.? I appreciate this would probably be a bit fiddly to implement, though...
Although it would have a rather fun side-effect of being able to remain commodities with an OXP... Just imagine what you could buy...
I've also uncovered another little quirk/fault that's causing another problem.
Since I'd like to play in English again for a bit, I've the commodities.plist file back to English, but the text for commodities remains in Russian after I load my commander file. So I do a little bit of poking, and find that the settings for the current station are saved in that file, together with the names (in Russian) of the commodities.
Hence the problem.
Edit the file, all should be well, in theory (I haven't tried it yet).
I think, if localisation is going to be a go in any way, this needs to be looked at. Could a constant name be used instead of the actual commodity name, in the same way that constants are used for equipment? So, say, GOODS_FOOD, GOODS_NARCOTICS, GOODS_ALIEN_ITEMS, etc.? I appreciate this would probably be a bit fiddly to implement, though...
Although it would have a rather fun side-effect of being able to remain commodities with an OXP... Just imagine what you could buy...
German Translator reporting in.
Here is the translation sample:
German is easy to use, there only 3 additional chars to ASCII: äöü.
Please tell me, how to go on (which files, send to whom, or generally how it shall be done).
Here is the translation sample:
Code: Select all
Daten über Lave
Wirtschaft: Ergiebige Landwirtschaft
Regierung: Diktatur
Technische Stufe: 8
Bevölkerung: 2,5 Milliarden (Menschliche Kolonisten und Laveianer)
Bruttoprodukt: 7000 M Cr.
Mittlerer Radius: 4116 km
Lave ist eine wohlhabende und sagenumwobene Welt, vielleicht am berühmtesten für seine ausgedehnten Regenwälder, das stürmische Palubermeer und den Laveianischen Holzwurm.
Es ist auch das einzige System, welches den Weltraum- und Interstellaren Pilotenschein anbietet.
Please tell me, how to go on (which files, send to whom, or generally how it shall be done).
Hi, folks from this mostly harmless planet
Some Quenstions
Is the translation still in process? give it some releases?
which translations are needed.
I offer myself for german (de_DE, de_AT) translations.
Is the translation still in process? give it some releases?
which translations are needed.
I offer myself for german (de_DE, de_AT) translations.
-
- Poor
- Posts: 4
- Joined: Sat Dec 02, 2006 6:12 pm
Well, I could offer myself to translate for Portuguese, if I had the time, but there are many problems. The portuguese language uses several acentuated letters and that may be a problem. Furthermore, the POR language is not 1-1 translated, more 2-1 or 3-1 translated, which means in average 2 or 3 words in POR to explain a concept in ENG I'll post an example when I have the time.
"BRILLIANCE IS MERELY THE ART OF PLANNING AHEAD"
The fact that you played the game in English doesn't mean that everyone out there knows, understands and is comfortable with English.Rxke wrote:I have the same feeling, (for Dutch/Flemish) probly also age-related. My first computers were 'talking' English, as were the keyboard-layouts. Oh, and the early Atari STs 'spoke' English, mixed w/ German error-messages. Now *that* was weirdWolfwood wrote:I, for one, cannot even understand the need to translate games to native languages. Perhaps I'm too old, but in my day, _all_ the games were in English. It would feel weird seeing Finnish used in Oolite...
You are looking at the problem from the wrong perspective, there were computers made by English speaking people, which didn't had support for anything else but English, then things evolved and support was added. Now it is possible to have translations even in languages with complicated scripts like Khmer and Indic languages. (Before you ask, no, CJK languages are not that complicated scripts.)
There are parts of the world where literacy is low, not to talk about foreign languages. English is NOT the universal language and, like it or not, people are thinking in their native language (as they say).
-
- Poor
- Posts: 4
- Joined: Sat Dec 02, 2006 6:12 pm
Just for an idea, here is what some things tranlate in portuguese:
Fuel = combustível
Missile = míssil
Large Cargo Bay = grande compartimento de carga
ECM System = sistema CME
Pulse Laser = Laser de Pulso
Beam Laser = Raio Laser
Fuel Scoops = Sugadora de Combustível
Escape Capsule = Capsula de Emergência
Energy Bomb = Bomba de energia
Extra Energy Unit = Unidade extra de energia
Docking Computers = Computadores de acoplagem
Galactic Hyperdrive = Hiperdrive galáctica
Mining Lasers = Laser mineiro
Military Lasers = Laser militar
Food = comida
Textiles = têxteis
Radioactives = Items radioactivos
Slaves = escravos
Liquor/Wines = licores / vinho
Luxuries = produtos de luxo
Narcotics = Drogas
Computers = computadores
Machinery = maquinaria
Alloys = ligas metálicas
Firearms = armas ligeiras
Furs = peles
Minerals = minerais
Gold = ouro
Platinum = platina
Gem-stones = pedras preciosas
Alien Items = items extraterrestes
This is a sample, but it's done. Would there be problems with the longer descriptions?
Fuel = combustível
Missile = míssil
Large Cargo Bay = grande compartimento de carga
ECM System = sistema CME
Pulse Laser = Laser de Pulso
Beam Laser = Raio Laser
Fuel Scoops = Sugadora de Combustível
Escape Capsule = Capsula de Emergência
Energy Bomb = Bomba de energia
Extra Energy Unit = Unidade extra de energia
Docking Computers = Computadores de acoplagem
Galactic Hyperdrive = Hiperdrive galáctica
Mining Lasers = Laser mineiro
Military Lasers = Laser militar
Food = comida
Textiles = têxteis
Radioactives = Items radioactivos
Slaves = escravos
Liquor/Wines = licores / vinho
Luxuries = produtos de luxo
Narcotics = Drogas
Computers = computadores
Machinery = maquinaria
Alloys = ligas metálicas
Firearms = armas ligeiras
Furs = peles
Minerals = minerais
Gold = ouro
Platinum = platina
Gem-stones = pedras preciosas
Alien Items = items extraterrestes
This is a sample, but it's done. Would there be problems with the longer descriptions?
"BRILLIANCE IS MERELY THE ART OF PLANNING AHEAD"