伪翻译

伪翻译是软件测试中用来测试软件是否匹配国际化与本地化的方法之一。用于测试软件国际化方面的软件测试方法。不像在本地化过程中将软件的文本翻译成外语，而是用原始语言的改变版本替换应用程序的文本元素。

简介若一个软件在设计时并未将本地化能力（localizability）纳入考虑，那么在实际针对这软件进行本地化翻译时，将有可能会面临许多问题。例如文字在翻译后可能比来源语言的文字还要更长，那么将导致翻译后的文字被截断而难于辨识。例如软件的菜单、文字区域、按键、复选框等，设计者在做界面设计时通常先调整出适切于来源语言文字长度的大小（通常为英文），并进一步调整界面的对齐、位置、行距等等。然而，一些语言从来源语言被翻译后，往往会比来源语言的长度更长，例如德文或是挪威文通常都比英文要来的长，于是原始的界面大小便会显得过小而无法正常显示翻译后的文字。

问题还可能更加严重，一些语言的文字或符号可能因为软件原始指定的字形并未支持，而导致无法正常显示。问题也会出现到输入端，某些程序员错误的假设用户在输入时不会输入一些特殊字符或是特定语言的文字，而导致用户在实际操作软件时发生问题。

针对一些已然成熟且多数的目标语言翻译已经可以获取的软件而言，或是仅会有少量界面变更的软件，直接将翻译套用至该软件并进行多个语言的测试，可能是最直接且最好的测试方式。而针对一些新开发的软件，或是将会有庞大的界面变更的软件，等待翻译完毕之后再进行界面测试，则可能因此延迟了整个测试的时程。并且，在软件开发的初期也不见得会开始进行界面文字的翻译，因为界面有很大的机率会被调整甚至重新设计。若要等到产品比较成熟后，开始进行界面翻译，然后才进行翻译的界面测试，产品的上市时程将可能因此被延误。在这样的状况之下，伪本地化将会是最佳的选择，原因之一包含翻译并不会真正的被运行。

一般而言，程序里预计要被翻译的文字都将会被伪翻译（pseudo-translation）。假定英文为软件的来源语言文字，一般而言伪翻译的文字必须要比来源语言的文字长度还要长，文字并且要包含较长且不含空白的单字，并且最好包含了不同语系的文字。如此一来，测试者便可借由审查每个界面的组件来验证有无文字被截断的状况发生。1

本地化过程传统上，软件的本地化独立于软件开发过程。在典型的场景中，软件将以一种基本语言（例如英语）构建和测试，任何可本地化的元素都被提取到外部资源中。这些资源被移交给本地化团队，以便翻译成不同的目标语言。这种方法的问题在于，在本地化过程中可能会发现许多微妙的软件错误，因为修复它们的时间太晚（或者更可能是太昂贵）。

本地化过程中可能出现的问题类型涉及书面文本在不同语言中出现的差异。这些问题包括：

翻译的文本明显比源语言长，并且不适合UI约束，或者导致文本在尴尬的位置中断。

字体字形明显大于或具有源语言中未找到的变音符号，并且可以垂直切除。

阅读顺序不是从左到右的语言，这对用户输入尤其有问题。

应用程序代码，假定所有字符都适合有限的字符集，例如ASCII或ANSI，如果保留未被捕获的话会产生实际的逻辑错误。

此外，本地化过程可以揭示元素应该可以本地化的位置，但是用源语言进行硬编码。类似地，可能存在设计为本地化的元素，但不应该是（例如XML或HTML文档中的元素名称。）

伪定位旨在通过用源语言的发言者可读的伪语言机械地替换所有可本地化的元素来在开发周期中捕获这些类型的错误，但是其包含其他语言和脚本的大多数麻烦的元素。这就是为什么伪定位被认为是工程或国际化工具而不是本地化工具。

Microsoft Windows中的伪本地化在Windows Vista开发周期中，微软引入了伪定位。为此目的而发明的伪语言类型在Windows用语中称为伪语言环境。这些语言环境旨在使用Windows在时间基础（“西方”），镜像（“近东方”）和CJK（“远程” - 使用的三大类外语之一中的字符集和脚本特征。东“）。在Vista之前，这三种语言中的每一种都有自己独立的Windows版本，可能具有不同的代码库（因此，不同的行为和错误。）为每个语言系列创建的伪语言环境将产生仍然“读取”的文本。英语，但由其他语言的脚本组成。例如，文本字符串

编辑程序设置

将在“基本”伪语言环境中呈现为

[!!! εÐiţ Þr0ģЯãm səTτıИğ§ !!!]

此过程生成较长的转换字符串，包括非ASCII字符，并且（在“镜像”伪语言环境的情况下）从右到左书写。

请注意，此示例中文本两侧的括号有助于发现以下问题：

被截断的文本（截断）

通过组合（串联）形成的字符串

不可本地化的字符串（硬编码）

微软的伪本地化过程Michael Kaplan（微软项目经理）解释了伪本地化过程，类似于：

一个热切而勤奋而又天真的实习本地化者，他渴望证明自己[或她自己]以及谁将要翻译你不说的每一首字符串都不应该被翻译。

伪定位过程的一个关键特性是它在开发周期中作为例程构建的一部分自动发生。该过程几乎与用于生成真正的本地化构建的过程相同，但是在构建测试之前完成，在开发周期的早期阶段。这为在基本代码中找到的任何错误留出了时间，这比在发布日期临近之前找不到的错误容易得多。

使用与非本地化构建相同的QA循环来测试由伪定位过程产生的构建。由于伪语言环境模仿英语文本，因此可以由英语使用者进行测试。 Windows版本（7和8）已经发布，其中一些伪本地化字符串完好无损。对于这些最新版本的Windows，伪本地化版本是主要的临时版本（通常用于测试的版本），最终的英语版本构建是该版本的“本地化”版本。

用于其他平台的伪本地化工具除了Microsoft内部使用的工具外，其他国际化工具还包括伪定位选项。这些工具包括Alchemy Software Development的Alchemy Catalyst，SDL的SDL Passolo和g11n的Globalyst。这些工具包括伪本地化功能，包括查看呈现的伪本地化对话框和自动化测试过程本身的能力。虽然像Globalyst这样的工具完成了创建伪局部化构建和自动化测试的整个过程，但也可以通过在提取的文本资源上运行自定义伪局部化脚本并手动测试它来完成。

互联网上有各种免费的伪定位资源，可以创建常见的本地化格式的伪本地化版本，如iOS字符串，Android xml，Gettext po等。这些站点（如Pseudolocalize.com和Babble-on）允许开发人员将字符串文件上载到Web站点并下载生成的伪本地化文件。

本词条内容贡献者为:

王沛 - 副教授、副研究员 - 中国科学院工程热物理研究所