翻译术语表 101 — 在机器翻译中锁定角色名与术语

把一部 200 行的日文视觉小说丢进 DeepL，女主角的名字出来是 Alice。再跑接下来的 200 行，就成了 Aris。下一个批次又定为 Arisu。到第四章，她已经有三个名字，取决于你读的是哪一幕。

这是机器翻译在长篇叙事游戏上最常见的失败方式——不是语法差，也不是措辞别扭，而是专有名词不一致。提供方在批次之间没有记忆；每次看到一个名字，它只是猜测最合理的罗马音。在一款 40 小时的 RPG 里，这种漂移会把一份可读的译文变成像是四个不同的人翻译出来的东西。

翻译术语表能解决这个问题。你只需定义一次源到目标的术语对——アリス → Alice、勇者 → Hero、魔王 → Demon Lord——每一个翻译批次、在每一个提供方上都会遵守它们。提供方甚至根本看不到这些术语的原始形态。这正是本文要讲的内容。

术语表究竟是什么

RuneTranslate 中的术语表是一份三列规则的列表：

• source — 要锁定的源语言子串（默认日语；任何受支持的源语言）（例如 勇者）
• target — 你希望它在输出中呈现的样子（例如 Hero）
• targetLang — 该规则适用于哪种输出语言（这样你可以用一份术语表同时覆盖英语 + 西班牙语 + 德语）

为一部典型视觉小说的角色名单添加 30 条这样的规则，你就一举消除了整整一类专有名词漂移。

占位符掩码如何工作（与提供方无关）

强制执行术语表的幼稚做法，是写一条正则表达式，在提供方运行之后把目标术语换进去。这在 DeepL 上勉强能用，但在 LLM 提供方上会失败：LLM 已经围绕它翻译的那个术语重写了句子，而你的正则替换会留下悬空的冠词和奇怪的大小写。

RuneTranslate 在术语进入提供方之前就对术语表条目进行掩码。runner 遍历每一条批处理的源字符串，把每个术语表 source 替换为一个数字占位符——[[G0]]、[[G1]] 等等。提供方看到的是无法误译的不透明标记。回来时，这些占位符被替换成你的 target 术语，然后再在其上恢复引擎标签掩码（RPG Maker 代码、KAG 标签、Ren'Py 插值）。

结果就是：无论你用的是 DeepL、OpenAI GPT-4o、Anthropic Claude 还是免费的 Google Translate，术语表条目的呈现都完全一致。同样的掩码、同样的恢复步骤、同样的最终输出。

优先级顺序 — TM 胜过术语表，术语表胜过提供方

值得了解一个翻译批次在 runner 内部是如何处理的，因为这解释了为什么编辑术语表不会消耗你的提供方额度，以及翻译记忆如何与术语表配合：

1. 翻译记忆（TM）短路。 如果你在以往任何项目中已经翻译过这条一模一样的源字符串，缓存的译文会即时给出——零提供方调用、零成本。该单元在提供方看到之前就被从批次中移除。
2. 术语表掩码 会应用到 TM 未处理的那些单元上。
3. 提供方调用 在掩码后的文本上进行。这是唯一花钱 / 计入配额的步骤。
4. 恢复 — 术语表占位符变成你的目标术语，然后在其上恢复引擎标签。
5. 写入 TM — 最终译好的一行被缓存，这样下次你再看到这段日文时，它会免费回到第 1 步。

TM 命中是最大的省钱手段。术语表是最大的省质量手段。两者叠加会产生复利：手动改一行一次，它就被缓存进 TM，而术语表让专有名词在缓存命中和全新批次上都保持一致。

TM 与术语表的交互（绕过守卫）

有一个微妙的边界情况值得了解：假如三个月前你在没有术语表的情况下翻译了 100 行包含 勇者 的文本，TM 把它们随机缓存成了 Warrior / Champion / Hero——而现在你把 勇者 → Hero 加进术语表，会怎样？

