作者：Nicolas Lamanna

本土化是开发团队迟早要面对的老话题。无论你是独立开发者还是大型工作室，若你想要获取更多用户，游戏就需要进行文本转化和本土化（游戏邦注：当然也有些游戏采用应用视听模式，并没有多少文本内容，但本文主要谈论基于文本形式的游戏作品）。

过去10年里，我致力于本土化工具开发，同许多译者和编辑交流过。每当谈到这点，就会有很多选择映入我的脑海中：Excel表格、Word文档、.txt文件及若干定制应用，甚至是邮件客户端。

软件开发领域处于持续发展中，因此若这些工具是唯一选择，那么它们定能够进行一定程度的简化或管理。大家都清楚如何在那些熟悉的应用中编辑文本，这不是什么大问题，是吧？

事实证明此问题不仅没有得到进一步完善，反而还进一步恶化。本土化公司推出越来越多的定制应用，例如WordPress Plugins、Facebook翻译工具（也可能存在与Google+相关的本土化工具）、资源文件和定制XML模式文件等。诸多选择让我们无所适从。

存在疑问

首先，谈到本土化，主要话题就是文本文件。但参与此过程的人都知道，这其实涉及许多元素。基于Unicode的文本是基本内容，其之上还包括嵌入文本的图像、视频、音频文件和当地法律要求，也许还有针对本土市场的内容。在某文化看来很棒的元素也许在另一文化中隐含着死亡意味。

是的，你也许会说，不要将内容复杂化，只需标记excel文件或文件，在文件名称上设置数字编号，然后就大功告成。虽然这适合文本情况，但若内容涉及图像或音频文件，你就无法进行剪切。每种格式都有自己的特点及测试方式，QA团队鲜少精通5国语言，因此无法判断内容合适与否。

所以把握这些数字资产后，你得将这些内容发给译者或本土化机构（游戏邦注：无论他们是大公司，还是外包商）。然后你将内容取回，进行相应更新和编辑。别忘记还有校对过程。你还得将内容再发给译者，但此时截止日期就得稍微延后。

目前我们已有若干本土化解决方案。但将这些内容引申至游戏行业非常重要。

Localization(from blogs.adobe.com)

下面我们就来详述当前本土化存在的几个问题：

* 不一致性：多数工具都无法很好相互传达。它们存在于各种你无法访问的平台。转换需要基于多个层面，翻译失误会带来截然不同的意思。

* 效率低：本土化过程的时间和资源成本很高。很多情况下，文本需在各部门和团队中同时操作。

* 后续问题：文本和本土化需要随时进行修正，或进行文字校对，或存在排版失误，或者甚至是修改文化内容。不是所有工具都方便译者进行操作，都能让他们轻松使用。

* 被忽视的错误：在本土化过程中，所有这些调整元素都会导致产品质量降低。通常会出现某元素受到低估，然后鲜少受到关注的情况，而糟糕翻译所带来的影响通常不会马上就被察觉。

* 成本颇高：复杂问题需要复杂解决方案，好像确实如此。此过程听起来似乎也颇费资金，无论你是雇佣第三方公司，还是有自己的内部成熟团队。若你的公司规模很小，你多半会自己操刀，但你能投入的东西非常有限，因为你还需要烦恼其他事情。

我们显然需要进行彻底检讨。但切入点很多，我们要从何处着手？

建议

要解决此复杂问题，我建议采用KISS方式。我们需要直击问题核心。从中我们也许无法找到完美解决方案，至少能够充分把握基本概念。

所以现在就先来谈论共同特性。我们可以将各部分内容简称为本土化元素或本土化单元。各个单元都以特定形式呈现，或是文本、图像，或是视频等其他必要元素。为方便讨论，我将其称作Symloc（游戏邦注：这是由符号“Symbol”和本土化“localization”混合而成的词语）。

下面是若干基本要求：

* 本土化单元：Symloc是能够进行本土化的单个基本元素。这意味着它能够进行转化或修改，适应既定语言。它也许直接包含数据或者只是引用信息。

* 元数据：任何Symloc都有涉及资产的重要信息，能够给译者和内容编辑者提供一定帮助，能够为任何程序所应用。这类例子包括预览信息、注释、图像尺寸或文本及视频文件的长度。

