Extensible Game Localisation

There’s lots of text in a game, but there’s also a lot of languages in the world. Google Play and Apple both allow you to set properties for your game store releases for different regions when releasing. So what about the internals in your games like text and images? If you’re just to focus on English, or Japanese, or any specific language, then it’s easy to simply just hardcode all of the text. But what if you want to expand your audience, or what if you want to add languages later on?


Hardcoding multiple versions of text, within a set of Dictionaries or a 2D array is certainly an option… although this expands the complexity and size of your code and you could potentially run into memory issues as all the languages would need to be loaded at once. As well, It doesn’t make it very easy to change as you’d need to find the proper line buried in the source code.

Also, As the lead programmer for Virtex, I speak English, French, and pretty basic Korean thanks to working there two years, but what about languages I don’t know? Russian? Japanese? Arabic? I’d have to have someone fluent add and edit the source code, or I’d need to provide a list of words and lines I needed translated, and then would need to plug that back into the code? I could always use Google Translate…. (that was sarcasm). Surely there must be a better way… an elegant extensible way?

Serialization to the Rescue

For The Chaotic Workshop, the solution we’ve implemented was to create a set of Serialized XML files which correspond to a single LanguagePack class in the code. It’s set up so that there is one XML file for each language. For each line of text in the game, The files hold an entry with a Key, the Localised Text and a Description to help give context for any translators. When the game starts, it simply checks which languages are available by checking in the localization folder for xml files. From there, the user can select one from a dropdown box.

The English and French XML Translation Files

Plug and Play

This makes it simple to add any translations. When I want to add a Spanish Translation, all I need to do is send a base version of the XML file to a colleague who is fluent in Spanish, for Korean it’s just as simple. What it comes down to is simply having a fluent 3rd party be able to translate their XML file from English(or another preferred language) to their language, and then popping that XML file back into translations folder.

Done. Language Added.

To illustrate this, here is the game running with the English Version of the Settings Screen.

And here is the same instance of the game with the Partial French Translation of the same Settings Screen.

Fonts and Characters

A basic Latin Small ‘a’, a circumflex accented french ‘a’, and a Korean syllable (meaning house)

Font files are composed of a Unicode Index range indicating which characters to be included at compile time. English is composed of the basic latin characters, whereas French requires a few extra characters to be added for accented characters.

But what about other languages such as Cyrillic script, or Arabic? Chinese? Korean? They all use different characters. There’s no point in loading the entire set of Chinese Characters if the player doesn’t need them. SO there’s an extra line in the font file which references any extra font files for that specific language. That way the fonts are re-loaded when another language is added.

Handling Updates

The last thing to handle is updates. Games these days, thanks to how easy it is to create, publish and push an update, are fluid products. So how can we keep track of extra additions to the base XML file in the other language files.

A simple check at debug run time can solve that. Load the base XML file, and check that each file has a corresponding entry for each Key. That way if an entry is added in the English base XML but missing in others, it can be caught before publishing the app.

Beyond Words

What about other content? What about audio? or images? This would get a little more involved. But a simple way would be to set up the content paths where the language is part of the file path. For example:

SoundEffect HelloSound = Content.Load(“Sounds/”+language.Name+”/Hello”);

This would allow a very quick way to handle content loading for different languages and regions.

In Conclusion

All and all, we live in a global world, Where different regions and areas require a different set of localization files, texts, characters, and fonts. One thing we learned with The Chaotic Workshop, is it’s best to code from the ground up with this in mind, as it makes for not only a cleaner code base, but a significantly easier development of the product. This is something we’ve done with Metric Racer.

But until then, You can look for the addition of Localization and Translations in the upcoming 1.1 Update of The Chaotic Workshop. Which you can pick up now on the App Store and Google Play Store to be ready for this update! We’ll be shipping with English and French first, with more to come.

Download it on the App Store

Get it on Google Play

Do you have a different method in terms of handling Localization? Have a comment on our solution? Have a language you want added to one of our games? Let us know in the comments below or on Twitter and Facebook!

One response to “Extensible Game Localisation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s