导出 (0) 打印
全部展开

可本地化性测试

Visual Studio .NET 2003

可本地化性测试验证是否可以轻松地将程序的用户界面翻译成任何目标语言,而不需要重新设计或修改代码。可本地化性测试捕捉通常在产品本地化过程中发现的错误,所以完成此测试必须进行程序的本地化。因此,可本地化性测试本质上就是全球化测试和本地化测试的混合。可本地化性测试的成功完成表示产品已可用于本地化。可以使用伪本地化以避免真正本地化所需的时间和费用。伪本地化或许是查找本地化分析错误的最划算的方法,它的执行步骤如下:

运行程序的伪本地化版本

执行伪本地化的最划算的方法是自动修改程序的资源。例如,下面是讲英语的本地化人员在翻译程序的 UI 时所做的工作:

  • 用包含非英文字符的文本替换英文文本。最好使文本保持为可读。例如,使翻译算法用形状相似的非英语符号替换英语字符。例如:
    • 对于 a,使用 à 或 å
    • 对于 c,使用 ĉ 或 ç
    • 对于 n,使用 ń 或 ñ。
  • 向资源字符串添加额外的字符。在许多情况下,翻译的文本比原英语长(“some string”变成了“+++some string+++”)。
  • 拉伸对话框。当字符串的长度由于本地化而增加时,本地化人员常常这样做。
  • 标记每个资源字符串的开始和结尾。这些标记可以帮助您确定应用程序在运行时的什么时候显示文本(本地化分析错误的潜在根源)。
  • 使用多语言 Unicode 进行替换(因为资源字符串总是存储为 Unicode)。这有助于查找程序使用 ANSI 函数处理或显示文本的位置。

伪本地化程序后,测试它的功能。伪本地化应用程序的运行与原始版本应该没有区别。

在可本地化性测试中经常忘记的一个方面是镜像测试。如果希望将软件销售到程序的文本和 UI 从右到左 (RTL) 显示的市场,需要知道应用程序镜像后的样子。此测试可以作为产品伪本地化的一部分来执行。结果,文本以您选择的语言显示,而应用程序镜像窗口和文本对齐。

执行代码检查

确保代码满足下列要求:

  • 以标准 Windows 资源格式编写所有资源,并且不对源代码中的字符串进行硬编码。
  • 不将指针算法用于字符串长度计算、对字符串元素的访问和字符串操作。
  • 不在运行时通过抽出或连接来生成字符串。
  • 资源不假定字符串缓冲区长度。
  • 不在运行时定位 UI 控件。
  • 图标和位图不包含文本。
  • 不存在对驱动器和文件夹名称或注册表项的任何假定。

执行 UI 和文档检查

确保 UI 和支持文档中使用的术语清楚、一致、没有歧义。当 UI 和文档用不同的名称引用同一功能或者当文本包含过多的技术行话时,本地化人员可能会感到困惑。

请参见

全球化和本地化的测试

显示:
© 2014 Microsoft