让您的 UI 文案适配全球语言
作者 / Jen Schaefer, Manager of UX Writing Team, Google Travel
文案，是 UX 系统里广义内容的一部分。相信大家从我们之前的文章里也已经对文案的设计以及作用有了一些了解。越来越多的产品团队发现，使用专职的 UX 文案作者会产生更紧凑、更一致的文案，这些文案考虑得更加周到，与品牌形象更加贴合，并且能够对用户的愉悦度和参与度产生可衡量的影响。但是，当我们需要将完美的母语版本翻译成其他语言时，事情可能就会变得棘手起来。
也许这个文案中包含的俚语会让当地的译者难以看懂 (比如 "落袋为安" 这个俚语就不是每个外文译者都能理解的)。再比如，一段文本在被翻译为日语之后，长度会大大超标，导致限定的控件空间无法将其容纳。
在 Google 的产品里，每个细节都会影响成千上万的用户，文案翻译自然也并不例外。总而言之，我们将 100 多种产品的文本翻译成 120 多种语言，与世界各地成千上万的译者合作。每年累计译文超过——7 亿字！
对高质量翻译的需求正在增长，特别是在新兴市场。如今，全世界超过 30 亿人能够上网，预计未来几年还会有超过 10 亿人接入网络。
回到做产品上来——尽管我们的想法十分美好，但我们并不能每次都把事情做对。分享一则真实的故事: 几年前，Google 酒店搜索的 UI 把 "Book a room (预订房间)" 翻译成西班牙语 "Libro una habitación"，西班牙语 libro 的意思就是实体的书 (book)。看，我们也有搞砸的时候。
翻译错误不仅令人尴尬，而且还不利于我们创造真正全球化的产品，这些产品本应适用于所有地方的所有人。
UX 文案要做些什么，才能帮助我们把冥思苦想出来的原文完整地转换为其他语言？我们已经总结了一些经验，并会在本文中和大家分享。
提前考虑翻译适配性
以我们的产品举例，我们使用通用英语进行写作。“通用英语” 是一种非常精确，强调字面意思的写作风格 (不涉及太多字面外的含义)，从而方便非母语人士理解。通过使用这种语言风格，您就可以确保翻译过程尽可能顺利。下面分享一些小技巧:
使用简单明了的单词和句子。每个短语或句子表达一个想法，尽量避免使用从句和复杂的句子结构。这也正好是 UX 文案的最佳实践做法。
基于同样的原则，请保持文案简短。有些语言的字符数可能比其他的多 40％ (比如德语)。冗长的名词串 (连续出现三个或更多名词) 时尤其麻烦。
使用关系代词 “that” 和 “which”，比如同样的意思，使用 “the message that you see here” 而不是 “the message you see here”。很多人都觉得这些词汇是无关紧要的，但它们可以提高翻译的清晰度。
请使用主动语态而不是被动语态 (这也是另一个 UX 文案最佳实践做法)。要说 “Submit the form” 而不是 “the form should be submitted” ，这样更加直接，也更容易翻译。
避免使用口语和俗语，除非你想要看到非常失败的逐字直译，比如 “elephant in room” 被翻译成 “房间里的大象”。在翻译幽默类的文本时，通常也要注意同样的问题。
当心语义模糊。比如说 “change history”，它可以被理解为 “change the history (改变历史)”，也可以被理解为 “history of changes (变化的历史)”。请准确使用您的语言。
使用措辞时要注意前后一致。为一个概念定下一个术语，并坚持使用它，不要在一个地方说 “Rules for submission” 然后又在另一个地方说 “Submission guidelines”。标准化是关键。
坚持采用标准的英语单词顺序，以避免读者将其误解成其他语言: 主语、动词和宾语，前面加上修饰语 (“You’ll easily learn perfect English”)。
避免使用缩写。许多语言都不用缩写。
在将这些小贴士应用到您的产品中之前，不妨先试着定义短期、中期和长期内的项目翻译目标。如果您不打算翻译您的 UI 文本，或仅打算将其翻译为一种或两种语言，那么用全球英语写作就不是很重要了 (因为您可能会多花一些时间，使用您打算采用的几种语言进行精细的翻译)。
但是！如果您打算使用更多种语言发布产品和/或计划使用机器翻译，那么请您务必使用全球英语进行写作。
为译者提供背景信息
在考虑向译者提供哪些信息时，如果您有机会这样做的话，那么宁可提供过多的细节，也不要在这方面有所短缺。我还没见过有译者抱怨对方提供的背景信息太多的。
在 Google，有几个团队正在尝试一个流程，在这个流程中， UX 文案作者会在每一条需要被翻译的字符串中附带编写描述信息。描述信息是一些注释文字，它可以告知译者，字符串会出现在 UI 中的哪个位置，应该如何翻译，从而为译者提供有关 UI 中字符串的背景信息。
通常这些描述由工程师在代码中撰写。然而，根据我们已经开展的一些研究，让 UX 作者编写描述也许会获得很大的成功。这样一来，我们不仅能让作者更好地控制翻译质量，而且每个字符串还可以为工程师节省超过一分钟的时间——而这些实证也帮助 UX 文案团队争取到了更多人手。
UX 文案作者可以为译者提供的重要细节信息包括:
字符串将如何显示。是按钮吗？是下拉菜单吗？还是标题？译者可能在没有屏幕截图或其他视觉资料的情况下翻译，因此他们非常需要尽可能多的背景信息。
触发显示这个字符串消息的操作是什么，以及期待得到的用户操作是什么。
是否需要翻译占位符 (将被日期等动态文本替换的文字区域)。
如何处理口语或幽默类内容 (如果有的话)。请确保译者知晓，他们的语言中可能没有相应的表达方式。请为他们提供一个更直接的语言版本以供翻译，或者为译者提供自行解决的权限，让他们进行意译 (下文的 “译创” 部分对此有更为详尽的描述)。
受众/用户是谁，文本是否需要表达出特定的语气。例如，某些报错消息可能特别令人沮丧，这时的文本就应该使用舒缓而不是突兀的语气。
如何翻译含糊不清的词语。对于像 “traffic” 这样的词，译者需要知道它在原文里是作为名词还是动词使用。
字符串翻译结果允许的最大字符数限制。
在 Google，我们正在为不同的文本元素 (包括标题、按钮和错误消息) 试用上面这套消息描述模板，让描述更容易创建，更完整，更一致，更有用。事实证明，这可以节省大量时间。
给译者提供工具包
您的 UI 中是否经常使用一些术语，或是对您的品牌特别重要的短语？请为译者创建词汇表/术语表，在表中提供术语的唯一指定翻译方式，最好还要让母语使用者对其进行审查，然后将其存储起来以备将来使用，这是一种有效的策略。
另一个有用的工具是功能和产品级别的翻译摘要。摘要应该指明您的受众、所需的语气和腔调、用户目标以及其他概述性的指南，以便译者在翻译单个字符串时也能确保和产品全局保持步调一致。
△ 我们之前的文章中提到过的 “话术表”，也是文案和翻译常用的工具之一。
与译者一起进行深度规划
以我自己的工作为例 (本文作者是 Google Travel UX 文案团队的主管)，我们曾经为酒店搜索结果提供一系列看起来很时髦的评论摘要。举个例子: “客人们都很喜欢浴室，但有些人提出，浴室还不够大，清洁度也有提升的空间。” 可想而知，用其他语言翻译出来的结果简直五花八门……后来通过与身处日本和德国的语言专家进行沟通 (这两个市场的翻译问题特别严重)，我们解决了问题，并提供了更有针对性的话术和翻译规范。
如果您的产品有翻译成其他语言，而您有机会去造访使用那个语言的国家/地区，那就出发吧！比如通过拜访印度并参与用户研究，我对自己如何用英语写作产生了全新的认识，并且亲身体会到了将全球化的写作技巧付诸实践的重要性。
考虑 “译创”
翻译意味着把一种语言中的文本，变成另一种语言，并尽可能贴近原始版本。“译创 (transcreation)” 则与此不同，它意味着用目标语言重写原始文本，并确保它仍然适合其预设的语境。进行 “译创” 的翻译们需要彻底了解品牌个性、交互逻辑和其他可能的限制，确保自己不仅能翻译，还能在适当的场合对文本进行重构，让文本更好地为当地受众服务。
在 Google，我们在 Assistant 的许多回复中都使用了 “译创”。如果你使用葡萄牙语问一下 Assistant “今天你好吗？”，你可能会得到一个不同于英语的委婉语答复，而不是英语回复版本的字面翻译。
“译创” 让我们产品的语气和内容更加灵活，让 Assistant 更加适合数十个市场中用户的需求，更具相关性。英语版本的 Assistant 比较偏向直接和实用。然而在印地语中， Assistant 显得更甜美，更善良——用户研究结果表明，这种语气引起了良好的反响。(说件有趣的事: 印度版本的 Assistant 已收到超过 45 万次求婚！)
Assistant 团队与世界各地的文案作者合作，确保回复保持文化敏感性和适当性，并满足用户的期望。这种方法可能也会适合您，尤其是当您希望让翻译出来的产品更具乐趣和个性的时候。
尽可能使用真实用户进行测试
用户研究不仅在本土市场，而是在每个发布市场中都是关键所在。影响文案写作和翻译的许多因素会因地而异——社会文化背景、网络连通性，等等。如果您无法进行当面访谈，则可以使用远程测试服务。最易用并且最受欢迎的服务之一是 UserTesting.com，请务必试试。
花点时间了解各地的用户，并对您的内容进行相应的优化，您的产品将变得更加强大。“产品壮得像头牛！”——呃，我们明白了您的意思，但正如我们在本文中说的，有些意思，不用俚语会更好，对吧。
推荐阅读