14 Localization Kits

In this chapter:
• Defining Localization Kits
• Creating Localization Kits
• Contents of Localization Kits
• Organizing Content Effectively
• Finalizing Localization Kits
• Storing and Maintaining Localization Kits
• Localization Kit Checklist

Defining Localization Kits

A game consists of several types of assets that must be archived once
production on the game is complete. Creating these archives is an
important step in wrapping up production on a game. Without these
archives, it would be almost impossible to go back and rebuild the game
for product re-releases, develop ports of different gaming platforms, and
create localized versions. Additionally, these archived assets can be used
to create specialized versions of the game for Original Equipment
Manufacturers (OEM), which can be pre-installed on computers or
bundled with other hardware such as video cards. These archives will also
be used to create any necessary patches, and the patches themselves
should be added to the archives once they are completed.
These archives can be organized in three ways: a full closing kit, a
localization kit, and a translation kit. These kits are inter-related, and the
type of kit necessary for the desired tasks depends on how it is going to
be used.
A full closing kit contains all the final assets, source assets,
documentation, and source code necessary to create a working version of
the game without assistance from the original development team. In some
cases, the original development team will be needed to clarify the
documentation, offer expertise to fix a bug, or provide additional assets
and code that were not included in the original archives. However, it is
rare that all the information is included in the kit. This kit can be used to
completely rebuild the game, modify the existing game, or create a patch
for the game. A full closing kit is usually sent to people who may be
working on ports of an existing game or updating the current game with
new functionality.
A localization kit is a subset of the full closing kit and contains only
the assets that are necessary to create a localized version of the game. If
the game has localization-friendly code, it is unlikely the source code
will be needed to create the localized versions. This kit is smaller than
the full closing kit and can be used by localization vendors. The vendors
can use this kit to get the assets translated, integrated, and tested without
assistance from the development team.
A localization kit is easier for a localization vendor to work with since
it contains only the assets and documentation needed to create localized
versions. If the vendors receive a full closing kit, they will have to search
through a lot of code, assets, and documentation just to pull out the items
they need. With a localization kit, the vendor can avoid this and focus
entirely on the localization. However, if the code is not localization-
friendly, the localization vendor may need a full closing kit to modify the
code. For example, if an external vendor is creating a Japanese version of
the game and the game code is not double-byte enabled, the vendor will
need the game source code so this functionality can be added.
A translation kit is a subset of the localization kit. The translation kit
contains only the assets and text that need to be translated. It does not
contain all the files that are necessary to actually create the localized
versions. A translator can get the translation kit, translate all the
necessary text, and send this to the development team so they can
integrate, test, and release the localized versions.

Creating Localization Kits

Ideally, the localization kit should be created after the source language
version of the game has been code released. This ensures that the most
up-to-date assets and code are included in the kit. The developer will also
have more time to spend documenting the localization kit and can
provide all the details on the contents, language assets, and tools included
in the kit.
In cases where an external vendor is working on localized versions that
are releasing simultaneously with the primary game, a localization kit
will be needed before the primary version is code released. This is not an
ideal situation—assets and code included in the kit are usually not final.
If the vendor is working from a localization kit that is not final, designate
a contact on the development team who can provide the vendor with
regular asset updates. If this happens, the developer will need to create a
proper localization kit after the project is released for future
localizations.
Once the initial localization kit is created for the game, patches or
other game content may be created after the game's initial release. The
assets for this content need to be added to the localization kit as well. For
example, the Xbox version of Tom Clancy's Ghost Recon: Island Thunder
released additional downloadable content after the main game shipped.
An initial localization kit was created immediately after the game's
original release date, and the assets for the downloadable content were
added to the kit a few months later.
When content is added later, the content can be organized as a “mini”
localization kit that is added to the main localization kit. This mini kit
would have its own set of assets, tools, documentation, and code and
would be treated as a supplement to the main kit. This method is the
easiest because the initial localization kit does not have to be reorganized
to include the updated assets. Be sure the “mini” localization kit is
labeled clearly with the name of the main game and the type of content it
contains.
Where the content update is more complex, such as adding a new
character class or updating the game code to a significantly different
version, a new localization kit should be created with the updated
information. Archive the previous version of the localization kit, but be
sure this older version is not inadvertently sent in place of the newer
version.

