Hello people, I'm currently at the point where I plan my next game pet project. Early planning of localization is one lesson I learned the hard way from my earlier project - I didn't think about supporting anything else than english, but as the game got more popular, more and more people asked for versions in their native language, some even offered to do all the translation work for their particular language. Unfortunately my game had (and have) several problems with localization: No support of non-latin characters, no UTF-8 support, GUI that is very picky when it comes to text sizes, and game text being hardcoded into the program. All-in-all I won't even consider trying to add the support now... But as mentioned, I hope to make everything in a more clever way for my next project :) Now for the questions: - Can anyone point me in the direction of some good articles, texts, anything, that concerns localization as it relates to games? I've found and is reading "http://www.iosn.net/l10n/foss-localization-primer/foss-localization-primer.pdf", but it primarily concerns normal applications. I guess there's several things that are different when it comes to games, right? - I plan to implement a MPQ-like file packaging system, where several versions of the same file can exist, just with different locale specifications. Anything I should have in mind with such a system? Pitfalls? - As I see it, the major problem with all of this is text rendering. I'll have to use system fonts all the time, because otherwise I can't be sure all the obscure character glyphs are present. I don't like that because standard system fonts are so boring. What's the usual way to handle this? I guess even big developers aren't interested in drawing 1000s of crazy characters... - What about the GUI? It's going to be a mess to create one which don't care whether the text suddenly has a completely different size. Can anyone point me to an existing solution (with source) so I can learn some tricks? :) - How much should be translated? Only text inside the game? Error messages? Log messages? - Is it even worth the trouble to think of localization for hobby developers? How large shall a project be before it should be a concern? - Any other tips and tricks I should know about? :) Thanks in advance. I know these questions are pretty diffuse, but I can't express me in a more clear way, sorry.

Quote: Original post by kadaf
Now for the questions:

- Can anyone point me in the direction of some good articles, texts, anything, that concerns localization as it relates to games? I've found and is reading "http://www.iosn.net/l10n/foss-localization-primer/foss-localization-primer.pdf", but it primarily concerns normal applications. I guess there's several things that are different when it comes to games, right?

Why should there be? The only difference with games is that certain localization concerns like monetary types and time zone issues often don't exist.

Quote:
- I plan to implement a MPQ-like file packaging system, where several versions of the same file can exist, just with different locale specifications. Anything I should have in mind with such a system? Pitfalls?

It creates LARGE packages, and creates the possibility of version mismatches in multiplayer mode.

Quote:
- As I see it, the major problem with all of this is text rendering. I'll have to use system fonts all the time, because otherwise I can't be sure all the obscure character glyphs are present. I don't like that because standard system fonts are so boring. What's the usual way to handle this? I guess even big developers aren't interested in drawing 1000s of crazy characters...

meh. Standard font's are legible. Allow your game to use any font on the system [ala D3DXFont] and if someone wants to make another font or provide localized versions of your fonts, they're free to do so.

Quote:
- What about the GUI? It's going to be a mess to create one which don't care whether the text suddenly has a completely different size. Can anyone point me to an existing solution (with source) so I can learn some tricks? :)

From what I've done, this isn't so hard if you design around it in the first place. Just arrange things relative to others, and it should be fine.

Quote:
- How much should be translated? Only text inside the game? Error messages? Log messages?

I'd make all strings loadable from external file with hard-coded defaults. This allows you [or others] to translate what they need, but maybe not errors or log messages if they don't need it.

Quote:
- Is it even worth the trouble to think of localization for hobby developers? How large shall a project be before it should be a concern?

That depends on your audience.

You can check out the game localization handbook. It has some useful suggestions for how to organize your assets in a localization-friendly manner.

As for Unicode fonts, there are many good ones available, but more interesting ones may require licensing fees for you to use. Personally I kinda like Arial Unicode MS :-)

I think you're right that making truly localization agnostic GUIs is liable to be difficult. One possibility is to store your UI Layouts in independent files, and then localize these layouts along with your stringtables. This is more work for your localizers, of course (and for you, as you'll probably need to write a separate program for manipulating the UI Layout files), but yields much better results.

In terms of how much should be logged: anything that the player is going to need to understand to play your game of course! :-) Your game's log files are probably going to be incomprehensible to the lay user anyway, so there's little point having them translated; error messages that your game generates should be translated if possible. Having a game quit out with an incomprehensible message is slightly more frustrating than "Could not Create D3DDevice! Exiting!" On the other hand, these errors should probably also return invariant numbers, so YOU can figure them out, even if they're reported from a localized game client.

