这篇博客文章是我在过去几个月中就软件本地化学到的六种与技术无关的东西的个人汇编。 几周前，我们终于启用了支持22种不同语言的应用程序。 作为为德国客户服务的德国开发团队，我们在应用程序中将德语作为基本语言。 我们的客户负责将德语应用程序消息翻译成其他21种语言，并提供其他本地化的材料（图像，可下载的文档等）。

1.使用工具

您需要一种在开发人员和翻译人员之间共享消息文件和翻译的方法。 我们首先开始在网络托管协作工具中使用一个简单的共享文件夹。 我们会定期上传德国基本邮件文件的最新版本。 译者使用此文件作为更新其他语言的消息文件的参考。

这种方法的明显问题是，它导致许多不必要的工作。 每当删除，添加或重命名消息密钥时，更改都必须手动合并到22个属性文件中。 如果德语消息更改，我们必须手动通知翻译人员，以便他们可以针对其他语言调整消息。 显然，这不是一个不需要的过程。

幸运的是，有一些不错的工具可以为您提供整个翻译过程的支持。 实际上，我们转而使用开源工具Pootle ，该工具大大减少了手工工作量。 但是，我确信可以使用许多替代工具。 另请注意，您不必为此使用第三方工具。 如果您希望将本地化的消息保存在数据库中，则可以轻松地自己创建具有简单搜索功能的CRUD UI，然后翻译人员可以使用它来更新消息。

2.教翻译

您应该确保翻译人员完全理解消息的语法。 对于开发人员来说，占位符，转义和日期格式的工作方式很明显。 从翻译者的角度（他们可能根本没有软件开发经验）看来，事情并不总是那么明显。 如果您的应用程序因某些语言的日期格式异常而崩溃，因为日期格式 DD.mm.YYYY 转换为jour / mois / an（日/月/年，法语），您知道必须对此进行改进。

确保告诉他们占位符如何工作以及需要转义哪些特殊字符。 给他们一些常见的日期/时间模式的例子，包括它们产生的输出。 在消息文件中使用注释可提供常用的格式设置选项，或说明可在消息中使用的占位符。

3.给翻译者背景

仅将消息从一种语言翻译成另一种语言通常是不够的。 译者需要知道消息显示的上下文，以便提供适当的翻译。 这里的第一步是使他们能够访问测试系统，在该系统中他们可以看到带有最新翻译版本的应用程序。

我们会定期收到来自翻译人员的电子邮件，其中包含以下问题：

在应用程序中，我在位置Y看到消息X。X的消息密钥是什么？

根据消息X，简单地在消息文件中搜索X并不总是有帮助（请考虑占位符，其他标记或包含X的太多消息）。 我们对此的解决方案是扩展为UI呈现消息的方式。 之后，可以通过在我们的应用程序url中添加其他url参数，在测试环境中显示消息密钥。 每当添加此url参数时，我们都会在呈现的消息周围添加一个简单的<span>标记和一个title属性。 因此，代替了[message]，我们渲染了<span title =“” [key]”> [message] </ span>。 这样就可以用鼠标悬停显示的消息，以查看显示消息键的小工具提示。 这种方法不是100％防弹的，因为在某些情况下，附加的<span>会破坏布局。 但是，95％的时间都能正常工作，并且大大减少了我们从翻译人员那里收到的问题。

相反的方式也存在：

我在消息文件中看到消息X和密钥Y。 它在应用程序中显示在哪里？

我认为最好的解决方案是遵循消息密钥的逻辑命名约定。 我们使用以下简单约定来构造消息密钥：

[module].[section].[detail].[optional subdetail]

一些例子：

news.create.title=Title
news.create.title.emptyError=Please add a title
news.create.title.maxLengthExceededError=The title cannot be longer than X characters

这些是一些消息，显示在新闻模块中创建表单（部分）的标题输入字段上。 组织级别由点分开。 诸如maxLengthExceeded之类的错误描述没有描述组织，因此以驼峰形式而不是news.create.title.max.length.exceeded编写。

但是，这只是一个建议，对我们的使用效果很好。 随意提出自己的约定。

4.请记住，字宽可能会有所不同

根据您的基本语言，您应该意识到，在其他语言中，每个单词的平均字符数可能更高或更低。 我还没有找到有关平均单词长度的任何真实统计信息，但是我可以向您显示一些来自消息文件的数字：

每个单词的平均字符数：

这些是从邮件文件中获取的平均数量，每个文件约有1500条邮件。 请注意，这些数字不是那么准确。 要获得消息的单词，我只需将消息按空格分开即可。 单词和消息可以包含其他标记，标点或占位符。 但是，由于所有语言的标记和占位符几乎相同，因此仍然提供了一些有用的信息。 在我们的应用中，德语或俄语中的单个单词比英语中的单词长大约20％。

您应确保您的应用程序用户界面支持各种文本大小。 这对于按钮和导航元素（如果标签变大通常会扩展）尤其重要。 另请注意，一种语言的常见缩写可能会翻译成其他语言的一个（或更多）完整的单词。 例如， FAQ或Q＆A是英文网页上的两个常用导航元素。 虽然“ 问题与解答 ”消息可以翻译成不同的语言，但可能并不总是这样的缩写。

5.测试

广泛测试本地化的应用程序：验证翻译，使用非西方字符作为用户输入，并检查所有语言的功能。 为了强调测试的重要性，我只想举一些我们遇到的针对特定地区的问题的示例：

• 使用特定语言的用户没有收到特定的电子邮件。 事实证明，电子邮件中包含一个由区域设置相关模式格式化的日期。 该模式包含无效字符，日期格式化程序失败，并且未将电子邮件发送给用户。
• 在某些情况下，不会用法语的实际内容代替占位符。 该问题是由包含未转义单引号的消息引起的。 在Java的MessageFormat中，如果占位符位于两个未转义的单引号之间，则不会替换它们。 我们仅注意到法语的问题，因为法语邮件包含的单引号要比我们支持的其他语言的邮件多得多。
• UI元素损坏是因为翻译后的消息太长且不适合保留空间。
• 事实证明，我们使用的外部支付提供商不支持完整的UTF-8字符集。 因此，西里尔字符无法打印在发票上。

6.需要时间

本地化的整个过程可能会花费很多时间。 特别是如果涉及到来自不同国家的许多人。 因此，请确保正确计划。 请记住，您添加到应用程序中的每条短信都需要翻译。

一旦我们添加了一个小的功能，它花费了大约一天的开发时间。 开发完成后，我们花了大约三周的时间才能将该功能推入实时系统。 一些翻译在休假，对于某些国家，法律问题必须澄清。 此外，我们在翻译人员之间还存在一些依赖性。 如上所述，我们使用德语作为基本语言，但并不是每个翻译员都能理解德语。 因此，在某些情况下，德语消息必须先翻译成英语，然后才能翻译成其他语言。

从开发人员的角度来看，这不一定很糟糕。 如果客户或项目经理在产品发布前一天问您是否可以在明天之前添加功能X和Y，这实际上是一个很好的借口。 当然，您可以添加它，但是直到明天才有可能将其本地化，因此最好对其进行适当的计划并将其移至下一个版本！

翻译自: https://www.javacodegeeks.com/2013/11/six-things-i-learned-for-software-localization.html