Contents of Localization Kits

A localization kit contains several items: assets, documentation, tools,
and code. If one of these areas is neglected or does not contain enough
information, the localization kit will be difficult to use. In cases where
the localization kit is not adequate, time will be taken away from the
original development team to answer questions and provide any missing
information or assets. This can be a risk, especially if the team has moved
on to another project and is not readily available to provide assistance.

Assets
All the text, art, and sound game assets to be localized must be included
in the localization kit. It must also contain the original source files of any
of these assets, so the vendor can easily integrate the asset and then
convert it to the final file format used in the game. The localization kit
also needs the final format of all the other assets in the game. This is
because the translation vendor needs to have all the final assets, even the
assets that are not localized, to build the gold master for the game.

Text Assets
Text assets are any assets containing text to localize for the game. This
refers to any UI text, in-game text, help text, installer text, and so on. If
any text assets are missing from the kit, the vendor will spend additional
time tracking them down or may not even realize some of them are
missing.
When collecting the text assets for the localization kit, make sure to
include the following:
• Source language assets: All the text assets for the game must be
included. This means all the source language assets should be in
the kit. The vendor can compare his localized assets against the
source language assets and correct any incorrect formatting or
context bugs in the localized versions.
• Help files: Help files and “readme” files should be included. If
using .hmtl help files, make sure all the .html assets are included.
“Readme” files are usually done for PC games and are the last
thing to be written before the game is code released.
• Installer strings: All installer strings for the PC version must be
organized in a central place in the localization kit.
• Error messages: Text for the console error messages should be
pulled out and included in a separate file.
• Checklist of text assets to be modified: A complete checklist of
all the text assets to be modified should be created by the
developer. This checklist will be immensely helpful to any
external people who need to create localized versions of the game.
They can look at the checklist and have an immediate idea of how
many files need to be localized and where these files are located in
the game. Figure 14.1 is a sample checklist. The first column lists
the text filename, the second column provides details on the
context of the text included in the file, the third column provides
an estimated word count of what needs to be localized, the fourth
column shows where this asset is located in the game, and the fifth
column is for any additional notes.

Voiceover Assets
Voiceover assets are another component of the localization kit. They are
more complex to localize properly since actors need to be cast, studio
recording time needs to be booked, and the files must be post-processed
to sound their best in the game. To get the best quality of voice acting and
sound for the localized VO files, several items need to be included in the
localization kit:
• Source language VO files: The source VO files are included in the
localization kit to provide reference for the localization vendor. He
can hear how the actors deliver the lines, what the post-processing
sounds likes, and what the timing is for each of the files.
• VO script: The script provides all the lines spoken in the game
within the correct context. The script should be organized in
chronological order so the vendor understands the story flow of the
game when reading through the script from beginning to end.
• Casting notes: This includes all of the character descriptions and
casting notes for each speaking part in the game. If celebrity
voices were used for the source language or other localized
versions, this should be noted in case the localization vendor
would like to get equivalent voice talent for the version he is
doing.
FIGURE 14.1 Checklist for text assets to be localized.

• VO technical specifications: The localization vendor needs to

know in what format to record the original VO files and into what
format they need to be converted. (Refer to Chapter 9 for more
information on VO technical specifications.)
• Master VO sheet: This sheet has all the spoken dialogue broken
down line by line. It includes which character speaks the line, the
filename, voice direction, and context for each line. It also
includes information on any type of special postprocessing effects
that should be added to the audio files. This spreadsheet can be
easily sorted by the information in any column and can act as a
master checklist for all the audio files in the game. (Refer to
 Chapter 9 for more information on organizing the VO files for
localization.)

Art Assets
The text used in art assets should be included in a separate layer in the
file so it can be easily localized without modifying the image. If the art
files do contain embedded text that needs to be localized, make this clear
in the localization kit so the vendor can get an artist to modify the files.
Art assets include:

