级别： 初级 Dan Kehn, Eclipse ISV 启用小组, IBM
2002 年 7 月 09 日 本文向您演示了如何验证您国际化的产品，使您对翻译测试期间可能遇到的常见问题类型有所准备。本文包括一个定义 Properties File Compare 视图的 Eclipse 插件，该插件可以帮助您的翻译测试人员更快地找到错误。
翻译验证测试
如果您遵循了本系列第一篇文章
Internationalizing your Eclipse plug-in中概括的国际化步骤，将您的本地语言（NL）资源（*.properties 文件、HTML 文件、图标等）交给翻译中心。这些内容返回了，并且您将它们重新集成到了产品中，现在该做什么？要使时间和金钱上的投资物有所值，您必须验证您的产品与译文一起能正确工作，并且它们在实际的产品使用环境中是语义正确的。这一过程被称为
翻译验证测试（Translation Verification Testing (TVT)）。
可以从两个方面来考虑 TVT：过程和技术。您采用的
过程很可能类似于您为产品的功能验证所采用的过程。但您将用到的特定
技术是很特别的，而且这些技术的选择还会影响测试过程的质量和效率。本文将概述翻译验证技术和经典错误，并提供了一个工具，您可以
下载它来帮助您的翻译测试员更有效率、更有成效地工作。
理想情况下，产品的本地语言版本（NLV）和国内版本是同时开发和交付的，在交付产品的国内版本以前就对翻译进行了测试。启用本地语言的产品的第二个及后续发行版更有可能是这种情况。然而，在首个发行版的情况中，国内版本可能是用已经启用本地语言的代码发行，但是在翻译可用之前进行的。这通常是不可避免的，因为，根据本地语言资料的数量，翻译可能要花几周或几个月，在这期间推迟国内版本的发行没有多大意义。
这就是 Eclipse Workbench，版本 1.0 遇到的情况。后续 Eclipse 发行版的国内和国际发行版应当接近同时发行，因为可以从以前的发行版继承大量的翻译和测试工作。在规划验证测试周期时，要权衡期望投入的时间和人员数量，使之与受翻译影响的资料数量成比例。一般而言，翻译资料中的微小更改通常是孤立的风险，不同于功能上的修改，其中一行出错的代码可以破坏整个系统的稳定性。这允许您按版本 1.0 投资的三分之二到二分之一的比例显著地缩减“版本 2”和后续的翻译工作。
基本翻译验证测试由什么组成？
为取得最好的结果，您应该在所有已翻译的语言中，使用操作系统的本地语言版本和针对目标区域的有代表性的硬件，对您的产品进行测试。但如果您必须选择一个子集，则下面的准则介绍了对产品的本地语言支持进行测试的内容以及如何测试：
- 对于单字节字符集（single-byte character set，SBCS）测试：使用德语，因为该语言比英语要长。除了验证是否对原始语言进行正确的替换以外，还要检查缓冲区溢出、显示时的消息截断和非 Latin-1 字符数据项（例如，é、á、ä 等），以及页面布局问题。
- 对于双字节字符集（DBCS）测试：使用日语，因为该语言涵盖了 DBCS 领域内的多种可能性。
- 对于双向字符集（BIDI）测试：使用希伯来语或阿拉伯语。它们是有代表性的 BIDI 语言。
TVT 集中检测：
- 无法使用语言环境敏感的函数
- 由翻译带来的新的代码问题
- 硬编码字符串
- 文本扩展问题
- 无意中翻译掉的字符串
- 字体更改、编码／代码页问题
- 脱离环境的翻译错误
注：本文的篇幅不允许我们对这些问题逐一地进行深入分析，但我们会详细讨论那些不太显而易见的问题。
TVT 工作箴言
为了以最短的延期时间交付产品支持本地语言的版本，测试人员很有可能将所有的测试工作都集中在该版本上。但本地语言版本中引入的校正可能会影响到国内版本。在决定是否应用代码校正时，要确定这种校正对成品有多重要。您的翻译测试员知道翻译缺陷在其文化环境中相对的消极影响；可以让他们帮助您划分所报告问题的优先次序。对于可能使国内版本不稳定的校正，不要急于采取行动，而对那些会使翻译产品部分不可用的校正，则不要耽搁。相信自己的判断，并且提出一份“绝对必须修改”的问题列表。
常见问题的测试
所有专业功能测试员都会关注他们擅长处理的问题领域，如边界测试、压力测试和公共路径测试。对于翻译测试专业人员也是如此，他们掌握了要进行测试的语言并且在脑海里形成了常见问题区域的列表。这些常见问题中的大部分适用于所有的目标语言翻译，但其它的则特定于给定的语言、文化、以及国家或地区。我们将集中讨论前者，因为解决这些问题无需先掌握目标语言。而且可以在验证测试阶段的早期应用这些问题，就是说，可以在翻译测试专家到来之前，在开始付出时间和金钱以前解决这些问题。
 |
