i18n 和 l10n：有什么区别？

就像 In-N-Out 汉堡著名的*秘密*菜单一样，每个行业细分领域都有其秘密语言，一旦你掌握了它，你就会觉得自己是某个特殊群体的一员。 翻译和本地化行业也不例外。 与我们的数学界朋友相比，我们这个行业总是有点自卑情结，所以我们决定在关键词中间塞入数字： i18n 和 l10n。

听起来很专业，也很吓人，对吧？

原来它只是 国际化 和本地化的简称。

国际化，或称 i18n （发音为“eye-eighteen-en”），指的是使软件能够在任何语言中运行的工程工作。 它通过从代码中提取文本字符串、处理字符编码以及构建灵活的日期、货币和单位格式来实现这一点。 i18n 是为本地化 (l10n) 所做的技术性幕后工作，本地化工作是针对每个地区、每个市场单独进行的。

我看到的大多数解释页面都有些混乱，因为它们把 i18n 和 l10n 当作同一任务的两种形式，然后在文章的其余部分讨论代码库。 这不是同一项任务。 国际化是你的工程团队要做的事情，希望只需要做一次！ 另一方面，本地化是指每次您添加市场时网站都会发生的情况，它决定了多语言访问者在访问时是否感到受欢迎，或者他们是否感觉自己进入了恐怖谷，即有些地方不对劲，但他们就是说不上来。

这种区别不仅仅是我吹毛求疵（当然，这确实是吹毛求疵，但对于 从事 本地化的团队来说，这种区别至关重要！） 一个网站即使完全国际化，在目标语言中仍然可能显得“不尽如人意”。 您的团队精心设计了可展开以适应德语文本的按钮、带有正确货币符号的价格标签以及以读者熟悉的格式显示的日期戳。 那是 i18n！ 但是按钮旁边的那句话呢？ 这篇文章听起来像是了解市场的人写的，还是用翻译软件处理后直接发布上去的？ 这就是本地化的作用，也是决定访客是点击进入还是点击离开的关键因素。

i18n 的真正含义

我以前说过，但值得再说一遍（双关语）：国际化是一个数字词。 取第一个字母（i）和最后一个字母（n），数一数它们之间有多少个字母（ 18 ），瞧，就得到 i18n。 这种简写方式之所以流传下来，是因为开发人员希望在代码审查中无需拼写五十次就能输入该单词。 因此， l10n 代表本地化， a11y 代表可访问性，等等。

但缩写部分才是最无聊的地方。 重要的是 i18n 实际能做什么。

这是指对代码库进行结构化改造，使其无需重写即可支持任何语言或区域设置的过程：

• 将代码中的文本字符串提取到外部文件中，而不是硬编码。
• UTF-8 编码，因此带重音符号的字符和非拉丁文字都能正确显示。
• 不假定文本总是从左到右阅读的布局
• 日期、数字和货币格式被视为变量，而不是固定假设。

如果做得好， i18n 课程就像水对金鱼一样，隐形且不引人注意（这是最好的方式）。

l10n：永无止境的部分

如果 i18n 代表汽车，那么 l10n 代表燃料。 决定添加法语时，你需要进行本地化。 添加日语后，需要再次进行本地化。 这不是你完成的一个阶段，而是一个重复的过程，这就是为什么本地化需要自己的工作流程、负责人和工具集，并与工程分开。

一个团队可以发布一款真正国际化的产品，但在本地化方面仍然可能做得不够好，因为 本地化不仅仅是替换文字。 它还可以包含习语和正式语体，以及图像替换，甚至细微的颜色变化！

差异在实时页面上的体现位置

格式问题是了解 i18n 和 l10n 分别运行的最简单方法。

以数字为例。 美国将一千美元五十分写成 1,000.50。 欧洲大部分地区将 1.000,50 写成相同的值，只是将逗号和句号互换了。 货币栏显示美元金额为 99.00 美元，德国货币金额为 99,00 欧元，符号分别位于两侧。 日期进一步细分。 03/04/2026 这意味着在美国是 3 月 4th 日，在其他地方几乎是 4 月 3rd 日，这就是 ISO 8601 (YYYY-MM-DD) 存在的原因，为了避免歧义，而不是逐个国家地争论这个问题。 语言代码也遵循标准：ISO 639-1 分配了 de、ja 和 pt 等双字母代码，因此区域设置系统有一个稳定的标识符可以依据，而不是根据国家/地区名称进行猜测。