FIGURE 14.2 Checklist for art assets to be localized.

• Layered art files: If the game uses .bmp, .jpg, or other file
formats, the text should be included on a separate layer.
• Source art assets: If the game requires the art files to be converted
to a different file format before they are included in the game, all
the source art assets must be included to create the localized art
files. For example, if the original art asset is created in a .bmp
format and then converted to a proprietary graphic format, the
.bmp source file needs to be included.
• Logo art: As discussed in the Chapter 9, the game logo may
require localization before being distributed in other territories.
 Include any logo art in the source language so it can be modified if
necessary.
• Checklist of art assets to be localized: As with the text assets, it
is helpful to include a checklist of all the art assets that need to be
localized. Figure 14.2 is a sample checklist that can be used for
tracking the localized art assets. This is based on the checklist
presented in Figure 14.1 and includes similar information.

Cinematics
Include the final version of the cinematics in the localization kit, along
with any source files. The main cinematic assets to include are:
• Final cinematics: The final compressed version of the cinematics
in the source language provides a reference for the localized
cinematics the vendor will create. They are also useful for
directing the voice actors because the actors can see how the lines
are delivered and will get a better idea of the context.
• Codecs and movie viewers: A codec is technology that
compresses and decompresses data. Specific codecs can be used
when creating compressed versions of the cinematics. If the
cinematics require a specific codec not readily available in any of
the popular movie viewers, like QuickTime, the codec and the
movie viewer should be included so the vendor can easily play the
cinematics.
• Uncompressed cinematics: If there is text to be localized in the
cinematic, the uncompressed version of the cinematic should be
included. The uncompressed version provides an easy way for the
vendor to get to the source file that needs to be localized. Once the
file is localized, the cinematic would be re-rendered and re-
compressed. Uncompressed cinematics can take up several
gigabytes of memory, so be sure they are in a format that can be
 managed easily. If there is not text to be localized in a cinematic,
the uncompressed version does not need to be included in the kit.
• Sound mix components: The cinematic audio is divided into three
tracks: music, sound effects, and voiceover. These tracks should be
included as separate uncompressed tracks in the kit so the VO
track can be easily replaced with the localized VO track.
• Final sound mix: The final sound mix can be included as part of
the compressed cinematic. This is useful to have as a reference
when recording the VO for the localized versions.
• Checklist for localized cinematics: This checklist includes all the
areas of the cinematic that need to be localized. Figure 14.3 is an
example. A checklist can be created for each cinematic that needs
to be localized.

FIGURE 14.3 Checklist for localized cinematics.

Localization Assets
If localized versions of the game have been created before the
localization kit is finalized, all the localization tools that were created
while making these assets should be included as well. These tools
include:
• Localization glossaries: If a glossary has been compiled for the
game, include it in the localization kit. (Refer to Figure 9.6 in
Chapter 9 for an example of a glossary.)
 • Text translation spreadsheets: If text and VO assets have been
organized for translation for other localized versions, these
spreadsheets should be included. (Refer to Figure 9.8 in Chapter 9
for an example of a text translation spreadsheet.)

Box and Docs

