Gamasutra: The Art & Business of Making Gamesspacer
Lessons Learned from Localizing Canabalt
Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 21, 2014
arrowPress Releases
April 21, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:

Lessons Learned from Localizing Canabalt
by Adam Saltsman on 01/17/12 01:28:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


At the end of 2011 we finally released an update to our popular game Canabalt that had support for something like 15 languages. If only for the sake of our own unreliable memories I wanted to record some of the things we learned during that process. This is not, by any stretch of imagination, a mandate to localize your own software, or, if you decide to, to do it this way. It is simply a public recording of our experience and our plans for the future :)  Much of what is recorded here will have to do with iOS specifically, but likely applies to other platforms as well.

Fan Translations (i.e. Crowdsourced Translations)

We certainly were not the first game to rely on fans to translate the game content into other languages. World of Goo and Fieldrunners, among others, were famously ported to other languages by dedicated fans.  If this was a traditional postmortem, though, we would definitely file "fan translations" under the What Went Right column. We had a ton of up-front interest from fans from all over the world, who in general displayed a remarkable degree of dedication, patience and professionalism.  I believe there were a couple of keys to making this work though:

  1. Canabalt has very little, in the grand scheme of things, to translate. It is maybe 1 page of double-spaced full sentences, if that.
  2. Canabalt is a popular game with some very passionate fans.

The combination of these two things I think led very naturally to some amazing people being willing to dedicate a few hours to "the cause" as it were. The ratio of effort to results was quite good for them I think!

File Management, Nuts & Bolts

The way we did most of the translation work, physically speaking, for Canabalt, I would probably file under the What Went Wrong column, even though it basically worked. We put together a central file in english, clearly annotated, of all the sentences we needed translated. Then we sent a copy of this file to anyone that was interested in working on a particular language. This was really easy to do at the start of the process. It was... less easy to deal with at the end of the process.

Copy-pasting and touching up the translated files at the end of the process was sufficiently daunting that we ended up delaying the inclusion of the translated files for months! It was that boring. In the end we had to kind of pull ourselves together and just knuckle down and do the grunt work, which was about 3 or 4 work days of copying, pasting, and touching up files. More later on why that took so long, but in the meantime, we figured out what we think might be a better approach. We are testing it out on some new languages now, so the jury is still out... but it seems pretty promising.

In the future I'd like to try prepping a Google doc of the annotated English language file, and then duplicating that to any requested language. These other language files will be publicly viewable, possibly publicly exposed using a Google Form. Fans who are up for doing a translation can email us, and we will then add them as a private editor for that Google doc. Once the editors (3 or fewer, ideally) are satisfied with the translation, we can simply copy-paste the entirety of the file directly into the XCode language project file and test it out in-game.

EFIGS and Other Acronyms

Initially it seemed quite important to focus on EFIGS to maximize our effort to "new market exposure" or whatever, which actually makes a lot of sense if you're doing traditional localization, rather than crowd-sourcing. Traditional localization is pay-by-the-word, so there's a kind of obvious, direct cost there. Crowd-sourced localization has muddier, less obvious costs though, which generally boiled down to about 2-4 hours of grunt work per language. This made including some non-standard languages viable and interesting, and allowed us to cater to small but vocal fan-bases in oft-ignored countries like Finland or the Czech Republic.  For a small company with a small game I actually think this makes a lot of sense. Those players mean a lot to us!

It also meant that we were able to survey the impact the different languages had technologically. Languages like Italian and German are infamously lengthy, and thus problematic, especially if you make tight, minimalist games with compressed interfaces!  We found that 1.5-2 lines of English text expanded to nearly 3 lines in Italian or German. However, many emerging markets like China have logographic languages that can easily fit within the English layouts for very little effort (you will, of course, need a font that supports a few extra thousand characters).  For a small developer, those things are worth keeping in mind I think.

Various Pitfalls & Other Details