文本扩展是工程团队最容易低估的功能之一。 Phrase 自身的 i18n 文档 以鞋码为例：英国尺码 10 相当于欧洲尺码 38，美国尺码 38 则完全相当于欧盟尺码 6。 现在，如果以同样的方式翻译 UI 标签，就会出现同样的单词长度不匹配问题。 德语和芬兰语文本通常比英语原文长 20 % 到 35 %，这就是为什么标有“提交”的按钮可以正常显示，而“Zur Kasse gehen”却不行，除非布局是用灵活的容器构建的。 阿拉伯语和希伯来语作为从右到左（RTL）的语言，带来了一个完全不同的问题：整个布局都是镜像的，而不仅仅是文本方向。

这些问题在翻译阶段都无法得到充分解决。 这个问题应该在代码中解决，因此我才力主在开始学习 l10n 之前先把 i18n 做好。

工作流程：在坚实的基础上建造房屋

在健康的架构中，国际化只需进行一次，本地化就可以在其基础上无限重复进行。 您只需一次提取字符串、设置编码并构建灵活的布局。 然后将其本地化为法语。 之后，你需要将其本地化为日语。 后来又增加了阿拉伯语，而无需再次修改底层架构，因为该架构从一开始就是为了处理任何语言环境而设计的。

导致团队失败的原因在于跳过了第一步，试图在第二步中修补问题。 这时就会出现硬编码字符串被埋在三层组件深处，以及只能理解 MM/DD/YYYY 格式的日期选择器。 最终，翻译项目演变成了一场谁也没预料到的重构。

我们需要重建我们的技术栈吗？

我旁听过足够多的销售电话会议，知道大多数团队都在担心什么：“为了做好这件事，我们是否必须重建我们的技术栈？” 这里的假设是，如果他们的网站从一开始就没有国际化，那么正确本地化就意味着彻底推倒重来。大多数情况下，答案是否定的。

如果本地化层运行在现有网站之上而不是在其代码库内部，则无需重新构建。 我在这里稍微透露一下，但这正是 Bablic 运作方式。 大多数情况下，一个轻量级的 JavaScript 代码片段会在访问者的浏览器中运行，并在请求时将翻译后的文本替换为正确的语言环境，而无需抓取或重建源站点（页面实际所在的原始服务器）。

通常随之而来的性能问题是，浏览器端方法意味着每次页面浏览时都要加载整个翻译语料库。 如果您确实担心这个问题，那么请选择提供预翻译缓存的工具，该工具可以存储以前翻译过的文本，这样浏览器就不必在每次请求时都重新调用翻译 API。

现在你可能会说，“但是我的产品是一个原生应用程序，具有深度嵌套的条件逻辑，并且字符串和代码之间没有分离”……等等等等。 嗯，这可是个工程问题，浏览器端解决不了！ 在这种情况下，请寻找带有 SDK 的解决方案。 但对于营销网站和电子商务商店而言，页面最初是用一种语言构建的，现在需要服务于五个市场，因此重新架构的假设通常是错误的。

不要脱离上下文进行翻译。

一个页面可能通过了所有 i18n 项检查（货币正确，日期格式正确），但对于它应该与之对话的人来说，仍然明显是外语。 客户能够分辨出信息是否切题或略有错误，而注意到这一点的人就不会进行转化。 这就是我之前提到的恐怖谷效应，它可是转化率的真正杀手。

理解并重视语境有助于解决这个问题。 首先，通过控制特定术语（例如您的品牌名称和产品专有名词），您可以确保关键短语每次都以相同的方式呈现，而无需考虑机器翻译引擎的默认设置。 使用词汇表可以让你锁定这些决定，从而使翻译后的页面听起来像你的品牌，而不是面向任何特定对象的通用版本。

第二点是能够直接查看翻译后的页面并就地纠正错误，而无需精通目标语言就能发现不恰当的短语。 上下文编辑器会实时显示翻译后的页面，并允许您直接编辑，这意味着讲西班牙语的同事可以在几分钟内检查输出结果，而无需翻译人员从电子表格中重新翻译整个内容。

对于大多数页面而言，机器翻译（MT）是一个合理的起点。 Bablic的默认引擎是 Google Translate 和 DeepL，它们处理初稿的速度是任何人类团队都无法企及的。 对于我们接触的大多数企业来说，这些引擎，再加上词汇表和上下文编辑器的抽查，就足以让企业感觉自己的网站真正实现了本地化。

常问问题