Include any “box and docs” that are created for the original version of the
game. Although the vendor may change the layout of the packaging to
better suit the version he is creating, he needs to make sure all the
appropriate content is included. The types of “box and docs” assets are:
• Packaging: This is a .pdf file of the box layout and text and can
usually be obtained from the marketing or creative services
department.
• Manual: A .pdf of the manual layout can be obtained from the
marketing or creative services department. Additionally, if there is
a final draft of the manual text in document form (i.e., not a
manual layout), this should also be included in the kit.
• Screenshots: Screenshots used for the box and manual should be
included separately from the manual and box layouts. Some of the
screenshots used in the manual may have text overlays to call out
specific parts of the image. For example, UI elements in the
screenshot could be labeled on the image and then defined in the
manual text. In this case, a labeled and unlabeled version of the
screenshot should be included.
• Electronic manuals: If an electronic version of the manual is
created in .pdf or .html format, all the source assets are needed.
• Box and docs checklist: Include a checklist of all the “box and
docs” that need to be localized for the game. This includes any
keyboard reference cards, box layouts, and manuals. The checklists
in Figures 14.1 and 14.2 can be used to create this list.
Tools
Tools refers to any proprietary tools or plug-ins that are used to create the
final localized game assets. For example, if a specific text editor is
needed to open and edit the text files, it should be included. Any
proprietary program needed to convert .bmp files into the graphic file
format used by the game should also be included. Additionally, the kit
should include proprietary tools created by the development team to
make the asset integration less time-consuming. If specific commercial
software is needed to create these assets, the information and the correct
version must be noted. The types of tools to include are:
• Plug-ins: A plug-in is software that augments the feature set of a
larger software system. For example, a plug-in might be used in
Photoshop to display a particular graphic file format.
• Proprietary tools: These are tools created by the developer to
handle the game assets. For example, the developer may create a
proprietary text editor to edit the text files used exclusively by the
game code.
• Text editor: A text editor opens text files and allows the user to
edit the files. If a specific text editor is needed to work with the
game's text assets, it should be included in the localization kit. If a
specific text editor is not required, this should be noted in the kit
documentation.
• Localization integration tools: A developer may create
proprietary tools that streamline the asset integration for the
localized assets. If any localization specific tools are available,
include them in the kit.

Game Code
Since the localization kit is only a subset of the full closing kit, it does
not need to include all of the game's source code, only the code necessary
for creating the localized versions. If the code is localization-friendly, the
vendor can just replace the source language assets with the localized
assets and build the game. The following types of code can be included in
the localization kit:
• Original source language master: Ideally, the localized masters
can be created by replacing the source language assets with the
localized assets. If this is not the case, detailed instructions on
recompiling the build with the localized assets will need to be
included.
• Tools source code: If proprietary tools have been developed,
include the source code. This allows the localization vendor to fix
any localization bugs that occur when using the tool. For example,
since Korean requires double-byte enabled code, the vendor may
find that a tool for converting text files has trouble reading some
of the Korean characters. Consequently, the assets do not get
properly converted and the text displays incorrectly in the game. If
the source code is available for this tool, the vendor can fix the
issue without asking the original development team for help.
• Installer files: When working on PC games, the installer files
must be included in the kit. If using a commercially available
installer, include all the proper files so the localization vendor can
open it and make any necessary changes.

Documentation
Documentation encompasses design documents, technical guidelines,
tools information, and general information about the game and the
localization kit and will be the first thing vendors check for information.
Make sure the documentation is up-to-date and clearly written. The
documentation can quickly explain what the game is, how the text is
organized, and any technical issues the developer will encounter when
working with the assets.
When adding documentation to the localization kit, use descriptive
filenames to make it easier to locate the correct information. For
example, a document should be called “Using the RSB Editor,” instead of
“RSB.” Additionally, try to provide a brief overview of each document or
groups of documentation in the table of contents for the kit.

Table of Contents for the Localization Kit

Include a table of contents for the localization kit on the first disc. It must
detail each folder in the kit and have an overview of folder contents. If
the assets are particularly complex, include information about the
subfolders. However, a general overview of the contents is sufficient if
the assets are organized within a logical file structure. Figure 14.4 is a
sample table of contents that has been started for a localization kit.

FIGURE 14.4 Sample table of contents for a localization kit.

Game Documentation
Include game documentation in the localization kit. If the localization
vendor knows what the game is about and how the gameplay works, a
high-quality localization can be done. If the development team has
already created localized versions of the game, add the same game
documents that were sent to translators originally. The types of game
documentation are:
• Core design docs: These documents explain the overall game
design and how to play the game. Controller and keyboard
diagrams, character descriptions, story outlines, and gameplay
features are explained in the core design documents.
• UI flowchart: The UI flowchart can be invaluable to people
working on localized versions of the game. If they can see how the
overall UI fits together, they can make sure the translations flow
logically from one screen to the next. The translators will also
understand the context of the terms and can make sure they are
used consistently throughout the UI.
• Cheats: Cheats allow a localization vendor to quickly play through
the game and easily access any part of it. If the release version of
the game has the development cheats deactivated, an executable
that has the cheats activated may be needed. The localization
vendor can use this version for the linguistic testing and then do
the final functionality testing with the release executable.
• Mission walkthroughs: Mission or level walkthroughs allow the
localization vendor to know everything that is included in the
game levels. The walkthroughs should detail where the enemies
and objectives are, provide a map of the space, and describe any
special weapons or items the player can use on that level.
• Test plans and test scripts: The test plans provide information on
all areas and features of the game that need to be tested. Test plans
for the source language version of the game should be included so
the localization vendor can base his functionality test plans on
them. If programming scripts were created to automate testing,
these should be included as well, along with any instructions on
 how to use them.

