Celestia l10n and i18n

[Eugine V. Kosenkoi]

Hi all!

I like to use Celestia for my own interest, and I want to publish it in my native languages (Ukrainian and Russian), especially, for schools. I would like to make the translation. However, when I had discovered the code, I did not found widespread i18n/l10n mechanism in Celestia. I guess this is because Celestia is a multiplatform application, and must work on platforms without i18n support. So, there are two questions:

1. How hard is to implement i18n in Celestia, and is it possible at all?

2. Is it possible to localize Celestia easily in other ways, e.g. via conditional compilation and/or macros?

[Christophe]

I like to use Celestia for my own interest, and I want to publish it in my native languages (Ukrainian and Russian), especially, for schools. I would like to make the translation. However, when I had discovered the code, I did not found widespread i18n/l10n mechanism in Celestia. I guess this is because Celestia is a multiplatform application, and must work on platforms without i18n support.

You're spot on. It's been more or less agreed that i18n should be done using the GNU gettext tools. The main problem here is to make this work with the Windows resource files.

So, there are two questions:

1. How hard is to implement i18n in Celestia, and is it possible at all?

The KDE interface is already translated.

2. Is it possible to localize Celestia easily in other ways, e.g. via conditional compilation and/or macros?

It's probably doable but a real pain to maintain. Working out proper i18n is a better way.

[Eugine V. Kosenko]

So, there are two questions:

1. How hard is to implement i18n in Celestia, and is it possible at all?

The KDE interface is already translated.

Does it mean only interface, or the object names (i.e. constellations, planets, stars and sattelites) as well?[/quote]

[Christophe]

Only the KDE part of the interface is translated. Meaning that strings displayed in the OpenGL widget aren't translated, nor are the catalog files (but that's eithier to i18n, just replace the files by their translated versions, later on we could add language extentions and choose the file according to the locale).

Keyboard shortcuts and documentation are other things you have to consider.

[Eugine V. Kosenko]

Meaning that strings displayed in the OpenGL widget aren't translated, nor are the catalog files (but that's eithier to i18n, just replace the files by their translated versions, later on we could add language extentions and choose the file according to the locale).

Well, I saw essential part in separate files, however a part of names (e.g., constellation names) is hardcoded into source. Why so? Is it possible to bring the messages to a separate data file and load them via celestia.cfg?

Keyboard shortcuts and documentation are other things you have to consider.

I'll see

[Christophe]

Well, I saw essential part in separate files, however a part of names (e.g., constellation names) is hardcoded into source. Why so? Is it possible to bring the messages to a separate data file and load them via celestia.cfg?

I think constellations are the only thing hardcoded, and it's fairly common for astronomy software to display only latin names of constellations. But if i18n is really a requirement for you, loading them from a file should be a minor modification.

[Eugine V. Kosenko]

I think constellations are the only thing hardcoded, and it's fairly common for astronomy software to display only latin names of constellations.

I'm sorry, it is a big mistake! In popular comunity (like middle-education pupil, astronomy amateurs etc.) the native names are very popular. For example, the Russian (Ukrainian) name of Ursa Minor is 'Malaya Medveditsa' ('Mala Vedmedytsa'), which is, actually 'Small Bear' . Even more, there is a set of folk names, like Ukrainian 'Velyki Voz' (i.e., Big Car) for Ursa Major.

Once again, the constellation names coded twice -- in data files and in code. It's may be an overkill.

[Eugine V. Kosenko]

I think constellations are the only thing hardcoded, and it's fairly common for astronomy software to display only latin names of constellations. But if i18n is really a requirement for you, loading them from a file should be a minor modification.

Apart from this, I see a set of service words in the code like "Distance", "Temperature" etc. They also need to be translated.

I have a minor experience in I18n. I would make appropriate changes. However, I do not have any experience in open-source projects. How can I publish my changes? Can you provide my changes in the source base for the first time?

