Multi-lingual Considerations

INTRO

English is not the only fruit. With a prominent international market, we need to cope with the vagrancies present in other languages. But how to begin?

To be blunt, start early. Create code for the SKU and language settings during the first month. Empty function stubs that just return LANG_ENGLISH, and SKU_UK_VERSION are fine (don't use #ifdef LANGUAGE unless you like recompiling code). This not only puts everyone in an international mind-set from day one, but emphasises the distinction that SKU and language are not the same. The German SKU will very likely have the low violence and green blood options set permanently to TRUE. Whereas, the German language may also be present on an international CD supporting high violence. Essentially, the SKU determines game logic (e.g. blood colour), and the language determines assets.

It is also a good idea to create a complete font early, with the accented characters present and correct! All games need them, even if only for the credits (where at least one French word will need an accent!). This will give you an accurate memory footprint. Test it early too, since the font processing code will require unsigned chars, not signed. If you need to produce a Japanese version of the game prepare a Kanji font (this is bigger still) and use Unicode.

WORDS

Processing text is the single largest area of concern. Naturally, no string should be written directly into the code, but loaded instead as a data resource (like the string tables in DevStudio). These strings should be numbered with the credits placed last. Credits always grow, as more publisher hanger-on's get their name added under "Additional Tea Boy #7"! They also grow in foreign language versions, to include the translators and different territories may also have different publishers and support staff to include.

It is wise to support several string tables in memory at once (I use a linked list). You can then link the generic text (menu options), to the level-specific text (objectives and subtitles), to the credits, limitting duplicate text. If you're writing a cross-platform game, then move any text required for standards compliance (e.g. memory card messages) from the generic string table, to a platform-specific one to prevent maintaince of three generic files.

These tables should contain separate entries for 'explosives' and 'the explosives'. Although you might be tempted to use sprintf to construct "You have the %s"-like sentences, be advised that English is one of the few languages with a single word for 'the'. Explosives might be considered masculine, feminine, neuter or plural! Only the translator knows which, so create two lists. The cost of extra translation is minimal compared to programmer time.

And talking of sprintf - ignore it. It's useless! Not all languages place the verb and noun in the same order. So write a custom version that references specific arguments with %1s and %2s, instead of %s. Coding such a function is not difficult - once you've learnt about vsprintf!

DRIVEN BY YOU

I'm sure that we've all got data-driven engines, so make sure this also applies to the text processing code. Dialog boxes should be created out of individual components, so it can grow to take longer strings than anticipated. The user interface (menus, configuration screens and in-game menus) should also adapt, to accomodate the text within it. Conversely, text on movies and level graphics are a bad idea - unless you enjoy more rendering!

Words are often much longer in German, so place all text into imaginary rectangles, letting the code format them (on separate lines where necessary). Base the layout on the text. Not vice-versa.

The menu system, as a whole, should also be data-driven. React to button presses based on the menu item itself (perhaps using a hash of its name) and not its position in the list, as this may change if the German SKU omits the 'High Violence' option.

OVER IT

Once you have a set of language-specific files, create a directory structure with the minimum duplication of assets. Have a 'common' directory tree for the game levels, UI graphics and publisher movies (which vary between SKU, not language), and an 'english' directory for any asset (voice overs, cut scenes and, of course, text) that is specific to that language. Each SKU can then be built by anyone capable of using Windows, freeing up valuable programmer time. The game will first attempt to load files from the language-specific directory, resorting to the 'common' directory where necessary. If you need separate English and American versions (tire vs tyre, anyone?), treat it like another foreign language.

END

The first foreign language is the hardest. The second is easy. So go on! Have a go!

BOXOUT:

- Start early. Play in French occasionally. You'll spot missing resources quicker.

- Work out the common elements. SKU != Language

- Write a good string table system. It pays dividends.

- Think data-driven! Use the text to build the layout. Not vice-versa.

- German has the most difficulties of all European languages. Do it first.

The Author