Hello,

I would like to translate Nexuiz in Romanian and I downloaded the French language pack so I can have an idea on what's to translate. Of course, I could use some dictionaries to pull it out but I would love to see it properly translated. This is why I ask for help.

Can anyone (officially) build a file list that need translation so I can work it out or should I use the same file structure inside the French pack?

In any case, I think a special area for i18n would be a nice touch to the already known Nexuiz. This would make it even more popular and I'm pretty much sure everyone agrees. Of course, thanks and congratulations go both to the developers and supporters of this open source FPS.

Cheers!

Hey.. well the problem is that currently you can only translate the client side.. all the messages send by the server will still be english. A future release of 3.0 might change that. Till then i thin its best to take a look at this french language pack as i doubt anyone really has a list of the things that need to be changed..

Thanks for your reply and I apologize for my late feedback. Not that this isn't enough for me, but I would still like to have an official comment on this one. I am not here to demand anything but find out any good news I can. I hope we will have some of those.

Well, given that our forum addon is one of our main developers, I'd say this is an official reply.

The French Language Pack however just translates the menu. That's easy to do, apart from the images that contain text. Currently, all in-game messages are generated by the server and thus can't get translated by the client. This will change in Nexuiz 3.0. But we have yet to think of a file format for the i18n translations that we can use in our CSQC code (note that QC does not provide a printf-like function, so we'd need to make our own).

We will probably write a _ function in QC and a printf-like function in QC and a translator from .po files to whatever we will parse in our code so that people can use the gettext utilities to make the translations. That printf-like function however will be a problem, given the extremely poor string handling in QC. I'd almost use strings in a format like

"'somestring' 2 'someotherstring' 1"

but the problem is that we may want to use both ' and " in strings to be translated. But do expect partial i18n support in Nexuiz 3.0.

Another i18n problem at the moment is that conchars.tga traditionally is 7bit and contains characters in another font in the "high range". I would want to change this to iso-8859-15 so it should suffice for German, French, Italian, Spanish and probably some other languages. Cyrillic characters won't be supported, that is, probably won't, but for sure not at the standard locations (how many are there, can we do that with about 60 codes not specially handled by DP?). Here we are limited by the Quake engine design again, it would be extremely hard to make it support UTF-8, let alone make it use Unicode fonts, as font rendering is anything but portable between operating systems.

Note that if we go the route of putting cyrillic characters at non-standard codes (because enough codes are left when using iso-8859-15), be assured that the .po -> whatever format we will use in our code translator will take care of it. But no idea if we will support them at all.

Well... I hope things will brighten up with v3.0 and you will succeed in making it easy for us, the translators, to localize the game. As far as the text-in-graphics I would suggest using "fake" fonts. I used such a thing when creating a dos-based graphical editor in Pascal and represented the letters in matrices. I mean something like:

Code: Select all

a : array[1..8,1..8] of byte = (
('0','0','0','1','1','0','0','0'),
('0','0','1','1','1','1','0','0'),
('0','1','1','0','0','1','1','0'),
('0','1','1','0','0','1','1','0'),
('0','1','1','1','1','1','1','0'),
('1','1','1','1','1','1','1','1'),
('1','1','0','0','0','0','1','1'),
('1','1','0','0','0','0','1','1')
);


You might wonder why didn't I just use the outtext function. I used runes instead of actual letters so every letter in the alphabet got a rune. That was some high-school fun when me and some of my buddies wrote letters in classes that noone could decipher. A bit geeky but it was sweet.

So, getting back to the translations, you might get the string "Johnny fragged by kneekoo" and simply use the fake character set to display the translated message. Would this have a big impact on the game performance? 'Cause I suspect it won't. The only thing is someone should create the so-called character sets for each language. I know it's a bit twisted but it is a solution. What do you think?

No, all languages need to use the same character set, because player names are also rendered in that font. Otherwise it would be weird if messages are displayed in a font that one can't use for own input.

But what if the server would only transmit message codes to the clients and the client itself display the message, using the local font? Not only that can be done but it would lower the server-side traffic. I've also updated my previous post so you can get a better picture of what I was talking about. Hope that helps.

Exactly that is what we will change with 3.0.

The only problem will be parsing an i18n file... but the font has to be the same for everyone or otherwise nicknames get displayed wrong.

What character set is it using now UNICODE? If not, I would like that. Haven't actually tried having Japanese characters... Gonna check it out now.

EDIT: Damn it >.<

divVerent wrote:The only problem will be parsing an i18n file... but the font has to be the same for everyone or otherwise nicknames get displayed wrong.

I see. Well... if the nicknames are quite an issue, there might be at least two choices for the correct nickname display on the clients.

1. Having all the language fonts on the client. The fonts would be very small in size the given the fact that there won't be thousands of translations this option wouldn't be too bad.
ADVANTAGE - this way everyone can freely choose a nickname and it would be properly displayed.
DISADVANTAGE - the users who want to have a "as light as possible" client would probably be disturbed by the extras files and end up seeing "???????? has entered the game"

2. Having the server to generate a unique user ID based on the IP address and such then have the nickname rendered on the server side and sent to the clients.
ADVANTAGE - the clients stay thin, without the extra fonts
DISADVANTAGE - the nickname has to be sent to all the clients that do not have it, but keep in mind that the nickname is usually a short one so the server traffic won't be a killer.

Making any sense? How does it sound?

Well people play quake for 10 years and non-unicode was never a problem.. why create one? Yes it might be nice but i think its not needed.

Who am I to argue such a thing? You're right, of course. People have been playing Quake the last decade and having English all-over it didn't keep them out. Being translated, though, might boost the project's popularity so that's another strong argument to consider.

I won't say games have auto-programming or auto-evolution mode. There's human effort in every new feature and we're already enjoying the current outcome. We are grateful for that. You did that for us. Now making it multi-language might make it more rewarding for you, because new people can join. Translators will be ready when you are. Until then, keep up the good work.

kneekoo wrote:Who am I to argue such a thing? You're right, of course. People have been playing Quake the last decade and having English all-over it didn't keep them out. Being translated, though, might boost the project's popularity so that's another strong argument to consider.

Hehe what i meant was that the way the engine and its font system work are not prepared for unicode.. all they do so far are at max 256 characters and i'm not sure how easy it would be to change this. For knowing that i think divVerents idea to just replace some of the now used glyphs with common european characters is the most promising idea and is also rather easy compared with huge rewrites of internal stuff. I have little clue about the engine itself so maybe its easier then one thinks but from what i learned while programming thats a thing that has not happend to any programmer yet

However, Darkplaces DOES need a better font renderer. Currently it takes an image and divides it into 16 rows/columns of characters, just like Quake did. This also means that fonts are necessarily fixed width.

If there is some way to get a TTF renderer in, why not - but the problem is that:

• the main engine developer lives in the US, and TTF's hinting is covered by software patents
• TTF renderers are quite large and not exactly portable
• Internals of the engine rely on fixed width character cells (well, in Nexuiz the chat area feature also brought some readiness for variable width character sets; but we don't have a format for such fonts we can use, and stuff like centerprint still wouldn't work with that)

And no, one cannot rely on the user environment's font renderer (Windows' Truetype or X.org's Freetype) in OpenGL applications.

Another problem: games need to take full control of the keyboard (in X11 language, they "grab" the keyboard) so for example accidentally pressing the Windows key doesn't minimize the game and open the start menu. However, when that is done, shortcuts to switch keyboard layouts don't work either. So on a Russian keyboard, one then can't switch between Cyrillic and Latin characters. What also is impossible under these circumstances are input method editors like used for Asian languages which have LOTS of characters. However, if there's demand, we can code specific support for Russian keyboard layout.

What may come is variable width font support at least for chat and info messages.

So TTF is not a choice as well as fixed type characters are. But how about SVG? It's scalable, open standard and we could create nice graphical fonts with open source software to have every message displayed as needed.

What do you think of this one?

Wudan got freetype working in q3 once, and getting things to work in Q3 is hard.

One of the main advantages of using freetype (and such) is the east asian language support.