作者：Adam Saltsman

2011年底，我们终于推出《屋顶狂奔》的更新内容，游戏支持15种语言。出于方便记忆，我决定记录自己在其中所学到的些许经验。这不是本土化游戏的操作指令，或者你也可以选择按此操作。这不过是要记录我们的经验和未来规划。这里记录的信息很多主要针对iOS平台，但其实也适用其他平台。

Canabalt from tig.wikia.com

粉丝翻译（或称大众翻译）

《屋顶狂奔》显然不是首款依靠粉丝将内容翻译成其他语言的游戏。例如，《粘粘世界》和《炮塔防守》就已被游戏的忠实粉丝巧妙地转化成多种语言。如果本文是一篇事后分析报告，我们无疑会将“粉丝翻译”列于“正确做法”一栏。我们的作品备受全球广大用户的喜爱，他们大多具有相当高的投入性、耐心和专业精神。但我觉得要做到这点，有几大关键：

* 整体来看，《屋顶狂奔》的翻译内容很少。可能只有1页两倍行距的完整语句。

* 《屋顶狂奔》是款拥有狂热粉丝的热门游戏。

所有这些因素使得有些玩家愿意腾出几小时投身此“事业”。我觉得他们从中获得的投入/回报比例非常显著。

文件管理的具体内容

坦白讲，我会将《屋顶狂奔》翻译操作方式归入“失误做法”一列，虽然其具有可行性。我们将所有需要翻译的句子整理成英语版核心文件，同时附有详细注释。然后我们将文件发给有兴趣的译者。在项目初始进行此步骤很简单，但到项目尾声就不那么容易。

尾声阶段的翻译文件复制/粘帖及润色工作令人望而生畏，我们最终延迟数月才将翻译文件植入游戏中！整个过程非常枯燥。最后我们只能团结一致，开始认真处理这些繁重的工作，腾出3-4个工作日复制、粘帖及润色文件内容。现在我们开始基于新语言测试游戏内容，所以最终结论还有待分晓，但情况非常乐观。

未来我想要试着创建附带注释的英语版谷歌文档，然后将其复制到其他语言版本。这些其他语言版本的文件具有可视性，能够基于Google Form呈现。意愿翻译内容的粉丝可以通过发邮件联系我们，我们会将其添加成谷歌文档的私人编辑。只要若干编辑对翻译内容感到满意，我们就会将整个文件直接复制/粘帖到XCode语言文件，然后在游戏中进行测试。

EFIGS及其他文件格式

初期阶段，基于EFIGS格式提高“新市场曝光度”非常重要，若你采用的是传统本土化模式，而非依靠群众收集资源，那么这所起的作用就非常显著。传统本土化模式是按翻译字数计费，所以其呈现明显的直接成本。而基于群众的本土化模式，其成本则就不那么明显，通常每种语言是2-4小时的繁重工作。这使得融入若干非标准语言变得具有可行性，同时颇具趣味，让我们得以覆盖那些常被忽略的国家（游戏邦注：例如芬兰和捷克共和国这些存在小规模的活跃用户的国家）。我觉得这特别适合发行小规模作品的小型开发商。这些国家的用户对我们来说意义重大。

这同时也意味着，我们能够从技术角度研究不同语言所产生的影响。意大利语和德语之类的语言以啰嗦著称，因此是个麻烦的问题，特别是当你制作的是采用压缩界面的紧凑简约游戏。我们发现1.5-2行的英语文字会延伸成3行的意大利语或德语。但中国之类的许多新兴市场都采用语标语言，能够轻松融入英语的布局结构。我觉得这是小型开发者应该牢记的内容。

各种误区&其他具体细节

最后我想要谈谈我们在此过程中遇到的问题，未来我们会将此牢记于心：

1. 包含手动换行字符的文本非常棘手，扩展性很差。杰出自动换行设计和各种高度的文本显示区域从编程角度看具有可行性，能够简化开发后期的本土化过程。

2. 我在发送给译者（游戏邦注：我们将译者输入自己的“鸣谢”页面）的语言文件中添加特殊字段，这样他们就能够将自己添加到游戏“鸣谢”名单中。此方式效果显著，自此各译者的名字都会自动出现在对应语言版本的页面中。但我觉得我们未来在此还有发挥空间；这些存在些许疑惑：他们是否应该以英语或其本土语言标注自己是“X语言的译者”。注意：我们所有译者都是在无偿工作——我们至少要能够以其本土语言标注出他们的姓名！

3. 基于iTunes Connect本土化游戏的成就内容是非常可怕的经历，我并不打算将成就内容本土化，想要等到出现更优质的编程方式。据我所知，你需要翻译游戏中的所有成就文件，然后手动将单个图像和成就文本上传至iTunes Connect的网页界面。这显然有些疯狂。我们需要把握上传翻译成就包裹（这能够从游戏既有语言版本的文件中生成）的渠道。这样的话我们就需要一名免费实习生。

4. 《屋顶狂奔》的有些句子通过变量自定义其呈现方式。例如，“I ran 400m before falling to my death on my iPhone”，句子通过两种变量表明玩家玩家跑多远，采用什么设备。不是所有语言都在设备名称前呈现距离测量标准。此句子可以简单转化成“On my iPhone，I ran 400m before falling to my death”。所以当你在单个翻译句子中采用多种变量时，需确保给那些变量的顺序设定代码，尤其是C风格语言。否则，玩家只会失望地发现自己“ran iPhone meters before falling to their death on their 400”。

5. 文本编码有些令人头疼。通常IDE能够很好地打开文件，但若译者保存方式出现错误（其采用UTF-8，而非UTF-16），可能你就无法获得正确字符，需要译者做出改变。我希望，Google Docs未来的更广泛运用能够有效减少这些问题。

6. 我们在《屋顶狂奔》选项中添加语言重写选择。这是一大进步，原因如下：执行过程不那么可怕；玩家很喜欢这点，因为他们能够继续通过英语体验内容，即便他们的手机采用的是俄语，这方便我们测试各种语言的落实情况。我们发现有些语言能够以XCode设置，但无法自动采用手机的内置语言设置。

结果

有人在twitter上提醒我说，我从未谈及这是否会给销量带来影响。在我看来，至少在短期，引入新语言选择不会给销量带来明显影响。但我相信未来其作用将会非常突出。这能够扩大我们的用户基础，向其他国际用户呈现粉丝创造的内容感觉非常不错。《屋顶狂奔》自今已诞生2年多。将游戏国际化在刚发行阶段意义最显著，因为国际应用商店更有可能推荐作品。虽然我们在此所投入的时间不少，但非英语Phone用户依然只是小众市场。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Lessons Learned from Localizing Canabalt

by Adam Saltsman

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:

* Canabalt has very little, in the grand scheme of things, to translate. It is maybe 1 page of double-spaced full sentences, if that.

* 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.

Results

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.（Source：gamasutra）