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

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.

	Figure 1. Asset overview form.

Achieving Simultaneous Release

A 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.

Things 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.

If 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.

Linguistic and Functionality Testing

The 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.

When 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.

Linguistic 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.

Even 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.

A 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

The 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.

Voiceover 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.

The 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.

Due 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.

The 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.

File-Naming Conventions

File-naming 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.

A 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.

Informative 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

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.

Cultural

Cultural 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.

Content

Actual 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.

This 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.

Although 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.

______________________________________________________