Localizing For Lands Beyond The Wild Frontier

"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).

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.

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:

A Programmer's Guide To Foreign Languages

Depending upon the nature of the game, the programmer may not need to code with future localization efforts explicitly in mind -- as long as that programmer is organized and keeps the data separate from the code. Storing text within the code is ill-advised, as it makes the text very difficult to collect. Your localization people could very easily miss whole portions. With all the strings in a string table -- even the system provided by Windows -- replacing all of your game's text is a simple matter. The task doesn't even require a programmer.

From a programmer's point of view, graphics and sound files can be in any language -- besides, perhaps, the varying length of the text. The simplest way to cope with variations in the length of a line of spoken text is to have the speak animation run until the text file has ended. Alternatively, you can have the program read the file's length beforehand. Both approaches are easy to implement. One nameless and unreleased adventure game used the following system for spoken text: Once the script was complete, the script writer timed himself speaking the text (I swear it's true) and passed this information on to the artist and programmer, who then constructed an animation that would run for that length of time -- for all 250 pages of script. Then the script changed. What was that bit about "common sense?"

That said, there are three instances in which the programmer needs to be careful when handling text: display, input, and manipulation.

Display. Some languages (many languages, actually) use more characters than English, not to mention languages that use completely different character sets. The German characters ä, ö, ü and ß can be replaced with ae, oe, ue and ss, but this really looks unprofessional. And you really can't replace the accents in French. In the age of Windows, these character discrepancies are less of a problem, but nonetheless something to keep in mind if you're using your own font and text-display routines. You should try to adhere to some standard for these characters, so the text files won't need conversion or extra work. It is worth noting at this point that number formats vary as well (Table 2).

Input. A similar problem arises when you need input from the user. One oversight has probably generated more frustrated users and calls to hotlines than anything else: keyboard layouts. I can think of at least one installation program in which you couldn't change the installation drive -- not because the program didn't let you, but simply because you can't enter the [\] character on a German keyboard. Similarly, Yes and No don't always start with a Y or an N; the French prefer Oui and Non, the Germans Ja and Nein. At the very least, try to ensure that these simple functions work -- for more complex key layouts, making certain that the localized manual lists the correct keys for that locale should be sufficient.

Manipulation. If you're trying to localize a game that involves some form of text manipulation that goes beyond simple retrieval, then you may have bitten off more than you can chew. Trying to build sentences from individual words is relatively simple with the familiar English grammar. The results of trying to transfer this familiar system directly to a foreign language range all the way from hilarious to bizarre to, well, completely embarrassing. Anyone who has ever tried to learn a foreign language will remember the difficulties: word order is often completely different, and even if the order is the same, the meaning may be completely different. One might assume that half-three means three-thirty, but halb drei in German is two-thirty. Not to mention those blasted articles and their declensions. Take German, for example (not for extra credit): usage of the three articles der, die, and das depend on the gender of the object. Each article and noun has four cases (plus plural), and usage of the different cases depends on where the word is used in the sentence. Is it the direct object? The indirect object? The subject? What pronoun is being used with it?

Punctuation also varies from language to language. Whereas in English the punctuation is connected to the previous word, the French expect a space before colons, semicolons, question marks, and exclamation points. A good translation company will worry about these details for you, but if you're doing your own translation, pay close attention to punctuation rules.

Many other languages can be even more complicated than German and French, and even if the language's rules are known and defined, generating the data required to translate all of your game's text will be a major undertaking. The point is if you're considering a system that involves text manipulation, you're going to have to talk to someone who is knowledgeable about each of the planned languages well in advance to try to find a system that is useable.

"T" Time: Text and Translation

The key to translating a computer game effectively (especially if it's a text-dependent game) is attention to detail. Giving the translation to a friend who "lived in Paris for a few years" may improve your friendship, but most likely won't do your game justice -- unless, of course, your friend is from another area in France and just didn't like Paris. But I digress... The moral of the story is, bring on the experts. Translating any form of entertainment is quite different from other types of translation -- you essentially have to rewrite the text to recreate the atmosphere within the cultural context of the target country. Real-world references in a game can add a lot to the dialog, but once those references have been translated and moved out of their original context, they actually do more harm than good. A good translator will replace (and often improve) those references with some that are more suitable. Similarly, some freedom should be left to change the nature of the characters. One of your game's characters may be mere filler in the original version, but given a local dialect, might transform into a real highlight. The new emphasis on this character might even compensate for a slightly uneventful dialog with the main character. Changing the a character's name may very well improve this "new" character further. The film and cartoon business are no different in this respect; take a peek at some of your favorite cartoon characters, such as Bugs Bunny.

In order to be able to recreate your game's atmosphere, the translator needs as much information as possible. An experienced game translator will require less coaching, and a well-commented script will go a long way; character sheets and sketches are helpful, too. I've seen scripts that go so far as to comment each line with a brief explanation of any slang that's used and a quick mention of the context (Table 3). The point is simple: assume that the translator knows nothing about the game. Even such a simple line as, "That's great" can be interpreted and translated in many ways -- most of which are wrong -- depending on the context in which it's used. Translators may have a near perfect grasp of the language from which they're translating, but some peculiarities are lost even on a native speaker. This is exactly the problem that leads to obscure and pointless dialogs, such as the introduction to this article.

Table 3. A complete audio script.

You should also inform the translator, in advance, of any restrictions -- such as text lengths and, more importantly, the in-game purpose of the text -- that they may have to watch out for when translating. Translating text to be dubbed to video is somewhat more difficult than translating static text that is simply displayed. Ideally, you want the syllable count to be as close to the original as possible, so you don't end up with characters who speak without opening their mouths -- this really makes things look cheap. Experienced voice talent can compensate for minor differences, but when there is only time for a simple "Yes," you won't be able to fit in, "Certainly, my dear," even though that may fit the dialog better. Note that in the example script (Table 3), the translation is inserted next to the original text; it does not replace it. This format serves two purposes: first, when you're looking for a particular file, you can just look for the English and find all the information in one place; and second, you can judge approximately how long the translated versions are relative to the original.

Any text that appears literally in the game should be explicitly marked to ensure that it isn't translated. The best example of this is a game that required the player to input a password. The password itself wasn't particularly difficult for players to find; sufficient clues were dropped in previous conversations. For most players, the difficult part was figuring out that the password had to be input in English -- not the most logical conclusion considering that the rest of the game was completely in German. The same rule applies to any text that appears on graphics, such as place names and labels.

Often, you'll end up using several translators. You'll need to ensure that they are all aware of the previously translated work. Many words don't have unique or obvious translations, and the last thing you want is a menu that's translated differently in the game, the manual, and the help file. Usually, there are standard words for everything about the computer or console being used. Sony actually has a set of guidelines with translations for standard items that appear in PlayStation manuals, such as controller, memory card slot, and so on.

Visuals

The secret of successfully localizing your game's visual elements is to retain the raw materials for any graphics that may have to have text replaced. This is one area where layers are quite useful. All you have to do is replace the text layer, reposition it if needed, and you're done. It's that simple. Imagine the pain of having to retouch the background on 70 screens so that you can replace the text. While it can be done (believe me), it really is wasted time. If you don't have the original backgrounds and are planning many localizations, you should only have to restore the backgrounds once.

If your game has a lot of graphics that incorporate text, such as signs or labels, then you'll have to decide whether it's worth the time and effort to replace them. Place names can usually be left as is. If you have a panel that contains some instructions that are required for the rest of the game, however, you may have to replace them, unless the instructions can be built into the text elsewhere. Just make sure that you make a note of these graphics. They are easy to overlook, and if their existence isn't noted until the later stages of localization, making changes will be all the more difficult.

Even if the original artist isn't going to be doing the changes, it's nonetheless useful to at least have them on hand in case someone less proficient ends up doing the work. That unique combination of 25 different filters may look good in the original, but once someone else has collaged the foreign text onto it, the image may have lost some of its luster. Even though a thorough explanation of the illustration methods may not yield the same results, it will at least ensure that the quality drop isn't too extreme.

Talkin' The Talk

Even though recording may be one of the more time-consuming steps, it's usually best left until late in the localization schedule. The reason for this is simple: you want to do all your recording at once. Studio time isn't cheap, and the last thing you want is to have to go back and re-record a voice-over because the testers have found that several important clues are missing, or worse, misleading. Check the script, check it again, and before you check it, make sure you check it.

You really do want to use local talent for voiceovers; using someone who lives nearby and happened to live abroad for a few years might save you the cost of recording overseas, but it will cost you the game's atmosphere. Using a recognized personality as a voice-over actor can boost sales in your home country -- why not do the same abroad? You may not be able to have Harrison Ford record the German voiceovers -- or the original for that matter -- but you can have the next best thing: his voice. How? Almost all famous actors have one actor who does all foreign-language synchronization for all their movies. In the eyes -- I mean ears -- of the foreign audience, that is the actor's voice. And while they may be more expensive than the normal voice talent, they are still cheaper than trying to hire the original. Imagine having your main character speak in the voice of Brad Pitt, and your heroine sound like Whoopi Goldberg. At the very least, it gives your marketing people something to brag about, the magazines something to write about, and may well give your game some additional publicity.

The basic rules apply here as well: keep the raw materials. Most audio and video software these days lets you put different elements onto different tracks in much the same way that you can layer images in paint programs. You also should have decided in advance who will be doing the editing. While your in-house audio whiz may have the time to edit the entire script, he does have a slight handicap: he (probably) can't understand what it is that he's editing. If you have the script prepared correctly in advance, most studios with some experience in the business will actually record right into the correct files. They'll even add the required sound effects and supply you with a complete set of files that you can use to replace the original files.

With a complete script, you might not even need someone in the studio who knows the game. I would still recommend it, however, to make sure that text is emphasized correctly and doesn't seem out of place, and that the pronunciation is correct.

Finally, don't forget to state the format requirements in advance. High-quality betacam tapes might be great, but if they're in NTSC format, someone in Europe who only has PAL playback won't see much color, if they can actually see anything at all. Format requirements represent only minor hurdles these days, but people experienced in directly dubbing AVI or QuickTime are still few and far between. And trying to organize an overnight videotape conversion isn't something anyone wants to do twice...

Another often-neglected localization item is the supporting materials such as packaging and manuals. Packaging can be especially difficult to oversee from abroad. In some cases, standardized sizes are preferred or even necessary to get any shelf space. In others, the whole packaging design may be unsuitable for the market. Attention to detail is the key here, too. Emblazoning the packaging with reminders of the fact that this game comes from the creators of Big, Bad, and Ugly won't help sales if Big, Bad, and Ugly was never released in the target country, and review scores from U.S. magazines really don't mean much in Europe and Asia. People might think that Big, Bad, and Ugly was never reviewed in their country, or that you're afraid to publish the review scores. Given some of the ghastly localizations that people in other countries have had to put up with -- even of high-profile and hyped products -- the level of public skepticism is quite understandable, especially because they may be paying a lot more for your game than U.S. customers.

I'd like to offer a final word to the wise: just because a word or name makes no sense or has no connection to reality where you are doesn't mean it has the same status elsewhere. A good example is Secrets of Rama. You might think that a harmless name. However, Rama is brand of margarine in Germany. That would only be a minor slip-up (and wasn't, if I remember correctly), but I'm sure no one has forgotten a large Japanese company's ill-fated Internet campaign featuring Woody Woodpecker as "Woody -- The Internet Pecker." That's the kind of publicity we can all do without, and is an excellent illustration of why it's important to have local people involved in any localization project. If localizing a game seems to involve a lot of effort and details to keep in mind, well, it can at first. Once you have a few localized versions under your belt, the process becomes more familiar and can be smoothly incorporated into the development schedule. The costs may also seem high initially. Try thinking of it this way: for a small amount relative to the development costs, you are in effect producing a new product, for a new market, where it can then sell as well as or even better than the original. You've thereby halved the development costs for each product. And if that doesn't convince you, well, then I wonder: What's up? The ceiling, perhaps?