系列： 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 官方无隶属、授权或背书关系。
-
A Tour of Go 历史上的多个社区翻译项目，曾经投入大量时间和人力，最后仍因为上游变化、部署失效、维护者更替、基础设施和长期投入等因素逐渐停止维护甚至离线。基于这些历史经验，我开始重新思考一个免费、多语言社区项目怎样才能长期存在。除了广告之外，这次项目正式加入了 Support 功能，为中文和国际用户提供不同的自愿支持方式。Support 的重点不是改变项目的免费和开放属性，而是为翻译更新、上游同步、Production、基础设施和长期维护增加一种可持续可能，同时继续优先保证社区项目能够被更多开发者发现、使用和长期维护。
-
记录 A Tour of Go 多语言翻译项目第一次系统开展站外推广的过程。除了 go.dev、搜索引擎和 GitHub 之外，实际尝试了 Go Weekly、Golang News、Reddit r/golang、DEV Community 和 Go Forum，并记录了投稿、社区活跃度、积分限制、审核机制、内容发布和外链策略。也进一步明确了后续推广思路：不单纯为了 SEO 堆链接，而是优先进入 Go 开发者真实活跃的社区，并逐步为不同语言版本寻找对应的本地开发者渠道。
-
在为 A Tour of Go 多语言项目新增阿拉伯语版本时，我第一次真正处理 RTL（从右到左）语言。翻译本身仍沿用既有 TranslationUnit、Quality Check、Course SEO 和 Locale Surface Review 流程，但 RTL 很快暴露了桌面双栏重叠、移动端编辑器被压窄、课程导航方向语义变化、代码区必须保持 LTR 等问题。最终通过调整共享布局、响应式规则和浏览器回归测试完成阿拉伯语正式上线，并在排查 PageUp/PageDown 快捷键时进一步确认了一个可在官方 go.dev/tour 复现的上游焦点问题。整门阿拉伯语实际投入约 7 小时，相比普通 LTR 语言多出的时间，主要来自首个 RTL locale 的一次性基础设施建设。
-
在完成 Go 多语言项目的 65 个 community locale 后，我进一步整理出一套可跨项目复用的语言选择与商业优先级体系。文章解释为什么跨项目语言池应扩展为包含 en-US 的 66 个目标 locale，以及为什么语言排序不应简单按照人口、单一广告平台支持情况或某个项目的特殊需求决定，而应以长期广告收入潜力为核心，综合考虑语言人口、主要国家和地区、经济体量、数字广告市场、开发者人口等因素。同时区分“商业基础顺序”与“项目级战略 override”：例如 Swahili、Kazakh、Persian、Amharic 在需要申请官方链接或生态合作时可以提前，但不改变基础商业排名。最终目标不是精确预测每一种语言的收益，而是冻结一套足够合理、长期可复用的 66 locale 顺序，避免未来每启动一个多语言项目都重新做语言选择。
-
在 Go 多语言翻译项目从 A Tour of Go 扩展到 Site、Learn、Docs 及 future content packages 后，原本用于避免无意义重复审核的 glossary compatibility 机制开始暴露出严重性能问题：部分 Quality Check、Reviewer Bundle、finalization 与 revision 命令需要数分钟才能完成。本文记录一次真实的架构决策过程，对比“继续优化 semantic-delta compatibility carry”和“退回 glossary SHA 变化即 full QC”两种方案，并说明为什么最终暂时保留 compatibility、采用全语言共享的 invocation-local prepared-state 优化。同时进一步确定，无论最终采用哪一种方案，提前基于更完整的 Go/go.dev 技术语境稳定 glossary，都是降低长期维护成本的关键。
-
A Tour of Go 多语言翻译项目正在进入 v2。随着翻译范围从 Tour 扩展到 Site shell、Learn、Docs 以及未来更多 content package，原有围绕 Tour 构建的架构已经不足以继续扩展。本文记录为什么需要 v2，以及 TranslationUnit、统一术语表、内容包、历史复用与网站集成等设计背后的整体思路。
-
在 Go Learning & Documentation v2 中，Learn / Docs 的 Markdown 内容虽然可以被 parser 拆成标题、段落、列表、代码注释等更小的结构，但正式翻译与审核仍然坚持以完整 Page 作为 TranslationUnit。本文从上下文、自然语序、Independent Review、parser 演进和历史稳定性等角度，解释为什么机器内部的解析粒度不应该直接决定语言治理边界，以及 Page TranslationUnit 与 internal slot 应该如何分工。
-
随着 Go Learning & Documentation v2 从 A Tour of Go 扩展到 Learn、Docs 以及未来更多 content package，术语治理也需要从 package 级调整到 locale 级。本文介绍为什么同一个 locale 最终只保留一份正式 glossary，以及 Unified Glossary、Terminology Discovery、术语复用和 future content package 之间的关系。同时说明，统一术语表并不意味着无限收录所有词汇，也不意味着 glossary 每次变化都要让全部 TranslationUnit 重新处理。
-
Go Learning & Documentation v2 统一 glossary 之后，一个关键问题随之出现：术语表发生变化时，是否所有已经翻译和审核完成的页面都要重新处理？本文介绍 v2 如何从简单的 glossary SHA 变化，进一步判断 Semantic Delta、相关 Page、Compatible 与 Affected 范围，只让真正受到新术语规则影响的 TranslationUnit 进入 revision 和 re-QC，同时尽量复用已有的高质量翻译结果。
-
Go Learning & Documentation v2 为了支持更精确的 Semantic Compatibility，引入了更复杂的状态准备与影响范围判断，但也让部分 CLI 从秒级逐渐退化到分钟级。本文记录一次实际性能优化：通过识别同一 invocation 中被反复构建的 Compatibility State，将执行方式调整为 Prepare Once / Reuse Many Times，在不改变原有判断结果、fail-closed 语义和验证范围的前提下，将一次典型命令从 6m54.554s 优化到 10.335s，约提升 40.1 倍。