* 分组：Symloc能够进行组合，从而将不同语言植入同个资产或将相关资产合并起来。

* 支持所有语言：这是指完全支持Unicode格式，因为我们没有任何尺寸限制，所有内容都应囊括在内。

* 适应其他标准：很多研究内容都锁定本土化和国际化标准，这通常是针对特定内容的标准，例如货币、日期和时间、电话号码或其他存在文化差异的元素。

* 以XML为基础：XML能够适应任何格式。那么正式模式就能够用于验证适当本土化文件。

* 真正标准：将此设置成开放选择，不要让任何公司操控此标准，从而避免产生利益冲突。

显然事物都有两面性，其中也存在若干弊端。

潜在问题

首先，小型文本涉及少量开支。别担心，Symloc可以进行组合。所以若你手中持有众多小型文本，你可以将它们归类。

其次，各开发者都有自己的最终格式，这可能各不相同。这是此解决方案的缺点所在，注意格式是中间媒介，它是本土化数字资产的通用关口。就这点而言，公司可以创建自己的脚本和工具，以自己觉得合适的方式存储信息。

第三，和任何新标准格式一样，若没有人采用此格式，它无法受到推广。在这种情况下，我们就需要参照范例模式，若标准格式表现突出，能够创造真正价值，其他人就会采用此格式，否则，它就会逐渐淡出大众视野。

总结

谁将从游戏标准本土化格式中受益？答案很简单，所有人都会从中受益。

游戏开发公司也许就会开始考虑制作自己的转换工具，而不是其他翻译机制。若本土化公司遵循特定标准，他们将能够轻松传递自己的翻译内容，而且最终结果会如预期所料。

小型团队可以采用他人的工具，甚至是开源工具，将游戏文本翻译成多种语言，高效扩大自己的覆盖范围。

译者也可放宽心，因为用于翻译的工具越来越标准化，他们无需费心掌握其他模糊机制。同样，整个操作过程也会变得更富效率，他们能够在更短时间内传递更多内容。

现在，我们需要权威人士支持此理念，将此运用至实践中。

游戏邦注：原文发表于2011年7月10日，所涉事件及数据以当时为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Localization: We need a standard format!

Localization, the old familiar concept that many development teams had to see face to face, sooner or later.

Whether you are a small indie developer or a big studio, if you want to reach a bigger audience, your game needs  to be translated and localized. Of course, there are games that forego text for a more audiovisual experience (Flower for instance) and that’s perfectly fine but here we’ll focus on the ones that do have text, even when it’s only a small amount.

The last ten years I’ve been involved in localization tools development and talking to different translators and editors. When I think of that, a lot of options immediately come to mind: Excel sheets, Word Documents, .txt files, several custom applications and even mail clients.

After a while and since software development is undergoing a constant evolution, I found myself thinking, okay, if those are the only options, surely they can be reduced or managed to some extent. Everybody knows how to edit documents in those familiar applications, it really is not that big of a problem, right?

Turns out, the problem not only didn’t get any better but it has worsened. Let’s add to that list, more custom applications from localization companies, WordPress Plugins, Facebook translations, I’m not sure about Google+ but they probably have something too, resx files, a giant list of custom XML schemas, you name it.

This madness has to stop.

Problematic

First of all, when one talks about localization, the common subject is text files. But anyone who has been involved in that process knows that it actually implies a whole umbrella of elements. Text with Unicode support is a given (even though there is a plethora of issues there), then you have images with text on them, videos, audio files, local legal requirements and maybe content tailored for a local market, one culture may think one symbol is cool while others may think it resembles death incarnate.

Sure, you could say, don’t complicate things and just stamp an excel file or a document there, put an incremental number scheme on the file name and you are set. Whilst that could work for text, when you have images or audio involved, it just doesn’t cut it. Every format has its quirks and ways of testing it and it’s not like your QA team speaks 5 major languages and can corroborate whether the content is correct or not.

So you have all these digital assets, you send it to translators and localizators, whether it’s a big company or contractors. You get them back, you approve them for updating, editing takes place. Voila, somebody forgot about a word here or proof-reading there. You have to send it back to the translators, but now the deadline had to be pushed a little forth. Rinse, repeat.