Technical Guidelines
Technical guidelines provide information on how to integrate the assets,
convert assets to the game-specific file formats, and hardware and
software specifications. These technical guidelines should be clearly
written and geared toward someone not on the original development
team. The types of technical guidelines to include are:
• Localization pipeline overview: This document provides
information on the overall localization pipeline. It includes
specific instructions on how to use the assets in the kit to create
localized versions of the game. Information on which assets need
to be localized, what tools are necessary to integrate the
translations into the assets, and how to convert the assets to the file
format used should be included.
• Build instructions: Build instructions are a subset of the
localization pipeline information. These detail how to set up the
development environment to build the localized versions.
• Software specifications: This refers to any commercial or
proprietary software that is needed to create the localized versions.
If commercial software is used, include which version of the
software is required for the game. If proprietary software is used,
be sure to note any hardware specifications that are needed to run
the software.
• Hardware specifications: This refers to any specific hardware that
is needed for the game such as console development kits or
computers that meet certain minimum requirements. If using
console development kits, include the contact information for the
third-party publisher because the localization vendor may need to
contact them to order the hardware.
 • Tools instructions: Any tools included in the localization kit need
to have specific instructions on how to use them. Information on
hardware specifications, how to install and run the tool, how to
open and edit files, and how to convert file formats should be
included. The instructions for the tools should be clearly written
and geared toward someone who is not familiar with how to use
the tools.

General Product Information

The general production information sent to the internal localization
coordinator should also be included in the localization kit. The contact
information is especially important. The localization vendor needs to
know whom to ask if he has problems or questions with the content of the
localization kit. The general product information should include:
• General game information: This gives the vendor specifics on
which version of the game is included in the kit. General
information about the game's original release date, the version, and
the platform should be provided in the localization kit.
• Contact information: This should be someone the vendor can
contact with any questions about the localization kit or the game.
This contact acts as the liaison between the localization vendor and
the developer. Figure 14.5 is a form that can be used to list the
general product information.
• Known bugs: If there are known issues or bugs that are not being
addressed in the game, these should be included in the kit. For
example, if there is a known bug in the final version of the game
code about the capitalized versions of accented letters displaying
incorrectly, include this information in the kit. If the localization
vendor is aware of this bug, he can work around it when getting the
assets translated.
FIGURE 14.5 Form to list general product information.

Organizing Content Effectively

Since so much information is included in the localization kit, it is
important that it be well organized and contain thorough documentation.
The kit needs to be organized so that someone unfamiliar with the game
and how it is organized can create a localized version. Although each kit
will be organized differently, depending on how the assets are structured
in the game, there are a few general rules to follow when organizing the
localization kit.
Organize the game assets, documentation, code, and tools into separate
folders. Figure 14.6 is an example of this directory structure. The
“Kit_Contents” document is a detailed table of contents for the
localization kit. Each main folder is further broken down into subfolders
that are logically organized.
If putting the kit on multiple discs, the documentation and table of
contents file should be located on the first disc for easy reference. If
possible, include the documentation and tools on one disc, and the game
assets and game code on a second disc. The key is to keep everything
logically organized and documented so a vendor can quickly locate the
necessary assets.
Documentation
The detailed table of contents is always at the root of the first disc in the
localization kit. Next, create a folder called “Documentation” with
subfolders labeled “Game Documentation,” “Technical Guidelines,” and
“General Product Information.” The directory structure then gets more
detailed within these folders. For example, the “Game Documentation”
folder contains subfolders for “Core Design Documents,” “Cheats,” and
“UI Flow.” (Refer to Figure 14.6 for examples of the subfolders to create
for the “Technical Guidelines” and “General Information” folders.)