重音符号的技巧
Windows 对国际键盘布局的支持有助于在 QWERTY 键盘上输入重音符号。它启用了所谓的重读符号的“死键”输入。例如，输入单引号 + 希望重读的字母就会生成带重音符的字母（'+e = é、'+a = á 等）。类似地，用脱字符号（^）可以添加音调符号（â），用左重音修饰符（`）可以添加重音符（à），用双引号（"）可以添加分音符号（ä）。
然而，尽管这使得 QWERTY 键盘用户可以输入重音符号，但它无法保证同样的重音符号键在“本地”键盘上可以起作用。情况确实如此，因为键扫描码序列在两种情况下将会不同，从而在非本地键盘上可能检测不到输入错误。双字节字符的输入错误同样难以解决。尽管 Windows 确实支持非 DBCS 机器上的双字节字符输入，但其设置比仅仅切换键盘布局要麻烦得多 — 它涉及到安装 DBCS 字体和使用多笔划键输入。
|
|
没有使用语言环境敏感的函数
这类问题主要围绕着特定于语言环境的数据显示，
Internationalizing your Eclipse plug-in和
Java Tutorial: Internationalization系列中有详细介绍。开发人员可以通过更改数字、货币、时间和日期的区域设置，然后验证这些字段是否用当前的语言环境显示，以及输入是否如预期那样被接受来预先测试这一项。验证排序的列表是否正确（即使它们包含重音符号）。非本地翻译测试人员可能不知道精确的排列次序，因而不得不将其留待本地翻译测试人员处理，但通常您会指望非重读字符与其重读对应字符应该相互排列在一起。换句话说，很显然您没有使用
Collator类或其同等类进行排序，因为二进制比较通常会导致重音字符出现在距其对应字符很远的位置（例如，a = \u0061，á = \u00e8）。
好消息是，没有使用 Java 语言环境敏感类不象本文中进一步列举的那些问题那么普遍，这可能是由于与语言环境有关的字段占少数这一事实。与翻译过程本身引入的本地语言问题不同，程序员还是趋向于对这些类所解决的本地语言问题的本质有更直观的评价。在继续以下更微妙的测试问题之前，记得要考虑输入域项。验证您可以输入重音字符，以及它们在从永久性存储器重新读取时没有被代码页转换破坏（或缺乏该转换）。验证非 Unicode 敏感操作没有破坏（分割）双字节字符。
翻译带来的新的代码问题
很难概括这类问题的特征，但通常的想法是错误地假定本地语言数据的格式依附于程序员的母语，或假定数据根本不是本地语言敏感的。例如，在假定分隔符是句号或空格的情况下解析文本，或不小心使用了本地语言数据定义或修改字符集敏感数据（如数据库的列名称）而没有对相应的用户输入域验证进行编码。
硬编码字符串的测试
硬编码字符串无疑是所有 TVT 错误的“祖先”，其数量远远超过所有其它错误的数量。找出这些错误有两种基本方法：黑箱方法和白箱方法。
白箱方法依靠扫描 Java 源代码、XML 和 HTML 来寻找硬编码字符串。Eclipse Workbench Java Development Tooling（JDT）的
External Strings向导使 Java 源代码扫描过程自动化。
黑箱方法需要大量手工操作，因为它依赖执行测试案例（testcase）方案，即：在非美国英语工作站上将产品用户界面的所有元素（视图、菜单、对话框等）显示给测试员，由测试员确认所有文本都已翻译。
然而，在上述两种方法之间还存在一种
灰箱方法。该方法需要将所有文本转换成具有相同数量字符和词的易于识别的无害字符串。例如，以下的资料信息：
Import resources from the local file system
变成
***** ********* **** *** ***** **** ******
如果您的产品测试小组明智地使用了自动化测试工具，可以修改它们的脚本以检测哪里有未被黑箱方法检测出的硬编码字符串。这些疏漏可能是由于您的产品使用了未经翻译的第三方产品、或由于组合字符串等。即使您没有从自动测试中受益，该方法仍会简化硬编码字符串的手工检测。此外，它还具有无需特定语言技能的优点。有些测试员喜欢“Pig Latin”方法。用这种方法，我们上面的示例就会是：
Importway esourcesray omfray ethay ocallay ilefay ystemsay
这样做的好处是，在同样可以指明什么文本没有翻译的同时，保持了一定程度的可读性。
无意中翻译掉的字符串的测试
灰箱方法可能是验证所有字符串是否都已翻译的最严格方法。但它在检测是否有无意中翻译掉的字符串方面也有用。例如，假设下面是特性文件
org.eclipse.jdt.internal.formatter\options.properties 的摘录：
style.reuseExistingLayout.number=8
style.reuseExistingLayout.category=Style
style.reuseExistingLayout.name=&Reuse existing layout
style.reuseExistingLayout.possibleValues=2|Reuse|Do not reuse
style.reuseExistingLayout.description=If the user formatted code a certain way, ...
|
将所有明显的用户文本转换成星号会包括下面的键和值：
style.reuseExistingLayout.possibleValues=2|*****|** *** *****
|
这本身也许不会引起运行时错误，因为并不清楚这些值是否实际上代表用于保存用户首选项的键（换句话说，“Reuse|Do not reuse”从未显示给最终用户）。如果翻译人员无意中将英语中有不同意义的两个术语翻译成目标语言中的同一个词，则更改一个首选项有可能覆盖另一个不相关的首选项。
这就是把属性文件混用于可翻译文本和运行时参数化的风险。这当然是一种有效的编程技术，但它要求翻译人员知道这一点（至少可以通过向特性文件本身添加注释）。更好的方法是使用明显与程序有关的值。回到我们的示例中来：
style.reuseExistingLayout.possibleValues=2|REUSE_LAYOUT_YES|REUSE_LAYOUT_NO
|
这里，翻译人员和他们的翻译工具都很清楚：不应修改等号后面的值。
文本增加问题的测试
英语翻译成几种欧洲语言后的平均文本增加比例大约为 40%。考虑以下几个示例。首先，一个英语单词翻译成两个德语单词：
Restart -> Neu starten
没有问题，7 个字符增加到 11 个。但下面的示例就令人惊讶了。两个英语单词翻译成一个（长的）德语单词：
Counter Logs -> Leistungsindikatorenprotokolle
哎唷，12 个字符增加到 30！尽管相对于英语的文本增加，德语很容易被识别，不过它并不是唯一这样的语言。看看“air bag”的 Acadamie Française 的官方法语对应词语：
coussin gonflable de sécurité。要在翻译可用之前在开发中解决这个问题，您可以修改特性文件的文本以使其长度加倍。为了明显地表明这是一个测试案例，可以用一个简单的脚本重复每个单词。还是以我们上面的示例为例：
Import import resources resources from from the the local local file file system system
现在重新运行您的应用程序，继续验证页布局仍然是适当的，以及文本未被截断等等。如果页面是可调整大小的，可以从四个角的任意一个调整它的大小。要知道甚至这个测试都有缺点，因为它假定短语包括空格并且可以自动换行；但对于一些基于非拉丁字符的语言，情况并非如此。
对于布局要求翻译的文本最少的那些情况，要在原始语言的文件中记录该限制。例如，添加注释：
# translation note: Text below is limited to approximately 60
# characters, see testcase 1.13 to validate
|
这里告诫翻译人员不允许冗长这一事实。测试案例引用将允许翻译测试员验证文本未被截断，因为字母的选择会影响相应字体下最终的文本宽度。翻译人员还要具有指定布局约束（如表的列宽）的能力，特别是对于那些不可调整大小的布局约束：
# translation note: Width in pixels of the "Completed"
# column. The text is a 'C' in US English, it should
# be as short as possible in the translation.
taskList.completedHeading=C
taskList.completedHeadingWidth=10
|
这里，考虑了与语言和操作系统相关的缺省字体后，翻译人员或翻译测试人员不用依靠不自然的简洁翻译，就可以提供最佳大小。
注：文本截断意味着不能获得完整的文本，即使使用可选的用户界面机制（如滚动、显示另一个对话框或提供“More >>”按钮）也无济于事。很明显，无法显示文本的文本截断比只要求用户滚动查看区域严重得多。出于这些原因以及可使用性原因，要避免创建不能滚动或换行的文本区域。
字体大小变化的测试
在不同操作系统和语言中，字体像素大小的高度和宽度都会发生变化。这些情况的大多数是由基本窗口构件（widget）处理的；例如，文本域将自动调整大小以适应较大的字体，如果需要也可以自动滚动。但如果您绘制自己的图形或文本，则为了避免随意的文本截断，必须查询适当的系统度量。
对于双字节语言字体尤其如此，其最小高度通常比单字节语言字体大。另外，虽然
并不要求为了符合
Section 508可访问性标准而处理字体大小的改变，但那些因视觉缺陷而希望选择较大字体的人们肯定会感激这一点。您可以在 Windows 上进行快速测试：增加缺省字体大小，然后重新启动机器（
Display > Settings > Advanced > General > Font Size > Large Fonts）。您会惊讶每天使用的应用程序有多少不能通过这个简单的测试。不要重蹈他们的覆辙！
脱离环境的翻译错误的测试
直接影响这些翻译的质量的一个方面是环境的明确性。在翻译特性文件时，下面这个问题是显而易见的：
这个示例是假想的，但它能说明问题所在。这条消息显示时所处的环境是什么？第一个参数可以是日期，第二个则是时间。但也许第一个参数是资源，而第二个是存储该资源的服务器的 URL。在没有给出注释时，翻译人员只能按字面意义将其翻译成最可能的可选译文。
下面是来自 Eclipse Workbench 的实际示例：
WorkbenchPreference.autobuild = Perform build automatically on resource modification
|
在这个环境中，“on”的意思是“当资源被修改时”。Workbench 用户可能知道这一点，但第一遍翻译是由不具备详细而精确的产品知识的中心机构完成的。因为他们对“资源修改”知之甚少，所以将“on”按字面解释，如“在……之上”，或非常勉强地用程序上的意义解释为“作为超级任务”。
可以考虑向特性文件添加注释，那么翻译人员就可以知道给定消息的环境。这对于有暗示的主语的情况尤其重要，因为许多语言必须清楚地知道主语，以便选择适当的形容词和动词形式。下面几条来自 JDT 的消息是作为 Java 源代码编辑器的标记显示的，消息增加了示范性翻译人员友好的注释：
# Note: The error messages below are displayed in the Java source
# editor with an "X" next to the offending line. They are also
# displayed in the Task List with a reference back to the file.
# Double-clicking the error in the Task List will open the editor
# and scroll to the corresponding line number.
# The subject is a method, i.e., "Method must return a result of type 'x'"
108 = Must return a result of type {0}
# "Variable (or field) must provide either dimension expressions...
159 = Must provide either dimension expressions or an array initializer
# "Class must implement the inherited abstract method 'x'"
400 = Must implement the inherited abstract method {0}
# "This class overrides deprecated method from 'its superclass'"
412 = Overrides deprecated method from {0}
|
没人指望编写了这样一条消息的开发人员知道短语的微妙解释。以上示例说明：即使开发人员做了最大的努力，翻译测试仍是不能取代的。
遗漏翻译的测试
除了对翻译产品的运行版本执行 TVT 以外，您还可以使用
Property Files Compare视图加速测试周期以及检测常见错误，从而使您产品的本地语言版本有更高质量。
简而言之，该工具的目标有两部分：
- 通过并列地显示翻译文件的内容和其相应的原始语言文件允许快速的翻译验证。这是“脱离环境”的验证，但它使测试人员有机会快速地复查译文并保证文件 100% 都翻译了并且转换成了正确的代码页。
- 确保您的本地语言产品一旦发布将不会由于已翻译文件遗漏关键字而抛出异常。
请记住，在发送原始源语言文件进行翻译与开始 TVT 之间有一段时间间隔。在此期间，代码 — 以及一些原始源语言文件 — 可能已经更改。可能向它们添加了翻译中没有的新关键字，这会导致运行时错误。
要解决这种情况，可以使用该视图并列地比较源语言文件和其相应的翻译文件。该工具会标记遗漏的关键字并使您有机会校正这些文件。
结束语
使您的产品可用于世界市场，费用大且耗时间。但如果有任何迹象显示需要世界范围的软件销售，那么忽略这种需求本身就要付出代价。用
本系列第一篇文章中介绍的详细指导信息和本文介绍的测试提示和工具，您应该可以
présenter votre produit en n'importe quelle langue comme si c'était sa langue maternelle（象用母语一样用任何语言展现您的产品）！
并列比较特性文件的工具
翻译验证测试需要一位语言专家实际执行该产品以便校正前面讨论的翻译错误。这个过程很耗时间，有时很乏味而且容易出错。作为一种降低成本、改进生产力和提高最终产品质量的方法，我编写了一个简单的视图工具，它可以使用运行时格式化和参数替代来并列地显示两个特性文件。这使语言专家能快速验证初始翻译并查看以与运行产品本身相同的方式格式化的消息。
下载该工具的代码。
更确切地说，下面是
Property Files Compare工具解决的问题：
- 使语言专家能快速验证初始翻译。请记住，第一遍翻译通常是由没有产品经验的翻译人员“大批”完成的。他们使用有助于确保翻译一致性的翻译工具，但这并不能替代现场验证。翻译验证测试员知道产品隐含意思，并且能够以并列方式快速地复查翻译以便找出明显的过失。
- 将以和运行的产品本身相同的方式格式化的消息可视化，包括参数替代。这有助于检测一些常见错误，如遗漏的或多余的引号、遗漏的反花括号等。这些错误的大部分会在源语言中显现，其它错误则是在翻译过程中引入的。多余的或遗漏的单引号是一个众所周知的示例，即使在英语中也是如此（例如，“The process didnt complete”遗漏了一个撇号，而“The process didn''t complete”则多出了一个撇号）。请参阅下面的
“一个或两个单引号？”以获取详细信息。
- 确保消息是可显示的。和听起来一样简单，编码／转换错误并不少见（请参阅
Internationalizing your Eclipse plug-in以获取详细信息）。快速显示实际运行时环境中的特性文件是很好的“健全”检查。
- 确保源语言中定义的所有键在目标语言的特性文件中都存在，反之亦然。当对源语言的键进行了添加或删除而未对目标语言文件进行适当的校正，以及无意中删除了目标语言文件中的键时，就会出现不匹配的情况。
- 标记未翻译文本。
一旦安装了它的插件，可通过选择
Perspectives > Show View > Java > Property Files Compare打开它。然后输入包含源和目标语言的目录名称；在
Source Language Directory或
Target Language Directory域获得焦点时，按 Enter 键将启动对所有 *.properties 文件的搜索。选择左边的某个特性文件，试图通过匹配相同的部分文件规范（从目录路径中最后出现“eclipse”的地方开始）在右边自动选择其相应的目标文件。
图 1. 特性文件比较视图
例如，如果 Eclipse Workbench 安装在
x:\eclipse2.0 中，则 Eclipse 安装根目录是直接位于其下的子目录，（毫不奇怪地）被命名为
eclipse 。该视图假设您（a）按照语言在单独的子目录树中维护本地语言特性文件，或（b）原始语言（源）文件没有国家或地区后缀，目标文件则有后缀，且后缀基于操作系统返回的国家或地区代码。例如：
(a) Languages separated by directory
x:\english\eclipse\plugins\org.eclipse.core.jdt\plugin.properties
x:\french\eclipse\plugins\org.eclipse.core.jdt\plugin.properties
x:\german\eclipse\plugins\org.eclipse.core.jdt\plugin.properties
(b) Languages separated by country-specific file suffix
x:\eclipse\plugins\org.eclipse.core.jdt\plugin.properties
x:\eclipse\plugins\org.eclipse.core.jdt\plugin_fr.properties
x:\eclipse\plugins\org.eclipse.core.jdt\plugin_de.properties
|
因此，在第一个目录域输入
x:\english ，然后按 Enter 键，表示启动从 English 子目录开始的搜索。在第二个目录域输入
x:\french 将启动从 French 子目录开始的搜索。选择
Source Language列表中的一个特性文件将自动选中
Target Language列表中的对应文件，并显示其按键排序的内容。
Property Files Compare视图（尽管有帮助）在功能上相当有限，无可否认，它对目录结构做了假设，这使得有些人觉得受到约束。我的唯一辩白是：我匆匆将它拼凑起来以解决问题并且再也没有抽时间改进它。在这里提供它用于下载，因为您可能会觉得它有用，告诫一点：该源代码不是良好的 Eclipse 插件开发的模型。
注：可在 alphaWorks 上获得另一个名为
RBManager的工具。根据其描述，“
RBManager（资源束管理器）自动执行与创建、更新和管理资源束文件相关的乏味任务；它还防止大多数常见的由于跨束传播产生的错误。这个工具对于从事国际化的应用程序和基于 Web 的服务的开发团队很有帮助。”
RBManager 不包括并列特性文件视图（至今？），但它确实有助于管理翻译中通常涉及的许多资源文件。RBManager 有良好的文档和一个教程。
一个或两个单引号？
您如何计划格式化特性文件消息会影响到单引号的输入方法，就是说，单引号是重复还是只输入一次。为了说明这个问题，请考虑下面的代码：
package com.ibm.jumpstart.messageformattest;
import java.text.MessageFormat;
public class MessageFormatTest {
public static void main(String[] args) {
String msg1 = "This is a ''{0}'' program and it''s not ready for production.";
String msg2 = "This is a beta program and it's not ready for production.";
String msg3 = "This is a beta program and it's not ready for {0}.";
System.out.println(MessageFormat.format(msg1, new String[] {"beta"}));
System.out.println(MessageFormat.format(msg2, new String[0]));
System.out.println(msg2);
System.out.println(MessageFormat.format(msg3, new String[] {"production"}));
System.out.println(msg3);
}
}
The output is below:
This is a 'beta' program and it's not ready for production.
This is a beta program and its not ready for production.
This is a beta program and it's not ready for production.
This is a beta program and its not ready for {0}.
This is a beta program and it's not ready for {0}.
|
第四行特别麻烦，因为不仅遗漏了撇号，而且还遗漏了替代参数！这些区别来自这一事实，即：如果要把单引号包括在结果中，则
MessageFormat期望输入两次单引号。没问题，但如果有些程序员使用 MessageFormat，有些程序员编写自己的参数替代版本，而其他一些程序员在没有替代参数时根本不使用它，那该怎么办？翻译人员显然不知道什么代码将操作翻译的文本，因此他们必须知道如何输入所需的单引号／撇号。
下面是在 Eclipse Workbench 版本 1.0 TVT 期间对于所需的引号采取的一些约定：
- 如果没有替代参数，则只输入一个单引号
- 如果有任何替代参数（象 {0}），则输入两个单引号
这是观察到实际上所有的程序员都只在有替代参数的情况下才使用 MessageFormat 后，对它的接受。为了避免这种编程不一致性，Eclipse JDT 版本 2.0 包括一个 Externalize Strings 向导以帮助集中进行消息检索和参数替代。请考虑采用该策略或系统地使用 MessageFormat，以便您的翻译人员只遵循一条关于所需单引号的规则。
参考资料
关于作者 | | | Dan Kehn 是美国北卡罗莱纳州 Research Triangle Park 的 IBM 高级软件工程师。他对面向对象编程的兴趣要追溯到 1985 年，当时这种技术还不象现在这样广为接受。他拥有广泛的软件经验，从事过开发工具（如 VisualAge for Smalltalk）、操作系统性能和内存分析以及用户界面设计。Dan 作为面向对象开发项目的顾问走遍了美国，并且还在欧洲工作过四年。他最近的兴趣包括面向对象分析／设计、编程工具，以及使用 WebSphere Application Server 进行 Web 编程。去年，他加入了 Eclipse Jumpstart 小组，这个小组的主要目标是帮助 ISV 创建基于 Eclipse Platform 的商业产品。在其余时间，Dan 撰写了关于几篇关于各种 Smalltalk 主题的文章，如元编程、团队开发和内存分析。可以在
Eye on SmallTalk上找到这些文章。
|
对本文的评价
| 
