Targeting new regional markets is always a challenge for game producers, as high-quality translation is often not enough for the product launch to become rewarding. To ensure the game is successfully introduced to the target audience and to eliminate possible retail risks, it is important for the product to be perfectly adapted to all the regional requirements and standards, taking into consideration a significant number of social, cultural and legal aspects. Proper localization requires a considerable amount of resources and effort; therefore, detailed step-by-step planning is crucial for a successful project.

We shall start with prelocalization analysis. Assuming you’ve got a game with a certain language interface, you’d like to offer it to gamers in other regions in their respective languages. What do you need for that? At the start, you need to decide how deep your localization is going to be. It may be just the translation and text information support implementation, or you may want to redub all game dialogues, which may require both graphic component adaptation, such as gaming textures of the game model, and possibly some plot adaptations, if this is required by the culture or attitudes of your target region. All this will affect your localization budget and deadlines. When you have decided on the localization depth, you can then move forward.

The next stage of the process will require you to collect all the resources to be localized, keeping in mind how you are going to implement the localized resources into the game. The set of resources to be localized and the toolkit to implement your translation into the game is called a localization kit. The main thing here is to provide a good structure for your localization kit and clearly describe how its components work, so that the people involved in localization can understand it without the need for clarification and can do their job properly, as this will directly affect the cost of the localization.

 

Localization kit structure

To make sure that your localization kit is structured correctly and includes all the necessary components, you should include the following information:

1. Localization manual

2. Text

        a. Non-gaming text

        b. Gaming text

        c. Glossary

3. Dubbing (where applicable)

        a. List of characters and dubbing actors

        b. Dubbing text

        c. Audio file samples

4. Graphics

        a. Interface

        b. Textures

        c. Fonts

5. Tools (toolkit for localization and version compilations).

The localization manual usually includes the project’s word count and instructions for the localization team, such as gaming text word count, non-gaming text word count, dubbing word count, the number of characters and actors, the number of graphic components for localization, how to work with specific formats, font use manual, additional tools user manual, how to produce local game compilations and so on.

The next stage is working with text. There are usually gaming and non-gaming texts within games. Gaming text is text that is used in a game: for instance, dialogues, names, objects and their descriptions, directions for the player and menus. Non-gaming text consists mainly of manuals, license agreements and so on. Localization of non-gaming text is relatively problem-free, while the gaming text may present difficulties. The first such difficulty is hardcoded lines that have not been added to resources. There is a very important stage of the process called internationalization when all textual information is placed into resource files for the user. Internationalization is a software development task to make your software product localizable for any region.

Before you start the translation, you should check if there are any lines of text in the game that you might have forgotten to move to the external resource files for easy editing by the translator. So-called mock builds are used to check this. These are pseudolocalized versions of your game. To make a mock build, several symbols are added to every line of text, at the beginning and at the end. They may be special symbols, as shown in Figure 1 — it looks a bit scary but this is how it should be.

The symbols used may be letters from the localization target language. You can avoid problems later if you use such builds. For a start, a mock build will show you if your interface will accommodate additional symbols and how many symbols. This is rather important as texts in different languages have different relative lengths. For instance, a text in German will be approximately 15-20% longer than a text in English. Once we know this, we can change the design or move around the elements of the interface in order for it to accommodate longer localized lines. We could also set the limit for the number of symbols for the appropriate elements and indicate this limit in the localization kit. The localization team will have to make sure that the translation in the target language fits the space on the controls. The most important function of the mock build is to show you the lines where the added symbols are missing. This means that you have discovered some hardcoded lines, as in Figure 2. After such discoveries, the hardcoded text needs to be moved to resources and the game should be recompiled.

At the next stage, it would be good to collect your text in a single location and bring it into a format suitable for translation. You must include the text source file name, the original text and the maximum number of symbols for translation.

It is essential to create term glossaries, which include, among other things, names of game objects, locations, character names and other terminology. This is necessary to maintain overall consistency in translation. You should also consider certain linguistic peculiarities and word forms. In different languages, words may change according to case, tense and declension. In some instances, it is insufficient in translation to reword the sentence to avoid inflections. It is worth setting up the game engine so that the correct form of the word could be supplied depending on the situation, in which case you should inform the translators which word forms of particular terms may be used.

Various translation tools are helpful in setting up your localization kit. Many contain a number of useful features such as the ability to parse the majority of resource files and to generate resources for mock builds and dictionaries.

