1.将文本硬码到源代码中
为了节省时间，有些游戏开发者会将自己的游戏文本硬码到源代码中，例如：
/** Bad Example */
var language = getCurrentLanguage();
function attackEnemy(event) {
var message = document.getElementById(‘message’);
// Name of player and enemy decided by code logic
var player_name = ‘…’;
var enemy_name = ‘…’;
// To show a message on the screen
if (language === ‘english’) {
message.innerHTML = player_name + ‘ attacks ‘ + enemy_name + ‘.’;
} else if (language === ‘chinese’) {
message.innerHTML = player_name + ‘向’ + enemy_name + ‘作出攻擊。’;
}
// Continues with other logic
}
// Attack Enemy by clicking a button
var attackButton = document.getElementById(‘attack’);
attackButton.addEventListener(‘click’, attackEnemy);
在这个例子中，攻击信息“玩家攻击敌人”嵌入了源代码逻辑中。这种硬码文本是个捷径，但与许多捷径一样，你过后总会为此付出代价。
所有文本都嵌入代码中，你过后每次都得重新追踪你想修改或更新的
翻译内容。这会拖慢你的
翻译进度并且成本更昂贵。
如何解决？
一定要遵从符合国际惯例的最佳字符串包装技巧。此外，当你从源代码中提取文本时，要全面考虑并将其放入资源文件夹（由关键/值匹配数据组成）。针对每种游戏语言保存资源文件夹。这样更便于管理你的翻译文本。
上述例子可以采用如下解决方法：
/** Good Example */
var locale = getCurrentLocale();
// Some predefined translations
var translations = {
‘en’: {
‘patrick’: ‘Patrick’,
‘slime’: ‘Slime’,
‘attack_message’: ‘{{ player }} attacks {{ enemy }}.’
},
‘zh-HK’: {
‘patrick’: ‘帕特里克’,
‘slime’: ‘史萊姆’,
‘attack_message’: ‘{{ player }}向{{ enemy }}作出攻擊。’
}
};
function getTranslation(identifier, params) {
var string = translations[locale][identifier];
// handle parameters substitution
// …
return string;
}
function attackEnemy(event) {
var message = document.getElementById(‘message’);
var player_name = getTranslation(‘patrick’);
var enemy_name = getTranslation(‘slime’);
// To show a message on the screen
message.innerHTML = getTranslation(‘attack_message’, {
player: player_name,
enemy: enemy_name
});
// Continues with other logic
}
// Attack Enemy by clicking a button
var attackButton = document.getElementById(‘attack’);
attackButton.addEventListener(‘click’, attackEnemy);
2.未向翻译人员提供足够的情境信息
许多游戏开发者并没有认真对待游戏的本地化处理，只是给翻译人员发送一个含有大量文本的表格，却没有提供任何图片或其他情境化信息。
情境对于翻译质量来说很关键，如果翻译人员不清楚该在某一情境下该如何用词，就可能犯下严重的错误。
例如，将《现代战争2》从英文翻译成
日语时，翻译人员偶然将“Remember, no Russians”译成“他们是俄罗斯人，杀死他们”。如果了解更多情境，该
日语翻译人员就会清楚俄罗斯人并不是这个游戏环节的射击目标了。他们理解错了，所以翻译有误。日本游戏玩家也被误导，结果射击目标就错了。他们为此极为不快。
解决方法
你的团队中必须有人负责本地化事项，例如本地化项目经理。这个职位的人员的职责就是响应翻译人员的问题，并为之提供情境信息。（建议：如果你的团队很小，无法专门指派一个人监管本地化事项，那就让文案人员来负责这个项目）。
如果你为翻译人员提供了良好的情境信息，就更有可能获得良好的翻译内容。这些信息要包括：
*翻译术语表
*风格引导
*实用的视觉内容，如截图
*关于对话字幕的细节
*游戏主角的附录
3.聘请了错误的游戏翻译人员
游戏是一种独特的内容。不同游戏题材会带来不同的翻译挑战。
研究型文本
许多游戏中含有俚语，这包括游戏行话（例如《英雄联盟》中的gank一词）。有些游戏还含有专用术语——例如FIFA游戏中的体育术语。这就要求翻译人员进行大量的研究调查，我们将此称为研究型文本。
创意型文本
而像《QuizUp》或《Candy Crush》等其他类型的游戏则引进了大量新的游戏概念，这样翻译人员在一定程度上也成了内容创造者。我们将此称为创意型文本。
一般来说，常规的翻译人员并不总能与任务对口。如果选择了错误的翻译人员，你可能就会陷入一个漫长而昂贵并且不快的游戏本地化经历中。
解决方法
你要找的翻译人员最好就是当地人并且是活跃游戏玩家，理想情况下，最好是你这种游戏类型的玩家。
要先想想你游戏内容的细节，它属于研究型还是创意型的内容？然后再查看游戏翻译人员的履历。看看对方之前翻译过哪些游戏？对方玩什么类型的游戏？对方是否具有调查研究的经验？还是富有创造内容的经验？
4.没有在真正的设备上测试翻译版本
有些开发者并不会测试本地化版本的游戏——而这可能给游戏的UI和图像造成影响。
问题在于翻译出来的字符串通常未必符合游戏画面或UI元素。毕竟，翻译会改变句子的长度。例如，一个句子在翻译成
德语之后一般会变得更长（所占空间比
英语文本多50%），而翻译成中文则会变得更短（中文的字符更紧凑）。
除此之外，翻译完成后的翻译，有些字符串也会因为硬码而丢失。
解决方法
在真正的设备上测试翻译版本！有一个方法就是伪码本地化测试，即替换应用中的文本元素。一个更简单更有效的方法就是在设备上进行本地化测试，这还有利于你观察游戏本地化处理后的整体质量，而不仅仅是发现故障。
你还可以将文本空间设置成自动调整格式，这可以避免出现一些常见的UI错误。
5.没有注意文化上的差异
世界是多元化的，不同地区的玩家也有不同的游戏喜好。每个国家的发行和内容规范也不尽相同。每个手机游戏市场都有其独特的生态圈。
如果你没有做好准备，就可能被新市场的一些特点挡住去路（例如：中国的Google Play不支持IAP功能）。你的游戏内容可能不适合特定的市场，你可能要调整游戏内容。例如，原版PC游戏《帝国时代》登陆韩国时，它对日军攻陷朝鲜半岛的历史描述激怒了该国政治决策者。最终《帝国时代》不得不创造了一个可下载补丁更改了该描述，以便安抚韩国官方的情绪。
解决方法
你一定不想因为文化差异而惹上麻烦。你可以向当地的游戏行家，即翻译人员寻求帮助。让他们帮忙审核一下你的游戏内容有何不妥之处。
6.翻译内容管理不当
游戏开发者要处理大量不同类型的内容：手工内容，包装或应用商店描述，营销文件，游戏内界面文本，以及对话字幕等。
开发者有时候会在管理不同格式和文件上犯错。因此不同内容之间就可能产生一些错误翻译，这就可能降低效率和增加成本。
解决方法
确保对翻译内容进行集中管理。理想情况下要使用翻译管理系统，这有助于你组织和管理翻译内容，并对其进行调整。
7.最后才考虑本地化事项
许多游戏开发者将本地化视为游戏开发周期的最后环节。对于他们来说，这相当于一个额外步骤，所以会推到最后。
但实际上，这种想法并不明智。这种做法会让你错失海外市场机遇。你很可能在当地市场遭遇大量山寨产品，并因此无功而返。如果你决定之后再对游戏进行本地化处理，这会导致你不得不重新编写源代码并创建翻译材料。
解决方法
要一开始就考虑本地化操作。在开发早期阶段就要包装字符串，以便进行本地化处理。如果不这样操作，至少也要尽量调整编码方式以令其符合国际化标准。
