翻译术语表 101 —— 锁定角色名和术语

把一部 200 行的日语视觉小说丢进 DeepL，女主角的名字出来是 Alice。接下来的 200 行把它变成 Aris。再往后那批决定用 Arisu。到第四章，她按你在读哪一幕而有三个名字。

这是机器翻译在长篇叙事游戏上最常见的失败模式 —— 不是语法、不是措辞，而是不一致的专有名词。翻译服务在批次之间没有记忆；每次看到一个名字它都重新猜最看似合理的罗马音。在一个 40 小时的 RPG 上，那种漂移会让一个可读的翻译感觉像是四个不同的人翻的。

一个翻译术语表能修好这个。你把"源到目标"的术语对定义一次 —— アリス → Alice、勇者 → Hero、魔王 → Demon Lord —— 每一个翻译批次、在每一个翻译服务上，都遵守它们。翻译服务甚至从不以原始形式看到那些术语。

什么是翻译术语表

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

• source —— 要锁定的源语言子串（默认日语；任意支持的源语言），例如 勇者。
• target —— 你想让它在输出里如何呈现，例如 Hero。
• targetLang —— 该规则适用于哪个输出语言，于是一个术语表可以同时覆盖英语 + 西班牙语 + 德语。

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

占位符屏蔽如何工作（与翻译服务无关）

天真的做法 —— 在翻译服务运行之后用正则替换换入目标术语 —— 在 DeepL 上勉强能用，但在 LLM 上会坏，因为它们已经围绕它们翻译的那个术语重新措辞了句子，留下悬空的冠词和奇怪的大小写。

RuneTranslate 在术语到达翻译服务之前屏蔽它们。运行器遍历每一个批处理的源字符串，把每一个术语表 source 替换成一个数字占位符 —— [[G0]]、[[G1]] 等等（最长匹配的术语优先，于是 魔王軍 胜过 魔王）。翻译服务看到它无法误译的不透明标记。回来的路上，那些占位符变成你的 target 术语，然后引擎标记屏蔽（RPG Maker 码、KAG 标记、Ren'Py 插值）在上面被还原。结果：无论你在 DeepL、一个 LLM，还是免费的 Google Translate 上，术语表术语都渲染得一模一样。

优先顺序 —— TM 胜过术语表胜过翻译服务

了解一批文本如何流经运行器，能解释为什么术语表编辑不花翻译服务额度，以及翻译记忆如何配合：

1. 翻译记忆（TM）短路。 如果你在任何过去的项目里已经翻译过这个完全相同的源字符串，缓存的译文会被瞬间提供 —— 零翻译服务调用。这个单元在翻译服务看到它之前就离开了批次。
2. 术语表屏蔽应用于 TM 没有提供的那些单元。
3. 翻译服务调用在屏蔽后的文本上运行。这是唯一花钱 / 计入配额的步骤。
4. 还原 —— 术语表占位符变成你的目标术语，然后引擎标记在上面被还原。
5. TM 写入 —— 最终译好的行被缓存，于是下次你看到这段日语时它是一次免费的第一步命中。

TM 是最大的省钱者；术语表是最大的省质者。它们一起复利：手动编辑一行一次，它被缓存进 TM，而术语表让专有名词在缓存命中和新批次上都保持一致。

TM + 术语表的相互作用（旁路守卫）

一个微妙的边界情形：假设你三个月前在没有术语表的情况下翻译了 100 行含 勇者，TM 随机地把它们缓存为 Warrior / Champion / Hero。现在你把 勇者 → Hero 加进术语表。

天真地看，TM 仍会交回 Warrior —— 那是缓存里的东西。RuneTranslate 对此设防：在 TM 命中时，如果一个术语表 source 出现在单元里，而缓存的 target 不含术语表的 target 呈现，这次缓存命中就被旁路，那个单元落到一次新的翻译服务调用。运行摘要会显示一行"N 个单元旁路缓存以遵守术语表变更"。所以给一个旧项目加一条新术语表条目，绝不会让你困在陈旧的名字上 —— 只需重跑受影响的单元。

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

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

• 先是角色名单。 每一个具名角色 —— 从维基、VNDB 或游戏自己的制作人员名单里取。单这一项就消除长游戏上约 80% 的漂移。
• 其次是地点。 城镇、地牢、地区、王国 —— 尤其是有不止一种看似合理罗马音的汉字。
• 第三是招牌招式 / 技能。 Boss 招式、反复出现的法术、绝招名 —— 对 RPG 和战斗密集的 VN 很重要。
• 第四是世界观特有术语。 为种族、职业、神器、货币生造的词。

不该加什么：常见词。剣 → sword 招来误报 —— 它锁定每一个含 剣 的复合词（魔剣、聖剣、剣士），而这些翻译服务本能自行译好。条目是字面、区分大小写的子串匹配，所以让它们长到足以对你所锁的那个专有名词是唯一的。

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

在和协作者一起翻译？设置里的术语表标签页有 导入 CSV 和 导出 CSV 按钮，它们通过一个表头为 source,target,targetLang、每行一个术语的 RFC-4180 文件来往返你的条目 —— 例如 勇者,Hero,en 和 勇者,Héroe,es。表头行是必需的；含逗号或引号的字段用双引号包裹（内嵌引号加倍），导入以带可选 BOM 的 UTF-8 读取（Excel 的默认）。空行和带不支持 targetLang 的行会被跳过，并附一个逐行原因。

导入提供一个 合并 模式（把 CSV 行加在上面，按 source + 语言去重，冲突时 CSV 胜）或 替换 模式（清空现有并只用 CSV）。合并是协作者共享部分术语表时的正确默认；替换适合恢复一个备份。

当前的局限

• 仅字面子串匹配。 没有正则、没有通配符 —— 要同时锁定 勇者よ 和 勇者だ，加两条条目。
• 每条条目一个目标语言。 一行绑定到一个输出语言，所以"勇者 → Hero (en) + Héroe (es) + Held (de)"是三行。CSV 格式自然支持这个。
• 仅付费档位（赞助者及以上）。 免费档位显示术语表卡片，但条目不影响翻译运行；发现对话框指向 Patreon。

总结

在机器翻译的每一个质量杠杆中，术语表有着最高的投入产出比 —— 花十分钟构建它，省下下游手动修正不一致名字的几小时。从角色名单开始、发一个初稿，然后随着你读完结果、注意到漂移而添加术语。

把它与一个善于处理语气的翻译服务（Anthropic Claude 是我做 VN 的默认）以及 AI 润色器搭配，你的输出就已经越过"可读的机器翻译"、进入"可作为粉丝翻译发布，只需轻度手动编辑"。

下载 RuneTranslate 在一个真实项目上试试术语表。它是一个赞助者（$3/mo）功能；免费档位在引擎和翻译服务上保持完全解锁。