FIGURE 14.6 Directory structure for localization kit.

Tools
Create a “Tools” folder and include a subfolder for each tool. The
subfolders should be labeled with the name of the tool. In Figure 14.6, the
tools subfolders are called “Max Plugin,” “RSB Editor,” and “RSF
Editor.” Each folder contains all the files to run the designated tool, along
with directions on how to set up and use the tool.

Code
Create a “Code” folder and include subfolders for game code and tools
source code. The game code folder should contain all the game files that
are needed to create a localized master of the game. The vendor should be
able to take this folder, drop in the localized assets, and quickly have a
localized version of the game up and running.
The tools source code folder should include a subfolder for each tool
that has source code. In Figure 14.6, the tools source code folder contains
directories for “RSB Editor” and the other tools. Also include compiling
instructions with each set of source code.

Game Assets
The “Game Assets” folder contains all art, audio, cinematic, packaging,
and text assets to be localized, along with all the necessary translation
documentation. All the assets included in a localization kit are in the
source language.
Figure 14.7 is a sample directory structure for organizing the assets. A
separate folder is created for each type of asset, with subfolders in each
asset directory labeled “Documentation” and “Assets.” “Documentation”
is where all the translation documentation is located. For example, in the
“Audio” folder, all the assets to be translated are located in the “Assets”
folder, and all the supporting documentation, such as the VO script and
the character notes, are located in the “Documentation” folder.
FIGURE 14.7 Directory structure for assets.
FIGURE 14.8 Directory structure for game assets.
The structure of the “Assets” directory for each type of asset in the kit
should mimic how the assets are stored in the game directory structure.
Figure 14.8 is an example of a game asset directory structure. In this
example, the audio files are not all located in a single folder; they are
organized by character and mission.
The same is true for text files. If the text files are organized a certain
way in the game directory, they should be organized in a similar way in
the localization kit. (Refer to Figure 14.9 to see how the text files are
organized by type and mission in this example.)
FIGURE 14.9 Localization kit checklist.

Finalizing Localization Kits

Once all the assets are gathered together and organized into the
localization kit, do a final check to ensure that all the proper assets and
instructions have been included. Then, give the complete kit to a
developer who was not on the original development team and ask him to
create a sample localized version. The assets do not need to be translated
for this; he is checking the kit for accuracy of contents and clarity of
directions. This important step should not be skipped. If the contents of
the kit are not verified by a third party before sending it out, the kit may
be missing key tools and information that are necessary for creating the
localizations.
Once the contents have been verified, there are a few other checks to
do before the kit is finalized. First, check all the files to make sure they
are not corrupted. Second, virus-scan all the files to make sure they are
all virus-free. Third, verify that no extra files are included and that no
files are missing. Fourth, verify that all the files are the most current.
Once these checks have been made and the contents confirmed, the kit
can be considered final.

Storing and Maintaining Localization Kits

Since localization kits are a subset of the full closing kit, they should be
stored alongside the full closing kit. Usually, a copy of the localization
kit is stored with the original developer; another copy of the kit is sent to
the publisher's archives; and another copy of the kit is stored off-site with
other closing kits. Multiple storages areas ensure that the correct data
will always be available, even if one kit is lost or missing information.
Each disc should be clearly labeled with:
• Game name
• Version number
• Platform
• Date the kit was created
• Disc number, out of the total number of discs
• General description of contents (documentation, tools, etc.)
This information is useful if there are several discs in the localization
kit or if there have been updates to the kit. This information also lets the
vendor know which disc will contain the information he is looking for.
If the localization kit is updated to include patches or additional
content created after the game was released, create a mini-localization kit
with the critical assets stored on a separate set of discs. The table of
contents should state that this kit is an addendum to the main localization
kit and include information on the main localization kit and how this
mini-kit should be used in relation to the main one.

Localization Kit Checklist

