Software Localization

The Four Steps To World Domination A Programmer's Guide to Foreign Languages "T" Time: Text and Translation Visuals Talkin' The Talk Wrapping It Up

"What's happening?"
"Don't know. The blanket?"

Huh?

What may at first appear to be two completely unrelated sentences is, in fact, an attempt at humor. Correction: It is the translation of the translation of an attempt at humor. Either way, it doesn't make much sense. Sadly, this is an excerpt from the dialog of an adventure game, and as such, it's an example of a common misconception: localization equals translation. Thankfully, the situation is improving and blunders such as this are becoming rare; the process of localization is becoming more and more streamlined as people gain experience. Unfortunately, most of that experience was gained through the trusted and proven method of trial and error.

The Four Steps to World Domination...

If you're planning to make your next project available for worldwide distribution, one of the first things you need to do before beginning production of a foreign version is to decide whether it's worth the effort. You may have the greatest and most realistic shoot-'em-up-kill-a-thon with hours of perfectly synchronized German voice-over, but it probably won't sell in any great numbers in Germany because the violence will make the game available only under the counter to those over 18. Submitting your game to a sales system with no advertising, no reviews, and no revenue is not exactly the best way get your money's worth. Whether or not such systems are necessary, useful, or just a pain isn't the issue; the fact is, it's "different strokes for different folks." In such a case, you have to evaluate your options. Changing the game to make it suitable for a certain market may be fairly simple, such as replacing red blood splatters with green, but can be more invasive, involving removing the gore and death completely. Take a look at the screenshots to see just how little can make the difference (Figures 1 and 2).

Figure 1. Spot the difference: unacceptable and acceptable.

Figure 1. Spot the difference: unacceptable and acceptable.

On the other hand, a game may be perfectly acceptable, but simply out of place -- soccer games may sell like hot cakes in Europe, but soccer isn't the mass-market sport of choice in the U.S. Likewise, business simulations still sell well in Germany, but aren't really an international product worthy of localization. Be aware of these differences, and if in doubt, have someone check out the situation.

Once the decision has been made to go through with the foreign version, the fun really starts. Even if you haven't yet decided upon or brought up the question of localization, it's worthwhile to be prepared. Basically, a localization goes through four different stages: organization, translation, modification/integration, and testing.

During the organizational stage, you need to make an early decision as to when to localize: during development or after completing the game. Most often, the localization takes place once the original product is complete. This isn't due to the process itself, but rather to the insecurity of development and the additional costs that a localization entails. Unless you're certain that your game will sell well abroad, it's hardly worth risking the money in advance. Scheduling a near simultaneous release of all versions really is perfectly feasible -- it's just a bit more involved, and can benefit from the close ties between the development and the localization staffs. Whatever the scenario, one person should be responsible for organizing the materials. Any others who will be needed should be informed early on of the decision to localize. Development schedules are tight at the best of times, and you don't want the programmers to find out at the last possible minute that they will be doing some "minor" modifications.

How the materials are organized is critical for the success of the localization. An approach that has worked well is the creation of a localization kit, which contains all of the game's material and some form of documentation. This documentation is often a table containing file names, types, and a brief explanation of each file's purpose, as well as any other notes (Table 1). Text files may need a bit more description, but we'll get into that later. Just use some common sense when preparing the kit. A dozen CD-ROMs with thousands of files documented in hundreds of tables is going to be as useless as a disk full of source code that contains the game's text somewhere in a couple of dozen .c files.

Table 1. Sample from a localization kit.

Filename	File type	Purpose	Text to be translated	Notes
Intro.bmp	BMP, 8-bit, no compression	Splash screen at game start	Click to continue…	Palette as PAL.bmp
PAL.bmp	BMP, 8-bit, no compression	Palette for main screens	_	_
Normal.bmp	BMP, 8-bit, no compression	Main menu buttons, normal state	Audio, Video, Options, Quit	Palette as PAL.bmp Each item max. 8 chars
Highlite.bmp	BMP, 8-bit, no compression	Main menu buttons, highlighted state	Audio, Video, Options, Quit	Palette as PAL.bmp Each item max. 8 chars
Pressed.bmp	BMP, 8-bit, no compression	Main menu buttons, pressed state	Audio, Video, Options, Quit	Palette as PAL.bmp Each item max. 8 chars

