Localization providers organize the assets they receive from the game developers and prepare them for translation to ensure that everything goes smoothly. However, in many cases, the quality of the localization can be improved more effectively if developers and localization providers work together from the early stages of development.

In the software industry, developers are aware of the importance of a well localized product and therefore write the software with translation in mind. While technical writing is less creative than the script of a videogame, there is still room to plan the translation and foresee any problems that the translator might encounter.

Different alphabets and length restrictions

The first thing to consider is that different languages use different characters, there are multiple alphabets as well as right-to-left and vertical-reading languages. The code used to develop the videogame should ideally support non-Roman languages and character encodings, so that it can be translated into Greek, Russian, Arabic or Japanese.

Another important issue is the length of words, which also varies from language to language. For instance, when translating a text from English into Spanish, the Spanish text is about 30% longer than the original. When translating documents such as manuals, developers must assume that the localized versions will be longer and, in the case of audio scripts, the translations will have to be shortened to fit the allocated time.

The on-screen text in videogames is usually subject to rather strict character restrictions. While it is understandable that the space on the screen is limited, developers should leave at least some room for other languages. If the word "we" has 2 characters in English, restricting the space for this word to just 2 characters makes it impossible to translate into Spanish, where "nosotros" has 8 characters.

Translation of source code I: translatables

The translation of source code can be sometimes as puzzling as a hieroglyphic. The developer should make very clear what parts of the code should remain untouched and what should be translated, the so-called "translatables".

In most cases, the translatables are just one or two words completely out of context. In the same file we can find two instances of the term "set up". It can be an instruction, a menu option or a button name; the translation will vary accordingly.

When writing the source code, the writer should include a note indicating the function of every string. Instead of:

001 "Display Mode"
002 "Language"
003 "Start"
004 "Exit"

The code could be written as:

001 "Display Mode" - title of a list box showing currently selected video resolution.
002 "Language" - Title of a list box showing currently selected language.
003 "Start" - Start the game.
004 "Exit" = Exit the game.

Where only the terms between quotes are to be translated, and the rest is an explanation.

Translation of source code II: chained strings

Another common practice when writing strings of code, is chaining two or three strings to create a full sentence. While this works in English, experience shows that it doesn't usually work in the target language.

Here is one example:

Depending on the situation, string 1 can be chained to strings 2 and 5 to say: "You win a red car". Or we can join string 1 + string 3 + string 5: "You win a blue car".

Now let's translate the strings:

Joining strings 1 + 2 + 5 creates the sentence "Has ganado rojo un coche", which doesn't make any sense at all because the adjective + noun pair in Spanish is inverted.

As a result, the translation process becomes slower and more complicated, since translators and project managers have to come up with solutions to a problem which, sometimes, can only be solved by getting back to the developer and asking them to change the code.

An easy way to avoid this is to write three separate strings in English:

String 1: You win a red car
String 2: You win a blue car
String 3: You win a yellow car

Dialogue

Videogame scripts, whether they are going to be dubbed or subtitled, also pose a problem if the dialogues do not include enough information. In the world of games, the names of characters, items or weapons are quite creative and abstract.

In order to be translated properly and to preserve the meaning behind the name of a weapon, a place or a character, it is important to provide the localizers with information such as the gender of the character and graphical support: pictures of weapons and items are very helpful to come up with an equivalent in the target language.

The grammatical differences between languages - gender, agreement between the subject, verb, adjectives and nouns - also make it difficult to translate dialogue if the developer doesn't indicate who is talking (singular or plural, masculine or feminine) and who is being addressed (again singular/plural, masculine or feminine). Again, planning for these problems in advance and providing this simple information can help prevent having to send hundreds of queries for clarification.

Consistency and use of glossaries

The lack of consistency in big localization projects is not rare in the videogame industry. Very frequently translators spot inconsistencies between the on-screen text and the manual of the game. The names of menu items or buttons keep changing throughout the material, making it even more difficult to keep track of them.

A good practice is to create a glossary with all the terms that appear in the game, during the development process of the games. The glossary should be divided into categories: names of characters, places, stages, items, weapons, buttons, screens, menu options, etc.

	A good practice is to create a glossary of all the terms in the game for the sake of consistency.

This will help to keep consistency in the original text as well. The glossary should be the first asset to be localized. Once translated and approved, the terms in the glossary will be then used in the translation of all the material related to the game: on-screen text, manual, dialogues, box, etc. Furthermore, it would be an invaluable piece of information for future versions of the game.

Excel vs. Word

More and more localization assets come in MS Excel files, especially scripts and in-game text. Developers prefer to insert the text in Excel because they can use separate columns for different information: character name, dialogue, TC-in and TC-out, etc.

However, translation is all about typing and Excel doesn't have all the features than a text editor like Word has. Most translators like to delete the original text as they type, which can't be done in Excel unless they click on each cell to edit it. This might not sound very terrible, but when we are talking about translating thousands of rows, it can certainly slow the translation down. It would be helpful to have both the Excel file for organizational purposes and the translatable text in a separate file.

Taking into account the differences between languages - alphabets, characters, length, grammar, providing information to the localization provider like guidelines, screenshots, descriptions and ensuring consistency throughout the project can make a big difference. Planning a title for its future localization doesn't involve much trouble, can save everyone money and time and will certainly result in a much better product and a happier end-user.

_____________________________________________________