Of course, there are already several localization initiatives (for instance, i18n, l10n, etc). However, it′s important to have something shoehorned to our industry.

But let’s be a bit more precise and summarize the problematic:

* Inconsistency: Most tools don’t talk well to each other. They could reside on different platforms which you don’t have access to. Conversion must be made at several levels, lost in translation gets a whole new meaning here.

* Inefficient: Great overhead in time and resources. Files need to be synchronized across multiple departments and teams, in many cases.

* Follow-up nightmare: Text and localization need to be corrected all the time, be it proof-reading, typos, even cultural corrections. Not many tools are friendly enough for translators to be comfortable with them.

* Error prone: All these moving parts leads to a loss of quality in terms of localization. It’s usually a part that gets underestimated and ends up with a lesser priority. The impact of a bad translation is not immediately obvious.

* Expensive: A complex problem that needs a complex solution, sounds about right. That sounds expensive too, either you hire a third-party company or you have a full-grown localization team in-house. And if you are really small well, you probably do it yourself but then the amount of content you can pour is limited since you have to worry about other things too.

This definitely calls up for a major review. But given that many angles to tackle, where shall we begin?

The proposal

In order to solve this complex problem, I would definitely go with a KISS approach. We need to go to the core of the issue. We may not end up having a perfect solution but at least a solid foundation to build upon.

So let’s picture a common denominator. We can reduce every part to a localizeable element, a unit of localization if you will. Every unit can then have a type, which could be Text, Image, Video or anything we consider necessary. For the sake of argument, let’s call it, a Symloc (A portmanteau of Symbol and localization).

Let′s take that up a notch and formulate a basic list of requirements:

* Unit of localization: A Symloc is a single atomic element that can be localized. Meaning it can be translated or modified and corresponds to any given language. It may contain the data directly or just a reference (in case of a video that weights a gigabyte).

* Metadata: Any Symloc can have important information related to the asset. It can be used as an aid for translators and content editors or it can be used by another program. Examples of these are preview information, notes, the size of an image or text, the length of an audio file, etc.

* Grouping: Symlocs can be grouped together to have different languages into one asset or to have related assets merged together.

* Support for every language out there: This one is a no-brainer, Unicode support from the ground up, since we don’t have any size restrictions, no one is left behind.

* Play nice with other standards: There is a lot of research poured into localization and internationalization standards, possibly use those for specific things like currency, date and time, telephone numbers and any other term that may be culturally different.

* XML as a foundation: XML is flexible enough to be used for any format. Official schemas can then be used to validate a proper localized document.

* A true standard: created as an open initiative, no company should control this standard to avoid conflicting interests.

Naturally, not everything that shines is going to be gold so we surely have a couple of drawbacks that should be anticipated.

Pitfalls

First of all, there is a little overhead for small texts. Not to worry, Symlocs can be grouped. So if you have a swarm of small texts, you could have them all under the same category (which is simply another metadata element).

Second, every developer has a final format and that probably differs from others. This is where this solution is not perfect, note that the format is intermediate (in that regard, it’s similar to COLLADA) where it acts as a common gateway for localizeable digital assets. In this regard, companies can build their own scripts and tools to store the information in the way they see fit, generally for performance gains.

Third, as any new idea for a standard format, there is no way it’s going to pick up steam if nobody uses it. In this case, we simply need a lead by example approach, if the standard is good and provides some real benefits, others will follow. Otherwise, it will be submerged into oblivion.

Let’s conclude

Who would benefit because of a standardized localization format for games? The answer is simple, everyone.

Game development companies could then worry about having their own conversion tools instead of having yet another translation system. Localization companies could deliver their translated assets easily knowing that if they stick to a standard, the final result is going to work as expected.

Smaller teams can use other’s people tools, even open source ones, to have their games translated to as many languages and cultures as possible, effectively augmenting their reach. They can be be sure that volunteers can step in and send back game assets in a format that can be easily inserted back into the game.

Translators can rest assured that the tools used for translation are becoming standardized and not worry about learning yet another obscure system. Again, effectively becoming more efficient by delivering more assets in less time.

Now, we just need somebody big out there to believe in this idea and make an example out of it.

Meanwhile, I’m going back to design my own tool for this format.（Source：gamedesigntales）