The next aspect of your localization kit is dubbing, if that is going to be done. A list of all talking game characters must be compiled, and redubbing the video trailers may also be added along with this. Every character must have a description, where gender, temperament and voice type are outlined. A character screenshot should always be attached in order for the localization team to find an appropriate sound artist and to avoid the situation where a female character has a male voice, and vice versa. Dubbing texts should also be isolated in a separate file in the same format as the rest of the gaming text, so the translator can easily work with it. It is also advisable to provide the original sound files for localization.

When it comes to graphics, you should include interface aspects such as menus, various buttons, text textures, fonts to be adapted based on locale and occasionally logos. Graphic files should be provided for localization in their original format, where all text elements are placed in different layers to make translation easier and faster. It is useful here to dwell on fonts for a bit. My experience suggests that it is not enough to edit the font by adding new symbols. Often the game engine just won’t cope with extended ASCII symbols or Unicode tables. That is why it is worth checking how the game is working with the appropriate language symbols right at the start, at the internationalizing stage, for instance, when mock builds are created.

On top of all original resources, you should also add your specific tools and scripts, along with manuals on how to zip or unzip their texture packs, audio and video files, in case your game engine uses nonstandard binary files. You should also inform your localization team which software to use. Often localization companies also provide localization testing as a service. This makes it easier for the developers and saves localization time. If you are going to use localization testing, you should also include the description of mock builds and supply the appropriate tools and scripts in your localization kit, so that your localization specialist could create localized versions to test and fix issues.

 

Adaptation to regional requirements and standards

In preparing your product for localization, it is essential to remember that the main stage of adaptation is the implementation of regional standards. All units of measurement, appropriate for the target region, must be carefully analyzed to adapt your game properly. Different countries use different number formats for fractions and larger numbers, different date formats and different units of measurement, which will be very important for your end user. For instance, in the United States, Britain, Japan and some other countries, a period is used as decimal separator, and a comma is used as a delimiter for larger numbers. At the same time, in the majority of European countries a comma is used to separate the integer part of a number from the fractional part. Because of that, number 999,999 will be understood differently by users in different countries unless you consider local standards carefully in localization. Let’s see how regional formats are applied to write down the tenth of November, 2012:

10/11/2012: Brazil, Greece, Thailand, Britain, Spain, Italy, France and other EU countries

11/10/2012: United States

2012/11/10: Japan, Taiwan and other South Asian countries

10.11.2012: Germany, Norway, Russia, Ukraine

10-11-2012: Denmark, Portugal

 

As you can see, in some countries the first date component is the year, in some it’s the month and in others it’s the day.

The units of weight, distance and speed measurement are also very important. In most countries, the metric system is used; however, the imperial system of measurement is used in the United States, Britain and some other countries. The problem is that the quantities represented in different measurement systems cannot be translated digit per digit. Therefore, at the internationalization stage, it makes sense to provide the multiplier inside the game engine to move between different measurement systems and let the player choose which system is the most suitable.

 

Culture and legal systems

One of the last but equally important stages of localization is the cultural and legal adaptation of the game for your target area. There are many examples of significant changes that the developers had to make to the game before marketing it in a particular country because of cultural, legal, historical and other issues. Occasionally, you have to adapt the game plot, character names, locations and objects to make the world of the game closer to that of the player.

There are even extreme instances when the developers had to redraw game characters because of some regional cultural issues. Also, different countries use different age ratings for the appropriate game content. If these issues are not taken into account, your game may not be completely accepted by the users, and you may even be fined for breaching some regional legislation.

As we have reviewed various aspects of localization, you may have noticed that we always start with a detailed analysis of the task in hand, be it translation, regional options support or any other stage of the process. Therefore, the first task that you have to perform when you start localization is to analyze the project as a whole to give you the overview of what you need to change in the game. When we analyze a project, we occasionally decide that the code itself needs changing to prepare for localization. We have also mentioned internationalization several times. From experience, this transitional stage is vitally important for a successful outcome, helping you check if the game is localizable and if all the corresponding resources have been prepared for translation. After the detailed analysis and internationalization of your product, you’ll be able to gather all the data needed for a so-called localization kit compilation, which makes up the third stage of the process.

The three stages of project analysis, internationalization and localization kit compilation are the starting points of a localization workflow. It is important to keep in mind that careful planning and organization from the very start of the localization process will help your project to run smoothly all the way to the release date. Additionally, if you’ve considered all the regional requirements standards, you’ll make sure nothing prevents your game from being truly popular with the target audience.