Localisation vs Culturalization

We just went through another round of localisation for Stunt Star, so I thought I’d talk about localisation a bit. Firstly, there is a difference between localisation and culturalization. Localisation is mainly about changing the text and voice in your game to a different language. For example, you might have made the game in English and you want people that speak French, German, Italian and Spanish to understand and enjoy it, so you add versions of the text in those languages. Culturalization is changing the game to suit a different culture. For example, changing the story to better resonate with a people in a different part of the world.


Localisation is much easier if you have planned for it from the start. Avoid using text in textures and use a dynamic font system so that you can easily translate to non-alphabetic languages which have a large number of characters (eg Japanese). If you use people’s names in leaderboards, you’ll have to make sure that your font supports the characters in their names. Allow a bit more space in your UI, as the German version of a phrase tends to be longer than the English version. Don’t use voice unless you have to, as six versions of it is going to be fairly costly! It’s a good idea to not have strings directly in code, as each of them will have to be found and replaced later.

Every game I have worked on has been in at least English, French, German, Italian and Spanish (EFIGS). Some games had separate versions of English for UK, US and Australia, separate versions of French for France and Canada and separate versions of Spanish for Spain and The Americas. A few have been in Japanese as well. It’s a good idea to do some research in pre-production to work out which language will be worthwhile for your game. This depends on the type of game, it’s content and what platforms it is on.


We tend to use a spreadsheet with some importing/exporting tools to store the localised strings. For Stunt Star, we used Localisation Package and Google Drive. Each string has a key, maximum length, the string in English, a field for every other language and notes for the translators (eg if the string doesn’t need to be a direct translation). The key is what is used in code/data to reference the string. You can also add fields that check that the localised strings aren’t too long. Some strings don’t need to be direct translations, so it is good to allow the translators to be creative and put something more appropriate for that language. We used this for some of the fail messages in Stunt Star - I guess this is a way to sneak in some culturalization. You can have a separate spreadsheet for different areas of the game if you don’t want the entire thing in memory all the time. Also, have a separate spreadsheet for strings that aren’t in the game (store descriptions, keywords, achievements, etc).

The strings get exported from these spreadsheets into separate files per language and sheet. On first boot, the game chooses the language based on the device setting, showing the language select screen if the device language isn’t supported. The game then uses the current language to lookup the string key and use the appropriate string. We have a debug button that is always on screen that cycles strings between the string key and the actual string for each supported language for quick testing.

Localisation Tips

Check if the platform you are targeting has a standard set of terminology that is already localised. Quite often things that the end user interacts with have standard names, for example, "Live Tiles". Microsoft have a handy search page which can be found here.

To get the best results, get whole phrases/sentences translated, even if your string is made up of dynamic things like score. Subject-verb-object ordering can be different in different languages. For example, “Get 5000 cr on Cornballs 2 level 15 with the Monster Truck.” should be one string and the English version might be: “Get <score> cr on <chapter> level <level>.”, and the Italian version might be: “Ottieni <score> cr nel liv. <level_num> di <chapter>.”

Also, send the translators a general introduction to the project (themes, tone, audience, platforms, genre, etc) and the game if possible. It’s also best if the translations are made by one person and then checked by a native speaker. Most good translation services will offer that. We used Localsoft on Stunt Star. Even better if the strings can then be tested in game by a third party. Finally, put the translation team in the credits. They have allowed you to get your game out to many more people!

To sum up, localisation isn’t too much work if you plan ahead a little and it will allow you to reach a greater audience. I’m pretty sure platform holders are much more likely to feature your game if it is localised as well.

 - Paul (@pbaker05)

Stunt Star: The Hollywood Years is available on iPod, iPhone, iPad and Android in English, French, German, Italian and Spanish.