Figure 14.9 is a sample checklist of all the items to include in a
localization kit. The first section lists all the assets to include in the kit.
The following sections list the code, tools, and documentation to include
in the kit. The last section is a list of questions to answer before the
localization kit is finalized.

DEVELOPER INTERVIEW
Ellen Guon Beeman, Executive Producer, Microsoft Casual Games®

No One Lives Forever ® 2: Deathmatch™ Add-on, No One Lives Forever

2: Doomsday™ Add-on
The localization pipeline for No One Lives Forever 2 (NOLF2) was very
well organized. This is where I have to give all the credit to Jon
Gramlich, the terrific QA Lead (now Associate Producer) for the team,
who organized the assets and delivered them to Vivendi Dublin. Jon
organized the assets, Vivendi Dublin localized them, the final build and
installers were completed by Brad Pendleton, Lead Engineer from the
NOLF2 team, and Jim Geldmacher, Engineer, and the final QA was done
in Dublin.
The initial breakdown of responsibilities between Monolith and
Vivendi Dublin was clearly defined. Monolith's responsibilities were to
create English versions of the source code, game assets, documentation,
and installer. Next, we created placeholder localized versions of the game
using the English assets and provided detailed documentation to Vivendi
Dublin on where the localized files were located. We also provided
documentation and source code for building the game and installer. Once
Vivendi Dublin localized and finalized the assets, it was Monolith's
responsibility to incorporate these assets into the game, create the final
build, and release it for manufacturing.
Vivendi Dublin's responsibilities were to check the game for any
violations of the localization standard and report them to Monolith to be
fixed. Additionally, Vivendi translated and localized all the text assets,
voiceover, art assets, and installer assets. Once these localized assets
were created, Vivendi built localized versions for testing. They were
responsible for testing the build, making linguistic bug fixes, and creating
new builds to verify the fixes. Once Vivendi was satisfied with the final
versions of the localized assets, these assets were sent to Monolith to be
included in the final localized versions of the game.
Initially, the release schedule for the localized versions was set by the
publisher. The international versions were not released with the U.S.
version. In fact, the extensive delays caused the final Doomsday
localizations not to be released at all.
There were minimal technical changes for the localized versions,
primarily because the layout was controlled by a separate text file. The
Lead Engineer, Brad Pendleton, set it up this way so any layout changes
were done only to the “layout.txt file.” For the German market, blood and
damage effects were removed, and bodies faded to backpacks, since an
integral part of the game is acquiring game items from defeated
opponents. On previous localization projects, I've dealt with the German
violence restrictions and similar localization issues. The localized
versions were capable of connecting and playing with each other,
although restricted to the same version of the game. Vivendi Dublin
provided testing for the international versions of the game and that
included testing the ability of players on different language versions
playing against each other on the same server.
For my current project, we're switching to a database-driven text
system for in-game text that I anticipate will dramatically help accelerate
localization efforts for the bulk of the in-game text. With database
queries, I'll be able to output spreadsheets specifically of game text that
has yet to be localized for a specific language, and when that text has
been translated, feed those spreadsheets directly back into the database. I
had initially thought of this as an online-only process, but was convinced
not to go in this direction for security reasons. This database system
doesn't help with tool-tips and other UI localization, which will have to
be localized separately for recompiling, but since that kind of UI asset
will change infrequently and the in-game text will be constantly updated,
the system should be a substantial improvement over other localization
methods I've used in the past.

Chapter Summary
Organizing a localization kit is an important step in the localization
process. This kit enables external vendors or other development teams to
create localized versions of the game. It also acts as an archive in case the
original localized versions need to be re-mastered or updated. This
chapter provided detailed information on what to include in the
localization kit, along with advice on how to organize, finalize, and store
the localization kit most effectively. The chapter concluded with a
checklist for what needs to be included in a localization kit.
Now that complete information has been presented on the localization
process from beginning to end, it is time to look at things to be aware of
in the process. The next part of the book presents localization lessons to
be mindful of when developing international games. It begins with a
chapter on some common pitfalls that are encountered during the
localization process and offers solutions for avoiding these mistakes.