5.5 国际化与本地化

概述与动机

国际化（i18n）是这样一项工程工作：构建软件，使其能够在不修改代码的情况下适配任何语言、地区和文化。本地化（l10n）是随之而来的工作：通过翻译文本、格式化日期和数字、调整布局，以及考虑文化期望，把一个产品真正适配到某个特定的语言区域。这两者是不同的。国际化只做一次，在架构层面完成。本地化则要做很多次，在内容层面完成。前期把架构做对，每一次本地化都会很便宜。做错了，每一次都会变成一次痛苦、易出错的返工改造。

对大型团队而言，i18n 是一项基础性的架构决策。它触及每一层：数据存储、字符串处理、布局和内容流水线。如果你不早早确立它、并通过共享库和代码检查规则来强制执行，团队就会硬编码英文字符串、拼接已翻译的片段，并假定文本使用拉丁字母。在产品能够进入任何新市场之前，这笔债务都必须被清理干净。一个共享的 i18n 框架和本地化工作流，能让数十个团队以多种语言发布同一个产品，而不必各自重新发明这套底层管道。

企业和政府场景与此直接相关。跨国企业必须为跨越众多国家、语言和监管体制的客户及员工提供服务。政府必须为语言多样化的人口提供服务。许多国家官方上是多语种的，许多国家在法律上被要求以多种语言提供服务，包括从右到左书写的文字，以及原住民或少数族裔语言。对公共服务而言，语言可及性是一个公平和法律问题：一个无法阅读唯一可用语言的公民，实际上就被剥夺了该项服务。

关键原则

架构层面的国际化只做一次；内容层面的本地化要做很多次。
绝不要硬编码面向用户的文本；把所有字符串外部化到受管理的资源中。
在任何地方都使用 Unicode（UTF-8）；假定文本可能使用任何文字系统。
绝不要拼接已翻译的片段；不同语言的语法和词序各不相同。
要为文本膨胀、从右到左书写的文字，以及复杂的复数和性别规则做好规划。
按照语言区域、而不是按照代码来格式化日期、数字、货币和姓名。
把可翻译内容与代码分离，使译者永远不需要接触源代码。
本地化是文化层面的事情，不仅仅是语言层面的：颜色、图像和示例都很重要。

建议

构建一套健全的国际化架构

从头到尾（数据库、API 和用户界面）都以 Unicode（UTF-8）存储和处理所有文本，从而使任何文字系统都能被表示出来。把每一个面向用户的字符串外部化到资源文件或按标识符索引的消息目录中，绝不要嵌入代码或标记之中。把一个语言区域表示为语言加地区（在需要时再加上文字系统），这样你就能区分，比如说，同一种语言在不同国家的变体。把格式化逻辑保留在一个经过充分测试的国际化库中，而不是自己手工编写日期、数字和货币的格式化代码。把数据以中立、无歧义的形式存储（UTC 时间戳、ISO 国家和货币代码、基本单位），只在展示层进行格式化。

正确处理语言的复杂性

不要假定文本长度；要预留充裕的空间，因为译文通常比英文长得多，并设计能够重新排布、而不是截断或重叠的布局。通过使用逻辑属性、而不是物理属性来定义布局，并在合适的地方镜像界面，从而支持双向（从右到左）书写的文字。通过你的 i18n 库使用该语言区域的复数规则（不同语言的复数形式从一种到六种不等），而不是使用简单的单复数逻辑。在语言要求的地方，处理性别和语法一致性。绝不要通过拼接来构建句子；要使用完整的、带参数的消息模板，让译者能够掌控词序。

建立本地化工作流和翻译管理

把本地化当作一条持续运行的流水线，而不是发布前的一批集中工作。自动提取字符串，把它们推送到一个翻译管理系统，再把完成的翻译拉取回来，理想情况下与 CI 集成，使新字符串能被自动标记出来，本地化版本也能保持同步。为译者提供上下文：截图、描述、字符数限制，以及每种语言各自的词汇表和风格指南，以保持术语和语气的一致性。使用翻译记忆库来复用先前的工作，从而降低成本。要有意识地决定在哪些地方可以接受机器翻译（低风险、大批量的内容），在哪些地方必须要求人工翻译和审校（法律、医疗、安全、品牌相关的关键内容）。要尽早进行伪本地化，用加长、带重音符号的占位符替换字符串，从而在真正的翻译开始之前，捕获硬编码字符串、截断和编码方面的 bug。

