Production covers a wide range of localization tasks
and contains several areas in which things can quickly get out of
control. Production pitfalls can be easier to rectify than technical
pitfalls, since they do not need to be fixed by adding new game
code. Most production pitfalls can be avoided if the localization
process has been thought out thoroughly and planned for accordingly.
Poor planning is the number-one cause of difficulties
during localizations. As discussed throughout this book, a number
of items must be planned for and considered when developing localized
versions. For example, localization-friendly code is not something
that happens late in the project, it must be planned for in advance.
Moreover, if the assets translation is not planned
in advance, the developer cannot expect to have the assets translated,
integrated, and tested a week before the localized versions are
scheduled to release.
People often make the mistake of putting localizations
on the back burner instead of working on them throughout the production
process. Localizations should be an integral part of the production
planning because there are many external and internal resources
to coordinate. Items such as translations, foreign voice recordings,
and linguistic testing all need to be planned ahead of time. These
things can't be planned until the developer knows the scope of the
localization, which includes what the code can handle, how the assets
are organized, and how many assets there are to localize.
A good practice is to complete the asset overview
sheet in Figure 1 as early in the project as possible. This sheet
is discussed in detailed in Chapter 3. Even if the information included
in this sheet is unknown or not final, the developer can start thinking
about localizations by making estimates about the product. This
sheet can continue to be updated throughout the pre-production process
until the scope is determined. Throughout this process, the developer
and the localization coordinator will work together to determine
the production schedule.
1. Asset overview form.
mistake developers make when trying to achieve sim-ship of localized
versions relates to poor planning. Sim-ship of all localized versions
can be done, but only
if well planned and well executed from the beginning. Since doing
this is heavily dependent on the English version, if the English
version of the game is running
behind schedule, the localized versions will as well.
often not taken into account when working toward sim-ship are the
resources needed to integrate and test all of the languages at once.
For example, if the developer is planning to sim-ship nine languages,
there will be a lot of linguistic and functionality testers to coordinate.
Additionally, all nine versions will need to be integrated, built,
and available for testing at once. A project of this undertaking
will require a few production people to coordinate all the resources,
integrate the assets, and track the schedule to ensure everything
is going as planned.
the developer works closely with the localization coordinator and
the necessary resources are planned for, sim-ship can be a reality.
Other aspects that contribute to a successful sim-ship are localization-friendly
code, well-organized assets, and a clearly defined localization
pipeline. Sim-ship is a group effort, and if everyone knows what
the expectations and deadlines are beforehand, they will be able
to deliver the localized versions when needed.
and Functionality Testing
main pitfalls regarding linguistic and functionality testing are
underestimating the amount of time testing takes and not having
enough testers to complete the scheduled test plans. As the number
of languages increases on the project, the planned number of testers
should increase as well. If the game has many language assets, the
developer may want to schedule two or three linguistic testers per
language to get the game tested more quickly.
working with linguistic testers located remotely, the developer
must also provide the testers with all the information they will
need to thoroughly test the game. If a console game is being developed
and there are specific technical requirements the linguistic testers
must check, such as the use of correct terminology, the developer
needs to supply the necessary tools to check this terms. In addition,
the developer must clearly communicate to the linguistic testers
what the testing expectations are so they can do their best job.
Any tools provided to the linguistic testers before testing begins,
such as cheat codes, walkthroughs, and UI flow charts, will help
them be better testers and complete the tasks more efficiently.
and functionality testing are time-consuming tasks, and developers
have a tendency to underestimate the testing schedule. If the developer
has no experience developing localized versions, testing may be
thought of as something that can happen on short notice and not
take a long time.
if the localized versions are using the same code base as the English
version, linguistic testing is time consuming. In addition, checking
French, German, Spanish, and Italian language assets with four different
sets of testers requires a lot of time just to coordinate the bug-fixing
process. If the developer is in charge of fixing the linguistic
bugs, a lot of time is spent looking over bug reports for all these
languages and making fixes.
general rule of thumb is that it takes a linguistic tester about
three to five days to do a first pass on the game, and it takes
the developer one day per language to make the fixes. Add in time
for making a new build and getting it back to the testers, and the
schedule extends quickly.
quality of translations is something the developer has no direct
control over, but is a problem for localized products in general.
If the translator does not thoroughly understand the main concept
of the game, appropriate translations will often not be provided.
For example, if the game features a character who uses a lot of
goofy puns or sarcastic one-liners and the translator does not understand
these jokes, the phrases and jokes will likely be translated incorrectly.
Therefore, instead of having a goofy character in the French and
German versions, the character may appear to talk nonsensically.
If the developer provides design documentation, a build of the game,
and the other resources discussed in Chapter 8, the translator will
have a better understanding of the game.
acting can also contribute to poor quality localizations. If the
voice actors and director for the localized voiceover do not understand
the context and delivery of the lines, the localized voiceover may
not match the game's context. For example, if the characters in
the game are human and interact in a realistic environment, the
voice acting should match this style. If the voice actors for the
localized versions deliver their lines in a cartoon-like, over-the-top
fashion, the localized versions will appear less realistic.
game experience will be affected if the voice acting makes the player
think of a cartoon character instead of a real human. The opposite
can happen as well. If the character is supposed to be fun, over-the-top,
and cartoon-like, the voice actors for the localized versions must
convey this in their performance. They should not deliver the lines
in a flat voice devoid of personality.
to cost, travel, or scheduling issues, it is unlikely that the developer
will be able to send someone to direct the localized voiceover sessions.
However, it is something to consider, especially for high-profile
titles. It will be difficult for a non-native speaker to direct
voice actors, but if onsite, the developer can assist in the session
and provide some context and direction for the lines in general.
If possible, the developer should talk with the directors of the
localized VO sessions to explain the game and provide examples of
how the lines should be delivered.
developer must provide resources for directing the actors in the
localized voiceover sessions. By sending a build of the game to
the voice director, the actors can see how their voiceovers will
be used in the final product. The final English voiceover files
are also helpful because the actors can hear how the line is delivered
in English and adapt their line delivery accordingly. The developer
can also include context and voiceover direction for each line in
the script. Any other resources, such as detailed character notes,
pictures of the character, or sample line readings in the appropriate
language will also help the performance of the voice actors.
conventions themselves are not a pitfall; it is the lack of a file-naming
convention that can cause problems. Because localized versions require
the involvement of so many external people, things can quickly get
confusing if there is no standard way of referring to the assets.
If the filenames are consistent throughout the project, the developer
and translator will better understand what information has been
sent. For example, if a document called "Character Notes,"
which contains the character descriptions, is sent to the translator
at the beginning of the project, this filename should stay consistent
throughout the course of the project. The developer should not send
a file later in the project called "Character Voice Notes"
that contains the same information as "Character Notes,"
as this can create confusion between the documents. This may seem
like a small detail, but when 50 or 100 documents are sent back
and forth, addressing such a detail can prevent a lot of confusion
later in the localization process.
file-naming convention for the language assets is also important.
If the asset names provide some information about what information
is contained in the assets, the developer will have an easier time
organizing and tracking what is sent to the translator. For example,
a text file named "Game Text" does not provide any information
about which part of the game the text is from. If this file is the
only text file from the game that needs translated, then this is
not a problem. However, if several text files need to be organized
for translation, and they are named "Game Text 1," "Game
Text 2," "Game Text 3," and so on, it will be difficult
to provide specific context on what the file contains. A good filename
is more descriptive, such as using "Mission 01," "UI
Text," "Help Text," or the name of the character.
Of course, the developer can always open the file to check the contents,
but this can get time consuming if there are many of them.
filenames are especially important for voiceover files. Some games
contain hundreds of voiceover files, some contain thousands. If
they are named in a consistent manner, the developer can tell what
the file contains just by looking at the name and will not have
to open every file to check the contents. Additionally, a consistent
naming convention makes the files easier to sort by name, so specific
lines and sound effects can be quickly located. The voiceover filenames
must be clearly communicated to the sound studio conducting the
voiceover sessions, so they can return the files properly named.
If the files are not named properly, the developer will have to
rename all the files before they can be used in the game.
design pitfalls are harder to define because game design is subjective.
What one person finds fun to play may be boring to another. However,
developers should still take into consideration other cultures and
languages in order to design games that appeal to a global audience.
Developers do not want people who buy the localized versions to
feel short-changed by a game that is very Euro- or U.S.-centric
if this is something that can be avoided. However, a global game
is heavily dependent on the game's context. As an example, True
Crime: Streets of L.A. is obviously a U.S.-centric game based
in Los Angeles. Changing the setting for a global audience would
take away the game's flavor and context.
issues are best identified by having the game design elements reviewed
by people from other countries. If the developer works for an international
publisher, the company will have access to people in international
locations who can provide some basic feedback on how suitable game
design and features will be for gamers in their country. They will
provide information on cultural taboos, such as language or actions
that are considered offensive. They will also know if the game will
appeal as a whole to their country and culture. If international
resources are not readily available to a developer, feedback can
be solicited from international people available locally, such as
at college campuses.
game content can also create some issues for localized versions.
In some cases, the content is not offensive; it is just not the
best choice for the localized versions. For example, Shanghai:
Second Dynasty is a tile-matching game that contains a set of
tiles called "Spelling" in the English versions. The basic
premise for this tile set was for players to match pictures of objects
with written words, thus the name "Spelling." The artwork
for the tiles had the text and pictures embedded into the .bmp files.
tile set caused some concern when the game was localized into German
and Japanese. Both countries wanted the tile set localized into
their language and were distressed that a tile set of this nature
had been included in the game without a plan for the localized versions.
Due to the production schedule, there was no time to design a set
of words and pictures for the German and Japanese versions, or to
completely redo the tile artwork for each language. Completely removing
the tile set was briefly considered, but was rejected because it
meant altering the game code and putting the release schedule at
risk. In the end, each country decided to just rename the tile set
to "English." This was an appropriate compromise since
English is something taught to children in Germany and Japan.
this issue was discovered late in the production cycle after the
artwork was completed and implemented in the game, a good compromise
was reached that did not put the game's release in jeopardy. In
other instances, a content issue like this may not be resolved so
easily. Developers must be aware of potential content issues sooner
rather than later so they can be fixed before the game assets are
in full production. The best way to do this is to gather international
input early in the pre-production process and solicit this input
through the game's production.