WordPress 中的翻译词汇表与术语一致性
打开一个 WooCommerce 商店的德语版本，观察“购物车”（Cart）这个词在界面中是如何变化的。页眉按钮显示 Warenkorb。结账页面显示 Einkaufswagen。确认邮件中又写着 Korb。从技术上讲，这三个词都是德语中购物车的有效表达，按文件逐个翻译的人工译员可能会使用其中任何一个。但浏览网站的顾客看到的并非是三个同义词。他们看到的是一个无法保持自身词汇一致性的网站，在电子商务网站上，这种不一致在您要求输入信用卡信息时，就显得尤于漫不经心。
这就是翻译词汇表解决的问题。词汇表，有时也称为术语库，是规定特定术语在每种语言中如何呈现、哪些术语绝不能翻译以及哪些术语每次都必须以相同方式翻译的权威列表。本指南将解释词汇表的概念、最重要的两类术语、为什么将大文件分成小块会悄然破坏一致性，以及如何通过一个在不同文件块中维护词汇表的翻译流程来解决这个问题。
什么是翻译词汇表
翻译词汇表是一种结构化的映射，将源术语与其批准的译文对应起来，并按语言进行维护。最简单地说，它是一个表格：包含源术语、所需的译文以及关于它是否锁定或可翻译的备注。译员和翻译引擎会将其作为单一的事实来源，以确保同一个概念永远不会以两种不同的方式呈现。
一个小的词汇表片段在 JSON 中可能看起来像这样：
{
"en": "Cart",
"translations": {
"de": "Warenkorb",
"es": "Carrito",
"fr": "Panier"
},
"translatable": true
},
{
"en": "Acme Pro",
"translations": {},
"translatable": false,
"note": "Brand product name. Never translate."
}
或者，如果您的团队更喜欢扁平的电子表格，相同的数据以 CSV 格式表示：
source,de,es,fr,translatable
Cart,Warenkorb,Carrito,Panier,yes
Checkout,Kasse,Pagar,Commander,yes
Acme Pro,,,,no
Add to Cart,In den Warenkorb,Añadir al carrito,Ajouter au panier,yes
词汇表同时完成两项工作。对于可翻译的术语，它强制执行一种经批准的译文。对于不可翻译的术语，它充当一个禁止触碰的列表。
格式本身几乎无关紧要。JSON、CSV、电子表格或简单的键值文件都可以，因为词汇表的价值不在于其文件扩展名，而在于它作为商定参考的作用。重要的是它存在，它是唯一的权威副本，并且无论是什么在翻译您的字符串，都确实会查阅它。一个放在共享驱动器中但翻译过程从未读取过的词汇表只是一份文档。一个在每个字符串上都由流程强制执行的词汇表，则是一项质量保证。
大多数团队是在首次在生产环境中因不一致性而感到尴尬之后，才被动地开始建立词汇表。更好的方法是在第一次翻译之前就植入明显的条目：您的产品名称、前二十个界面术语，以及任何如果选择错误会导致客户困惑的行业词汇。二十个精心选择的条目可以防止绝大多数的一致性问题。
没有词汇表就容易出错的两类术语
哪些术语实际需要词汇表控制？有两类，它们会以相反的方式出现问题。
绝不能翻译的品牌术语
产品名称、品牌名称、功能名称和商标在翻译时应完全保持不变。当 Acme Pro 在西班牙语中变成 Acme Profesional，或者您的 QuickShip 运输功能变成 EnvíoRápido 时，您就破坏了品牌识别，而且通常会破坏代码中精确匹配该字符串的 UI。
这是最常见也是最具破坏性的词汇表失败情况。一台自行运行的机器翻译器会很“乐意”地翻译 Pro、Plus、Cloud 以及任何看起来像普通名词的词，因为它无法知道这些词是品牌的一部分。词汇表的作用就是告诉它停下来。
必须保持翻译一致的术语
相反的问题是 Warenkorb 与 Einkaufswagen 的情况。这些是应该翻译的真实词语，但必须始终以相同的方式翻译。诸如 Cart（购物车）、Checkout（结账）、Account（账户）、Wishlist（心愿单）、Order（订单）和 Shipping（配送）等界面词汇，在每个屏幕、电子邮件和按钮上都必须映射到一个固定的目标术语。这里的危险不是误译，而是漂移：每个单独正确的选择在独立来看都没有问题，但只有在整个网站上的不一致性才是缺陷。
这就是信任侵蚀问题。用户在浏览界面时会建立一个关于其界面词汇的心理模型。当词语发生变化时，这个模型就会破裂，认知摩擦表现为一种模糊的感觉，认为网站质量不高，即使顾客无法具体说明原因。
除了感受之外，一致性还有具体的可用性成本。支持文档、工具提示和入门电子邮件都引用了界面术语。如果按钮上写着 Warenkorb 而帮助文章上写着 Einkaufswagen，困惑的客户就无法将说明映射到屏幕上。不一致的术语会悄然破坏您自己的支持内容。词汇表正是让产品、文档和营销文案都在字面上“说同一种语言”的关键。
为什么大文件分块会导致不一致
以下是将一次性词汇表问题变成大型网站系统性问题的机制。一个大型 WordPress 或 WooCommerce 商店可能有一个包含数千个字符串的 .po 文件，这远远超出了任何 AI 模型在单个请求中翻译的能力。因此，文件会被分成若干块，每块单独翻译。
问题在于，当每个文件块被孤立翻译时，翻译引擎不会记住它在三个文件块之前是如何翻译某个术语的。文件块 1 可能将“Cart”翻译为 Warenkorb。文件块 7，作为一个没有共享上下文的独立请求进行处理，也可能同样合理地将同一个“Cart”翻译为 Einkaufswagen。两者单独来看都没有错。这种不一致是分块的产物，而不是任何单一错误决策的结果。
# Chunk 1 - header strings
msgid "Cart"
msgstr "Warenkorb"
# Chunk 7 - footer strings, translated in a separate request
msgid "View Cart"
msgstr "Einkaufswagen ansehen"
文件越大，分块越多，同一术语出现分歧的机会就越多。这正是为什么大型文件翻译比看起来更困难的原因，我们将在如何翻译大型 PO 文件中深入探讨这个话题。天真的分块以完整性换取一致性，在一个拥有数千个字符串的商店中，这种权衡无处不在。
词汇表感知型流程如何解决这个问题
解决方案是一个同时做两件事的翻译流程：它智能地分割大文件以便进行处理，并且在每个文件块中传递词汇表和术语上下文，这样分割就不会引入漂移。
这就是 智能分批 和 上下文感知型 AI 协同工作的地方。智能分批将一个 10MB 以上的文件分成可处理的文件块，但这些文件块不会被当作孤立的陌生人来翻译。流程会强制在文件块之间保持词汇表和术语的一致性，因此一旦“Cart”被确定为 Warenkorb，之后包含“Cart”的每个文件块都会得到相同的译文。锁定的品牌术语词汇表也随每个文件块一同传递，因此无论 Acme Pro 出现在字符串编号 5 还是字符串编号 5,000 中，它都能保持完整无缺。
实际结果是，一个包含 6,000 个字符串的商店文件返回时，拥有一个一致的词汇表，而不是东拼西凑。品牌名称保持不变。界面术语统一。同时，这些字符串内的占位符，即 %s 和 {name} 标记，也保持锁定不变。您会得到一个文件，读起来就像一位记忆力超群的细心译员一次性完成了整个翻译工作。
与此形成对比的是大多数人会退而求其次的选择：将文件分段翻译，然后手动进行查找替换来规范术语。这种方法失败有两个原因。首先，您必须已经知道所有发生漂移的术语，这意味着需要审阅数千个字符串才能首先发现不一致之处。其次，盲目地查找替换是危险的，因为同一个词在一种语境下可能是正确的，而在另一种语境下可能是错误的。在翻译过程中强制执行词汇表，当引擎仍然拥有每个字符串的完整上下文时，从根本上讲比事后修补更安全。
多站点工作流程中的词汇表
对于为多个客户网站进行本地化的代理机构来说，词汇表规范的作用会倍增。每个客户都有自己的品牌术语和批准的词汇，将一个客户的词汇表用于另一个客户必然会导致尴尬。一个可重复、词汇表驱动的工作流程是保持十几个多语言网站一致性而无需进行十几次手动审查的关键，这也是代理机构管理多个客户网站的理想本地化工作流程的核心。词汇表成为一项按客户分配的资产，伴随您为他们翻译的每个文件。
术语一致性是那种当它正确时无人察觉，而当它错误时人人都能感受到的质量信号之一。在每个屏幕上都看到 Warenkorb 的顾客从不思考这个问题。而看到购物车有三种不同说法的顾客也不会提出投诉，他们只是对网站的信任度降低了一点，转化率也随之变差了一点。词汇表，在每个文件的每个文件块中强制执行，是确保他们永远不必为此担忧的方法。
准备好让您的整个多语言商店中的每个术语都保持一致了吗？免费试用 SimplePoTranslate ——无需信用卡。免费套餐可在文件块之间强制执行词汇表和术语一致性，因此“Cart”始终是一个词，您的品牌名称从第一个字符串到最后一个字符串都保持不变。