不只是翻译文字，还要本地化格式、文化和内容

按语言区域格式化日期、时间、数字、货币、地址、电话号码和姓名，尊重当地的惯例（日期顺序、小数点和千位分隔符、货币符号位置、姓名顺序）。要让图像、图标、颜色、示例和隐喻适配当地的文化含义，因为符号和颜色在不同文化中承载着不同的寓意。要考虑当地法律和监管内容方面的差异。要把全球一致性（品牌、核心功能）与区域适配（内容、示例、合规性）区分开来，并明确决定哪些元素是固定的，哪些是可以灵活调整的。

把 i18n 作为共享基础设施来治理

提供一个共享的 i18n 库、拒绝硬编码字符串的代码检查规则，以及一套标准的语言区域解析机制，从而使团队不会意外地硬编码文本。要确立本地化流水线和词汇表的所有权归属。要在 CI 中对多个语言区域进行测试，包括一个从右到左的语言区域和一个长文本伪语言区域，从而自动捕获回归问题。

权衡：优点与缺点

决策	优点	缺点
从第一天起就进行国际化	日后进入市场成本低，无需返工改造	即便还不需要第二个语言区域，也要承担前期成本
日后再补做 i18n	如果全球化需求不确定，可以延后成本	清理硬编码假设的成本高昂，风险也高
人工翻译	质量高，贴合文化	更慢、成本更高
机器翻译	快速、廉价，能扩展到极大的量	存在质量和准确性风险；不适合高风险内容
持续本地化流水线	各语言区域保持同步，不会在发布前手忙脚乱	需要投入工具和流程建设
针对各地区进行深度文化适配	更贴合当地、更受信任	需要构建和维护更多内容变体

关键的权衡在于何时投资国际化。把 i18n 补做进一个充斥着硬编码、拼接、假定拉丁字母的代码的产品之中，是偿还起来代价最高的一种技术债务之一。对于任何有可能走向国际化或多语言的组织而言（）这基本上包括了所有大型企业和多语种政府（）尽早对架构进行国际化，远比日后补做要便宜得多，尽管回报会延后到来。

与团队讨论的问题