There is also another problem: Celestia fonts do not include cyrillic letters. I discovered the rendering of the text in Celestia, and found a stop-point: the renderer accepts signed char, which is become negative and blocked to render, when the string is cyrillic. The change to 'unsigned char' in 'overlay::print' fixes the problem on my machine, but I may not see the architecture issues.

In general, there is also the encoding problem: there is a range of cyrillic encodings like cp1251 for MS Windows, koi8 for *nix and a set of encodings for Mac OS. Modern applications used to use Unicode (UTF8) encodings, and I think Celestia also must do so. I also do not have an experience for Unicode applications, but I may try to adapt Celestia.

[Christophe]

Apart from this, I see a set of service words in the code like "Distance", "Temperature" etc. They also need to be translated.

Yes, there are many strings in the engine that need to be translated too. Our main problem here is doing it in a sensible cross-platform way.

I have a minor experience in I18n. I would make appropriate changes. However, I do not have any experience in open-source projects. How can I publish my changes? Can you provide my changes in the source base for the first time?

If you have a workable solution, by all means go ahead!

If you've already been able to compile the CVS version, do your modifications and then produce a patch using 'cvs diff -u > i18n.patch'. Then send it to me by mail (chris at teyssier.org), I'll review it and commit it.

There is also another problem: Celestia fonts do not include cyrillic letters. I discovered the rendering of the text in Celestia, and found a stop-point: the renderer accepts signed char, which is become negative and blocked to render, when the string is cyrillic. The change to 'unsigned char' in 'overlay::print' fixes the problem on my machine, but I may not see the architecture issues.

In general, there is also the encoding problem: there is a range of cyrillic encodings like cp1251 for MS Windows, koi8 for *nix and a set of encodings for Mac OS. Modern applications used to use Unicode (UTF8) encodings, and I think Celestia also must do so. I also do not have an experience for Unicode applications, but I may try to adapt Celestia.

