系列： A Tour of Go 多语言翻译项目
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 简体中文：A Tour of Go 简体中文版
✅ 日语：A Tour of Go 日语版
✅ 德语：A Tour of Go 德语版
✅ 法语：A Tour of Go 法语版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前已上线简体中文、日语、德语和法语版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
-
在 A Tour of Go 多语言站点接入 Google AdSense 后，课程页虽然存在大片视觉空白，但普通展示广告始终没有出现。本文从 Auto Ads 配置、adsbygoogle.js 加载状态以及官方 A Tour of Go 的 DOM / layout 结构入手，分析为什么“页面看起来有空白”并不等于“Google 认为这里存在可插入广告的位置”。最终将问题范围收敛到 A Tour of Go 特殊的左右分栏和交互式页面结构，并引出后续一个更重要的架构选择：是否值得为了 AdSense 放弃原有 SPA。
-
在排查 A Tour of Go 展示广告始终不出现的问题时，一个看似直接的方案是放弃 SPA，让每一节课程都通过完整页面刷新来简化 AdSense、统计和 SEO。但进一步对比后发现，最大的代价并不是一次性的前端改造，而是长期偏离 golang/website 上游架构，持续增加同步与维护成本。本文结合官方 A Tour of Go 的 SPA 导航、上游 _content/tour/ 目录以及项目自身的 upstream baseline 管理方式，对“保留 SPA”与“放弃 SPA”进行完整权衡，并最终确定：让广告适配 A Tour of Go，而不是为了广告重新设计 A Tour of Go。
-
在决定保留 A Tour of Go 原有 SPA 架构之后，广告问题从“要不要整页刷新”转变成了“广告应该放在哪里、又该如何跟随 SPA 页面生命周期”。本文记录了从 AdSense Preview 识别 footer 下方候选广告位，到方案 A 使用 MutationObserver 跟踪 DOM 变化，再到方案 B 将广告直接绑定 Angular route-owned course view 生命周期的完整演进。最终通过 mount() / $destroy / unmount() 管理每一页独立广告节点，并保留 Auto Ads 继续服务其他已正常运行的站点和域名。
-
A Tour of Go 的 SPA SEO 问题早已存在：对用户来说，103 个课程 URL 明明对应不同内容，但 Google Search Console 曾将多个页面判断为“重复网页，用户未选定规范网页”。这一次在继续优化 AdSense 的过程中，我最终决定为全部 103 个正式课程页生成独立 Prerender HTML，让服务器首次响应就直接包含本页标题、正文、Go 示例源码、canonical 和 description，同时继续保留 Angular SPA、CodeMirror 与 Playground。本文记录了为什么 SEO 与广告上下文理解共同推动了这次 Prerender 实现，以及如何让每个课程 URL 真正拥有独立页面身份。
-
A Tour of Go 的广告优化在方案 B 与 103 页 Prerender 上线后，又进入了一轮真正的生产稳定性收尾。本文按时间线记录了从方案 A 因复杂 DOM 监听与操作而出现难以稳定复现的问题，到方案 B 改用 Angular course view 生命周期管理广告，再到 Prerender、Angular、CodeMirror 交接过程中出现短暂源码空白，以及真实 AdSense 写入 height: auto !important、min-height: 0px !important 导致课程高度塌缩和 footer 提前进入第一屏的完整过程。最终没有恢复复杂的方案 A，而是仅将其中已经验证有效的局部 layout protection 接回方案 B，并通过浏览器回归测试和真实广告展示完成最终验收。
-
A Tour of Go 第三门社区语言 de-DE 已正式上线。从开始推进到完成 TranslationUnit 质量审核、Locale Surface Review、production 部署和最终验收，这一轮粗略投入约 16 小时。 但这 16 小时并不是从零开始完成一门语言的全部成本，而是建立在此前数百小时的项目开发、质量流程、服务器基础设施和第二门语言标准化工作之上的增量成本。de-DE 真正值得复盘的，是第三次完整执行以后又暴露出了哪些历史流程债、哪些人工操作已经可以交给工具，以及为什么下一门语言的目标可以进一步压缩到 8 小时以内。
-
A Tour of Go 法语版在约 9 小时内完成上线后，我没有立即开始下一门韩语，而是先继续完善新增 locale 的执行流程。这一轮优化不再重复讨论“如何建立一套标准流程”，而是进一步减少已经可以机械化的重复操作：新增 locale init 初始化能力、自动生成语言骨架与状态文件、完善首次 production 自动化与 production identity、精简命令执行成本，并建立 Deferred Issues 机制记录已经真实发现但暂缓处理的问题。目标不是减少 Quality Check、Final Review 或 production acceptance 等质量 gate，而是把人的时间更多留给真正需要判断的翻译质量和生产风险。
-
A Tour of Go 韩语版原本预计约 6 小时完成，但最终从初始化到 production 收尾跨越约 44 小时。根据 76 次 Git 提交按 30 分钟封顶方式估算，实际活跃投入约 15 小时 43 分，结合 ChatGPT、Codex、浏览器、服务器、Cloudflare 和 Naver 等未完整进入 Git 的操作，最终更适合记作约 16～18 小时。本文复盘韩语为什么明显慢于法语：包括多轮 Quality Check 与 revision、Final Review 后再次返工、韩语语法触发新的 validator 边界、5 小时模型额度影响生产节奏，以及 TranslationUnit 完成后仍持续出现的 preview、production、Cloudflare、课程目录和 Naver 上线问题。最终也重新认识到，成熟流程的价值并不是保证每门语言都越来越快，而是遇到真实问题时，能够正确地慢下来并留下可复用的改进。
-
A Tour of Go 韩语翻译在 codex-ko-KR-004 中首次出现 13 个 TranslationUnit 里 3 个 validation failure。进一步排查发现，其中 concurrency/2 与 concurrency/6 并不是 Go identifier 真正丢失，而是韩语助词直接附着在 ASCII 标识符后，触发了 validator 的词法边界误判；concurrency/4 则属于真实的 present font span 结构错误。本文记录如何区分“应该改译文”与“应该改 validator”，并通过 ko-KR 窄规则、正反测试与 revalidate 流程，将结果从 10/13 提升到 12/13，最后再修正真实 candidate 问题达到 13/13。核心原则是：validator 的目标应保护技术身份，而不是强迫目标语言适应源语言的书写边界。
-
A Tour of Go 的社区翻译历史中，法语、德语、韩语等多个项目都曾长期维护、积累大量提交，却最终出现仓库归档、站点离线，甚至原仓库不可访问的情况。本文结合官方 tracking issue 与多语言仓库 Git 历史，分析社区翻译真正困难的并不是第一次上线，而是多年以后仍然能够持续同步上游、维护部署、掌握 production 权限，并承担服务器、带宽、CDN、域名、AI 工具和维护时间等长期成本。也正因为如此，我现在不仅重视统一流程、正式文档和自动化，也开始通过广告尝试让多语言项目逐渐具备一定的自我供血能力，降低长期完全依赖个人时间、热情和资金补贴的风险。