作者：Mike Souto

引言

将你所有的东西打包成一个文件，听起来好像就可以进行本土化处理了。你已经用一个出色的excel/gdoc/loc工具将其整合在一起，是时间将其发送出去了。但这里要提个醒：你确定真的都准备好了吗？你会得到最好的翻译结果吗？它会准确无误，不含漏洞吗？以下就是面向开发者本土化处理的一些建议，本博文包括两个首要环节，游戏介绍以及背景/描述的重要性。

恰当地介绍你的游戏

翻译人员拥有你的文件，知道标题，你最好还要提供一些关于游戏和平台的信息。这就够了吗？如果你只打算收到简单的翻译结果，这就可以了。但如果你想收到出色的翻译内容，最好要让翻译人员更好地理解源文本内容。

我们有时候会收到大量很棒的信息。但如果只提供极为基本的信息，就只能得到极为普通的结果。所以尽量为翻译人员提供更多信息这一点就十分重要了。这种做法值得称道，你也确实不要过份担心安全性的问题。

如果有些内容是十分机密的，那就要确保与翻译人员签署保密协议。这样等于是告诉翻译人员，他们会知道即将发布游戏的细节，如果泄密的话就会追究他们的责任，你今后也不会再与他们合作。多数翻译公司会有一支可依赖的团队（签署保密协议）来翻译文本。

translation(from commlabindia.com)

那么关于游戏信息，你能否提供了以下内容？

游戏名称：这是个很简单的内容对吧？你希望将这一名称本土化吗？或许只是标签线？还是想在本土化标题后加括号用英文注明？

平台：这现在已经是个很简单的问题了。、

语言：确保你已经明确了你所需要的语言。如果你只是想要中文版，许多本土化专家就会问你偏好哪种风格。但如果你还没有事先调查自己的需要，那么这就会拖延你的翻译进程。

概述：告诉游戏玩家有关游戏本身、游戏题材，游戏主色，游戏目标等内容。

*目标受众：游戏所瞄准的对象，以及它应该包含哪种语言？它是否属于应该使用简单易理解文字的儿童游戏？

*年龄分级：这款游戏是拥有一些温各声明，面向更年长的用户市场吗？如果翻译人员知道其瞄准的分级情况，那么就会完成相应的本土化文本。每个国家的声明原则都会有所不同，所以明确的指示是关键。

视频以及代码：如果你有代码，或者游戏已经发布英文版，那就再好不过了。翻译人员可以下载试玩一下。对于主机游戏来说这当然并非易事。但最好是为之提供一些视频或网站上可点击的链接，让他们先体验一番。

截图/UI视频：如果你可以提供一个包括UI连续镜头的短视频，那么也会很有帮助。翻译人员就会理解他们需要应对多大的空间。这也有助于了解游戏情境。

之前的翻译：这是一个续作吗？如果是，那么就有必要让翻译人员看看前作的翻译内容。他们就能够确认是否可以翻译某些字段（以及他们应该翻译的内容）。如果你的前作中有一个称为“Demon Bob”的角色，但在续作中却更名为“Devil Bob”那就非常不可取了。如果地图图像无法更改，那么与城镇相关的翻译就应该保持为原来的语言。例如，翻译在本土化文本中就不应该涉及“Shadow cliffs”这一地名，否则玩家寻找这座城时就会不知所措。

哪些内容应该进行本土化处理：如果这是首次翻译，那么你就应该列出哪些内容要翻译，哪些保持原样。你可能并不是最理想的拍板人选，所以要与本土化合作伙伴进行沟通。

你可能还有不想本土化特定元素的其他原因。例如，有些文本可能含有图像元素特征，需要花费许多精力和时间进行本土化（游戏邦注：例如，你的某个地图含有城镇名称）所以要向他们指出这一点。例如，当你的地图中含有城镇名筄时，假如地图图像不可更改，那么文本中涉及城镇的翻译就要保持原来的语言，以便玩家寻找某一城镇时不知所措。

特殊字符和变量的说明：

你的文本是否含有需要区别对待的特殊字符？最好让翻译人员知道这些要求。例如：

1.你的字符串中是否含有“\n”？在 “\n”之前是否要留一个空格？这里有没有什么需要遵守的规则？

2.是否存在你无法支持的特定字符？最好在翻译之前进行确认。例如，是否只能使用特定类型的引号？

3.也许你需要确保“…”这一符号是3个单独的句号而非自然生成的省略号。

4.方括号里的内容是否都不需要翻译？

这些说明越多越明确。如果翻译人员完全清楚其中的约束条件和规则，那么之后发生的错误就会大大减少！

描述和情境