我们是否用代码检查规则强制执行字符串外部化，伪本地化是否在真正的翻译开始之前就已在 CI 中运行？ 让国际化变得昂贵的那笔债务（硬编码的英文字符串、拼接的句子片段、假定拉丁字母的代码），会在无人察觉的情况下不断积累，除非有工具在提交时就把它拦下来。标记出硬编码用户文本的代码检查规则，加上在 CI 中运行的带重音符号的长文本伪语言区域，能在截断、重叠和编码 bug 还容易修复的时候就把它们捕获出来。这正是让数十个团队能够以多种语言发布同一个产品，而不必各自重新发明底层管道、或在日后的截止日期压力下清理各种假设的关键。请带上一次对硬编码字符串的搜索结果，问一问今天是否有任何团队可能意外地发布出这样的字符串。如果流水线中没有任何环节能捕获到它，那就是首先要弥补的缺口。
我们把权威数据存储在哪里，格式化工作是否被限定在展示层？ 把时间戳存储为 UTC、把国家和货币存储为 ISO 代码、把金额存储为基本单位，意味着任何语言区域都能在边缘正确地格式化它们，而如果格式化逻辑被嵌入到数据层中，就会产生难以清理的 bug。要达成一致：日期、数字、货币、地址和姓名只在展示层通过一个经过充分测试的库来格式化，而不是靠手工编写的代码。这一点对跨国企业和多语种政府都很重要，因为公民必须能以他们自己的惯例，看到正确的日期顺序、小数点分隔符和姓名顺序。请带上一个你们系统中已经以某种格式存储的值的例子，追溯当一个新的语言区域需要不同的格式时会出现什么故障。如果数据和展示是纠缠在一起的，就要在添加更多语言区域之前，决定如何把它们解开。
机器翻译究竟在哪些地方是可以接受的，我们的本地化流水线如何保持持续运行，而不是分批处理？ 机器翻译对低风险、大批量的内容来说既快又便宜，但不适合法律、医疗、安全或品牌相关的关键文本，因为在那些地方，一次误译会造成真实的损害，因此这条边界需要成为一项明确的政策，而不是由各团队自行猜测。同样，把本地化当作发布前的一批集中工作，必然会导致翻译方面的手忙脚乱，而自动提取字符串并通过翻译管理系统同步，能让每个语言区域都保持最新。要决定谁拥有这条流水线、这些词汇表，以及针对高风险字符串的人工审校关卡。请带上最近的一次发布，问一问它的新字符串花了多长时间才出现在每一种语言中。如果各语言区域在发布之间逐渐脱节，说明你们的流水线其实是变相的批处理。
我们是否自动测试一个从右到左的语言区域和一个长文本伪语言区域，还是我们在默默地假定拉丁字母和英文长度的布局？ 双向（从右到左）支持和文本膨胀，是在一个新市场中最明显会崩溃的假设：从未被镜像过的镜像界面，以及一旦德语或芬兰语比英语长出百分之四十就会被截断的按钮。与之相抗衡的因素是速度，因为基于逻辑而非物理的布局属性进行构建、并把一个带重音符号的伪语言区域接入持续集成（CI），需要在任何真实客户需要之前就投入精力。请带上你们最常用界面在一个从右到左的语言区域和一个加长的伪语言区域中渲染出来的截图，数一数有多少重叠、被截断的标签和卡住的箭头。对于一个跨国企业、或一个依法必须服务从右到左文字或少数族裔语言的政府机构而言，一个无法镜像的布局不是一个外观上的小缺陷，而是一个如果不重建就无法满足的市场或法定义务。
产品的哪些部分在全球是固定不变的，哪些会因地区而灵活调整，谁有权做出这个决定？ 本地化是文化层面的事情，而不仅仅是语言层面的，因此颜色、图像、示例、敬语，甚至提供哪些功能，都可能因市场而异，然而你允许的每一个区域变体，都是又一个需要永久构建、翻译、审校和维护的制品。这里的张力在于本地贴合度（能建立信任和促成转化）与一致性（能保持品牌连贯、维护负担有界）之间。请带上一份具体的清单，列出一个拟议的新语言区域除了翻译字符串之外还会改变什么，并为每个变体的持续维护定价，而不只是它的初次构建。在一个大型企业中，这项决策需要一个明确指定的负责人，以免区域团队随意地对产品进行分叉；在政府中，它必须尊重因司法管辖区而异、且不可协商的法律和无障碍内容规则。
我们究竟承诺支持哪些语言区域，我们如何在这些区域之间保持术语一致，是什么证据支撑着这份清单？ 添加一种语言，承诺起来容易，维持起来昂贵，因为每一种语言都需要一份词汇表、一份风格指南、针对高风险字符串的人工审校，以及大多数语言中都会被简单单复数逻辑弄错的正确复数和性别处理。相互竞争的考量是覆盖范围与成本之间的权衡：一个服务质量很差的市场或人群，可能比完全不服务还要糟糕。请带上每个候选语言区域背后的人口或营收规模、你们的库为其提供的复数规则和格式化覆盖程度，以及谁拥有它的词汇表。对跨国企业而言，驱动因素是可触达市场和每种语言的支持成本；对政府而言，则是法律上的语言可及性义务和公平性，以只能用该语言办理业务的居民数量来量化。

行业视角

初创企业。 在第一天就做出那些成本低廉的架构选择，然后就此打住：从头到尾都用 UTF-8，每一个面向用户的字符串都放进消息目录，日期、数字和货币都通过一个具备语言区域感知能力的库来格式化。当你只以一种语言发布产品时，这些选择几乎不花什么成本，却能在你的第一个大客户想要第二种语言时，省下一次重写。不要在还没有人为此付费之前，就搭建一条翻译流水线或支持语言区域；把门开着就好，不必把整栋房子都装修好。

小型企业。 没有国际化专家，预算也紧张，应当依靠你所用框架中已有的 i18n 功能，以及一项托管的翻译管理服务，而不是自己去构建流水线。对低风险、大批量的内容使用机器翻译，只在一处错误会让你失去客户或违反规则的地方（例如法律、安全或账单相关的文本）才为人工翻译付费。只有当一个特定市场明显能够支撑起持续的翻译和审校成本时，才承诺支持某个语言区域。

