Итак, свершилось :-)

Стараниями группы энтузиазистов проект наконец-таки вышел на финишную прямую!

Обьявляется открытое альфа-тестирование русского перевода UQM!

Официальный сайт перевода: http://uqm-rus.sh.nu (сайт слегка переехал).

Переведено практически все кроме голосовой озвучки. Есть еще пару мелочей, но это уже детали. Планов по переводу голосовой озвучки у нас нет.

Качайте, тестируйте, коментируйте. Коментировать лучше всего на сайте (в форуме) либо на irc.freenode.net канал #uqm.

I don't see much sense to make sc2 dependent on a completely new layer here (e.g. of the unicode API). This may harm portability for no apparent reason.

The only reason for using isgraph() there seems to skip spaces, tabs and newline chars. So I'd  propose something alot simpler:

while (*pStr <= ' ')
 pStr++;

This won't affect UTF-8 characters because they are always >= 128.

And about setlocale - yes, I think doing setlocale (LC_ALL, "") would be the right thing to do now. Setting locale to anything different from the current locale (as it is done right now -- reading the locale from locale.txt) may cause wrong strings coming out of strerror etc. If you remember, initialy my patch used LC_CTYPE rather than LC_ALL

That's good but how we will deal with UTF-8 strings in MakeReport (sc2code/planets/report.c). I mean the isgraph() call. It just won't work for UTF-8 characters, and even doing setlocale("ru_RU.UTF-8") (or whatever other language) won't help, because isgraph gets just one character.