通常情况下，人们提交给翻译人员的文件是一系列没有描述或情境的字符串。这样他们就无法进行恰当的翻译。难道他们应该靠自己的猜测来完成翻译吗？有时候，如果字符串ID拥有明确的结构和注明用处，翻译人员就会知道其中情境。例如“STR_KillEnemyBarkOrder001”或“STR_Xbox360ButtonPressOK”。但多数情况下这种可能性很小。这正是字符串的描述/信息的关键所在。你可能会认为这很麻烦，不值得考虑。但事实并非如此。你都愿意花钱本土化自己的游戏，难道不该得到正确的翻译吗？提供情境和进一步信息，有助于削减之后翻译人员向你提问的次数，这不是更省时省力吗？

以下就是一些参考例子：

1.FIRE。这是什么意思？是指开枪的Fire还是指燃烧的Fire？

2.WATCH。这是指认真观察还是手腕上戴的手表？

3.KICK。是指痛打敌人，还是在多人游戏中把某位玩家踢出局？

这里还有像HAT和CHAIR的例子。

你应该说明哪种帽子或椅子。许多语言针对帽子或椅子类型会有不同的词语。这是一个大礼帽，猎鹿帽还是常礼帽？至于椅子，这是一个餐椅，手扶椅还是办公椅呢？

清晰和情境是关键，如果你的游戏让玩家去找一顶帽子，而翻译中的帽子与他们所找到的帽子截然不同，那就很糟糕了。

针对平台的文本

你应该如何向翻译人员讲述文本针对的是哪个平台？这个问题给翻译人员制造了大量问题。如果目标平台就在字符串摘要栏中，这种情况就很理想。

千万不要创造“这是面向所有平台”这种描述。你也不要指望某个字符串的翻译与英文字符串一模一样。例如，意大利语中的“按钮”在PS和XBox平台上就存在区别。所以你可能会有一个“摁压按钮”的字符，并认为这种翻译适用于所有平台。事实并非如此。因此你要确保每个平台都有特定的字符串，并清晰指出它们针对的是哪个平台。没错，这会有相当数量的副本，但这总比最后才被告知翻译有所区别要好，因为这意味着你要重新为新字符编码，以呈现这种区别。如果早期就制定计划，就可能避免这种情况。

你还应该确保自己区分和复制了涉及平台上的点触、触摸和摁压这些字符。在移动平台上，点触和触摸是很常用的词语，但却甚少出现在主机平台上。如果翻译不准确，那么团队就得重新创造字符，这本是在开发循环初期就可以避免的麻烦。

确认这些平台特定字符尤其重要。在提交过程中发现的任何问题都可能威胁到发布日期和相应的PR工作，以及你可能规划好的营销活动。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Developers – Make your text translator-friendly – A few tips (Part 1)

by Mike Souto

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

This blog was originally posted on Localize Direct’s blog on Feb the 12th, 2014.

Developers – Make your text translator-friendly – A few tips (Part 1)

Intro

Putting together a file with all your strings may sound like enough to then push into Loc. You’ve put it all together and it’s in a nice excel/gdoc/loc tool etc. Right then, time to send out. Although a word of warning, is it all really ready to go? Will you get the best possible translations back? And will it all be accurate and bug free? Here are a few tips to help you along the way. This blog contains the first two sections, Game Introduction and Importance of context/description on strings.

Introducing your game properly

The translator has your file, been told the title and hopefully provided with some info on the game and platforms. Is that enough? This can suffice if you plan to receive a basic translation result. If you want to receive superior quality the translator needs to have a greater understanding of the source text.

We sometimes receive a huge amount of information and that’s great. It’s all too regular however that the request comes in, very basic info is provided and that is all. It really makes a lot of sense to provide the translator with as much information as possible. It is greatly appreciated and you really don’t need to be too worried about security. If it’s something super secret then by all means get the translators to sign an NDA. That said however, the translator is fully aware that should details of the game be released and they are to blame then they will not be asked to work with you again. Most translation companies will have a trusted team (under NDA) that work on the text.

So with regards to the game information, are you able to supply the following?

Game name. Nice easy one eh? Although do you want this to be localised? Or perhaps just the tag line? Or perhaps you want the English in brackets after the localised title?

Platforms: Now that’s an easy one.

Languages: Ensure that you have been specific enough with which languages you require. If you just asked for Chinese then most LSPs will ask which flavour you desire. However if you haven’t researched which you need in advance, then this will delay kicking off the translations (obviously).

Overview: Tell the translator about the game, the game genre, who the main protagonist is, what the aim is, etc.

Demographic: Who is the game aimed at and what kind of language should it contain? Is this a kids game so the language used should be simplistic to understand?

Age rating: Is this a game for the older market with some mild swearing? If the translator is aware of the target rating then the text can be localised to suit. Swearing guidelines vary in each country so a clear indication is key.