企业。 问题在于跨众多团队的治理：一个共享的 i18n 库、拒绝硬编码字符串的代码检查规则、一条带有翻译记忆库和各语言词汇表的持续本地化流水线，以及包含一个从右到左语言区域和一个长文本伪语言区域的多语言区域 CI 测试。要把本地化作为共享基础设施来运行，并设有明确的负责人，从而让各团队不再重新发明底层管道，也不再各自脱节。要衡量语言覆盖率、本地化质量，以及推出一个新语言区域所需的时间，并依据这些数字来管理语言区域组合，而不是随意地推出新市场。

政府。 语言可及性往往是一项法律义务，涵盖官方语言、从右到左的文字，以及原住民或少数族裔语言，因此透明度和公平性塑造着每一个选择。要跨机构构建一个共享的 i18n 框架和翻译工作流，对法律和安全相关的术语要求人工审校，并公开发布词汇表，使各项服务之间的术语保持一致。采购环节应当在合同中要求语言区域、从右到左和无障碍支持，而每种语言所服务的人口数量，正是向公众证明这笔开支合理性的指标。

示例

初创企业。 一家只以英语发布产品的小型初创企业，依然在第一天就做出了几个成本低廉的架构选择：处处使用 UTF-8，每一个面向用户的字符串都被拉进消息目录、而不是硬编码，日期和货币都通过一个具备语言区域感知能力的库来格式化。在他们只有一种语言的那段时间里，这几乎没有花费任何成本。一年后，当他们最大的潜在客户要求提供法语和德语版本时，添加这些语言区域基本上只是一项交给承包商的翻译工作，而不是一次重写，他们在几周之内就拿下了这笔交易，而不是把它推迟一个季度的工程工作量。

企业。 一家全球性的电子商务公司很早就对其平台进行了国际化：全程使用 UTF-8、外部化字符串、一个具备语言区域感知能力的格式化库，以及一条带有翻译记忆库和各语言词汇表的持续本地化流水线。进入一个新市场基本上变成了一项内容工作（翻译、审校、调整图像），而不是一个工程项目，这让公司能够在几周之内就在新的语言区域上线。建立在逻辑布局属性之上的从右到左支持，意味着阿拉伯语和希伯来语市场几乎不需要新的界面开发工作。

政府。 一个依法必须以多种官方语言（包括一种从右到左的文字和一些少数族裔语言）提供服务的国家政府，构建了一个跨机构使用的共享 i18n 框架和翻译工作流。CI 中的伪本地化在发布之前就捕获了硬编码字符串和截断问题；一份共享的词汇表让法律术语在各项服务和各种语言之间保持一致。公民能够以自己的语言、并以正确的日期、数字和姓名格式，完成税务、医疗和福利相关的业务，这既满足了语言可及性法律，也提升了非主流语言使用者的公平性。

商业论证：动机、投资回报率与总拥有成本

国际化的投资回报，体现在市场准入和速度上。一个经过良好国际化的产品，能够快速、低成本地进入新的国家和语言市场，让每一个新的语言区域都变成增量的营收或公民触达，而不是一个大型项目。本地化质量驱动着每个市场中的转化率、信任度和支持成本：当产品能够正确地讲用户的语言、并尊重他们的惯例时，用户交易更多，联系支持的次数也更少。

在总拥有成本方面，采纳这种做法的成本，是前期的国际化工程投入，加上持续的翻译和流水线成本。不采纳的成本，则是昂贵的返工改造：在整个代码库中清理硬编码字符串、拼接逻辑、编码 bug 和布局假设，而且往往还要赶一个由市场或法律要求驱动的截止日期。糟糕的本地化也带来隐藏成本：服务质量差的市场中损失的销售额、因格式混乱而产生的支持负担，以及因高风险内容误译而造成的法律或声誉损害。持续本地化能避免代价高昂的发布前翻译手忙脚乱。

要向领导层证明这件事的合理性，就要把国际化描述为一份针对未来市场的期权。它是一笔适度的前期投资，能大幅降低未来每一次进入新市场的成本和时间。对政府而言，驱动因素是法律上的语言可及性义务和公平性，以每种语言所服务的人口数量来量化。

反模式与陷阱

