LOCALIZATION
In This Chapter
• Introduction
• Creating International Content
• Localization-Friendly Code
• Level of Localization
• Localization Plan
• Organizing Assets for Translation
• Integrating Translated Assets
• Testing
• Console Submission
• Localization Checklist
21.1 I
NTRODUCTION
A
s international markets continue to grow, there are many opportunities
for publishers to profit from localized games. It is now common practice
for publishers to simultaneously release French, German, Italian, and
Spanish versions of the game at the same time as the English version. Other
languages such as Chinese, Japanese, and Korean are likely to be released a few
months later, depending on the genre and content of the game. In addition,
gamers in other countries continue to raise their expectations about what consti-
tutes a quality localized title, and they want to have the same gaming experience
as their international counterparts.
Chapter 21Chapter 21
344 THE GAME PRODUCTION HANDBOOK, 2/E
If not properly planned for, localization can be a frustrating and time-
consuming process for the development team. However, if the development
team starts planning for localizations in pre-production, many issues can be ad-
dressed and eliminated, so that the localized versions can have minimal impact
on the overall game development cycle.
This chapter presents an overview of how to plan a successful localization.
The topic of localization is quite large, and it is beyond the scope of this book to
delve into specific details. For more information on localizations, please refer to
The Game Localization Handbook by Heather Chandler. Full reference infor-
mation on this book is available in Appendix C, “Resources.”
21.2 CREATING INTERNATIONAL CONTENT
When developing localized versions, consider how the game content may be
received in other countries and try to develop content that is culturally sen-
sitive. For example, if the game is going to be released in Germany, don’t
include references to Nazis—the game will be banned in Germany, and gen-
erate some bad publicity. Be aware of how the game uses humor and slang, as
these elements are difficult to translate and may end up making no sense in
the translated versions. Figure out ways to tailor the content for international
markets. For example, some sport titles include players from several different
countries and the game will default to displaying the appropriate nationali-
ties for each player—a French player will see a French sports team when the
game initially starts, a German player will see a German team, and so on.
During pre-production it is important to seek input from native speakers
on the game design and story. A native speaker will be able to advise the team
on what might be a red flag in the localized version. These natives will also have
advice on what type of content will best appeal to international players. There
are many cultural issues to consider, so be sure to use whatever resources are
available when developing content for the game.
21.3 LOCALIZATION-FRIENDLY CODE
Localization-friendly code is easy to localize. This means that text and other lan-
guage assets can be easily swapped into the game and that builds can be quickly
compiled for testing. Localization-friendly code takes into account all technical,
translation, integration, and testing needs. Even if localizations are not initially
LOCALIZATION 345
planned for, it is good practice to create localization-friendly code, in case the
publisher decides to localize the game at a later date.
Many factors are considered when planning for localization-friendly code,
such as:
■
How are language assets organized?
■
What support is included for fonts and special characters?
■
How are international keyboards supported?
■
Does the game support subtitles?
If issues like this (and others) are planned for in the pre-production,
localization-friendly code can be easily created.
Retrofitting code to be localization-friendly is not recommended; it is time
consuming, challenging, and introduces a number of bugs. In situations like
these, more time may be spent on retrofitting the code, than on working with
the current code to create a localization.
Language Assets
Centralize and organize all the language assets into a separate language-specific
directory within the game. This makes the translation and integration process
more efficient. Figure 21.1 is an example of one way to organize this for multiple
languages. In each of the English, French, and German folders are subdirecto-
ries for “Audio,” “Cinematics,” and “Text.”
FIGURE 21.1 Directory structure for organizing language assets.
346 THE GAME PRODUCTION HANDBOOK, 2/E
Text Assets
The game should be stored in a format that is easy to access, translate, and
integrate. This will save the developer time, when the assets need to be orga-
nized and sent out for translation. Several things can make the text assets more
localization-friendly. For instance, don’t hard-code any of the in-game text.
Instead, make it all accessible from string tables stored in the game. This method
makes it much easier to organize, integrate, and test the translations, because the
developer knows exactly which files must be localized.
Art Assets
Avoid storing text in art assets whenever possible and use game code to display all
the text instead. If text needs to be part of an art file, be sure to put the text in a
separate layer on the source file so it can easily be replaced with translated text.
Voiceover Assets
As discussed in Chapter 10 “Voiceover,” it is important to define a filenaming
convention that allows the voiceover files to easily identified. The same goes
for localized VO files—establish a naming convention that allows someone to
quickly understand what language is used for any given VO file. Also, music,
voiceover, and sound effects should be stored on separate tracks so that the dia-
logue can be easily replaced with translated VO.
International Characters and Fonts
The engine needs to be able to handle both uppercase and lowercase versions
of special linguistic characters, such as ä, Õ, and Ç. Currently, Unicode is the
standard for representing text characters, since it provides a unique number for
every character regardless of the platform, software program, or programming
language. This gives the game code the capability to display more than 65,000
unique characters, including Asian and Cyrillic. Keep in mind that if the lan-
guage uses an Asian or Cyrillic font, the engine must be double-byte enabled and
capable of displaying bidirectional text.
Choose a font that is easily read on televisions and computer monitors.
Televisions display at a lower resolution, so don’t choose fonts that will be diffi-
cult to read when they are displaying international characters. Keep in mind that
some languages, such as Japanese, display better in larger fonts. However, make
sure that the font size is not too large. If it is too large, there will be issues with
overlap when displaying other languages.
User Interface
The User Interface (UI) has many localization challenges. The text usually over-
laps or is cut off, forcing the translator to come up with an abbreviation or an
LOCALIZATION 347
alternative translation that will fit the space better. Keep these things in mind
when designing a localization-friendly UI:
■
Leave space in the UI: As a general rule of thumb, plan for localized text
being about 25 to 30 percent longer than English text. Extra space must be
designed in the UI to accommodate the longer words. This also ensures the
UI screens don’t have to be redesigned later on to display translated text.
■
Use scalable UI elements: If the UI buttons, drop-down menus, text
boxes, and other elements can dynamically scale, localized text can be accom-
modated more easily.
■
Use icons: Using universally recognized icons is a good way to avoid local-
ized text.
■
Support international date and currency formats: Display dates and
currency in the appropriate formats.
Keyboard Input
For PC games, determine how the keyboard commands are mapped to the
keyboard. If the keyboard commands are mapped by location (that is, the far
left key on the bottom row will reload a weapon), make sure this key functions
the same way on all international keyboards. Also, the manual writer for each
language will want to make a note of the exact key when writing the manual,
since the name of the key will be different in each country. If the keyboard
commands are mapped directly to the keys (that is, ~ will switch the weapon
the player is using), make sure that all versions of the keyboards have this key
available. If not, it is necessary to pick a different key to map the command to
for that language.
PAL versus NTSC
If console games are being developed, it is important that the game engine sup-
ports both the NTSC and PAL video standards. NTSC is the video display stan-
dard for the United States and Japan. In this format, the video image delivers
525 lines of resolution at 60 half-frames per second. PAL is the video display
standard for Europe, and the video image delivers 625 lines at 50 half-frames
per second.
If the game does not support PAL standards, it will display incorrectly on
PAL video monitors. If an NTSC image is displayed on a PAL video monitor,
the image will appear to have black bars at the top and bottom of the screen, be-
cause NTSC has 100 fewer lines of resolution. In addition, the image will flicker
because a game running at 60 half-frames per second is being displayed on a
monitor that can only support a refresh rate of 50 half-frames per second.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.