Lessons Learned: Localizing Puppet Punch in 10 languages - Part 1

Me and my team at Mech Mocha are all set to release our first iOS title named “Puppet Punch” this week and are pretty excited about it. It took us a long time in making this game, iterating through each and every aspect; trashing some modules and starting all over again.

But, the most painful point we faced (and all my team would agree) was Localising the game in 10 Languages.

It was so painful and tedious and boring which obviously led to mistakes and led to more time spent in QA. We could have made it more interesting, quicker and less of manual work if we knew some tricks that we learned by the time we completed it! So, here are some tips for the developers who are planning to localise their game. These are just some points among a lot of points I am planning to mention in parts.

1. Scripts, Scripts, Scripts!

As Bill Gates says, “The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency”.

PROBLEM:

The whole process of Localisation includes a lot of copying text from here to there. First, one has to take all the text in the game and make an spreadsheet out of it to be shared to the translators. Then, the translators translate each text in different columns, after which there’s a lot of copy-pasting into different files depending upon the language. This is not only tedious, but also error-prone. And these errors are not easy to find. For example, it’s very difficult to differentiate Korean, Chinese and Japanese if you don’t know either one of them and while copy-pasting the text from the spreadsheet, we mix-matched these texts a lot of time and didn’t even get to know. We later had to spend a lot of time on QA again to correct these mistakes.

SOLUTION:

Scripts! – To automate stuff

Script – 1:

Making a spreadsheet out of all the text labels in your game

Script – 2:

Exporting the Spreadsheet into different files (per column). These files would serve as your localised text according to each language. You might have to use some kind of version control to take care of changes being done from either sides and keep both sides in sync always!

Might save time (depends on your scripting skills) and most importantly, avoid a lot of errors. Now, to make these scripts, you need a little bit of structuring since Day-1 and that’s my next point.

2.Structuring your code:

PROBLEM:

I know, text labels don’t even come to mind when you sit and think about how to structure your code. You might think about how to structure some variables that are important in the balancing of your game like Speeds, Levels, Difficulty; so that they might be later changed from server; but never ever did a dev-friend tell me to take these text-labels seriously!

Creating a spreadsheet from all the text in your game will be a nightmare, as your they would be all over your code.

SOLUTION:

It’s easier to create spreadsheet of the whole text in your game, if you would have all the text in your game at one place (one separate file, preferably). For this, use MACROS since Day1. Every text should be paired with a MACRO and the whole list should be in a separate file(s). If you have too many screens (like we did), maintain multiple files according to the screen. This would make it easier for the translator to understand the context (whether it is in the score screen or the main screen or inside the game).

 3.Localisation System:

Most of the devs (including us) use this; but still needs a mentions as this article is kind of a Localisation:101.

PROBLEM:

You do all that is mentioned above. You finally get 10 files for 10 languages. What do you do with those? How do you change the English text in the text labels into respective languages?

SOLUTION:

Lots of stuff available on this. We used something similar to this. It takes a “Key-Text” (in our case, English) as the input and simply returns the text in the corresponding selected language.

For this, the syntax is :

//This is in your file which has all the Text

#define@"CONNECTING TO APPSTORE..."

//This is where your font label is initialized.

labelWait = [CCLabelBMFontlabelWithString:AMLocalizedString(TEXT_SAMPLE,TEXT_SAMPLE) fntFile:AMLocalizedString(@"HeadingFont.fnt",@"HeadingFont.fnt")];

The second parameter (the second “TEXT_SAMPLE”) is the text that would be displayed if no corresponding localised text (value) is found for this “key-text”

If you have already initialized all your label fonts, then don’t worry. There are plugins which convert

labelWait = [CCLabelBMFontlabelWithString:TEXT_SAMPLE fntFile:@"HeadingFont.fnt"];

to

labelWait = [CCLabelFontlabelWithString:AMLocalizedString(TEXT_SAMPLE,TEXT_SAMPLE)fntFile:AMLocalizedString(@"HeadingFont.fnt",@"HeadingFont.fnt")];

Here’s one of the XCode plugins called Quick Localization. [A little tweaking required according to your specifications]

That's it for Part 1, In Part 2 of this series I will be discussing about handling complex labels, leaving enough buffer in images that hold text, choosing the right font and setting up systems for translators for maximum efficiency. Stay Tuned!