Finally I wanted to run down some other things we ran into along the way, that we will definitely be keeping in mind for the future:

  1. Text with manual line breaks in it is a huge pain in the butt, and scales badly. Good word wrapping and variable height text display areas are not that hard to do, programmatically, and will vastly simplify the process of localization later in development.
  2. We added special fields in the language file we sent out to translators that we parsed into our Credits screen, so they could add themselves to the game credits. This worked really well, since then each translator is credited but only in their own language, completely automatically. I think we can do it even better in the future though; there was some confusion about whether they should credit themselves as "Translator for Language X" in English or in their native language. Note: all of our translators worked for free - being credited in their native language was the least we could do!
  3. Localizing achievements in iTunes Connect is a horror I wish upon no one, and I have no plans to ever do localized achievements until they provide some better procedural approach. As it stands, as far as I know, you have to translate all the achievement text in your own game, but then upload individual graphics and achievement text to iTunes Connect's web interface manually. This is patently insane. There needs to be a way to upload a translated achievements package that can be generated locally from the game's existing language files. That or we need an unpaid intern.
  4. Canabalt has some sentences that use variables to customize their display. For example, "I ran 400m before falling to my death on my iPhone." uses two different variables to indicate how far the player ran and what device they are using.  Not all languages display the distance measurement before the device name.  The sentence could just as easily be "On my iPhone, I ran 400m before falling to my death."  So when you are using multiple variables within a single translated sentence, make sure you encode the ordering of those variables, especially in C-style languages. Otherwise, players may be disappointed to find that they "ran iPhone meters before falling to their death on their 400."
  5. Text encoding can be a bit of a headache. Usually your IDE will do a good job of opening the file, but if the translator saved it wrong (UTF-8 instead of UTF-16 or some such thing) then it may be possible that you can't get at the proper characters at all, and have to request changes from the translator. I am hopeful that relying more on Google Docs in the future might alleviate some of these issues.
  6. We added a language override selection to Canabalt's options. This was a huge win, for a few reasons: it wasn't that nightmarish to implement, players liked it because they could still play in English even if their phone was Russian, and it made it very easy to test the different languages as we implemented them. We found that some languages (like Bulgarian I think?) could be set up in XCode, but would not automatically trigger using the phone's built-in language settings.


Someone on twitter reminded me that I never mentioned anything about whether this had any impact on sales. As far as I can tell, at least in the short term, the introduction of new language options has had no measurable effect on sales.  I am confident that in the long run it was a good idea though. It broadens our fanbase, if only by a little, and it felt good to deliver fan-generated content to other international fans. Canabalt was more than two years old by the time we released this update as well. Internationalization may matter more at launch, when international app stores may be more likely to feature the game. The time put in to implement was substantial though, and non-English-speaking iPhone users are still a minority of the market.

Related Jobs

Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States

Associate Animator (temporary) - Treyarch
Activision Publishing
Activision Publishing — Santa Monica, California, United States

Executive Producer-Skylanders
Activision Publishing
Activision Publishing — Santa Monica, California, United States

Director, Central User Testing
Goblinworks — Redmond, Washington, United States

MMO Producer


Fernando Fernandes
profile image
Thanks for sharing, Adam. Personally I believe some things aren't worth localizing. Your text kind of reinforce that (I'm not talking about your app, particularly; my point is generic). At least considering App Store, where the majority isn't "non-English" users -- as you well stated. And I would say localization is overrated. I mean: it is something I would work on only if there is time left (and there is no other things to improve / no new relevant features to implement). It's not something I would plan and include in the roadmap from the beginning. Well, I'd love to see an update in this article when there is more data on Localization VS Sales. ;-)

Javier Arevalo
profile image
A really long time ago I wrote a wrapper to add position to printf() format strings - anyone tackling that issue in a C/C++ app may find it useful:

Pallav Nawani
profile image
We just load all of our text from a utf-8 xml file.

Jamie Mann
profile image
"As far as I can tell, at least in the short term, the introduction of new language options has had no measurable effect on sales [...] The time put in to implement was substantial though, and non-English-speaking iPhone users are still a minority of the market."

I'd argue that the localisation has had minimal impact on sales because non-English-speakers are *already* able to play Canabalt; there's very little text in the game - and the text that is there is not critical to the gameplay and reasonably easy to understand without translation - most people should be able to guess what "xxxxxxxx 400m xxxxxxx iPhone" means at the end of a game. Similar applies to other internationally popular games such as Angry Birds, Fruit Ninja and Cut the Rope: the gameplay is either self-explanatory or explained via visually-orientated explanations (e.g. cartoon drawings).

In any case, providing localised translations does generate goodwill and publicity and should be relatively low cost if a suitable framework is put in place beforehand. Though "low cost" is always relative - for a small dev team, even 2-3 days can be a significant amount of time!

Wojtek Kawczynski
profile image
Thanks for this Adam. We're thinking of localizing our game to Chinese as that seems to be the second largest market after the US. How did you guys choose a font that you felt comfortable was appropriate to your game? Where did you even start looking?

James Coote
profile image
Edit: nevermind, worked it out

Aaron Isaksen
profile image
Hi Adam...just now dealing with bulk uploading of achievements. I wrote a little script using Fake which makes it very easy to automate Safari. I just dump my achievement database out in to a format thats easy to parse with javascript, and then loop while automating the clicking of each field in itunesconnect. Yay for scripting! I'll eventually get it loading json and then i can use the same achievement database in my app as well as on itunesconnect.