游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

Alconost CEO谈手游本地化需要注意的10条规则

发布时间:2020-07-08 10:29:48 Tags:,

Alconost CEO谈手游本地化需要注意的10条规则

原作者:Alexander Murauski 译者:Willow Wu

本文作者是Alconost的CEO。Alconost是一家为应用、游戏、以及其它软件提供本地化服务的公司,业务涉及70多种语言。Alconost还为Google Play和App Store制作广告、教育视频,还有图片、解说词和预告片等等。

我们能够写出这篇文章,得益于我们客户提出的不计其数的问题——我的游戏哪里有问题?本地化做到这种程度还不够吗?应该如何解决呢?

在刚开始做游戏时,很多人都会采取最省钱最省时间的方法。如果你不打算循序渐进地增长,这甚至还算得上是一个高效的策略。

然而,期待已久的本地化版本一切就绪之后,大多数游戏开发商才开始思考如何才能吸引更多海外玩家。自己的游戏在更多国家发行后,或早或晚他们就会提出几个与本地化相关的点子。

首先我们要明确——本地化的意思是将用户界面翻译成目标语言,并根据文化、宗教和政治因素进行调整,从而迎合某个国家或地区的市场需求。

要强调的是,本地化是为了“解释”,而不是“改变”。

举个例子,某游戏中包含了一个关于英语民间故事角色的笑话,翻译成德语时,本地化的处理方法应该是用在一个在德国广为人知的笑话来代替。但是,如果用户界面中没有足够的空间来容纳文字量较大的德文文本,有时就需额外花费更多精力。

另一个体现本地化涉及之广的例子是数字的翻译。比如说,在美式英语中,有些时候就要求用单词来表达数字,不能用阿拉伯数字。其他地区的本地化可能需要注意数词与名词的复数单数形式保持一致。例如在俄语中,单复数还存在一些特殊情况,而日语和汉语中则没有复数形式。但是,如果数字和文字是以硬编码的形式存在于游戏的静态图像中,仅仅翻译是不够的。

golf clash reward offer(from pocketgamer.biz)

golf clash reward offer(from pocketgamer.biz)

这两种情况还只是冰山一角——在本地化过程中,你还会遇到各种各样跟本地化无关的问题。有些人称之为伪本地化或者国际化错误——指的是一些本可以预测和避免,但需要开发人员花费很多精力才能解决的问题。

这就是为什么Alconost公司为开发人员罗列出了一份规则,让他们在项目启动时就按照这些建议走,以便在开发过程中可以轻松一些,为本地化早早打好基础。

1.提前选择本地化语言

我们之前写过一篇关于APP本地化工作流程的文章,行动清单的第一项就是“评估你的潜能”,我们现在也要做这件事。

你可能会反对说,在一款游戏真正上线之前,你不可能预见到所有潜在的市场。嗯,这在一定程度上是正确的:你得先用非本地化版本做个测试,看看用户的反响,然后你再进行本地化。但是,你并不用每次都按这个步骤来。

首先,你的游戏可能包含了太多文化和地域方面的禁忌,如果没有本地化,即使游戏叙事一流,你的游戏也会被拒之门外。

所以在游戏制作开始之前,预测潜在市场的最好办法是什么?

·分析竞品的本地化。一般来说,如果竞争对手的游戏在某一市场上找到了肥沃的土壤,那么你也有很大的机会那里获得成功。

·从游戏类型角度出发,评估一下本地化的效果。例如,如果你是一个独立开发者,正在考虑发行一款复古风格的roguelike游戏,你可以通过观察成功的同类游戏来确定哪些市场是比较有前景的——比如说《地痞街区》,已经被本地化成七种语言,外加英语。另外一种办法就是从地域角度去分析。比如说电子游戏是日本文化中不可分割的一部分,那么开发初期你可能就要把日本列为目标市场了。

