系列： Go 学习与文档多语言本地化项目
本系列完整记录 Go 学习与文档多语言本地化项目从 A Tour of Go 起步，逐步扩展到站点首页、项目说明页、Learn、Docs 及 future content packages 的实际开发过程，包括架构设计、统一术语治理、整页翻译、结构保护、自动校验、独立质量审核、Site v2 扩展、生产发布与长期维护。
项目源码：
✅ GitHub：shuijingwan/go-tour-i18n
语言版本：
当前跨项目目标语言池共包含 66 个 locale。Go 项目本身目前提供 65 个 community Production locale，下面每一门 Go 语言版本都直接链接到其当前公开站点。语言列表沿用项目首页现有的展示顺序。
en-US 仅作为跨项目目标语言纳入列表，并不是单独的 Go Production locale。当前 Go 的 English source authority 仍为 generic en，因此英语（美国）链接到 Go 官方英文站点，而不是不存在的本地社区部署。
- 阿姆哈拉语
- 阿拉伯语
- 孟加拉语
- 葡萄牙语（巴西）
- 保加利亚语
- 加泰罗尼亚语
- 克罗地亚语
- 捷克语
- 丹麦语
- 荷兰语
- 英语（澳大利亚）
- 英语（加拿大）
- 英语（印度）
- 英语（新加坡）
- 英语（南非）
- 英语（英国）
- 英语（美国）（官方 generic English source，不是单独的 Go Production locale）
- 爱沙尼亚语
- 菲律宾语
- 芬兰语
- 法语（法国）
- 法语（加拿大）
- 德语（德国）
- 德语（奥地利）
- 德语（瑞士）
- 希腊语
- 古吉拉特语
- 希伯来语
- 印地语
- 匈牙利语
- 印度尼西亚语
- 意大利语
- 日语
- 卡纳达语
- 哈萨克语
- 韩语
- 西班牙语（拉丁美洲）
- 拉脱维亚语
- 立陶宛语
- 马来语
- 马拉雅拉姆语
- 马拉地语
- 书面挪威语（Bokmål）
- 波斯语
- 波兰语
- 葡萄牙语（葡萄牙）
- 旁遮普语（果鲁穆奇文，印度）
- 罗马尼亚语
- 俄语
- 塞尔维亚语（西里尔文）
- 简体中文（中国大陆）
- 简体中文（新加坡）
- 斯洛伐克语
- 斯洛文尼亚语
- 西班牙语（西班牙）
- 斯瓦希里语（坦桑尼亚）
- 瑞典语
- 泰米尔语
- 泰卢固语
- 泰语
- 繁体中文（台湾）
- 繁体中文（香港）
- 土耳其语
- 乌克兰语
- 乌尔都语
- 越南语
项目正在持续扩展新的 Go 学习与文档内容，并长期维护各语言版本的术语一致性、翻译质量、独立审核、生产发布与后续更新。
本项目属于非官方社区多语言本地化项目，与 Go 官方无隶属、授权或背书关系。
-
Go Learning & Documentation v2 将 Learn / Docs 纳入翻译流程后，Markdown、inline code、链接、完整代码、教学注释等复杂结构都需要更精确的 parser 与保护机制。本文介绍为什么结构保护不能只是“锁住 token 和顺序”，而应该重点保护 pair、binding 与机器语义；同时通过 Parse / Protect、Generation、Reconstruct / Validate 的分层，让 AI 在不破坏结构的前提下，仍然能够按照目标语言自然表达。
-
在 Go Learning & Documentation v2 中，历史最初存在的价值并不是为了建立复杂的追溯体系，而是为了复用已经高质量完成的翻译成果。本文介绍为什么已经通过 Generation、Machine Validation 和 Independent QC 的 TranslationUnit 不应该因为 milestone、parser 或工作流升级就被无条件重做，以及 trusted carry、machine revalidation 和异常集合处理如何减少重复翻译、重复审核和无意义的语言漂移。
-
Go Learning & Documentation v2 在长期演进中逐渐积累了 Snapshot、predecessor、promotion、authorization、receipt、identity 等大量历史状态。最初，这些历史用于复用成果和支持恢复；但当正常工作也开始依赖不断向前追溯和还原旧状态时，工程成本迅速上升。本文介绍 v2 为什么最终引入 Trusted Checkpoint / Stop Point：旧历史继续保留用于审计、诊断和必要时追溯，但正常工作流从可信当前基线继续向前，不再要求无限重建过去。
-
Go Learning & Documentation v2 中，一个上游内容发生变化后，并不意味着所有下游状态都应该一起失效。本文介绍 v2 如何通过依赖关系、当前身份和真实影响范围，判断哪些翻译单元、质量审核、内容包封存、整合站点结果和激活状态仍然有效，哪些必须重新进入流程。核心目标不是尽量减少失效，而是让失效传播足够准确，让每一次变化只产生它真正应该产生的工程成本。
-
Go Learning & Documentation v2 扩展到 Learn、Docs 和完整站点以后，一个新的问题变得越来越重要：官方英文页面存在，并不代表本地语言站点也应该自动存在对应页面。本文介绍 v2 如何以“正式本地内容覆盖”为判断依据，决定本地 URL、导航、canonical、sitemap 和 404 的行为：已经完成本地覆盖的页面才进入本地站点；尚未完成的内容继续直接链接 go.dev，并让不存在的本地路径保持真实 404。核心目标不是让站点“看起来完整”，而是让公开状态准确反映真实内容边界。
-
代码块中的注释并不都是不可翻译内容：教学性自然语言通常应该进入翻译，而机器指令、结构和技术语义必须保持不变。更难的问题是，怎样证明所有应该翻译的注释都已经被发现，而不是只检查已经进入流程的那一部分。本文介绍 Go Learning & Documentation v2 如何从规范源内容建立代码注释清单，区分教学注释、机器语义和不支持的未知内容，再与当前正式译文进行精确对应，检查 missing、extra、结构变化和受保护内容变化。核心目标是避免静默遗漏，让“翻译质量正确”和“翻译内容完整”同时成立。
-
Go Learning & Documentation v2 在处理结构化内容时发现，一个原始文件即使字节完全没有变化，也不代表旧翻译仍然完整有效。books.yaml 的实际案例中，旧 parser 只识别出 10 个可本地化语义单元，而当前 parser 识别出 12 个，并新增 PDF 和 GitHub。本文介绍 v2 如何区分 source 变化、普通 stale 和真正的 semantic input expansion，为什么旧 Generation 应保留为历史事实却不能继续冒充当前完整结果，以及为什么重新进入流程前必须证明旧单元全部精确保留、当前输入只是严格扩展。核心结论是：判断翻译能否复用，不能只比较源文件，还必须比较模型真正接收到的正式语义输入。
-
Go Learning & Documentation v2 在内容生成、独立审核、内容包封存和整合站点审核全部通过以后，并不会直接修改当前激活状态。原因是从审核完成到真正写入之间，权威状态仍然可能被其他合法流程改变。本文介绍 v2 为什么将 Activation 拆成只读的 activation-preflight 和真正产生状态变更的 activation-apply，以及 prior_sha256、result_sha256 和 CAS 如何共同防止旧计划覆盖更新状态。文章还讨论了 prior mismatch、already_active=true、并发状态变化和 mutation=unknown 的处理原则。核心结论是：一次操作曾经合法，不代表它在真正提交时仍然安全。
-
Go Learning & Documentation v2 在 TranslationUnit、内容包封存和 Integrated Surface Review 全部通过以后，仍然需要执行独立的 Preview 验收。一次真实案例中，前面的语言内容和整合站点状态都已经通过，但 Preview 首页仍因 wrong renderer 直接失败。本文介绍 Surface 与 Preview 为什么不能互相替代，以及 Preview 如何验证从 activated authority 到 LoadContent、Compose、route resolver、renderer、HTTP、DOM 和浏览器行为的真实运行链。文章还讨论了为什么 HTTP 200 不能证明页面正确、runtime 工程错误为什么不应该重新打开可信翻译成果，以及修复后为什么必须重新启动 fresh Preview。核心结论是：内容正确，只能证明输入正确；Preview 还必须证明系统真正按照预期消费了这些输入。
-
在 Go Learning & Documentation v2 的性能优化过程中，我曾把一条只读规划路径从约 164.03s 优化到 125.65s，后来又通过更激进的方案一度压到约 35.93s。但最终，更快的方案并没有被保留，因为对应的 correctness、freshness、stale detection 和 targeted tests 无法完整证明继续成立。本文整理这次性能优化过程，讨论为什么性能任务不能只看 benchmark，为什么 invocation-local reuse 通常比复杂 persistent cache、LRU 和多级 memoization 更适合这类强调 currentness 的工作流，以及什么时候应该停止继续优化。核心结论是：性能优化的目标不是把执行时间压到最低，而是在正确性、复杂度、验证成本和实际收益之间找到合理边界。