The font used by Celestia is produced from common true type fonts and can be easily extended (it's currently limited to the WGL4 subset of unicode). The engine uses Unicode internally.

[Eugine Kosenko]

Yes, there are many strings in the engine that need to be translated too. Our main problem here is doing it in a sensible cross-platform way.

I've done i18n support for Linux GLUT interface. It would be transparent for Windows platform. Really, the localized strings are marked in the source code via _(s) macro, which may be defined as

#define _(s) s

for non-supported platforms.

If you have a workable solution, by all means go ahead!

If you've already been able to compile the CVS version, do your modifications and then produce a patch using 'cvs diff -u > i18n.patch'. Then send it to me by mail (chris at teyssier.org), I'll review it and commit it.

I take the anonymous access to CVS, and now try to join to the development group. Alternatively, I promote my solution as a patch to ALT Linux distribution, which is oriented on Russian users.

The font used by Celestia is produced from common true type fonts and can be easily extended (it's currently limited to the WGL4 subset of unicode). The engine uses Unicode internally.

Unfortunately, I have made the solution for the version 1.3.1. In the version 1.3.2 the structure of GLUT fonts has been changed, so my fonts prepared for the version 1.3.1 becomed unusable.

Now I'm searching for the celestia's GLUT fonts with cyrillic letters. This is most preferrable for me, because I'm not familiar with GL font rendering. Fonts for version 1.3.1 were obtained from the cyrillic X fonts with a special txf-utility, provided by the author of txf-font technology. The fonts were delivered in cp1251 coding, and worked in a way. The version 1.3.2 uses utf8, and this discourage me. Apart from this, I'm afraid I would use bad glyphs.

Who can help me with the cyrillic GLUT fonts? This is the last reason why I can't submit my solution to celestia.

Big thanks

[chris]

I have tools for building fonts. I believe that the TrueType source fonts include Cyrillic characters. If so, it's very easy for me to create versions of the TXF fonts with a complete set of Cyrillic glyphs. I should have files for you within a day.

--Chris

[andyrock]

Hi!

I'm thinking on translating kde-celestia to pt_PT..

I'm building poedit ATM. What editors do you ppl use?

Anything better than poedit, or is this good enough?


EDIT: I'm building KBabel now

[andyrock]

How can I test the translation i just made?

Anyway, here is the file (inside tarball)

It's 100% done

tarball Please 'save as' because i renamed it to bmp, because of the damn server

[Christophe]

How can I test the translation i just made?

Copy pt.gmo to /usr/share/locale/br/LC_MESSAGES/celestia.mo

I'll try and comit your translation tonight.

[andyrock]

Copy pt.gmo to /usr/share/locale/br/LC_MESSAGES/celestia.mo

hmm... maybe Copy pt.gmo to /usr/share/locale/pt/LC_MESSAGES/celestia.mo ?

I'm from Portugal, so i use pt_PT here

EDIT:

I had to copy it to: /opt/kde3/share/locale/pt/LC_MESSAGES/celestia.mo

I always change the prefix during configure

I had 3 or 4 typos... all fixed ATM

BTW, I found a possible bug in the original POT file... See under Eclipse finder, "buttonGroup1" - it should have a name like search or something nop?

Please download the updated file for pt translation. The link is the same as in my previous post!

[Christophe]

hmm... maybe Copy pt.gmo to /usr/share/locale/pt/LC_MESSAGES/celestia.mo ? ;)

Yes of course, sorry for the mix-up, I was just looking at the other portuguese translation...

http://celestia.teyssier.org/i18n/ is updated.

[Eugine Kosenko]

Hi!

I'm sorry for a long delay, but I had a hard month...

I have tools for building fonts. I believe that the TrueType source fonts include Cyrillic characters. If so, it's very easy for me to create versions of the TXF fonts with a complete set of Cyrillic glyphs. I should have files for you within a day.

--Chris

I would glad to take such fonts. Please, send them to me as soon as possible to the address

eugine at aroks.kiev.ua

I also have tools for building the fonts. Unfortunately, the fonts made by these tools do not conform the current version of celestia: the application gets segmentation fault. I guess, the problem is unicode addressing which is implemented in the version 1.3.2 to support greek letters.

Apart from this I do not have the fonts, which contain both Cyrillic and Greek letters.

[Eugine V. Kosenko]

Hi!

I've finished a stage of Celestia's i18. The result is the patch at

http://www.aroks.kiev.ua/downloads/cele ... 0.patch.gz

which is made over CVS version at the 20th of October, 2004, approx 22:00 EET. Unfortunately, I do not have nonanonymous access to cvs to submit the changes. I would join the development team, and I have an account at sourceforge, but I do not understand how to submit to cvs nonanonymously.

Now only glut-, gtk- and gnome-interfaces are i18ed, because only these interfaces I can build.

I also made fonts cyrclean12.txf and cyrcleanbold18.txf, which contain both cyrillic and greek letters. These fonts are most similar to sans12.txf and sansbold20.txf, however I'm not sure that these are good fonts consistent to others.

I made cyrclean12 from

-schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-*

and cyrfixedbold18 from

-misc-fixed-bold-r-normal--18-120-100-100-c-90-iso8859-*

The fonts conftain latin (1), greek (7) and cyrillic (5) glyphs, and I can combine the fonts. Can anyone state me X-name of the fonts used for sans12.txf and sansbold20.txf?

P.S. It seems there are problems with the patch. If something will fail, please, message me.

[dirkpitt]

I'm interested in Unicode and internationalization issues too. Only, I want to get multibyte encodings to work too.
After a bit of hacking, I've recently managed to make a multibyte txf font for Korean:
http://www.shatters.net/forum/viewtopic.php?p=50172

Getting Chinese to work maybe somewhat more problematic (at least on some machines) due to the texture size required.

[Christophe]

I've finished a stage of Celestia's i18. The result is the patch at

http://www.aroks.kiev.ua/downloads/cele ... 0.patch.gz

Going back over the i18n issue once more, I just reviewed your patch, and I must say I'm impressed, a lot of work must have gone into this.

I must still make sure it doesn't brake anything for the other platforms and integrates with the existing KDE i18n, but I have good hopes it'll be part of the next release.

One thing I don't quite like is the use of gettext for data files, I'm still not sure of the best way to handle this though...