·研究本地化需求最强烈的那门语言。说到这里,你可能想看看我们之前在 “Best Languages for Game Localization”(https://medium.com/@Alconost/best-languages-for-game-translation-836c467db417)一文中的研究报告。

我们的“0号规则”是尽可能地将英语作为游戏的源语言。我们建议在开发的第一天起,就要考虑两个本地化方向。这两个“默认”方向就是英语和你的母语(如果不是英语的话)。这种方法有几个无可争辩的好处:第一,以后可以将英文作为源语言翻译,这有助于确保游戏的一致性。第二,一开始就准备两种语言,这会让你提前认识到本地化前期工作中的所有陷阱。到时游戏扩展到20种语言,你就会熟练很多了。

2.为目标语言调整界面

在设计界面元素时,人们一般会为其它语言文本留出30%的空间(甚至更多,如果能够做到的话)。这对短字符串尤其有用(菜单选项、UI等)。

但是,我们还有更好的方法。如果你已经考虑到了规则1,并且有了一个初步的目标语言列表,那么我告诉你一个很有帮助的方法:为最棘手的语言设计界面。

就比如说,德语的文字量一般都会比英语多平均30%,俄语是10%。阿拉伯语也是这种情况。另一方面,繁体中文所占用的空间一般比英文少30%。

再说到字节,一个拉丁文字母等于一个字节,但西里尔文和阿拉伯文是两个,你在规划数据存储时也需要考虑到这一点。

3.不要把字符串直接嵌入到代码中

转换文本进行本地化,会导致这些硬编码字符串丢失。记住这条本地化规则:每一个可本地化的字符串都应该是可编辑的,不要触及任何代码。

实际上,为了本地化而做的这些工程都可以被归结为“国际化”,简称“i18n”——指让产品无需做大的改变就能够适应不同的语言和地区的需要。从程序角度来说,就是在不修改内部代码的情况下,能根据不同语言及地区显示相应的界面。

另一个重要的技巧是避免用简单的单词组成字段。某位谷歌程序员给我们提供了这样一个典型例子:

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是最常用的,而且是空间利用率最高的编码。所以,请确保你的输入文件没有出现编码错误。

关于这一点,我们就先讲到这里了。详细的编码教程,你可以看看“Where Do Mojibakes Come From? A Smart Guide to Encodings”这篇文章(https://medium.com/swlh/where-do-mojibakes-come-from-a-smart-guide-to-encodings-fa96de357123)。

8.如果已经为本地化做好准备,你可以试试伪翻译

当你把上面所讲的技术方面的事都搞定了,你可以试运行看看。网络上有很多很棒的伪本地化工具,可以将你的界面模仿成外语界面,包括调整文本长度、检查编码和硬编码字符串。

这些工具基本上都会运行一个模仿目标语言的脚本,并生成一个测试版本,然后必须在常规流程中作为非本地化版本进行QA测试。

这种提前测试并不是什么灵丹妙药,但是的确很有帮助。而对于开发者来说也是一件很有趣的事。

9.早点制作术语表

术语表是游戏内专有词汇和概念的整合,在游戏中必须保持前后一致。这些词汇主要包括物品、人物名称、器物和属性状态。

保持术语翻译一致是非常重要的,试想一下,如果某个游戏内的东西在一个地方被翻译成 “药水”(potion),在另一个地方被翻译成 “灵药”(elixir)——你在无意中为玩家制造了额外的逻辑难题。

10.准备好提供上下文

确保本地化团队有充足的上下文信息可以参考,这一点的重要性不亚于制作术语表。从我们的经验来看,译员、本地化项目经理和游戏开发者之间的充分交流有助于语境的建立。

我们意识到要让开发团队做到24小时待机是很难的。然而在本地化阶段,我们的建议是指定一个代表作为联系人——错误或模糊不清的语境确实会对本地化的最终结果产生很大影响。

除此之外,本地化工作流平台主要是根据客户的喜好来选择的,这样是为了最大程度地保证沟通的便利和高效。

充分的准备工作最终会让你看到好的结果。

我们希望这些简单的规则、建议能对你的游戏开发有所帮助。祝你能够取得辉煌成功,让玩家们沉浸其中!

本文由游戏邦编译,转载请注明来源,或咨询微信zhengjintiao

Editors note: This article has been contributed by Alconost, a global provider of localization services for apps, games and other software into 70+ languages. Alconost also makes advertising and educational videos and images, teasers, explainers, and trailers for Google Play and the App Store.

We’ve written this article as a tribute to numerous questions from our clients:
What’s wrong with my game? Why isn’t localization enough? How can we fix it?

Cutting corners when bootstrapping a new game is a widely-used strategy. And it might even be an efficient one, as long as you aren’t planning to grow incrementally.

However, shortly after the long-awaited local release is in the bag, most game developers start thinking about how to attract more international gamers. And sooner or later, after taking a crack at promoting their game in more countries, they come up with several ideas for localization.

Just so we’re clear, localizing a game means adapting it to the selected locale (country or region) by translating the user interface into the target language and making adjustments for cultural, religious, and political factors.

At this point, we’d like to stress that localization entails interpreting the interface, but not changing its elements
For instance, if a game that needs to be translated into German contains jokes about an English folk character, localization handles this by replacing the jokes with other ones that are popular in Germany. However, if there isn’t enough space in the user interface to accommodate the larger size of the German text, this issue can sometimes require more effort than just localization.

Another example illustrating the scope of localization would be the translation of numbers. For example, some locales such as en-US (American English) require numbers to be written in words rather than numerals in certain cases. Other localization locales might require matching numbers with the plural\singular forms of nouns. For example, in Russian, there are more options than just “one” and “more than one,” while in Japanese and Chinese there are no plural forms at all. However, if numbers and texts are hardcoded in static images within the game, just translating the text isn’t going to cut it.

These two cases are just the tip of the iceberg — there are countless non-localization issues that can rear their ugly heads during the localization phase. Some people call them pseudo-localization or internationalization errors — big words referring to something that could have been predicted and avoided but can require serious work on the part of the developers to fix.

This is why we at Alconost have decided to draw up a list of rules for developers to follow from the very beginning of the design process in order to make localization as painless as possible. Just follow these essential guidelines to get your game ready for localization with no extra effort.

1.Pre-select localization languages in advance

In our previous article dedicated to app localization workflow, we started our action list with #1: “Evaluate your potential.” And yes, we’re going to repeat ourselves here.

You might object that it’s impossible to foresee all potential locales for a game before it actually goes live. Well, this is somewhat true: first, you test the audience with a non-localized version, and then you scale up with localization. However, it doesn’t always work this way.

To start with, your game might contain so many cultural and regional taboos that it would be a no-go for the selected locale without localization, even with the most enticing narrative.

So what is the best way to predict promising locales before you start?

·Analyze the competitors’ localizations. Usually, if a rival game has found fertile ground in a certain market, you also have a great chance for a success story.
·Evaluate localizations by genre. For example, if you’re an indie developer contemplating the release of a retro-style roguelike, you might have a good idea of your potential locales by looking at a success story in the genre — say, Streets of Rogue, which has been localized into seven languages plus English. Another approach is to look at the question from a regional perspective. If video games are an integral part of Japanese culture, Japan might be a target market to consider from the very early days of development.
·Study the most wanted languages for game localization. At this point, you might want to take a look at our previous research published in the article “Best Languages for Game Localization.

However, your localization plans notwithstanding, our “Rule #0” is to make English the source language if at all possible. And we recommend developing with two locales in mind from day one.

The two “default” locales should probably be English and your native language (if that isn’t English). This approach has several undeniable benefits: first, you’ll be able to translate your game later on into new languages using English as the source material, which helps ensure consistency. Second, having two languages from day one will automatically guide you through all the pitfalls of preparing for localization. Then you’ll see little difference when you have 20 languages.

2. Adjust the interface for potential languages

When building interface elements, it’s generally a good idea to plan for at least 30% extra space (or even more, if possible) for other languages. This is especially valid for short strings (menu items, UI, etc.).

However, we have an even better idea. If you’ve taken Rule #1 into account and have a preliminary long list of locales, there’s another helpful option: design your interface for the worst-case language.

For example, the German version is going to be an average of 30% longer than the English one, and the Russian version will be approximately 10% longer. The same is usually true for the Arabic version. On the other hand, traditional Chinese characters generally take up 30% less space than English texts.

When it comes to bytes, one Latin letter equals one byte, but Cyrillic and Arabic characters are twice as big, which also needs to be accounted for when planning data storage.

3. Don’t build text strings into the code

Transforming the text for localization will result in these hard-coded strings being lost. Remember this localization rule: every localizable string should be editable without touching a line of code.

Actually, all the engineering tasks that need to be performed in order to begin the localization process are attributed to the internationalization process or i18n for short.

Another important tip is to avoid building pieces of text out of smaller single words. A good example of this kind of blunder has been spotted by a Google programmer contributing to StackExchange:

String currency = Locale::getCurrencyString() + money.toString(); // creates $123

The above example showcases this problem — other languages might place the currency mark after the number.

Instead, format strings can be used that need to be localized themselves. For example:

String format = Locale::get(“currency format”); // returns “${0}” in English String currency = String::Format(format, money.toString());

The latter approach allows localizers to rearrange words within the actual format string.

4. Remember that time, dates, units of measurement, and numbers also need to be localized

As a followup to the last rule, we just want to explicitly state that numerical information also needs to be extractable from the code for localization and therefore must not be hard-coded.

You also need to be ready to redesign your numbers in the interface. For example, a clock ticking down the game’s timeline should probably be localized. The underlying motivation for this is that Western countries are mostly monochronic, which means they’re used to having time represented as a stretching timeline, whereas Asian countries prefer to have time represented as a circle.

Not to mention that the formats for dates and units of measurement differ across almost all languages.

So our recommendation is to prepare yourself and consider every detail when it comes to localization.

5. Use placeholders and formatters and make them accessible

Using placeholders sometimes seems like a good alternative to just hard-coding text when it comes to localization and text editing. However, it can be a double-edged sword if you don’t provide access to placeholders.

This issue is connected to word and phrase order that might be absolutely different in another language. So our recommendation here is: make your placeholders part of the phrase so they can be inserted in context. Here’s a little example of what’s “good” and what’s “bad”:

No: “Mommy ate ” + %num + ” apples.”
Yes: “Mommy ate %num apples.”

A short description of placeholders can also be very helpful. This makes it possible to avoid confusion when a placeholder is considered to be wrongly related or unrelated to the previous piece of text.

6. Avoid text in images

If you use images in your game, be ready to localize them too, especially if they’re enriched with text. This means redesigning the whole image from scratch.

Redesigning images and creative assets is sometimes a good idea so you can meet standards for colors and characters in your target locale. However, it’s a waste of time and effort if you’re just doing it to insert translated text.

7. Try to use the right encoding and fonts

Encoding issues are inevitable if you need certain “spécîål” characters that don’t fit into your string class. If your target language has an encoding mismatch after localization, it could take a great deal of time and effort to remove those awful ��� characters.

The same problem applies to fonts. In particular, certain fancy fonts for games don’t contain glyphs for all languages. As a result, it might be necessary to choose different fonts for different languages. We recommend keeping this in mind when choosing a font; otherwise, you risk ending up with a bunch of boxes (□□□) instead of subtitled text.

Our recommendation is to use Unicode over ASCII whenever possible. UTF-8 is the most common and space-efficient encoding. So make sure your input files are encoded correctly.

We won’t get into more detail about this right now. An exhaustive tutorial on encoding can be found in the previous article on hunting for “mojibakes.”

8. Play with pseudo-translation if you’re ready for localization

Finally, once you’ve got all the technical aspects outlined above ready, try doing a test run. There are a number of great pseudo-localization tools available across the Web that can imitate your interface as if it were in a foreign language, including adapting text length and checking encoding and hard-coded strings.

These tools basically run a script that mimics the target language and produces a build, which then must be QA tested within the regular process as a non-localized build.

This pre-test is definitely not a panacea, but it helps a lot. And it can also be a lot of fun for developers to do a mockup with a camouflaged interface.

9. Start building your glossary early

A glossary is a collection of in-game terms and concepts that must be preserved consistently throughout the entire game. It mostly contains items, character names, artifacts, and statuses.

Maintaining consistency with the glossary across the entire game is essential. Just imagine if a certain in-game item is translated as “potion” in one place and “elixir” in another — you’ve unintentionally created an extra logic puzzle for your players.

10. Be ready to provide context

No less important than providing a glossary is ensuring that the localization team has all the context they need. In our experience, context can be established by enabling communication between translators, localization project managers, and game developers.

We realize that it’s extremely difficult for the entire development team to be available 24/7. However, during the localization phase, our best advice is to designate a representative to be your contact person – incorrect or insufficient context can really hurt the ultimate results of the localization process.

Besides, the platform for localization workflow is primarily selected based on the client’s preferences, so this communication can be conducted as conveniently and efficiently as possible.

And if the work is done well, it pays off in the end.

We hope you find this simple list of recommendations helpful for designing your games. We’re wishing you great success stories and captivated players!

(source: gameanalytics )


下一篇: