By Patrick
Dowling
Gamasutra
August 28, 1998
Vol. 2: Issue 34

originally published
May, 1998
|
"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'.
|