硬编码字符串： 用户文本被固化在代码中，迫使每个语言区域都要修改代码。
字符串拼接： 用片段拼凑句子，破坏语法和词序。
非 Unicode 假设： 编码 bug、乱码（因字符编码不匹配而产生的混乱文本），以及无法表示某些文字系统。
假定英文文本长度： 翻译之后会截断或重叠的布局。
忽视从右到左的支持： 使用无法镜像的物理左/右布局。
简单化的复数处理： 在大多数语言中都是错误的单复数逻辑。
不考虑语言区域的格式化： 硬编码的日期、数字和货币格式。
在没有上下文的情况下翻译： 译者靠猜测含义，产生错误。
批量的、最后一刻才做的本地化： 发布前的手忙脚乱，而不是一条持续运行的流水线。
文化上的迟钝： 在当地会冒犯或令人困惑的图像、颜色或示例。

成熟度模型

第 1 级：启动。 单一语言、硬编码字符串、非 Unicode 假设，以及通过拼接构建的文本。国际化是被动式的：任何新的语言区域都意味着修改代码，编码和布局方面的 bug 都是在生产环境中被意外发现的。

第 2 级：发展。 一些字符串已被外部化，Unicode 也在部分地方被使用，但这种做法在各团队之间并不一致。本地化是一项手动的、批量的、发布前的工作，格式化、复数处理和从右到左支持在不同团队之间的处理方式各不相同（甚至根本没有处理）。

第 3 级：标准化。 一个共享的 i18n 架构和一个具备语言区域感知能力的格式化库，是被记录下来、并在全组织范围内强制执行的标准。字符串外部化由代码检查规则来检验，一个翻译管理系统和持续流水线已经就位，配有词汇表和翻译记忆库，伪本地化加上多语言区域测试（包括一个从右到左语言区域和一个长文本语言区域）在 CI 中运行。

第 4 级：管理。 本地化项目被对照基线进行度量和控制。团队跟踪语言覆盖率、本地化质量和缺陷率、从提交到已翻译版本发布之间的字符串同步延迟、每次发布中捕获的截断和从右到左渲染缺陷、每个语言区域的翻译成本，以及推出一个新语言区域所需的时间，这些指标决定了发布是否放行，并指引着人工审校与机器翻译之间的投资分配。

第 5 级：协同。 国际化和本地化在整个组织范围内被持续改进和整合。本地化是持续进行的，机器翻译和人工翻译按内容类别被有意识地选择，文化适配是系统性的。组织依据市场和公平性方面的证据，增加、退役和重新界定语言区域的范围，新的语言区域能够快速、高质量地上线，而不需要返工改造。

讨论思路

如果国际市场需求尚不确定，一个产品应当多早开始国际化？
机器翻译在哪些地方是可以接受的，哪些地方必须要求人工审校？
你们如何在众多语言和团队之间保持术语的一致性？
多少区域文化适配才值得为其增加的变体维护成本买单？
从右到左和少数族裔语言支持应当如何被优先排序和测试？
你们如何在不拖慢流水线的情况下，为译者提供足够的上下文？

关键要点

架构层面的国际化只做一次；内容层面的本地化要做很多次。
在任何地方都使用 Unicode，外部化所有字符串，绝不拼接译文。
为文本膨胀、从右到左的文字，以及特定语言区域的复数和格式化规则做好规划。
用翻译记忆库、词汇表和上下文来运行一条持续的本地化流水线。
尽早在 CI 中进行伪本地化，在真正的翻译开始之前捕获 i18n 方面的 bug。
本地化是文化层面的事情，不仅仅是语言层面的。
尽早进行国际化远比日后补做便宜得多；对政府而言，这还是一项法律上的公平要求。

参考文献与延伸阅读

The Unicode Consortium, The Unicode Standard and Common Locale Data Repository (CLDR)
W3C Internationalization (i18n) Activity, techniques and best practices
Richard Ishida, W3C internationalization articles and tutorials
Bert Esselink, A Practical Guide to Localization
John Yunker, Beyond Borders: Web Globalization Strategies
Unicode Technical Standard #35 (locale data markup) and ICU library documentation
IETF BCP 47 language tags
Government multilingual service and language-access guidance
Nielsen Norman Group and W3C articles on RTL, text expansion, and localization UX