在游戏完成之前,许多项目都不会考虑本地化。然后将本地化作为一种hack进行,很明显,它是在以后添加的。一些具体的关注领域:
- 文字字串(很明显)
- 音频片段,例如音乐和/或叙述
- 在纹理上渲染的文本(例如,包装箱上的标签)
- 在预渲染电影中以帧渲染的文本
- 不同语言的字体/字符集
- 等等。
有什么好的方法可以在初始开发阶段为应对这些挑战做好准备,以便您可以更轻松地进行操作而又不会产生过多的费用?
在游戏完成之前,许多项目都不会考虑本地化。然后将本地化作为一种hack进行,很明显,它是在以后添加的。一些具体的关注领域:
有什么好的方法可以在初始开发阶段为应对这些挑战做好准备,以便您可以更轻松地进行操作而又不会产生过多的费用?
Answers:
我不是专家,但是这里有一些基本的东西:
确保您的字符串可以处理的不仅仅是ASCII
您将需要一些不适合ASCII的spécîål字符,并且您的字符串类最好不要放在上面。UTF-8是一种通用的编码,因为它节省空间。无论您做什么,都要尽早进行测试并解决问题。
使用实际的字符串类,而不是在char *
任何地方使用,都是一个非常好的主意,否则您将陷入痛苦的世界。
不要忘记您的字体。确保您使用的所有字体都具有所需的字符。
从代码中拉出字符串
这是最重要的。确保所有文本字符串都存储在代码之外的某个数据文件中,可以交换出来。为此设置管道可能会很麻烦,但是会为您节省大量时间。您将需要一些简单的API,以便任何时候在代码中需要字符串时,它都非常简单:
String text = Locale::getString("some unique identifier");
不要在代码中连接或构建字符串
重要的是,不要对小字如何构成一段文本做出任何假设。甚至是无害的东西:
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());
这样,本地化程序可以重新排列格式字符串中的单词。
尽量减少出现在艺术作品中的文字,尤其是视频中的文字
分叉艺术品是一件繁琐的事。对于某些UI元素,您可能至少需要做一点,但这很麻烦。分叉FMV是一个巨大的痛苦,因为现在您必须呈现并存储FMV的重复副本。
全面测试不同语言
在大多数代码库中,说printf("Hi there");
或loadTexture("someTexture");
忘了那些代码都需要通过本地化API 太容易了。有人会忘记,您最终会得到在您的主要语言中正确但在其他语言中却错误的东西。找到这些的唯一方法是让测试人员使用非主要语言进行测试。
使丢失的本地化文字显而易见
通常,您会在翻译周期的后期翻译文本,因此在很多时候,某些语言都不会提供数据。很好,因为它可以让您遍历内容而无需不断重新翻译。缺点是它很容易让您错过东西而忘记翻译一些东西。
您可以做的一件便宜的事就是使丢失的文本非常明显地显示为“ !!!需要ID #blah blah !!!的翻译!” 在游戏中消失的时候。
围绕最坏情况的语言设计UI
不同的语言倾向于使用更长或更短的单词。用英语看起来很漂亮的UI可能会有超出其边界的文本,被裁剪或用较长的语言错误地换行。您必须进行UI更改以适应最坏的情况(或分叉UI,但这可能不是您想要的。)
令人讨厌的是,英语通常是通常本地化的语言中最短的一种,因此您的设计师可能会无意中为最佳情况进行设计。在设计时,请让他们使用占位符超长的文本。假设任何给定的文本比英语长大约30%。Google Translate可以很好地为占位符获取一段文本。
预算翻译时间
通常在团队疲倦且不在乎时,才翻译文本。尽管如此,当发生这种情况时,您仍然会遇到很多错误。言语会越过边界,翻译人员会犯错误等。更糟糕的是,如果必须将文本发送给海外人员并等待他们的更改,则迭代文本的时间可能会很长。分配时间进行这项工作。
本地化游戏正确的是该死的努力。
您可以浏览互联网,阅读博客文章或StackOverflow答案;您可以学习传统的i18n框架,例如gettext;阅读有关国际化和游戏本地化的维基百科页面; 请查阅出色的Microsoft语言指南 -但是对游戏进行本地化实际上比这难得多。实际上,使用游戏可能比使用其他任何应用程序或网络界面都要困难。这是因为游戏具有更高的动态性,活力和活力(至少,好的游戏)。
更重要的是,可能需要采取以下步骤:
建立界限。
您想做出一个非常重要的决定,即您要尽早支持哪些语言。您选择的范围越广,关于语言行为方式的假设就越多。这些假设常常深深地印在我们的大脑中,以至于我们甚至无法想象如果没有人指出它们,它们可能是不正确的。这将我们带到下一点:
查找您要支持的每种语言的专家。
专家是指具有足够的分析能力和语言知识的人,他可以为您指出英语使用者不具备自己的语言所依据的假设。然后,您需要提出一个策略来解决这些假设。
例如:在西方语言中,我们通过在单词之间插入多余的空格来证明段落中文本的合理性。在阿拉伯语中的文本通过插入字符的kashida合理里面的话。它可能看起来像这样。
另一个示例:在俄语中,大多数单词有2个复数形式。因此,例如,您将“ 1个硬币” /“ 3个硬币” /“ 5个硬币”翻译为“ 1монета”,“ 3монеты”,但翻译为“ 5монет”。确定正确的复数形式的实际过程如下所示:
function LocalRU::GetPlural(n, form0, form1, form2) {
return (n%10) == 0 || (n%100) >= 5 && (n%100) <= 20? form0 :
(n%10) == 1? form1 :
(n%10) <= 4? form2 : form0;
}
创建一个上下文感知翻译模块。
您可能知道翻译总是取决于上下文。而且您知道游戏中的上下文一直在变化。如果我们将这两个语句放在一起会怎样?通常,您的翻译应该与您的游戏一样动态。
例如,根据说话者的性别(男性/女性/跨性别者),一个简单的短语“我同意”将俄语翻译为“Ясогласен” /“Ясогласна” /“Ясогласно”之一。如果这是您的对话行之一,则语言模块将必须在运行时根据角色的性别选择一种可能的翻译(假设您为玩家提供了这样的选择)。
取决于说话者和听者之间关系形式化的程度,将相同的短语翻译成日语后,将再次具有不同的翻译。因此,如果您在游戏中引入声誉,友谊或不同等级的优势(例如,您的角色可能从新秀演变为将军),那么在进行翻译时就必须考虑到这一点。(实际上,这不是日语专用的。即使是英语,在军队中,您也永远不会对等级低于您的人说“先生,是的,先生!”。)
有办法跳入上下文。
您的翻译人员应具有查看特定短语出现的上下文的能力。有时上下文很明显,有时您必须亲自看/听/体验它才能正确翻译某些内容。
甚至简单的句子如“这本书都是蓝色的”。不能明确地翻译没有我看的书,看到它是蓝色的特定阴影。
避免文字游戏,双关语和其他特定于语言的元素。
或者也许不回避,但是至少要记住一个策略,当无法翻译文字游戏时该怎么做。因为可能不会。
至少您不应该创建依赖于某些单词具有双重含义或与某些其他单词相似的任务/难题/游戏对象。因为一旦翻译,您将打破自己的游戏。(例如,在旧游戏Fallout2中,主要任务是找到名为GECK的对象;游戏中还存在许多“壁虎”怪兽(变异的蜥蜴);很自然地,他们围绕名称的相似性创建了多个引用和任务,做出出色的翻译非常困难)。
开心点!
本地化游戏很难。但是每个人都很难。如果您努力并正确地进行操作,那么您所在的目标国家/地区的游戏评论家将不会忽略它。具有良好翻译能力的游戏将脱颖而出,并获得更高的利润。毕竟,文本与图形一样对于在游戏中营造氛围同样重要(这就是为什么基于文本的旧RPG如此沉浸式的原因)。
到目前为止,Wil Shipley拥有我所读过的关于本地化的最佳指南。不幸的是,它是针对iPhone的,但是仍然可以获取通常有用的信息。此外,他还介绍了资产和UI的本地化-我可以想象的游戏本地化中的两个较大挑战。
我在这里看到了一些很棒的提示!
我将尝试列出最常见的错误,这些错误的范围可能从使您的本地化变得更加困难到彻底破坏您的游戏:
本地化应尽早集成到开发中,并且在设计游戏时应始终牢记在心。
有了正确的计划和仔细的市场研究,您将为自己节省很多麻烦和开支。
我恰好是一家游戏本地化公司的创始人,几个月前,我们在博客中介绍了为本地化准备游戏的过程。
这是总结该帖子的信息图:https : //magic.piktochart.com/output/18317297-9-steps-to-cheaper-game-development-with-localization
全文的链接(包括这些技巧的更多信息)位于其底部。