当 A Tour of Go 多语言翻译项目开始扩展到 Learn 和 Docs 以后，我遇到了一个看起来很简单的问题：
不同类型的内容，到底应该共用一份术语表，还是分别维护自己的术语表？
最直观的方案其实是分别维护。
Tour 有 Tour glossary。
Learn 有 Learn glossary。
Docs 再有 Docs glossary。
这样看起来很清楚。
每个 content package 管自己的内容，也管理自己的术语。
如果 Learn 中出现了新的专业词汇，就加到 Learn glossary。
Docs 中出现了新的概念，就加到 Docs glossary。
不同 package 之间互不影响。
从短期开发角度看，这甚至可能是最方便的设计。
但真正开始做 v2 以后，我越来越觉得：
这种设计虽然容易开始，长期却很难维护。
最终 v2 选择了另外一种方向：
一个 locale，只保留一份正式 glossary。
Tour、Learn、Docs，以及以后可能加入的其他 content package，都共享同一个 locale 的术语治理结果。
为什么最后会这样设计？
Go 的术语并不属于某一个 content package
最根本的原因其实很简单。
一个 Go 概念，不会因为它出现在 Tour 中，就变成“Tour 的术语”。
例如 goroutine、channel、interface、method、package，这些概念会同时出现在：
- Tour；
- Learn；
- Docs；
- 教程；
- API 文档；
- 其他 Go 学习材料。
它们属于 Go。
而不是属于某一个页面集合。
如果为不同 content package 分别建立 glossary，就意味着同一个概念可能被重复治理很多次。
例如：
Tour glossary
goroutine → goroutine
Learn glossary
goroutine → goroutine
Docs glossary
goroutine → goroutine看起来没有问题。
因为三个地方刚好决定了一样的译法。
但真正麻烦的是以后发生变化的时候。
假设某个术语经过重新审核，决定调整规范。
那么接下来就需要继续问：
Tour glossary 改了吗？
Learn glossary 改了吗？
Docs glossary 呢？
以后新增的 content package 是否也同步了？
这时，术语的一致性就不再由 locale 本身保证，而变成了：
依赖多个 glossary 长期保持同步。
这是一种很脆弱的状态。
多份 glossary 很容易产生“局部正确”
如果每个 package 都独立管理自己的 glossary，最容易出现的问题并不是明显的错误。
而是：
每一份 glossary 单独看都没有问题，但整个 locale 放在一起以后并不一致。
例如，同一个概念在 Tour 中长期使用一种译法。
Learn 中因为重新做了一次 terminology discovery，又选择了另一种表达。
Docs 后来再加入时，则采用第三种表达方式。
单独看每个 package，也许都可以找到理由。
但最终用户并不会关心这些内容来自哪个内部 package。
用户看到的是同一个中文 Go 网站。
如果一个概念在 Tour 中叫 A，在 Learn 中叫 B，在 Docs 中又叫 C，那么从用户角度来看，就是整个网站的术语不统一。
也就是说：
content package 是工程边界，但 locale 才是语言体验的边界。
这也是我后来越来越确定的一点。
Glossary 应该跟着 locale，而不是跟着 package
因此 v2 最终把 glossary 的正式治理边界放到了 locale。
例如简体中文只有一份正式 glossary。
Tour 使用它。
Learn 使用它。
Docs 也使用它。
以后增加新的 content package，原则上仍然继续使用同一份。
这并不意味着不同内容没有自己的特点。
它们当然有。
Tour 中常出现教学式表达。
Docs 可能更加正式和技术化。
Learn 中又可能包含大量面向初学者的解释。
但这些区别主要属于：
- 文体；
- 上下文；
- 表达方式；
- 句子结构。
它们不应该轻易改变同一个 Go 概念的核心术语。
因此更合理的分层应该是：
Locale
│
└── Unified Glossary
│
├── Tour
├── Learn
├── Docs
└── Future content packages而不是：
Tour → Tour Glossary
Learn → Learn Glossary
Docs → Docs Glossary前一种设计，术语从 locale 向下提供统一约束。
后一种设计，则需要不同 package 之间不断横向同步。
长期来看，我更愿意承担前者的复杂度。
但统一 glossary 不代表把所有词都塞进去
这里也有一个很容易走到另一个极端的问题。
既然整个 locale 只有一份 glossary，那么是不是应该把 Tour、Learn、Docs 中出现的所有专业词汇全部收进去？
也不是。
如果这么做，glossary 很快就会变成另外一种东西：
一份巨大的双语词典。
但 glossary 的目的并不是记录所有已经出现过的英文单词。
它真正应该管理的是：
那些需要跨页面、跨 package 保持稳定决策的术语。
例如：
某个 Go 核心概念应该翻译还是保留英文？
如果翻译，正式译法是什么？
是否存在不能使用的旧译法？
某个词在普通英语和 Go 技术语境中的含义不同，是否需要明确？
哪些术语如果自由翻译，特别容易导致整个 locale 出现漂移？
这些才是 glossary 真正应该治理的问题。
所以统一 glossary 并不意味着无限扩张。
反而意味着需要更加谨慎地决定：
什么值得进入这份全 locale 共用的规则。
Terminology Discovery 和正式 Glossary 是两件事
这也是 v2 中另一个逐渐明确的区别。
在真正决定 glossary 内容以前，可以对更大的 source corpus 做 terminology discovery。
也就是说，可以从：
- Tour；
- Learn；
- Docs；
- 未来内容；
中不断发现可能值得治理的术语。
Discovery 的范围可以很大。
因为它解决的是：
还有哪些词值得我们注意？
但正式 glossary 解决的是另外一个问题：
哪些词已经重要到需要成为整个 locale 的长期语言规则？
两者不应该混为一谈。
可以把它理解成：
Large terminology corpus
↓
Terminology discovery
↓
Candidate terms
↓
Review / decision
↓
Unified locale glossary如果把 discovery 发现的所有东西直接写入 glossary，术语表会越来越臃肿。
如果又完全不扩大 discovery corpus，那么以后每新增一个 content package，又会突然发现一批此前从未考虑过的核心词汇。
所以 v2 更希望做到的是：
让 discovery 尽量提前看得更远，但让正式 glossary 仍然保持克制。
为什么这一点在 future content package 上特别重要
如果项目永远只翻译 Tour，其实这个问题没有那么突出。
因为 corpus 本身相对稳定。
但一旦项目开始扩展到 Learn、Docs，以及未来更多内容，情况就不一样了。
假设每增加一个 package，都经历一次：
发现大量新术语
↓
大规模修改 glossary
↓
已有翻译大量 stale
↓
重新审核
↓
再增加下一个 package
↓
再次大规模修改 glossary那么整个项目会出现一种很明显的震荡。
每扩展一次内容范围，就重新影响大量已经稳定的翻译。
这显然不是一个长期可扩展的状态。
因此 v2 中 terminology discovery 的另外一个目标，就是：
尽量提前从更大的语料范围理解一个 locale 将来真正需要哪些核心术语。
这样并不能保证以后 glossary 再也不变化。
也没有必要追求这种不现实的目标。
但至少可以减少：
因为每增加一个 package，就重新发现一批最基础术语
这种可以提前避免的震荡。
Glossary 变化以后，也不能简单全量重做
当整个 locale 共用一份 glossary 以后，马上又会产生一个更实际的问题：
如果 glossary 改了，之前已经完成的翻译怎么办？
最简单的实现当然是：
old glossary SHA
≠
new glossary SHA
↓
全部 TranslationUnit stale这种判断非常容易实现。
也非常保守。
但问题是工程成本太高。
例如只是新增了一个只在两个页面中出现的 preferred term。
如果因此让整个 locale 上百个 TranslationUnit 全部重新翻译、重新审核，显然不合理。
这也是为什么统一 glossary 后，系统不能只比较一个整体文件 SHA。
真正需要判断的是：
这次 glossary 的语义变化，具体影响了哪些内容？
哪些页面包含这个术语？
这个变化属于 mandatory、preferred，还是其他规则？
旧 candidate 是否已经自然满足了新的 glossary？
哪些 TranslationUnit 确实受到影响？
哪些 TranslationUnit 完全可以继续使用原来的高质量结果？
这后来又发展成了 semantic compatibility 和 affected scope。
这部分我准备下一篇单独写。
因为我觉得它本身是统一 glossary 以后非常关键的另外一个问题：
术语表变化，并不等于所有历史翻译一起失效。
统一术语表其实也在降低重复工作
最开始设计 glossary 时，我更多关注的是：
怎样让翻译结果保持一致？
到了 v2，我越来越觉得 glossary 还有另外一个很重要的作用：
减少重复决策。
如果同一个术语已经经过 Generation、Reviewer，甚至多轮实际翻译验证，确认了一个稳定译法，那么新的 content package 再遇到它时，就没有必要重新讨论一次。
例如：
Tour 已经决定
↓
Unified Glossary
↓
Learn 直接复用
Docs 直接复用
Future package 继续复用这和整个项目后来逐渐明确的一个方向其实是一致的：
已经高质量完成的工作，应该尽可能复用。
不只是译文本身可以复用。
稳定的术语决策同样应该复用。
否则 content package 越多，重复决策也会越来越多。
这并不意味着 glossary 永远不能修改
统一 glossary 也不是一份一旦确定就永远冻结的文件。
语言本身会发展。
项目也会不断遇到新的上下文。
有时候一个早期看起来合理的术语，在更大的 corpus 中可能暴露出问题。
有时候 Tour 中没有歧义的译法，进入 Docs 后会发现它无法覆盖更正式的技术语境。
这时 glossary 当然应该修改。
关键不在于：
永远不要变。
而在于：
每次变化都应该有明确的语言理由，并且能够判断这次变化真正影响了什么。
这比简单追求“glossary 永远稳定”更加现实。
真正需要稳定的是治理方式。
不是某一个具体文件永远不动。
为什么不把 package-specific term 放到另一份 glossary
还有一种看起来比较折中的设计：
locale 有一份 global glossary，
每个 content package 再有自己的 local glossary。
这种设计也很常见。
但在这个项目里，我最终没有选择它。
原因之一是：
一旦允许多层 glossary，优先级问题会很快变复杂。
例如：
locale glossary:
interface → 接口而某个 package 中又出现：
package glossary:
interface → 界面到底谁优先？
如果允许 override，那么 reviewer 应该按照哪一份规则审核？
如果 package glossary 中只是因为特殊上下文临时采用另一种表达，它究竟应该属于正式 terminology rule，还是只是 TranslationUnit 的自然语言判断？
这种边界一旦打开，很容易重新回到：
同一个 locale 存在多套部分重叠的术语 authority。
所以 v2 更倾向于让正式 glossary 保持唯一。
真正属于上下文表达的问题，留给完整 TranslationUnit 中的语言判断。
如果一个差异确实稳定、重要、值得长期治理，则应该回到统一 glossary 中明确它的条件和含义，而不是再创建一份新的正式 glossary。
一个 locale 一份 glossary，本质上是在确定 authority
做到最后，我觉得这个问题真正重要的地方已经不是：
到底应该有几个 YAML 文件？
而是：
当不同内容对同一个术语产生不同意见时，最终谁是 authority？
如果 Tour、Learn、Docs 各自维护自己的正式 glossary，那么实际上就存在多个 authority。
而一个 locale 只有一份正式 glossary，意味着：
同一个 locale 的正式术语决策只有一个来源。
content package 可以提供新的语料。
terminology discovery 可以不断发现新的候选词。
Generation 可以暴露新的翻译问题。
Reviewer 也可以发现旧术语在新上下文中并不理想。
但最终正式决策仍然回到同一个 locale glossary。
这样，整个系统的语言治理链条会更加清楚。
v2 最终选择的原则
现在回头看，这部分设计其实可以压缩成几条很简单的原则。
第一：
术语属于 locale，而不是属于 content package。
第二：
Terminology discovery 可以覆盖越来越大的 corpus，但正式 glossary 应该保持克制。
第三：
新的 content package 应该尽量复用已有的高质量术语决策，而不是重新做一次。
第四：
glossary 可以演进，但每一次变化都应该能够精确判断真正受影响的内容。
也因此，一个 locale 最终只保留一份正式 glossary。
Tour、Learn、Docs 和 future content package 的加入，不应该让术语 authority 不断复制。
它们应该不断扩大我们对这个 locale 的理解。
但最终仍然汇聚到同一个语言标准。
Go 学习与文档多语言本地化项目
本系列完整记录 Go 学习与文档多语言本地化项目从 A Tour of Go 起步，逐步扩展到站点首页、项目说明页、学习内容、文档以及未来内容包的实际开发过程，包括架构设计、统一术语治理、整页翻译、结构保护、自动校验、独立质量审核、生产发布与长期维护。
项目源码：
✅ GitHub：shuijingwan/go-tour-i18n
语言版本：
当前跨项目目标语言池共包含 66 个语言版本。Go 项目本身目前提供 65 个社区 Production 语言版本，下面每一门 Go 语言版本都直接链接到其当前公开站点。语言列表沿用项目首页现有的展示顺序。
英语（美国）仅作为跨项目目标语言纳入列表，并不是单独的 Go Production 语言版本。当前 Go 的英文源内容仍为官方 generic English，因此英语（美国）链接到 Go 官方站点，而不是不存在的本地社区部署。
- 阿姆哈拉语
- 阿拉伯语
- 孟加拉语
- 葡萄牙语（巴西）
- 保加利亚语
- 加泰罗尼亚语
- 克罗地亚语
- 捷克语
- 丹麦语
- 荷兰语
- 英语（美国）（Go 官方英文站点）
- 英语（澳大利亚）
- 英语（加拿大）
- 英语（印度）
- 英语（新加坡）
- 英语（南非）
- 英语（英国）
- 爱沙尼亚语
- 菲律宾语
- 芬兰语
- 法语（法国）
- 法语（加拿大）
- 德语（德国）
- 德语（奥地利）
- 德语（瑞士）
- 希腊语
- 古吉拉特语
- 希伯来语
- 印地语
- 匈牙利语
- 印度尼西亚语
- 意大利语
- 日语
- 卡纳达语
- 哈萨克语
- 韩语
- 西班牙语（拉丁美洲）
- 拉脱维亚语
- 立陶宛语
- 马来语
- 马拉雅拉姆语
- 马拉地语
- 书面挪威语（Bokmål）
- 波斯语
- 波兰语
- 葡萄牙语（葡萄牙）
- 旁遮普语（果鲁穆奇文，印度）
- 罗马尼亚语
- 俄语
- 塞尔维亚语（西里尔文）
- 简体中文（中国大陆）
- 简体中文（新加坡）
- 斯洛伐克语
- 斯洛文尼亚语
- 西班牙语（西班牙）
- 斯瓦希里语（坦桑尼亚）
- 瑞典语
- 泰米尔语
- 泰卢固语
- 泰语
- 繁体中文（台湾）
- 繁体中文（香港）
- 土耳其语
- 乌克兰语
- 乌尔都语
- 越南语
项目正在持续扩展新的 Go 学习与文档内容，并长期维护各语言版本的术语一致性、翻译质量、独立审核、生产发布与后续更新。
本项目属于非官方社区多语言本地化项目，与 Go 官方无隶属、授权或背书关系。