Matrix 首页推荐
Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。
文章代表作者个人观点，少数派仅对标题和排版略作修改。
作者按：我并不是本地化的专业人员，只是借助一些资料谈谈我对伪本地化与本地化的理解，如果出现错误请大家及时指出，也谢谢大家的包涵。
几年前，微软发布 Windows 11 之后，远景论坛（pcbeta.com）出现了这样一张有关 Windows 11 小组件的图：
图中圈出的「Mǿґê oρτîǿйs !!!」引发了人们的讨论。一些人猜测这是乱码，但最终证明这只是一个产品测试中常用的方式：伪本地化（pseudo-localization）。
虽然不是本地化的专业人员，但我依然想刨根问底，了解伪本地化的目的。当时在我看来本地化与翻译差不太多，只是将源语言替换为目标语言而已。既然如此，为什么还需要一个看似「多此一举」的伪本地化，将文本变成了一个看起来不像英文实则是英文的东西，目的何在？带着这样的疑问，我上网去寻求有关伪本地化的更多信息。
维基百科是这么解释伪本地化的：
伪本地化是软件测试中用来测试软件是否符合国际化与本地化的方法之一。与正式本地化中将软件文本翻译成外语不同，伪本地化只是改变原始文本的呈现方式而不改变文本本身。这些特定的改变使得原始文字看起来仍可按源语言阅读，但却包含了不同语言间最可能存在的差异：文本或字符的长度变化、语言方向、界面适应等等。
原来，不同语言间的显示差异使得本地化并不是单纯的翻译那么简单，因此，在正式本地化之前，需要测试软件是否具备「可本地化」的能力。下面列举了在本地化中的出现的常见问题。
字符不同是不同语言间最直观的差别。比如都使用拉丁字母，相比英语，许多欧洲语言都会有变音符号（diacritical mark），而除了拉丁字母以外，又有西里尔字母、阿拉伯字母等等其它字母系统；相对于字母，中日韩（CJK）字符又另成一类。
如果编写软件时采用了覆盖范围有限的字符集（比如 ASCII），在本地化时很可能会导致其它语言需要用到的字符无法正常显示。（如下图）
除了字符之外，文本长度也是一个需要考虑的问题。如果翻译后的语言过长，而显示空间比较有限，可能会导致文本显示不全。
以源语言是英语为例，常见情况下：
不同资料的统计数据可能有所不同，尤其是日语差别比较大（见下图）1，但大体趋向是：由英语翻译为其它语言文本长度一般会增长，而翻译到东亚语言时一般会缩短。
一般来说文本变短不会出现太大问题（空白过多总比显示不全好），但如果文本变长，显示空间又比较有限的情况下，就会出现文本被截断，显示不全的情况，如下图：
原来英文的「Don't miss out. 」（不要错过）到了德文中变成了「Lassen Sie sich nichts entgehen!」，文本长度几乎多了一倍，因此原来适应英文的显示空间到德文中就不够了。
这个相信大家并不陌生。现在世界上的语言在横向上（不考虑垂直书写）多采用两种书写方式：从左往右（Left-to-Right, LTR）或从右往左（Right-to-Left, RTL），下图展示了两种语言（以英语/阿拉伯语为例）在界面上的差别。注意在软件中，RTL 语言不仅文本需要右对齐，其它控件也需要以从右向左的形式排列（但播放按钮、进度条等元素无需反向）。
另一个需要考虑的是「双向文本（Bidirectional text）」。在一些从右往左书写的语言中（比如阿拉伯语）数字，日期等却需要从左往右书写，如果需要包含其它从左往右书写的语言，这些语言仍将保持从左往右书写的形式。
上面说的是不同语言本身存在的差异，而这里则是在代码层面可能出现的问题。
字符串分割，表现为一个字符串被拆分成两个或多个部分。这可能会增加翻译的难度，因为翻译人员必须独立地翻译每个部分，而不知道这些部分是相关的。而且，不同的语言可能会要求以不同的顺序组织各个部分或采用完全不同的句子结构。这可能会导致翻译出的句子结构混乱。，
在 Windows 中，由字符串分割引起的最为知名的翻译问题应该就是「该内存不能为 read/written」（正确翻译应为「该内存不能被读取/写入」）了，该语段的英文原文是：The memory could not be %s. （其中 %s 表示占位符，将视情况被替换为 read 或 written），由于 read/written 在原句中仅表示为占位符，与原句分开了，所以该词无法被翻译。同时翻译人员将 could not be 理解为「不能为……」，实际应是「不能被……」。（不只是中文。这一翻译问题在其它语言中也广泛存在）
至于硬编码，其弊端已被许多人指出，这里不做详述。从本地化的角度来说，一旦一些字符串被直接写进了源代码中，而并非可用于本地化的资源文件中，在本地化过程中这种字符串可能不会被翻译，从而导致本地化的不完全。其实上面的「该内存不能为 read/written」也可以被看作是硬编码的问题（read/written 被硬编码进程序中）。
另外一个类似于硬编码的情况是图像包含文本，在准备本地化时，很容易忘记这些元素，从而导致图像中的文本未被本地化。
那么，伪本地化又是通过什么方式发现本地化潜在的问题呢？
对于字符不同的问题， 伪本地化采用添加来自其它语言的重音符号，或将这个字母替换为其它语言中与这个字母形态相似的字母。
如 a 可以替换成 ā á ǎ à ă ä å α ά ，t 可以替换成 ț ţ ť ŧ т ，等等。
以「Turn off the power（关闭电源）」 为例，它可以被“翻译”成 Țùŗη ôƒƒ ţђë ρõẃēя
一个字母的替换对象可以只是一个固定的字母（如 a 可以统一替换成 α），也可以是一个字符集。
有不同的方法可以扩展字符串。
微软采取了在字符串后加 ! 的方法，具体做法为：一个词组 3 个 ! ；一个单词 1-3 个 ! ，或者直接加空格。
如 [Гзƒгēśн ţћĕ рáġ℮ īŋ а ƒêω мīлúтęş. !!! !!! !]（Refresh in a page in a few minutes，几分钟后再刷新页面）
而安卓则采取了向文本后添加 1-20 的英文基数词（one two three……，到了 20 再从 1 开始，不断循环）的方法。
不过，上面两种方法可能会引起混淆，开发人员可能难以区分这些文本是伪本地化添加的，还是原本就存在于文本中的。因此，又出现了一些新的一些扩展文本的方式。一种选择是重复书写元音，例如：
原文：find Help Online（在线寻求帮助）
原来方式：[ƒîกี้ð Ĥéļþ Öกี้ļîกี้é one two]
重复元音：[ƒîîîกี้ð Ĥéééļþ ÖÖÖกี้ļîîîกี้ééé]
这样一来，文本长度没有显著变化，但引起混淆的可能降低了。
至于字符串分割，可以通过添加分隔符的方式来判断，常见的做法是将文本用 [] 包裹起来，如 [Turn off the power,][Sit back and relax.]
此外，如果伪本地化后文本仍以源语言环境显示，则表明可能是硬编码字符串，尚未外部化到资源文件中。
为了模拟不同语言的书写方向，在伪本地化过程中，可以选择将原始语言更换书写方向。下图展示了将英语从右往左书写的效果：
上面介绍的替换字符能解决与英文类似的字母文字的问题，那中日韩（CJK）等东亚字符呢？
对此，一些软件采取了直接在原文后添加中日韩（CJK）字符的方法。下图展示了 Windows Phone 的东亚伪本地化方式。
而为了更轻松地识别字符串，可以采用添加唯一标识符的做法以标识字符串。
如 [1Dw2L][Čômрµτ℮ř !]
微软是这么解释的：
添加唯一标识符，以便您可以轻松地在源中定位资源。标识符可以是资源标识符的哈希值，也可以是其它一些用于唯一标识资源的数据。
（在 Windows 中这一标识符被称为“Hash ID”，而在 Windows 的伪本地化构建中会包含一个“Hash ID Spy”应用程序，可以查询标识符所对应的字符串等信息。）
对于伪本地化的意义，维基百科是这样解释的：
传统上，软件本地化独立于软件开发过程。在典型情况下，软件将以一种基本语言（例如英语）构建和测试，并将任何可本地化的元素提取到外部资源中。这些资源被交给本地化团队，以翻译成不同的目标语言。这种方法的问题在于，许多细微的软件错误可能会在本地化过程中发现，但那时修复它们为时已晚（或更可能是成本太高）。
针对一些已然成熟且多数的目标语言翻译已经可以获取的软件而言，或是仅会有少量界面变更的软件，直接将翻译套用至该软件并进行多个语言的测试，可能是最直接且最好的测试方式。而针对一些新开发的软件，或是将会有庞大的界面变更的软件，等待翻译完毕之后再进行界面测试，则可能因此延迟了整个测试的进程。并且，在软件开发的初期也不见得会开始进行界面文字的翻译，因为界面有很大的几率会被调整甚至重新设计。若要等到产品比较成熟后，开始进行界面翻译，然后才进行翻译的界面测试，产品的上市时程将可能因此被延误。在这样的状况之下，伪本地化将会是最佳的选择，原因之一是无需进行真正的翻译。
也就是说，很多时候软件开发与本地化是分离的，如果本地化团队在本地化过程中发现了显示存在问题，就得联系开发团队修改代码，开发团队修改代码再返回本地化团队，这样一来一回很容易影响开发效率。（见下图）
而且，如果需要本地化成多种目标语言，而每种语言都存在相同的问题，那么问题数量将成倍增加，修复难度也将直线上升，这会是一件非常可怕的事情。
而通过伪本地化，开发团队就可以在正式的本地化开始之前就找出潜在的本地化问题，有效减少了本地化过程中出现问题的概率。
同时，伪本地化可以帮助开发人员无需实际进行真正的翻译，就可了解产品在翻译后的界面外观。
你可以把伪本地化看作是定期去看牙医。这样你就能尽早发现潜在的蛀牙，避免严重的治疗。
但是，如果你等到牙痛发作时才去治疗，你将不得不忍受巨大的痛苦。除了浪费时间和金钱进行更复杂的治疗外，你还需要……
开发人员在开发或调试产品时，甚至可以直接将伪本地化作为默认语言环境，这有助于他们将本地化视为优先事项而不是事后考虑，并让他们有机会在设计阶段，或在本地化开始之前解决问题。
正如微软前软件开发人员 Michael S. Kaplan 所说，
实际上，我们用伪本地化构建了很多 Windows，并将它们「本地化」为英语！
伪本地化就像一个热心、勤奋但天真的实习本地化人员，他（她）将「翻译」每一个字符串，并且可以找到我们从来没有希望在每种语言中都有相同覆盖率的问题——而且比我们以前任何时候都要快。
尽管伪本地化并不被视为一门真正的语言，但它仍拥有自己的语言环境。国际统一码部件（International Components for Unicode，缩写 ICU）提供了两个伪本地化语言环境名称：
许多软件和操作系统都有提供这两个语言环境，下图展示了安卓系统的两个伪本地化语言环境显示效果（需要开启安卓的「开发者模式」）：
而微软拥有一套自己的伪本地化语言环境：
| 伪本地化环境 | 语言环境名称 |
|---|---|
| 基本 | qps-ploc |
| 镜像（RTL） | qps-plocm |
| 东亚语言 | qps-ploca |
Windows 10 又新增了 qps-Latn-x-sh 伪本地化语言环境。
这些语言环境可以在 Windows 中启用，具体方法可见 使用伪本地化测试应用 - Microsoft Learn 以及 使用伪本地化环境进行本地化测试 - Microsoft Learn
（关于 Windows 伪本地化的历史和更多细节，可参见 Windows 伪本地化简史）
在中文维基百科的「伪本地化」词条上有这样一段话：
近年来，随着机器翻译技术的进步，借由机器翻译也可达到与伪本地化相当的效果。
早些时候使用伪本地化确实是考虑到开发人员可能不了解其它语言，而现在随着机器翻译的成熟，开发人员也可以直接选择机翻原文来查看本地化效果。那么，如今「伪本地化」是否还有必要呢？
在我看来还是有必要的，原因如下：
这也是直到现在，伪本地化仍然是测试本地化的一种重要方式，被许多公司所采用，经久不衰的其中一些原因。
> 关注 少数派公众号，解锁全新阅读体验 📰
> 实用、好用的 正版软件，少数派为你呈现 🚀
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。