天真地看，下次你再看到 勇者 时，TM 仍会返回 Warrior——毕竟缓存的就是它。RuneTranslate 对此有防护：在 TM 命中时，如果术语表 source 出现在当前单元中，且缓存的目标不包含术语表的目标呈现，那么该缓存命中会被绕过，这个单元转而落入一次全新的提供方调用。运行结束的摘要中会显示一行“N 个单元绕过缓存以遵循术语表变更”，让你知道它发生了。

净效果：给一个旧项目添加新的术语表条目，不会让你困在陈旧的译文里。只需对受影响的单元重新运行一遍翻译即可。

构建你的术语表 — 添加什么

对于一个典型项目，按影响力排序：

• 先做角色名单。 每一个有名字的角色。尽量从 wiki / VNDB / 游戏自己的制作人员名单画面里获取。仅此一项就能消除长篇游戏中 80% 的漂移。
• 其次是地名。 城镇、地下城、地区、王国。尤其是那些用汉字书写、存在不止一种合理罗马音的名称。
• 标志性招式 / 技能排第三。 Boss 招式名、反复出现的法术名、特殊招式名。对 RPG 和战斗为主的视觉小说很重要。
• 世界专属术语排第四。 游戏为种族 / 职业 / 神器 / 货币生造的词。

不该添加什么：常见词。剣 → sword 是一份诱发误报的配方——你会锁定每一个包含 剣 的复合词（魔剣、聖剣、剣士），而这些本来提供方自己就能译好。术语表条目是字面子串匹配；把它们保持得足够长，使其对你想锁定的那个专有名词是唯一的。

CSV 导入 / 导出 — 共享术语表

在和协作者一起做一个粉丝翻译项目？设置里的术语表标签页有 导入 CSV 和 导出 CSV 按钮，可以通过一个 RFC-4180 CSV 文件往返你的条目：

source,target,targetLang 勇者,Hero,en アリス,Alice,en 魔王,Demon Lord,en 村人A,Villager A,en 勇者,Héroe,es

表头行是必需的。包含逗号、引号或换行符的字段会用双引号包裹；内嵌的引号会转义为 ""。导入时为 UTF-8，可带可选 BOM（Excel 默认导出 UTF-8-BOM）。空行以及 targetLang 代码不受支持的行会被跳过，并附上逐行原因。

导入提供 合并 模式（把 CSV 行叠加到你当前的术语表之上，按 source+语言去重，冲突时以 CSV 为准）或 替换 模式（清空现有内容，只使用 CSV 中的内容）。对于共享部分术语表的协作者，合并是正确的默认选项；替换适合归档 / 恢复备份。

当前限制

• 仅字面子串匹配。 没有正则，没有通配符。如果你需要同时锁定 勇者よ 和 勇者だ，目前你要添加两条条目。
• 按目标语言配对。 一条术语表条目绑定到一种输出语言。你无法在一行里定义“source=勇者, targets=Hero (en) + Héroe (es) + Held (de)”——你要添加三行。CSV 格式天然支持这一点。
• 仅限 Supporter / Pro 层级。 免费层级会显示术语表卡片，但条目不会影响翻译运行。发现对话框会指向 Patreon。

总结

在机器翻译的所有质量杠杆中，术语表的投入产出比最高——花十分钟构建它，能为你省下之后手动修正不一致名称的数个小时。从角色名单开始，先出一版初稿，随着你通读结果、发现漂移再逐步添加术语。

把它和一个能很好把握语气的提供方（Anthropic Claude 是我做视觉小说的默认选择）搭配，你的输出就已经越过了“可读的机器翻译”门槛，进入了“略加手工润色即可作为粉丝翻译发布”的地带。

下载 RuneTranslate 在真实项目上试用术语表。这是一项 Supporter（$3/mo）功能；免费层级对引擎 + 提供方仍然完全开放。