我们能够写出这篇文章，得益于我们客户提出的不计其数的问题——我的游戏哪里有问题？本地化做到这种程度还不够吗？应该如何解决呢？
在引入新游戏时，不少人会采取一些投机取巧的方法。如果你不打算循序渐进地增长，这甚至还算得上是一个高效的策略。
然而，期待已久的本地化版本一切就绪之后，大多数游戏开发商才开始思考如何才能吸引更多海外玩家。自己的游戏在更多国家发行后，或早或晚他们就会提出几个与本地化相关的点子。
首先我们要明确——本地化翻译的意思是将用户界面翻译成目标语言，并根据文化、宗教和政治因素进行调整，从而迎合某个国家或地区的市场需求。
要强调的是，本地化翻译是为了“解释”，而不是“改变”。
举个例子，某游戏中包含了一个关于英语民间故事角色的笑话，翻译成德语时，本地化翻译的处理方法应该是用在一个在德国广为人知的笑话来代替。但是，如果用户界面中没有足够的空间来容纳文字量较大的德文文本，有时就需额外花费更多精力。
另一个体现本地化涉及之广的例子是数字的翻译。比如说，在美式英语中，有些时候就要求用单词来表达数字，不能用阿拉伯数字。其他地区的本地化可能需要注意数词与名词的复数单数形式保持一致。例如在俄语中，单复数还存在一些特殊情况，而日语和汉语中则没有复数形式。但是，如果数字和文字是以硬编码的形式存在于游戏的静态图像中，仅仅翻译是不够的。
这两种情况还只是冰山一角——在本地化过程中，你还会遇到各种各样跟本地化无关的问题。有些人称之为伪本地化或者国际化错误——指的是一些本可以预测和避免，但需要开发人员花费很多精力才能解决的问题。
这就是为什么Alconost公司为开发人员罗列出了一份规则，让他们在项目启动时就按照这些建议走，以便在开发过程中可以轻松一些，为本地化早早打好基础。
1.提前选择本地化翻译语言
正如在我们之前专门讨论APP本地化工作流程的文章中提及，行动清单的第一项就是“评估你的潜力”。我们将在这里重复一遍。
你可能会反对说，在一款游戏真正上线之前，你不可能预见到所有潜在的市场语言。嗯，这在一定程度上是正确的：你得先用非本地化翻译版本做个测试，看看用户的反响，然后你再进行本地化翻译。但是，你并不用每次都按这个步骤来。
首先，你的游戏可能包含了太多文化和地域方面的禁忌，如果没有本地化，即使游戏叙事一流，你的游戏也会被拒之门外。
那么在开始之前，预测有希望的语言环境的最佳方法是什么？
按风格评估本地化。例如，如果你是一个独立开发者，正在考虑发行一款复古风格的roguelike游戏，你可以通过观察成功的同类游戏来确定哪些市场是比较有前景的——比如说《地痞街区》，已经被本地化成七种语言，外加英语。另外一种办法就是从地域角度去分析。比如说电子游戏是日本文化中不可分割的一部分，那么开发初期你可能就要把日本列为目标市场了。
研究游戏本地化需求最强烈的那门语言。说到这里，你可能想看看我们之前在 “游戏本地化的最佳语言”一文中的研究报告。
但是，我们的“0号规则”是尽可能地将英语作为游戏的源语言。我们建议在开发的第一天起，我们建议从第一天开始就考虑两种语言环境进行开发。
两个“默认”语言环境可能应该是英语和您的母语（如果不是英语）。这种方法有几个不可否认的好处：首先，以后可以使用英语作为源材料将你的游戏翻译成新的语言，这有助于确保一致性。第二，一开始就准备两种语言，这会让你提前认识到本地化前期工作中的所有陷阱。到时游戏扩展到20种语言，你就会熟练很多了。
2.为目标语言调整界面
在设计界面元素时，人们一般会为其它语言文本留出30%的空间（甚至更多，如果能够做到的话）。这对短字符串（菜单选项、UI等）尤其有用。
但是，我们还有更好的方法。如果你已经考虑到了规则1，并且有了一个初步的目标语言列表，那么我告诉你一个很有帮助的方法：为最棘手的语言设计界面。
就比如说，德语的文字量一般都会比英语多平均30%，俄语是10%。阿拉伯语也是这种情况。另一方面，繁体中文所占用的空间一般比英文少30%。
再说到字节，一个拉丁文字母等于一个字节，但西里尔文和阿拉伯文是两个，你在规划数据存储时也需要考虑到这一点。
3.不要把字符串直接嵌入到代码中
转换文本进行本地化，会导致这些硬编码字符串丢失。记住这条本地化规则：每一个可本地化的字符串都应该是可编辑的，不要触及任何代码。
实际上，为了本地化而做的这些工程都可以被归结为“国际化”，简称“i18n”——指让产品无需做大的改变就能够适应不同的语言和地区的需要。从程序角度来说，就是在不修改内部代码的情况下，能根据不同语言及地区显示相应的界面。
另一个重要的技巧是避免用较小的单个单词组成字段。为StackExchange做出贡献的谷歌程序员给我们提供了这样一个典型例子：
String currency = Locale::getCurrencyString() + money.toString(); // creates $123
这就体现出了一个问题——其他语言可能会把币种符号放在数字后面。
你可以使用需要本地化的格式化字符串。就比如说：
String format = Locale::get(“currency format”); // returns “${0}” in English String currency = String::Format(format, money.toString());
后一种方法允许本地化人员在实际格式化字符串中重新排列单词。
4.记住，时间、日期、计量单位和数字也需要本地化
作为上一条规则的延伸，我们想明确指出，数字方面的信息也需要从代码中提取出来进行本地化，因此也不能硬编码。
你还需要准备好重新设计界面上的数字。比如说游戏时间线上的计时，应该也是需要本土化的。原因是，西方国家大多是单向性时间模式，也就是说，他们习惯于用一条延伸的线来表示时间的流动，而亚洲国家则喜欢多样性时间模式，用圆圈来表示。
更不用说不同语言的日期格式、计量单位各不相同了。
所以我们的建议是，在本地化的时候要做好准备，考虑好每一个细节。
5.使用占位符和格式化控件，并使其易于访问
涉及到本地化和文本编辑时，使用占位符有时也是一个很好的选择。但如果不提供占位符的访问权限，那么它可能成为一把双刃剑。
这个问题牵涉到不同语种中的不同语序。所以我们的建议是：让你的占位符成为短语的一部分，这样就可以在上下文中插入。举个小例子来对比一下：
反面例子：“Mommy ate ” + %num + ” apples.”
正面例子：“Mommy ate %num apples.”
对占位符的简短描述也会有很大帮助。这样一来，当占位符被认为是与前面的文字有错误的关联或不相关的时候，就可以避免疑惑。
6.避免往图片里加文字
如果你的游戏中有图片，记得也要本地化，尤其是那种带有文字的。这就意味着你要从头设计图片。
重新设计图片和创意素材有时是个好主意，这样你就可以根据目标市场的需求对元素做出调整。然而，如果你只是单纯替换翻译文本，那就完全是浪费时间了。
7.使用正确的编码和字体
如果你需要某些跟你字符串类不同的特殊字符， 比如“spécîål ”这样的，编码问题是不可避免的。如果你的目标语言在本地化后出现了编码不匹配的情况，可能需要花费大量的时间和精力来删除这些可怕的字符， 比如���这样的。
字体方面也会出现同样的问题。特别是某些花哨的游戏字体只涵盖了某些语言的字形。结果就是，你可能得为不同的语言挑选不同的字体。在选择字体时请注意这一点，否则游戏中可能会出现一堆方框(□□□)而不是文字。
我们建议还是尽可能地使用Unicode而不是ASCII。UTF-8是最常用的，而且是空间利用率最高的编码。所以，请确保你的输入文件没有出现编码错误。
关于这一点，我们就先讲到这里了。关于编码的详尽教程可以在Alconost另一篇关于寻找“mojibakes”的文章中找到。
8.如果已经为本地化做好准备，你可以试试伪翻译
当你把上面所讲的技术方面的事都搞定了，你可以试运行看看。网络上有很多很棒的伪本地化工具，可以将你的界面模仿成外语界面，包括调整文本长度、检查编码和硬编码字符串。
这些工具基本上都会运行一个模仿目标语言的脚本，并生成一个测试版本，然后必须在常规流程中作为非本地化版本进行QA测试。
这种提前测试并不是什么灵丹妙药，但是的确很有帮助。而对于开发者来说也是一件很有趣的事。
9.早点制作术语表
术语表是游戏内专有词汇和概念的整合，在游戏中必须保持前后一致。这些词汇主要包括物品、人物名称、器物和属性状态。
保持术语翻译一致是非常重要的，试想一下，如果某个游戏内的东西在一个地方被翻译成 “药水”（potion），在另一个地方被翻译成 “灵药”（elixir）——你在无意中为玩家制造了额外的逻辑难题。
10.准备好提供上下文
与提供词汇表同样重要的是确保本地化团队拥有他们需要的所有上下文。从我们的经验来看，译员、本地化项目经理和游戏开发者之间的充分交流有助于语境的建立。
我们意识到要让开发团队做到24小时待机是很难的。然而在本地化阶段，我们的建议是指定一个代表作为您的联系人——错误或模糊不清的语境确实会对本地化的最终结果产生很大影响。
除此之外，本地化工作流平台主要是根据客户的喜好来选择的，这样是为了最大程度地保证沟通的便利和高效。
充分的准备工作最终会让你看到好的回报。
我们希望这些简单的规则、建议能对你的游戏开发有所帮助。祝你能够取得辉煌成功，让玩家们沉浸其中！