The size of the kit depends on another factor: will you use an outside consultant merely to translate the raw text, or will someone else be replacing the graphics and editing the audio and video as well? This is really a matter of agreement and preference. Some may prefer that an external source perform all localization-related tasks, while others will want to do all the work themselves, using their own staff to perform the adaptation.

Given the sensitive and proprietary nature of games and game technology, it's perfectly understandable that a developer would want to perform localization in-house. The situation, however, does have certain pitfalls. Those making the changes will, in most cases, have little understanding of the material that they're processing, making it very easy for mistakes to slip in. Even for in-house localization, I would suggest having a complete and fully documented kit, using it to keep track of work as it progresses. Thus, if you do end up running out of time, it's fairly simple to off-load the work to someone else.

The kit can also be used to set costs and determine the time needed to translate the materials. If you're localizing during development, you're best off sending the materials in chunks as these are finalized. As soon as the graphics are finished, you can send along a graphics kit. As soon as the text is complete, you can have the text translated. Sending only final versions makes it easier to keep track of what is where and avoids the extra cost of retranslating elements that may have changed. You should provide as much information with the kit as you can: file formats, palette restrictions, compression, and any other information that may be needed to ensure that the materials returned are as complete as possible and useable right away. This completeness is vital to the success of your localization effort. You don't want to find out half-way through the project that you've left out a whole section of the game. Most likely, you'll have some internal documentation of assets anyway, which you can simply modify and re-use for localization.

Translation is, of course, the step most likely to be out-sourced, and is actually somewhat more involved than just translating the text. A translator must also move the text to the new cultural context; the process can take anywhere from a few days to weeks. Only then can you localize the rest of the materials.

Once the materials are complete, you can integrate them into the product. The modification phase that follows translation can, in some cases, be short to nonexistent, or in other cases, very involved. As I mentioned previously, modification may be as simple as replacing red blood with green; in other cases, you may have to remove or replace entire portions of the game. In one instance, a game involved a section with thousands of index cards, each with a graphic showing a few lines of text. Imagine the work necessary to replace all of these, individually. Given the game's estimated sales, the developer finally decided to leave out this part of the puzzle, and in its stead, a simpler puzzle was devised. This story illustrates why it's a good idea to consult the person responsible for localization efforts early in the development cycle; it will help you avoid some major problems.

Testing can be one of the most difficult phases of the project. The integration and testing work may take place many thousands of miles apart -- even with telephone, fax, and e-mail, this is quite a distance. What usually happens is a series of to-ing and fro-ing as the local testers find errors, pass these back, and receive new versions in return. There is no real way to shorten this process, and it can only work well if the people doing the integration and modification work are motivated, much the same as during the primary development. It is at this stage where all the previous organizational work pays off. If your game's assets were all labeled and sorted before they went out, and they come back from the localization team in the same state, then they'll just slot right into place. On the other hand, if something does go wrong, is misplaced, or goes missing, then you're really going to have trouble trying to put together the correct bits and pieces.

Let's look at what's involved in localizing some of the different types of material that make up the average game. In spite of their seemingly common-sense nature, someone, somewhere, has ignored one or more of these points, and has thus caused confusion, delays, costs, and many late nights... or at the very least, a localized game with dialogues like the one at the beginning of this article. But first, here are a couple of general tips:

• The English text will, in general, be the most concise; the translated version may be up to twice as long. Normally, the translated version shouldn't be more that 1/4 to 1/3 longer than the original, but it's still something to consider. None of your game elements can escape this rule; graphics will need to leave more space for text, you'll need more space on the CD-ROM, and certainly the programmer will need to account for varying text lengths. While accounting for completely variable text length is a real pain, you shouldn't assume that English is a good measure -- it usually isn't. Note any restrictions you make (such as, menu items: 16 characters; descriptions: 256 characters) and make certain the translator knows about them (by documenting them in the kit).
• Don't forget the simple things: make room for the localization people in the credits. Many people have only done this reluctantly, not wanting to see any other names on their product. A good localization often depends on people putting in a lot of effort. A properly localized game is as much their product as it is the developers'.