GAME LOCALIZATION FOR WINDOWS PHONE 7

Have you ever noticed how serious gamers seem to have their own unique language and culture? From old-school Zelda and MMORPG World of Warcraft to Halo and Half-Life, virtual universes are where today’s hardcore gamers spend several hours a day; many have even grown up in these alternative worlds. So what does this mean for your effort to release your game in new language markets?

There’s a host of game localization success stories out there and your game can join their ranks. By sensitizing yourself to localization elements in your personal gaming endeavors and with little bit of our help, you’ll be ready to conquer the hearts of gamers around the world.

In order to re-create your in-game experience for players in other countries, you’ll want to work with linguists, translators, voice talent and testers who have extensive experience playing games (whether for console, computer, mobile device, etc). Ideally, they’ll also be familiar with your game genre and have an appreciation for the unique setting and terminology. When this isn’t possible, look for linguists who are experienced in transcreation (or copy re-creation) and cultural peculiarities specific to both your regional markets and gamer demographics.

To make things a little bit more clear for those who don’t have much experience in this area, take a look at a small demo game developed using Microsoft XNA framework and Visual C# for Windows Phone 7. 

But first of all, a short story of this game.

This game was initially developed as a code sample for Xbox 360 console with XNA 2.0 back in 2006. In 2008 one guy from Spain added AI code to show bot navigation around the game world using NavMesh technique. And now, in 2012, I ported all of this stuff:

a) to 4.0 version of XNA (also known as the version with the most significant changes that actually break code compatibility with all previous versions);

b) to Windows Platform instead of Xbox 360;

c) to Windows Phone 7 and .Net 4.0 Framework Client Profile (which actually misses lots of stuff available in full profile of .Net 4.0);

d) added touch input for touchscreen devices and prepared the game for localization.

NOTE: Some wrong stuff in localized version of the game was left out as on purpose to show possible tackles in game localization practices.

So let’s get started!

When the game is launched, it checks current UI culture of a system and chooses a correct (if applicable) strings set.

All of the UI text in game was moved to resource files each of which corresponded to one of the languages selected for localization and later translated to five additional languages. As a side note: the .Net runtime automatically selects needed localized resource (if available) when started.

As a simple bonus the ability to change language via Options menu was added shortly. And here we got first problems. The problem sits where the developers decided to go hardcoded way. For example, take a look at these two screenshots:

English UI of the game does it well. The game calculated the strings length in pixels when the game was launched to get the middle point. This means that when the text is positioned, the actual position value is the middle point of the string. Later game divides the screen into 4 areas and calculates centers in width for each area. These values are position values for the text.

As far as Russian text in this case is much longer than English and we get some undesirable behavior. So we have the first rule for localizing text in games.

Do your best but keep strings length as close as possible to the original strings while preserving the meaning of these strings.

For example, there’s another UI culture in this game – the German version. Take a look at the screenshot:

These strings would not be translated back to English. They are shorter. They are not the same. But they preserve the meaning. Prefect.

So how exactly is this done? This actually is a pretty straightforward procedure that can be described with a few simple steps that have to be done.

1) Add a resource file to the project

2) Repeat for each language the game will be supported by with locale suffix in filename. For German this would look like StringData.de.resx.

3) Move all of translatable strings to resources file.

4) Translate the text preserving the text length similar to the original

5) Build the game.

Now, each time when the game is launched the .Net runtime on phone will look at current UI culture and select corresponding resource if available.

Building on the principles of this particular sample we can change the string sets in runtime by simply changing the Culture Info of current thread and repopulating the Screen Manager with its screens.

See the full demo version of Game Localization:

This is it for now. Next time we will take a look at graphics resources localization. So stay tuned for more.

by Artem Veselovskiy, Globalization Architect at ELEKS