上一篇里，我写了为什么历史值得保留。
它最初的目的其实很实际：
复用已经高质量完成的翻译成果，避免重复 Generation、重复审核和无意义的语言漂移。
如果一个 TranslationUnit 的 source 没有变化，新的 glossary 也没有真正影响它，旧 candidate 仍然能够通过当前的机器校验，而且之前已经完成了 Independent QC，那么最合理的做法通常不是重新翻译一次。
而是继续使用已经做对的结果。
但在这次 Go Learning & Documentation v2 的开发过程中，我也遇到了历史的另外一面。
随着工作流越来越完整，Snapshot、predecessor、promotion、authorization、receipt、identity、provenance 等状态越来越多，历史开始承担一种它最初并没有打算承担的职责：
为了完成今天的工作，系统开始要求把越来越早的历史状态重新还原出来。
这也是这次 v2 实际开发时间明显超过最初预期的重要原因之一。
最后真正需要调整的，不是“要不要保留历史”。
而是另一个问题：
保留历史，是否意味着未来必须永远能够从历史深处一路重建到当前状态？
v2 后来的答案是：
没有必要。
一开始，历史还原看起来非常合理
假设当前有一个 TranslationUnit。
它不是凭空出现的。
它可能来自某一次 Generation。
之后建立 Candidate Snapshot。
Reviewer 完成 QC。
如果得到 B、C 或 D，又进入 revision。
接着 re-QC。
再经过 finalization、promotion，最终成为当前使用的结果。
如果希望系统能够证明：
“为什么现在是这个状态？”
一个很自然的设计就是把这些关系都保存下来。
例如：
Current state
↓
Promotion
↓
Finalized Snapshot
↓
Quality Check
↓
Candidate Snapshot
↓
Generation每一步都有明确来源。
每一份结果都可以继续向前找到 predecessor。
从审计角度看，这种链条非常漂亮。
而且在系统规模还不大的时候，它确实带来了很强的确定性。
如果状态出现异常，就可以沿着历史关系向前检查。
所以最初不断增强历史追溯能力，本身并不是错误。
真正的问题，是后来它逐渐从：
“发生问题时可以追溯历史”
变成了：
“正常向前工作也必须先恢复完整历史”。
这两件事情差别很大。
为了恢复 A，又开始恢复 A 的前任
历史恢复最容易出现的一种情况是：
当前工作需要一份旧状态。
但是这份状态是由旧版本 workflow 产生的。
它缺少后来才加入的某个字段。
于是需要恢复。
恢复的时候又发现：
这份状态的 predecessor 也需要能够被当前程序识别。
于是继续向前。
然后 predecessor 又依赖另外一个 Snapshot。
那份 Snapshot 又可能缺少新的 identity 或 provenance。
继续恢复。
很快，一个原本只想解决当前问题的任务，会变成：
恢复当前需要的历史状态
↓
发现 predecessor 不完整
↓
恢复 predecessor
↓
发现更早 Snapshot 不满足当前 schema
↓
继续恢复
↓
发现旧 promotion 还需要补关系
↓
继续向前……这就是我后来越来越明显的一种感受：
历史恢复很容易没有天然终点。
每次都觉得：
“再补这一层应该就可以继续了。”
但补完以后，下一层依赖又出现了。
这和普通的数据迁移不太一样
数据库升级时，也经常要做 migration。
旧 schema 转成新 schema。
完成以后，系统继续使用新数据。
但这次遇到的问题更复杂一些。
因为工作流历史不是单纯的一张表。
它包含的是一系列互相关联的事实：
- 哪一次 Generation 产生了这个 candidate；
- Candidate 属于哪个 Snapshot；
- Reviewer 审核的是哪一份 exact candidate；
- revision 针对什么 finding；
- re-QC 对应哪个 successor；
- promotion 使用的是哪一份 finalized result；
- 当前状态和历史状态之间是什么关系。
当新架构增加新的约束以后，如果要求旧历史也全部达到新的完整标准，那么实际上是在要求：
过去所有时期产生的状态，都重新满足今天才定义出来的规则。
这件事情理论上当然可以做。
问题只是：
工程成本可能非常高。
最危险的是“已经花了这么多时间，再多恢复一点吧”
这种问题还有一个很典型的陷阱。
当已经恢复了很多历史以后，很容易产生一种心理：
前面都恢复这么多了，只差最后一点，干脆彻底做完。
但所谓的“最后一点”，往往又会继续展开。
因为旧系统从来没有按照今天的 architecture 生成那些 evidence。
有些缺失不是 bug。
只是：
那个时代根本还没有这种概念。
如果继续要求把它们全部补齐，就开始出现一种奇怪的工程目标：
不是为了当前翻译或发布需要什么。
而是为了让过去看起来像：
当年就已经运行在今天的系统里。
这显然是不现实的。
我后来开始怀疑：为什么必须恢复这么远？
真正的转折，其实来自一个很简单的问题：
今天要继续翻译和发布，为什么一定要把几个月前的整个状态链重新变成当前 schema？
假设我们已经能够可靠确认几个事实：
当前 candidate 是可信的
当前 source identity 已知
当前 glossary relationship 已知
当前 machine validation PASS
当前 QC 结论能够成立那么为了以后继续处理新的 TranslationUnit，真的还必须证明：
当前状态能够完全按照新系统的所有规则，一路重建到最早的历史起点吗？
慢慢地，我觉得答案是否定的。
历史需要保存。
但：
当前工作不应该永远依赖无限深的历史 reconstruction。
这两件事情应该分开。
历史保留和历史可执行，是两个概念
这是这次架构调整以后，我觉得特别重要的一个区分。
一份旧历史可以继续存在。
它可以用于：
- 审计；
- provenance；
- failure diagnosis；
- 理解过去发生了什么；
- 必要时进行人工调查。
但这不等于：
它必须继续成为未来 workflow 的可执行 predecessor。
可以把过去的设计理解成：
History A
↓
History B
↓
History C
↓
Current
↓
FutureFuture 想继续向前，就必须保证：
A → B → C → Current整条链全部可以按照今天的规则重新解释。
而新的思路更接近：
Historical records
Historical records
Historical records
↓
────────────────
Trusted checkpoint
────────────────
↓
Current state
↓
Future workflow断点之前的历史仍然存在。
但未来 workflow 的正式执行起点，从这个可信 checkpoint 开始。
“断点”不是删除历史
这里很容易被误解。
建立断点并不是：
老历史太麻烦，所以全部删掉。
也不是：
以前发生过什么不重要了。
相反，旧 evidence、旧 Snapshot、旧 provenance 仍然应该尽量保留。
真正改变的是：
它们不再全部承担当前工作流的执行责任。
也就是说，断点之前的历史主要回答：
过去发生了什么？
断点之后的 current authority 回答：
从现在开始，系统按照什么状态继续向前？
这是两个不同的问题。
断点需要是可信的
当然，也不能随便找一个时间点说：
从这里开始，前面不管了。
那只是把问题隐藏起来。
一个真正可以承担新起点的 checkpoint，必须能够提供足够的 current facts。
例如至少能够确定：
- 当前 source 是什么；
- 当前 candidate 是什么；
- 当前 glossary 是什么；
- 当前机器验证结果是否成立；
- 哪些 TranslationUnit 已经可信完成；
- 哪些还处于 pending；
- 当前 Generation / Reviewer provenance 是什么；
- 后续 workflow 应该从什么状态继续。
换句话说：
断点不是放弃验证，而是把验证目标从“重建全部历史”改成“证明当前状态足够可信”。
这是我觉得最关键的区别。
Current truth 比完整 replay 更重要
以前的架构容易隐含一种想法：
只要整条历史能够 replay，当前状态就一定可信。
这种想法有一定道理。
但长期系统运行以后，还存在另外一种可靠性来源：
直接验证 current truth。
例如：
如果当前 Page candidate 可以重新通过最新 parser。
如果 glossary compatibility 可以重新计算。
如果当前 source identity 可以确认。
如果 Reviewer 的正式结论已经存在，而且所针对的 candidate identity 仍然匹配。
那么这些 current facts 本身就有价值。
没有必要为了证明它们，再要求重新复现数十步之前的所有历史操作。
这就有点像长期运行的 event system。
可以保存所有事件。
但并不代表每次程序启动，都必须从第一条 event 开始 replay 到今天。
当历史越来越长以后，合理的 snapshot / checkpoint 本身就是系统设计的一部分。
历史最初是为了让未来更快，而不是更慢
这也是我后来重新审视整个 history architecture 时最在意的一点。
上一篇已经写过：
历史最初最大的价值，是避免重复翻译和重复审核。
也就是说，历史本来应该帮助我们：
更少 Generation
更少 QC
更少 revision
更快继续新增内容但如果后来为了复用历史，需要先花大量时间恢复历史：
restore old Snapshot
restore predecessor
restore promotion
repair identity
repair authorization
repair receipt
...那么历史已经开始产生相反的效果：
为了避免重复工作，又创造出了更多历史恢复工作。
这时真正应该检查的就不是：
“还能不能再把 restoration 自动化一点？”
而是：
是不是整个执行模型已经偏离最初目标了？
项目的根本目标不是建立完美的历史博物馆
做到这里以后，我觉得整个问题其实可以用一句有点直白的话概括：
这个项目不是为了建立一座完美的历史博物馆。
它真正的目标仍然是：
快速、高质量地完成 Go 学习与文档的多语言翻译。
历史对这个目标有帮助，所以保留。
Glossary 对这个目标有帮助，所以治理。
QC 对这个目标有帮助，所以建立 Independent Reviewer。
Parser 对这个目标有帮助，所以不断完善。
但这些都只是手段。
如果某一个手段开始吞噬大量工程时间，却没有相应提高：
- 翻译质量；
- 发布安全；
- 复用效率；
- 可恢复性；
那么就应该重新评估。
历史也是一样。
原本预计的开发时间，就是这样被拉长的
这次 v2 开始时，我对整体上线时间的预期并没有特别长。
原本预计大约 5 个工作日 可以完成这一轮。
真正开始以后，Learn / Docs 翻译本身当然需要时间。
Glossary、parser、Surface、Production 等也都需要继续完善。
但实际超出预期的一个重要原因，就是：
越来越多时间花在旧状态恢复上。
而且这部分工作非常容易被低估。
因为单看每一次 restoration，好像都只是：
补一个 predecessor。
修一个旧 Snapshot。
让一个历史 promotion 能够重新被识别。
每一件事情单独看都不是特别大。
但它们连续出现以后，就会形成很明显的累计成本。
最终开发时间已经远远超过最开始预计的 5 个工作日。
而这也迫使我真正面对一个问题：
到底要恢复到什么时候？
如果架构没有明确答案，历史恢复就可能继续下去。
新架构真正需要的是一个 Stop Point
后来我越来越喜欢用一个非常简单的词来描述这次调整：
Stop Point。
也就是：
历史追溯必须有停止点。
在 Stop Point 之前：
保留真实历史。
在 Stop Point：
建立足够可信的 current baseline。
在 Stop Point 之后：
使用当前正式架构继续向前。
可以简单理解成：
Past
│
│ preserved
│
▼
====================
STOP POINT
====================
│
│ current authority
│
▼
Generation
Validation
QC
Revision
Surface
Production未来如果某个真实 failure 需要调查旧历史，仍然可以向前看。
但这是：
diagnosis path
而不再是：
normal execution path
这个区别对长期维护非常重要。
Normal path 和 Recovery path 应该分开
过去还有一个容易混在一起的问题。
为了保证 recovery 能力，正常路径也承担了越来越多历史要求。
但其实：
“出问题时我们能不能恢复”
和：
“每一次正常操作是否必须执行完整恢复逻辑”
不是同一件事情。
更合理的设计应该是：
正常情况：
current trusted state
↓
continue forward只有真正出现：
FAILED
unexpected state
mutation unknown才进入：
historical diagnosis
↓
recovery这样历史恢复能力仍然存在。
但不会让所有正常 workflow 都支付这笔成本。
这也是我觉得 v2 后期非常重要的一次思路转变。
“mutation unknown” 反而应该停下来
引入 Stop Point 并不意味着以后遇到问题就强行向前。
恰恰相反。
如果当前状态到底发生过什么无法确认，例如：
mutation = unknown更合理的做法仍然应该是：
停止。
先诊断。
不要盲目 replay。
不要觉得：
“反正有历史，再重跑一下应该没问题。”
因为一旦无法确认某个操作是否已经产生 mutation，再次执行本身可能制造新的状态。
所以新架构并不是从“太严格”走向“随便继续”。
而是更加明确地区分：
哪些情况下可以安全向前。
哪些情况下确实需要回看历史。
哪些情况下必须停止等待诊断。
Recovery 应该处理异常，而不是成为日常工作
这和上一篇提到的另外一条原则也能够对应起来。
一个长期稳定的系统，正常应该主要处理：
new
changed
affected异常情况下才处理：
missing
restore_failed
validation_failed
unexpected
mutation unknown如果绝大多数正常工作都不断进入：
restore historical state那说明 recovery 已经开始反客为主。
理想状态下：
Recovery 是安全网，不是主干道。
历史保存也是一样。
它应该让系统在必要时能够回头。
但正常情况下，方向应该始终是：
向前。
断点还可以降低未来架构演进的成本
这套设计还有一个长期价值。
如果今天的 workflow 未来继续升级，可能又会加入新的：
- schema；
- identity；
- evidence；
- validation；
- package 类型。
如果每一次升级都要求：
所有历史记录全部补齐新字段。
那么系统越运行越久，migration 成本会越来越高。
但如果正式建立：
旧历史保持原样 + current checkpoint + 新规则从 checkpoint 向后生效
那么未来架构演进就会容易很多。
新的规则不必假装：
十个月前系统就已经知道今天的设计。
它只需要保证：
从新的正式起点开始，之后的状态全部符合新规则。
这更接近真实的软件演进方式。
不要让未来承担无限的过去成本
做到这里以后，我觉得这篇文章真正想表达的核心已经比较清楚了：
历史需要保存，但未来不应该无限承担还原过去的成本。
历史能够帮助我们：
- 复用已经完成的翻译；
- 调查真实 failure；
- 保留 provenance；
- 理解过去发生过什么。
但未来 workflow 不应该默认要求：
所有过去状态都必须先升级成当前 architecture，才能继续下一步。
到一定阶段，系统需要允许自己说：
这里以前发生的事情已经被保存。
这里是经过验证的 current baseline。
从这里开始继续向前。
这不是降低质量，而是在保护工程目标
最开始决定停止无限恢复历史时，确实很容易产生一种担心：
会不会变得不够严格？
但后来我觉得：
真正的严格不应该体现在：
系统可以还原多少年前的每一个内部状态。
而应该体现在：
当前发布的内容是否可靠。
如果 current candidate：
- source 正确；
- glossary 正确；
- machine validation 正确；
- QC 正确；
- Surface 正确；
- Production gates 正确；
那么用户真正关心的质量目标已经被满足。
把额外几天花在恢复一条已经不会再影响 current truth 的旧 predecessor，并不会让用户看到的中文因此更准确。
质量保障应该围绕真正的风险设计。
而不是围绕“历史一定要无限完整”设计。
两篇历史文章其实讲的是同一个目标
上一篇写：
历史为什么值得保留。
这一篇写：
为什么历史又不能无限重建。
看起来像是两个相反的方向。
但实际上，它们的根本目标完全一致：
快速、高质量地向前。
历史有助于避免重复工作，所以保留。
历史恢复开始阻塞新工作，所以建立断点。
换句话说：
历史是优化手段，不是治理目标。
我觉得这可能是这次 v2 在历史架构上最终最重要的一条经验。
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 官方无隶属、授权或背书关系。