If you're truly just doing this as a hobby, with no intent to profit from the game, then it doesn't make sense to get bogged down in the details and expense of localization. If you are seriously planning on distributing your game online for money, though, then it makes sense to at least design the game with an eye toward localization-friendliness. As you already know, it's something that's awfully hard to add in after the fact.

A few other things you should consider:
1) You mentioned UTF-8, but it will be easier for you to just use UTF-16 throughout and use wide strings everywhere in your code.
2) You should look into the XLIFF File Format. It is a standard XML-based format for encoding strings for translation. There are also some fairly standard tools which can be used to operate on these files for the purposes of translation.
3) If your game is text-heavy, then defining the in-game context of your strings is very important. It will pay to have an internal way for storing string comments in your resource files, and then get in the habit of USING that facility (e.g.: comment to specify whether "shoot!" means "fire a weapon!" or "ask a question").
4) Ask yourself if having static images with text is worth the bother of having to support localizing bitmaps. In most cases it will probably be a lot of bother with very little extra gain.

Quote: Original post by Telastyn

Quote: Original post by kadaf
...
I guess there's several things that are different when it comes to games, right?

Why should there be? The only difference with games is that certain localization concerns like monetary types and time zone issues often don't exist.

You tell me :)

Quote:
meh. Standard font's are legible. Allow your game to use any font on the system [ala D3DXFont] and if someone wants to make another font or provide localized versions of your fonts, they're free to do so.

Well, I guess I could post-process the standard fonts to make them more interesting.

Quote:

Quote:
- What about the GUI?

From what I've done, this isn't so hard if you design around it in the first place. Just arrange things relative to others, and it should be fine.

Yeah, but stuff like button graphics? Some things have to be fixed in size if it's not going to look crappy. But okay, then one can probably adjust the text size.

Quote:
I'd make all strings loadable from external file with hard-coded defaults. This allows you [or others] to translate what they need, but maybe not errors or log messages if they don't need it.

I think I'll go for a GNU gettext like approach (but I'm not going to use gettext itself, I won't require translators to fiddle around with cygwin, etc). All text strings inside the code is put in something like _T("Hello, World"). A special tool then finds all the _T occurances and build a special .POT template. Translators then use that file for a base of creating .PO files which are clear text "translation tables". I won't go into details here, check out http://www.gnu.org/software/gettext/.
A nice thing by using standard file formats, is that people can use one of the many fancy .PO-file editing tools.

Quote: Original post by Muse
You can check out the game localization handbook. It has some useful suggestions for how to organize your assets in a localization-friendly manner.

Books are a luxury I can't afford :)

Quote:
As for Unicode fonts, there are many good ones available, but more interesting ones may require licensing fees for you to use. Personally I kinda like Arial Unicode MS :-)

Actually I think it's pretty difficult to find ones that I can redistribute for free? Links? :)

Quote:
I think you're right that making truly localization agnostic GUIs is liable to be difficult. One possibility is to store your UI Layouts in independent files, and then localize these layouts along with your stringtables. This is more work for your localizers, of course (and for you, as you'll probably need to write a separate program for manipulating the UI Layout files), but yields much better results.

I think, requiring translators to be able to modify UI layouts is probably too much to ask.

Quote:
In terms of how much should be logged: anything that the player is going to need to understand to play your game of course! :-)

As mentioned in the other post I'll probably go for a .PO based solution. All text in the game is going to end up in the template, eventually with log messages marked as "not essential".

Quote:
On the other hand, these errors should probably also return invariant numbers, so YOU can figure them out, even if they're reported from a localized game client.

Good idea.

Quote:
If you're truly just doing this as a hobby, with no intent to profit from the game, then it doesn't make sense to get bogged down in the details and expense of localization. If you are seriously planning on distributing your game online for money, though, then it makes sense to at least design the game with an eye toward localization-friendliness. As you already know, it's something that's awfully hard to add in after the fact.

I think it's fun designing and implementing stuff like this :) That should be reason enough I think.

Quote:
1) You mentioned UTF-8, but it will be easier for you to just use UTF-16 throughout and use wide strings everywhere in your code.

The tinyxml XML-parsing library only supports UTF-8, so that's what I'm going to use :) Really, I don't think it's a problem.