Maybe the code could be modified to not depend on the locale in general. In this case the setlocale() code could be removed from InitLanguage() (or just use setlocale (LC_ALL, "") instead of InitLocale().

The lander report is also fixed by setlocale(). According to Meep-Eep, the fix is already in repository, so better get a fresh copy of the sources from svn...

hmm strange, I only had to make one minor change in order to support characters with codes up to 255.

I made a small change to sc2 sourcecode in order to support locales.
The problem is that in some places (like MakeReport()) functions from ctype.h (like isalpha() and isgraph()) are used, which won't work for anything but ASCII codes if the locale is not set.

The solution is to place a optional language.txt file in the root content directory (provided by the language addon) which contains the language defines (currently it contains just the locale). This way:

#(Locale)
ru_RU.CP1251

Can any of the developers take a look at the patch, and if it is okay, place in the CVS?
The diff can be downloaded from http://cs.ozerki.net/zap/sc2-rus/language.diff

That's a ugly hack, I think.

You can try getting the russian pack from cvs here:

cvs -d :pserver:anoncvs@cs.ozerki.net:/mnt/stuff/cvs checkout sc2-ru

There are several already translated things that *work*, so if it works for Russian, it *must* work for Spanish as well (I don't think sc engine is biased towards one or other language ;-))

You can get a tool that I wrote for the purpose of making editing sc2 fonts easier here: http://cs.ozerki.net/zap/sc2-rus/, I've described it above. Also before converting I made a script that copied the glyphs with similar shape to the respective Cyrillic codes, you may try this too.

I already translated about half of the starbas.txt file and it works okay (Cyrillic characters have codes 192-255). The only problem I've encountered is that unpacked files (the whole share/uqm/content directory) has precedence over addons, so you have either to use a zipped main content (for some reason uqm-content-0.3-0.fdr.1.1.noarch.rpm didn't worked for me ) or make a quick hack like me - in options.c line 313 change uio_MOUNT_BELOW to uio_MOUNT_ABOVE, and recompile. This will force addon files have priority over content files.

Thanks for your in-depth reply, I'm impressed

I think I'll mostly go by transliteration, except some slight modifications where I can add a little expression by just adding/moving a letter and such. Sure, it's impossible to translate the feeling and the associative row, I just hope the translated names will have their own associations (and here's where a careful choice would help a little).

So what, are there any volunteers? I'm not in a urgent need, I can finish the whole translation task myself, but if anybody wants to feel himself -- even marginally -- involved in this task, I'll be glad to hear their opinions on #uqm, irc.freenode.net from 12:00 to 24:00 GMT+4 every day So far only Meep-Eep visited me there, just to tell me there's the #sc2 channel there too where The Real Guys are sleeping online

Thanks for clarification. I'm indeed running the CVS version, so I did a temporary hack to mount the addon packages with the ABOVE flag, and it works okay now. Waiting to see what solution will you propose in the next version

After that everything worked as by magic... I just added some dummy character images with codes above 128 under the respective .fon directories, and translated some text to Russian... it worked! The only problem I've encountered so far is that the dialog history (the one that pops instead of the alien when you press Space) for some reason doesn't seem to like characters with codes above 128 (just skips them), although the text that displays above the alien is painted perfectly.

I almost finished a small tool that takes the .fon directory and combines all the characters on a single canvas, and saves it into a .PNG file; also it does the reverse process (e.g. splits one PNG into multiple characters). I hope I did not reinvent the wheel. I'll start painting the Cyrillic character set as soon as time will permit, there are a lot of fonts to draw, luckily some Latin glyphs are same or very similar to some Cyrillic characters... that will simplify my job.

-------------

Okay, so I'm inviting everybody interested in the Russian translation of Star Control to start a discussion on the subject... I'd propose a irc conference, as the forums discussions proceed slow and if we disagree we can never came to a decision. For example, we can meet on irc.freenode.net, channel #uqm, I'll be there everyday from 12:00 to 24:00 Moscow time. If it makes sense, we can set up some dedicated Web page for this.

--------------

Another thing I wanted to ask knowledgeaboe StarCon people what special meaning have the names of some races... for example it was a nice surprise to discover the deciphering of the VUX name... are there any other hidden jokes inside names, etc?

I think race names are the first and one of the most important things to translate correctly. Sure, we can just transliterate, but this is not so good as it can be.

Ah it looks nice indeed. I wrote once ago a very similar system called VFS (Virtual File System) for the Crystal Space project

I agree the --lang option could be avoided. I will try to take this route and see if no new problems will pop up..

---

Okay, here's the first problem. The addons are mounted with the uio_MOUNT_BELOW option, which means, addons can't override files from the base content. This is very bad not only from the localization point of view. Any special reasons to use the BELOW option instead of the uio_MOUNT_ABOVE? Also the base content dir is mounted as uio_MOUNT_TOP; I think it would be better to have it mounted as uio_MOUNT_BOTTOM although it shouldnt matter (or TOP/BOTTOM are absolute? or they have effect only at the uio_mountDir time?)

Unicode also is out of the ground, because utf-8 and utf-16 are multibyte encodings and I think they're unusable, if a character is picked by it's byte number. This is ok for most european languages though to use iso-* charsets...

Well, it's not so straight-ahead as using single-byte encodings but still it's achievable. UTF-8 is an encoding that use bytes, and the upper half of the code table (128-255) are really prefixes, and you can easily decode UTF-8 characters to a code in the range 0 ... 2^31-1.

However, multi-byte character set support is not a stringent need right now, it can be added later if the translation project turns to be viable.

looks like the game does not even need to know about lang-packs -- the addon-loader is supposed to _replace_ files from content packages with files from the addons, right?  I think it can replace just anything: fonts, txts, pics (like the ones used in game menu).

Yes, looking at uio_mountDir procedure in io.c, it has options to mount a zip file on top of a existing virtual directory, I think that's exactly what we want. And mountContentDir() function actually uses this option, so addons will perfectly suit our needs. So basically the --lang switch will be equivalent to --addon.

Just read that old thread about translation and have some comments.

First, it is a bad thing that the XML translation is put as a obstacle for the translators. If the XML translation will be eventually automated, it's not a problem to translate several sets of files instead of one.

Second, the game can just have zero knowledge about Unicode, UTF-8 and so on. Every language can choose an appropiate (single-byte) encoding, and draw the appropiate character PNGs with appropiate filenames (which are derivates of the character code). Also, if input will be desirable, the appropiate keyboard mapping will have to be done somewhere (not a priority task though).

For languages with more than 255 characters it is possible to use something simple to decode like UTF-8. Then we'll have just more characters to load, thats all.

Right-to-left scripting is something totally unknown to me, but I presume this also can be defined as a per-language attribute, and the text renderer will have to be slightly modified to account for that. Not a top priority task (for me, at least) though.

Okay, I'll try to start doing something this evening and see what problems will pop up.

There's no need to get involved in that TrueType madness... Its a lot simpler than that.

The character images are called like 42.png, 64.png and so on. You just have to provide your characters with the names corresponding to the code of the character, and ensure all text in one language is written using same encoding, thats all. The code 128 may mean one letter in a language, and a totally different letter in a different language - it's not a problem at all, since the letter images will be placed under ru/, de/, fi/ and so on directories.

Forget Unicode, TTF and all other buzzwords - they will take a lot of time and pay nothing.

Hello!

I know you guys don't want to make any serious modifications to UQM until the 1.0 release, but I and my friends just can't wait and the potential gain (IMHO) from the proposed changes is very noticeable, while the changes themselves are very simple. So I thought it would be good to ask your opinion on this.

My daughter likes the game alot, but alas he doesn't know English Also some of my frends that even know English to some extent won't play the game because they have to think hard on every phrase, and this is not fun at all; at the same time they like the game as a whole.

So I thought a little localization for the game would help spread the word about the game, and - who knows - bring new developers to help.

---

Now about the actual implementation. I thought it wouldn't be too intrusive to make it possible to translate at least the most important parts of the game to other languages. In general, the main part that matters most is the text of the dialogs. And since dialogs are separated into text files, and also every letter is separated into a .png file, it is possible to just create subdirectories like en/ de/ fi/ and so on under the same directory where text and font files are placed, and put the additional font characters and localized text files there. Something like this (I don't have the source tree at hand, so I may misspell some file names here):

065.png (letter 'A')
066.png (letter 'B')
mycoon.txt

ru/mycoon.txt (russian dialogs)
ru/128.png (cyrillic letter 'A')
ru/129.png (another cyrillic letter)

de/mycoon.txt (German dialogs)
de/155.png (some german letter)
de/159.png (perhaps another german letter)

The code will have to be modified just a little:

First there should be a command-line argument to switch to a specific language (--lang=ru), also it would be good to have some platform-specific function like GetUserLanguage() to fetch current language from environment (LANG), registry and so on. The default implementation can just return "en".

Then the dialog loader will have to be modified so that it first looks under the $LANG/ directory for the respective text file, and if it is not found, load the default (English) file. Same about the font loader - it will have to load all characters that are in main directory and additional characters that possibly are under the $LANG/ subdirectory.

These simple modifications already will allow translators work to begin. What do you think of the idea?