2026 年 9 月 11 日，我再次打开 Go 官方的 A Tour of Go：
在 Go local 的语言列表中，已经可以看到：
- French — Français
- German — Deutsch
- Korean — 한국어
- Simplified Chinese — 简体中文
这 4 个链接，最终都指向了我长期维护的 A Tour of Go 多语言翻译项目。
从结果上看，这件事似乎很简单：向 Go 官方申请，把几个翻译站点添加到语言列表中。
但实际过程比我最开始预计的复杂得多。
一开始，我先尝试通过邮件联系；邮件没有得到回复之后，才决定改走 GitHub Issue。后面又经历了广告要求、Tour 与其他站内内容的链接边界、问题反馈入口、生产环境改造等一系列问题。
最终，从第一次尝试联系，到 4 门语言正式出现在 go.dev 上，这件事才真正闭环。
这个项目，本来就是从 Go local 开始的
我其实很早就知道 A Tour of Go 有一个 Go local 页面：
甚至可以说，我最开始决定做这个项目，本身就和这个页面有关。
当时我发现，Go local 里原来的简体中文翻译已经无法正常访问。
也正是因为看到这个缺口，我才开始考虑：
是否可以自己维护一个长期可用、能够持续跟随上游更新的简体中文版本？
后来，这件事逐渐从一个中文翻译项目，扩展成了多语言翻译项目：
所以，申请进入 Go local 并不是我最近才想到的事情。
从项目一开始，这其实就是一个很自然的长期目标。
一开始，我选择的是发邮件
最初我没有直接创建 GitHub Issue，而是先向 golang-nuts 发邮件。
第一封邮件是在 2026 年 8 月 22 日发送的，主要申请添加简体中文版本。
一周没有收到回复之后，8 月 29 日我又跟进了一次。
那时候德语版本也已经完成，因此第二封邮件里同时补充了德语站点，并询问：
如果第三方语言列表更适合通过代码修改或其他方式提交，希望对方告诉我推荐的流程。
但邮件依然没有得到回复。
这时候我开始觉得，继续等待意义不大。
Go 本身是一个高度依赖 GitHub Issue 和 Gerrit 的开源项目。既然这是一个明确的网站修改需求，那么直接提交 Issue，可能反而才是更合适的方式。
从邮件转向 GitHub Issue
于是，我最终创建了：
golang/go#81336
https://github.com/golang/go/issues/81336
这一次我没有只申请中文。
当时已经具备稳定维护条件的有 4 门语言：
- Simplified Chinese
- French
- German
- Korean
我的想法其实很简单：
这些翻译都来自同一个仓库、同一套维护流程，并且会持续跟踪上游 A Tour of Go。
如果官方愿意接受，与其每完成一门语言再单独申请一次，不如先把目前已经成熟的几个版本一起提交。
Issue 创建以后，事情终于开始有了进展。
但第一个真正的问题，并不是翻译质量。
而是广告。
第一个意外：Go 官方不接受带广告的 Tour
我的这些站点从一开始就是实际运行的网站。
既然需要服务器、域名、CDN、维护时间，我也接入了 Google AdSense，希望多少补贴一些长期维护成本。
最开始我以为，只要广告不要遮挡教程内容，问题应该不会太大。
当时课程页面主要存在：
- Auto Ads；
- 一个课程页手动广告位；
- 部分自动广告形式。
维护者第一次反馈时，提到的是页面左下角的广告弹出。
于是我先关闭了弹窗、锚定等比较打扰学习体验的广告形式。
我原本以为这样应该就够了。
后来维护者进一步说明，她指的是页面中的 display ads，并明确表示：
As far as I’m aware, the other Go local tours linked from
https://go.dev/tour/welcome/2do not have any display ads. We won’t be able to link to these translations unless they are free of ads.
也就是说，这已经不是：
“不要有侵入式广告。”
而是：
如果要进入 Go local，Tour 本身必须没有广告。
这时候我其实纠结了很久。
为一个官方入口放弃 Tour 广告，值得吗？
这不是一个纯技术问题，而是一个商业上的取舍。
我最早优先翻译 /tour，就是因为我认为 A Tour of Go 是非常高质量的内容。
真正学习 Tour 的用户，经常会连续点击很多课程页面。
从广告角度看，这类页面其实是有价值的。
如果一门语言加入 Go local，就意味着这一门语言的整个 /tour/... 都需要保持无广告。
如果以后有 10 门、20 门语言满足条件并申请官方链接，那相当于越来越多的 Tour 页面放弃直接广告变现。
所以我当时真正考虑的是：
牺牲 Tour 的直接广告收入，换取 Go 官方入口，到底值不值？
后来我还是决定接受这个条件。
原因不是因为广告不重要，而是因为我认为 Go 官方入口本身可能带来另外一种长期价值。
Go 官方入口的价值，不只是一个外链
我从来没有把这些翻译站看成是在和 go.dev 竞争。
go.dev 主要提供英文内容，而我维护的这些站点面向的是不同语言的用户。
两者本身就是互补关系。
如果真要谈竞争，更多也是和同一种语言里的其他第三方翻译、教程站点竞争，而不是和 Go 官方英文站竞争。
所以我真正考虑的是另一件事：
如果用户本来就会先到 Go 官方页面，那么能不能让官方页面直接成为这些社区翻译的入口？
一旦被列入 Go local，访问路径就变成：
go.dev → 对应语言的翻译站
这意味着用户不需要先通过搜索引擎辨别哪个第三方翻译站更可信，而是可以直接从 Go 官方列出的语言入口进入。
这种价值，并不能简单拿 /tour 少赚了多少广告收入来衡量。
它至少可能包括：
- 官方入口带来的直接流量；
- Go 官方页面提供的信任背书；
- 高质量反向链接；
- 后续可能产生的品牌认知和回访；
- 对搜索引擎抓取和收录可能产生的长期影响。
所以我最终决定：
对申请 Go local 的语言，Tour 无广告；
其他没有进入 Go local 的语言，继续保持正常商业化能力。
项目内部后来把这两种模式正式区分为：
go-localstandard
目前 go-local 就是：
- zh-CN
- fr-FR
- de-DE
- ko-KR
而其他语言仍然是 standard。
这样至少不会因为 4 门语言的官方要求，把整个项目所有语言都永久绑定到同一套商业限制上。
不只是关闭广告，Tour 里的链接也需要调整
广告问题确认之后，又出现了一个更具体的要求。
A Tour of Go 的很多原始页面中存在这样的根相对链接：
/doc/.../blog/.../pkg/.../cmd/.../ref/.../talks/...
在 go.dev 上，这些链接本来都会进入 Go 官方内容。
但在我的独立翻译域名中，它们会被浏览器解析成当前站点下的路径。
这其实和我后续的项目规划存在直接关系。
我并不打算只翻译 /tour。
这 4 门语言后续仍然计划继续扩展：
/doc/blog- 以及其他 Go 相关内容
而且这些非 Tour 内容，我并不打算放弃广告展示。
所以最初我其实希望未来可以形成这样的站内路径：
/tour → 本站 /doc /blog
这样用户学完 Tour 以后，还可以继续留在同一个语言站里阅读更多 Go 内容。
但在沟通中，维护者明确要求：
从 Tour 中直接点击进入的这些内容，同样不能落到带广告的本站页面。
这意味着，如果我以后真的上线本站 /doc、/blog，那么现有 Tour 里的那些根相对链接就会直接进入带广告内容，不再符合 Go local 的要求。
因此，我才把 Tour 中原本属于 Go 官方内容的 /doc、/blog、/pkg、/cmd、/ref、/talks 等链接统一改回对应的：
这并不意味着我会放弃这 4 门语言后续的 /doc、/blog。
相反，我仍然计划继续翻译和扩展这些内容，而且 /doc、/blog 仍然会保留广告展示。
真正发生变化的是入口关系。
我不再让 /tour 里的这些链接直接进入本站未来的商业化内容，而是计划把 /doc、/blog 的入口放在本站首页。
最终形成的路径更像：
Go 官方 → /tour → 本站首页 → /doc /blog
而不是：
Go 官方 → /tour → 直接进入带广告的 /doc /blog
对我来说，这个边界是可以接受的。
虽然牺牲了 Tour 对其他内容的直接导流能力，但并没有放弃整个语言站后续的商业化空间。
还有一个细节：用户发现问题后，应该去哪里反馈？
当广告和链接问题基本解决以后，Go 维护者 Dmitri Shuralyov 又注意到了一个很实际的问题：
这些社区翻译如果出现问题，右上角的 “submit feedback” 应该指向哪里？
最初，我的翻译站仍然沿用了上游配置：
https://go.dev/doc/contribute#check_tracker
但这其实并不合理。
因为用户在我的翻译站里遇到的问题，很可能是：
- 翻译错误；
- locale 特有问题；
- UI 问题；
- 部署问题；
- 我的项目自身实现问题。
这些问题直接发给 Go 官方，反而增加上游维护者的负担。
因此我接受了建议，把统一反馈入口改成：
https://github.com/shuijingwan/go-tour-i18n/issues
以后流程就很清楚：
用户先向我的翻译项目反馈。
如果我确认问题来自 Go 上游，再由我整理后向上游提交。
这其实也是我很认可的一种开源维护方式。
既然我希望 Go 官方长期链接这些站点，那么我自然也应该承担对应的第一层维护责任。
法语站还出现了一个缓存小插曲
反馈入口部署完成以后，我分别更新并验证了中文、法语、德语和韩语站。
但维护者测试时发现：
简体中文、德语、韩语都已经正常跳转到新的 GitHub Issues，而法语点击后似乎仍然只是在新标签页打开当前页面。
我重新检查 production：
- deployment PASS；
- machine acceptance PASS；
- browser acceptance PASS；
- visual HUMAN gate PASS。
我又分别使用正常浏览器和隐私窗口测试法语站。
两边都能够正确打开：
https://github.com/shuijingwan/go-tour-i18n/issues
于是我回复对方：
可能是浏览器仍缓存了旧 JavaScript，可以尝试 hard refresh。
稍后维护者再次确认：
Thanks! It’s working for me now. Will merge the change to add these to the website.
到这里，我基本知道这件事已经成功了。
接下来只剩代码合并和官网部署。
CL 829864：4 门翻译正式进入 Go 网站源码
对应修改随后进入 Go Gerrit：
https://go-review.googlesource.com/c/website/+/829864
提交标题很直接：
_content/tour: add translations
最终合并进入 golang/website。
对应 commit：
db076098077c07d3cef1b85a2cf56ff52777f587
Issue #81336 随后被 GopherBot 标记为 completed 并关闭。
这次修改一共加入 4 个链接：
- French
- German
- Korean
- Simplified Chinese
从这一刻开始，申请本身其实已经正式成功。
但我仍然在等最后一步：
go.dev 生产站真正部署。
2026 年 9 月 11 日：正式上线
到了 2026 年 9 月 11 日，我再次打开：
这一次，4 门语言已经全部出现在公网生产环境。
这张图对我来说，比 commit merged 更有意义。
因为它代表的不只是代码已经进入仓库，而是：
普通 Go 用户已经真的可以从 go.dev 点击进入这些翻译站了。
到这里，从最开始发邮件无人回复，到最后进入官方 Go local，这件事终于完整闭环。
回头看，这次最大的代价其实不是开发时间
如果只看技术改造，这次并不算特别困难。
真正让我反复纠结的，其实还是：
为了官方链接放弃
/tour广告，到底值不值？
目前还没有答案。
现在刚刚上线，还不可能用一天两天的数据得出结论。
但至少有一件事已经发生变化：
之前这些站点只能依靠：
- 搜索引擎；
- GitHub；
- 我的博客；
- 直接访问；
- 其他自然外链。
现在又多了一个非常特别的入口：
go.dev 本身。
而且我一次拥有了 4 个实验样本。
可以把：
- zh-CN
- fr-FR
- de-DE
- ko-KR
作为 go-local 组；
把：
- ja-JP
- es-ES
- it-IT
- nl-NL
- pt-BR
- 以及未来其他语言
作为 standard 组。
以后就可以真实观察：
- go.dev referral 能带来多少访问；
- 是否提高回访率；
- 是否改善搜索引擎抓取和收录；
- 是否带来更好的品牌认知；
- 官方反向链接是否产生 SEO 价值；
- 这些收益能否抵消 Tour 本身失去的广告收入。
这会比任何理论分析都更有价值。
我打算把 2026 年 9 月 11 日作为 Day 0
后续我准备分别观察：
- 7 天；
- 30 天；
- 90 天。
尤其关注四门 Go local 语言与其他 standard 语言之间的差异。
如果未来发现：
官方链接确实能够持续带来稳定流量，并且明显改善搜索表现、回访和品牌认知，
那么以后遇到 Go local 尚未覆盖、同时具有较高商业潜力的语言，我可能会继续采用：
无广告 Tour ↔ Go 官方入口
这种模式。
反过来，如果几个月之后发现：
官方 referral 很少、SEO 没明显变化、品牌收益也不明显，那么我也会知道：
后续没有必要为了官方链接继续牺牲更多语言的 Tour 广告。
现在还不需要提前下结论。
先让数据自己说话。
接下来：再次同步上游
这次正式上线以后，我还准备马上再做一件事：
重新同步一次 A Tour of Go 上游。
原因也很简单。
现在这 4 个站点已经变成了会被 Go 官方页面直接导流的社区翻译。
既然获得了这个入口，我也希望进入这些站点的用户尽可能看到最新的 A Tour of Go 内容。
后续我仍然会继续维护：
https://github.com/shuijingwan/go-tour-i18n
并逐步增加更多语言。
不过对于已经存在其他官方社区翻译的语言，我不会以替换对方为目标。
新的语言是否继续申请 Go local，也会结合这 4 门语言接下来几个月的真实数据再判断。
写在最后
这次经历给我的一个很直观的感受是：
很多开源项目的“官方收录”，真正考察的并不只是：
你有没有把文字翻译出来。
它还包括：
- 内容是否长期可访问；
- 是否持续维护；
- 页面体验是否合适；
- 商业化是否符合官方接受范围；
- 出现问题以后谁负责；
- 用户应该向哪里反馈；
- 项目是否具备长期维护能力。
最开始，我只是想申请一个链接。
最后真正做出来的，却是一套专门面向 Go local 的发布策略。
从商业角度看，我也确实付出了代价：
4 门语言的 /tour 不再直接产生广告收入。
但换回来的东西同样很明确：
- Go 官方入口；
- 来自
go.dev的高质量反向链接； - 社区翻译身份的公开展示；
- 更低的用户信任成本；
- 一个可以长期观察官方导流价值的真实实验。
到底划不划算，现在还太早。
但至少这一次，我终于不用再猜了。
因为从 2026 年 9 月 11 日 开始，我已经可以用自己的真实数据来回答这个问题。
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 官方无隶属或授权关系。