Video and/or Code:  If you have code or the game has been released in English already then great. The translator can usually download and have a play. This is of course not so easy for console titles. As a backup then it’s very useful to either provide some video or links to clips that can be found online.

Screenshots/Video of UI: If you can provide a short video that contains footage of the UI then that really helps too. The translator can then understand how much space they have to play with. It will also help with context of strings (see below).

Previous translations: Is this a sequel? If it is then the translator really needs to see the previous translations. They are then able to check on whether certain terms should be translated or not (and also what they were translated to). It’s quite an error if you have a character called “Demon Bob” in the first game who has now changed to “Devil Bob” in the sequel.

What should and shouldn’t be localised: If this is a first-time translation then you should have a list of what you do and don’t want localised. You may not however be the best person to make this call so speak with your localisation partner.

You may however have other reasons for not wanting to localise certain elements. For example, certain text may feature in graphical elements which would take an age (and great effort) to localise. Point these out and let the guys know. An example is if you feature a map containing names of towns. If the map graphic cannot be changed then references to the towns featured in the translation should be kept in the source language. A translation shouldn’t refer to the “Shadow cliffs” in a localised form for example, when the player looks for this town they will have no idea where or what to look for.

Guidelines on special characters and variables:

Does your text feature special characters that must be treated in a certain way? Best to get this information in front of the translator. For example:

1. Do you feature “\n” in the strings? Do you need to have a space before the “\n”? Are there rules to follow?

2. Are there certain characters that you cannot support. Best to catch them before they go in.

For example, only a certain type of quotation mark can be used?

3. Perhaps you need to ensure that an elilipsis “…” is three separate full stops as opposed to the auto character that can be generated.

4. Is anything in square brackets to be left untranslated?

The more the merrier on these guidelines. If the translator is fully aware of the limitations and rules, then the number of errors found later can be greatly reduced!

Description and Context

All too often translators are provided with a file containing a collection of strings with no description or context. As such they find that they are none the wiser when it comes to appropriate translation. Should they speculate and use guesswork to base their translations on? Hmm, I don’t think they should. Sometimes context can be worked out if the String ID has a clear structure and points to where it will be used. “STR_KillEnemyBarkOrder001” or “STR_Xbox360ButtonPressOK”. All too often however, it’s not possible. This is where description/information on strings is key. You may think that this is a pain and not really worth it. It really is worth it. If you are willing to spend money to localise your game then shouldn’t it contain the correct translations? Providing the context and further information will also cut down on the number of translator questions you receive later on, isn’t that worth it?

A few examples for you:

1. FIRE. What does FIRE mean? Fire (as in to shoot) or Fire (as in the logs/coal burning hot thing)?

2. WATCH. To observe something or the time keeper on your wrist?

3. KICK. To kick an enemy protagonist or to eject a player from your mplayer game?

Then there are things like HAT and CHAIR (to provide two examples).

You should be clear in what kind of hat or chair it is. Many languages will have specific words for the type of hat or chair. It it a hat or cap? Is it a top hat, deerstalker or bowler? With regards to chair, is it a dining chair, armchair, office chair etc?

Clarity and context is key, it’s not the greatest advert for your game if the player is told to find a hat and the translation for this hat is very different to what they are looking for.

Platform specific text

How will the translator be able to tell which platform the text is for? This is a very popular type of problem that generates a large number of translator questions. Again if in the String ID then that certainly helps. If the target platform is included in a string description column then that is ideal.

Do try to get away from creating “this is for all platforms” strings. You also cannot rely on the translation for a string being the same for an identical string in English. For example, Button in Italian is different on PS and XBox. So you may have “Press a button” and assume that the translation for this will be fine for any platform. It will not. You should therefore ensure that there are specific strings for each platform, and clearly label which platform they are for. Yes, there will be a fair amount of duplication, however this is preferable to being told at the last minute that there are differences in the translation. You now have to code a new string into the mix to allow for the difference. This is something that can be avoided if planned for early in the process.

You also need to ensure that you have separated and duplicated strings with references to Tap, Touch and Press depending on the platform (for example). Tap and Touch are regular terms when it comes to mobile platforms but very rarely used on consoles. Again a popular area where translators will regularly notify the team to point out an inaccuracy. Once pointed out then the team have to create a specific string which is a pain and can be mitigated earlier in the dev cycle.

It’s extremely important that these platform specific strings are identified. Any problems found once in submission can jeopardise release date and corresponding PR and marketing you may have planned. The importance cannot be overstressed. A little extra effort in preparing your strings will result in minimising the potential for this catastrophic event.

In the next Blog; preparing your script strings and max text length considerations.（source：gamasutra）