Quote:
2) You should look into the XLIFF File Format. It is a standard XML-based format for encoding strings for translation. There are also some fairly standard tools which can be used to operate on these files for the purposes of translation.

Mkay, I'll see how it is compared to .PO.

Quote:
3) If your game is text-heavy, then defining the in-game context of your strings is very important. It will pay to have an internal way for storing string comments in your resource files, and then get in the habit of USING that facility (e.g.: comment to specify whether "shoot!" means "fire a weapon!" or "ask a question").

PO allows the programmer to add comments to strings, so that shouldn't be a problem.

Quote:
4) Ask yourself if having static images with text is worth the bother of having to support localizing bitmaps. In most cases it will probably be a lot of bother with very little extra gain.

It's not difficult to add, and I think it will look stupid if there suddenly is an english word or something inside the game.

Conclusion: Localization requires a lot of work. And I haven't even thought about scripting, which also are going to include text strings. And stuff. Yikes.

Thanks for your comments! :)

>- What about the GUI? It's going to be a mess to create one which don't care
>whether the text suddenly has a completely different size. Can anyone point me
>to an existing solution (with source) so I can learn some tricks? :)
Make sure you have sufficent space in the first place. If you
have a line with skills/start (for example), then make sure you have
50% extra space (compared to english as primary language) - you'll need
it for french translation.

... and the translaters can always use (obscure) abreviations :)

With Chinese, keep in mind that you definately do _not_ want to show
that in 8 pixel height; 12 is the _absolute_minimum_ for that - so don't
use tiny fonts anywhere in your english ui 'to make it fit'.

And also get info on IME - it's some kind of auto-complete-combobox for
chinese/japanese signs.

>but this perhaps would make people pay more attention to learn English.
I know what you mean. I really dislike german translations for tv-series
and the polish solutions with lektors (obviously cheaper to make than
translating entirely) is annoying.
I prefer the dutch method the best, plain old (cheap) subtitles and the
movie spoken in the original language :)

>about scripting, which also are going to include text strings.
Inside scripts, only use a "lokalization_id" - with that, get the translated
string from your package-files. Never put texts in scripts, that will give
you lots of headache!


Regards

[Edited by - Kitt3n on November 14, 2005 3:25:22 AM]

Hello,

I mostly disagree with you (no offense intended - I just disagree :)). Forgive me if I seem rude, it is not my intention.

Quote: Original post by ursus
This is probably a bit off topic but the idea of games localization is annoying me. I live in Poland but I used to study English in the UK and therefore see (and hear :) ) no problems in playing games in English (native language of most of the games ever produced).

That's not true. See below.

Quote: Original post by ursus
What irritates me is the current trend to localize every game, and so we have things like: Doom3 in Polish, Quake3 in Polish, Delta Force, etc. There is nothing wrong with that except for the fact that my personal preference would be to play game in English since with the localization almost all acting emotions, atmosphere and some of the storyline are gone. Some things cannot be translated and the quality of voice actors is always best in the game coming from the source factory. Games I mentioned are pretty simple and require very little (or no) English knowledge to configure, run, complete and have fun. Moreover, in my opinion, even with poor English it’s better to enjoy professional actors and storyline.

If you prefer the international version, then play the international version. Be aware that sometimes, the acting is poor even in the English version (you never played the last Vampire:The masquerade - Bloodlines?) [smile]

Quote: Original post by ursus
I understand there are games that require good understanding of English (rpg, strategy, etc) and there is no option but to translate them so that they can be sold in non-English speaking countries but this perhaps would make people pay more attention to learn English. I remember around 10 or 15 years ago there were no games in languages others than English and all players had fun playing them.

So here is my request to game publishers: do not localize games if it’s not absolutely necessary and even then don’t hesitate to pay for good translators.

O_o

Do you think that every people on earth must learn English just because you did it? That's rather rude. And 10/15 years ago games were also localized. there was also a fair amount of non-English games (France was rather active, with Cryo and a bunch of other global developpers and editors). This is still true today: I guess you find Final Fantasy easier in Polish than in Japanese, don't you?

The total number of people that speak English is by far less important that total number of people that don't speak English. It is true even in my country or your country. Moreover, beeing able to read English and understand it doesn't mean that you're going to be able to understand spoken English - which is by far more difficult.

Game publishers would be silly if they tried to target only the educated English speaking audience - IMHO, it is far too small.

Regards,