没有不值得去解决的问题,也没有不值得去学习的技术!

从 Go Weekly 到 Reddit、DEV 和 Go Forum:第一次系统推广 A Tour of Go 多语言项目

图5:评论成功发布

作者:

在

Go 学习与文档多语言本地化项目

图3:访问过去的 Go Tour 简体中文站 tour.go-zh.org 时,当前已经无法正常建立连接。

(1) 从「A Tour of Go 中文版」这个搜索词开始:我决定做一个持续维护的 Go Tour 中文版

本地运行的 A Tour of Go「Methods continued」课程页面,左侧为课程说明,右侧为 Go 代码编辑器及运行结果。

(2) A Tour of Go 中文版项目设计冻结:从 101 页到 103 页,从 Gin 转向 Cobra CLI

A Tour of Go 中文版开发实战:英文基线、在线运行与 101 页上游同步体系

(3) A Tour of Go 中文版开发实战:英文基线、在线运行与 101 页上游同步体系

go-tour-i18n 项目完成首个简体中文课程页面 welcome/1 的整页翻译、结构校验和本地预览。

(4) A Tour of Go 多语言翻译项目实录:完成首个 zh-CN 页面翻译闭环

图 1:DeepSeek 官方更新日志显示,本次只更新 DeepSeek-V4-Flash,DeepSeek-V4-Pro API 与 APP、Web 模型均未更新

(5) A Tour of Go 中文翻译项目进展:完成前 8 页、修复 present 语法,并暂缓 DeepSeek 对比

图 1:generics/1 简体中文页面本地预览

(6) 一个页面重试五次:使用 GLM-5.2 翻译 A Tour of Go 时遇到的 Token 与 Present 结构问题

图 1:methods/16 简体中文页面浏览器预览

(7) A Tour of Go 中文翻译实录:如何只翻译教学代码注释,而不破坏 Go 代码

图 2:A Tour of Go methods/20「练习:错误」中文候选页面最终渲染效果

(8) A Tour of Go 多语言翻译:当正确的中文语序被受保护标记顺序校验误判

图 3:methods/24 中文页面,静态代码、Bounds 行内代码和链接内的 image.Rectangle 均正确渲染

(9) A Tour of Go 中文翻译完成 7 个代表页校准:最后 3 页又发现了哪些真实问题

图 2:首批 10 个普通页面经过试跑与流程校准后全部进入 ready

(10) A Tour of Go 多语言翻译项目:首批 10 个普通页面试跑,从 2 个 blocked 到全部 ready

图 2:flowcontrol/6 最终中文页面,return 与 v 为适应自然中文语序发生整体换位

(11) A Tour of Go 中文翻译第二批实跑:从 Inline Code 顺序误判到历史响应重新验证

图 1:flowcontrol/6 首次原始输入实验直接通过统一自动校验

(12) A Tour of Go 多语言翻译项目:从 swap 问题重新审视 Token 保护,原始输入与最小保护的一次真实实验

图 7:moretypes/1 最终中文页面预览。左侧课程正文、静态代码块、行内代码和教学注释均正常渲染,右侧官方 Go 示例继续保持原样。

(13) A Tour of Go 多语言翻译实战:第三批 10 页全部 Ready,继续校准 Protected Token 的结构角色

图 4:上游源码确认共有 103 个课程页面,zh-CN 最终达到 ready=103、pending=0、blocked=0

(14) A Tour of Go 多语言翻译项目:zh-CN 103 个课程页面全部 ready,课程正文翻译阶段完成

图 4:GitHub 与 ChatGPT 已成功连接

(15) ChatGPT 连接 GitHub 实测:让 AI 直接读取 go-tour-i18n 仓库参与译文审核

图 3:中文 Go 术语校准完成后,将确定的译法写入 zh-CN glossary

(16) 为什么 channel 最终选择“通道”:A Tour of Go 中文术语统一的一次实践

图 1:技术含义基本正确,但“返回一个返回……”已经明显影响阅读,因此仍被列入 C 类修订

(17) 103 页逐页审核后,只返修 16 页:A Tour of Go 中文正文发布前质量审计

图 2:中文课程页面以及已经完成本地化的编辑器控制区

(18) A Tour of Go 多语言翻译项目:公共 UI 本地化完成,从课程译文走向完整中文界面

图 2:完整 zh-CN 正式投影成功生成,103 个课程页面被重新组装为 7 个 .article

(19) 从 103/103 ready 到完整站点验收:A Tour of Go 中文版补齐正式投影与课程元数据本地化

图 3:从 production bundle 独立启动的 A Tour of Go 简体中文页面,课程正文、公共 UI 和官方 Go 示例均已进入最终发布形态。

(20) A Tour of Go 多语言翻译项目:103 页全部完成后,我终于生成了可独立部署的 zh-CN Production Bundle

图 1:A Tour of Go 简体中文版正式生产页面,远程运行已经成功输出“Hello, 世界”。

(21) A Tour of Go 多语言翻译项目:zh-CN 正式上线,从生产发布到 go.dev Playground 的完整部署记录

图 1:新生产域名 go-dev.shuijingwanwq.com 已正常访问,Go 示例远程运行成功

(22) A Tour of Go 多语言翻译项目:从 go-tour 到 go-dev,完成 EdgeOne、Nginx 与 HTTPS 生产域名迁移

图 1:A Tour of Go 多语言翻译项目正式生产首页

(23) A Tour of Go 多语言翻译项目正式上线:从项目首页、公共 Footer 到生产发布元数据的完整收尾

图 3:GA4 g/collect 请求返回 HTTP 204,并携带当前课程页面地址,确认 Google Analytics 已产生真实事件上报

(24) A Tour of Go 多语言翻译项目:接入 Google Analytics 与百度统计,从 systemd 注入到 EdgeOne 与真实上报验证

图 1:生产环境 robots.txt 与 sitemap.xml 已正确对外提供,Sitemap 共包含 104 个规范 URL。

(25) A Tour of Go 中文站上线后:补齐 robots.txt、Sitemap,并完成五大搜索引擎提交

图 4:发布生产并刷新 EdgeOne 缓存后,再次通过真实手机访问,顶栏项目名称已经完整保持在一行,最终移动端验收通过。

(26) A Tour of Go 多语言翻译项目:修复手机端首页顶栏标题换行,并完成真机验证

图 3:生产自动部署脚本第一次真实运行时,systemd 已经显示 active,但首次 localhost 探测仍然得到 HTTP 000;随后连续 3 次同时满足 active + HTTP 200 后,脚本才判定部署成功,并继续完成公网 HTTP 200 验收。这次真实运行验证了连续应用层健康检查的必要性。

(27) A Tour of Go 多语言翻译项目:从一次 203/EXEC 故障到生产自动部署脚本落地

图 1:阿里云生产环境访问 go.dev Playground 时出现 TLS 握手超时

(28) A Tour of Go 多语言翻译项目:为 Playground 搭建独立的 ZgoCloud 执行代理

图 3:清除 /tour/script.js 缓存后,Run 已直接请求 ZgoCloud /compile 并返回 HTTP 200

(29) A Tour of Go 多语言翻译项目:将生产 Run / Format 切换到 ZgoCloud 执行节点

【图 1:微信中运行 Go 示例时出现 Error communicating with remote server.】

(30) A Tour of Go 中文版手机端运行与格式化偶发失败排查:从间歇性报错到补强 Nginx 可观测性

【图 4:向 golang-dev 公开邮件列表发送 Playground 使用告知邮件并投递成功】

(31) A Tour of Go 多语言项目:为 Playground 代理增加唯一 User-Agent,并主动告知 Go 官方

【图 3:百度剩余 9 个核心 URL 提交成功,remain 归零】

(32) A Tour of Go 搜索引擎收录实测:从 Google 自然索引到百度主动提交与 Bing IndexNow

【图 1:当前正式中文 methods/24 页面,右侧示例代码运行成功】

(33) A Tour of Go 中文翻译完成后,我为什么重新评估 minimal-protect 翻译模式

【图 3:5 个页面 Request SHA256 完全一致,但 Response SHA256 全部不同】

(34) A Tour of Go 翻译实验:更多原始上下文为什么没有更好?从 157 个保护标记到 30 次重复盲评

图 3:3 个代表页 × 4 个评审模型,共 12 次匿名评审的完整排名与第一名票数。

(35) A Tour of Go 翻译质量再评估:minimal-protect 未达预期后,我开始比较 ChatGPT、Codex 与 GLM-5.2

图 2:GitHub 中的 chatgpt-zh-CN-008 重译批次。一个 Batch 同时保存 inputs、raw-responses、candidates、validation 和 retry 记录,GitHub 成为 ChatGPT 与本地翻译流水线之间的数据交接层。

(36) 没有 OpenAI API,我如何用 ChatGPT + GitHub 完成 A Tour of Go 103 页全量重译

图 1:103 个正式课程页面完成最终语义质量审核,结果为 A=103、B/C/D=0,同时不存在缺失、重复或额外页面。A/B/C/D 是本轮项目内部语义质量分级,并不是自动结构 validator 的结果。

(37) 103 页翻完还不能发布:A Tour of Go ChatGPT 译文的语义审核与 Canonical Promotion

图 3:7 个 article endpoint 的 production origin 与 EdgeOne 公网响应全部 exact match,同时新的 ChatGPT 译文标记存在,旧版译文标记已经消失。

(38) 103/103 与 7/7 Exact Match:A Tour of Go ChatGPT 新译文的最终线上验收

【图 2:upstream source preview】

(39) A Tour of Go 多语言翻译项目首次实现 upstream 同步机制:从一次性翻译到长期维护

图 2:A/B/C/D 质量评级规则,展示正式质量 rubric 与 Promotion gate。

(40) A Tour of Go 多语言翻译项目引入 Translation Quality Review:从自动验证到 AI 翻译质量控制

图 4:翻译后 Playground Example,展示中文注释与保持不变的 Go 代码结构。

(41) A Tour of Go 多语言翻译项目实现 Playground Example 本地化:从代码注释翻译到完整学习体验

图 5:公网页面验证广告脚本输出

(42) A Tour of Go 多语言翻译项目接入广告系统:从 AdSense 专用配置到通用 HTML 注入架构

图 3:百度统计单页应用设置

(43) go-dev 单页网站接入统计与 Google AdSense Auto Ads 验证记录

图 1:GitHub 仓库中的多语言翻译项目结构

(44) A Tour of Go 多语言翻译项目:选择日语作为第二语言并启动翻译验证

图 5:模型身份描述不一致

(45) A Tour of Go 多语言翻译项目中的 AI 协作异常排查:一次长期工程会话失效分析

【图 1:ChatGPT GitHub 写入流程调整说明截图】

(46) go-tour-i18n 翻译流程调整:从 ChatGPT GitHub 写入到本地 artifact 导入

图 4 展示了本次异常状态。

(47) go-tour-i18n 翻译自动化流程复盘:已验证的 ChatGPT 翻译能力在新任务中的稳定性问题

【图 6:全部评审结束以后才读取 secret key,完成最终揭盲】

(48) A Tour of Go 翻译质量再评估:Codex High 已接近 ChatGPT High,我决定调整默认翻译引擎

图 4:ja-JP 生产课程页实际运行 Go 示例

(49) A Tour of Go 日语版正式上线:第二门语言 ja-JP 完成生产发布

图 1:ja-JP 上线以后,先提交“新增语言标准化流程”

(50) A Tour of Go 多语言扩展复盘:为第三门语言建立标准化流程

图 1:课程正文结束以后,页面左侧仍然存在大块视觉空白,但 AdSense 并没有在这里插入展示广告。

(51) A Tour of Go 明明有大片空白,为什么 AdSense 就是不显示展示广告?

图 2:golang/website 当前的 _content/tour/。课程内容、静态资源和模板都在这个上游目录中持续维护。

(52) 为了 AdSense,要不要放弃 SPA?A Tour of Go 页面架构的一次取舍

图 4:最终的手动课程广告真实展示在课程内容区域内,而不是 footer 之后。

(53) 保留 SPA 以后,广告应该放在哪里?从 AdSense 预览到方案 B

图 1:Google Search Console 中,多个不同的 A Tour of Go 课程 URL 被判断为“重复网页,用户未选定规范网页”。

(54) SPA 的 SEO 老问题:为什么最后还是给 103 个 A Tour of Go 课程页生成了 Prerender HTML

图 2:方案 B 生产环境中,源码已经正常,但课程主体高度异常缩短,footer 提前进入第一屏。

(55) 从源码空白到 AdSense 高度污染:A Tour of Go 方案 B 的生产收尾

图 1:A Tour of Go 德语版 de-DE 已正式运行在生产环境

(56) A Tour of Go de-DE 上线复盘:第三门语言用了约 16 小时,下一门如何压到 8 小时?

图 1:fr-FR 首次 production 验收完成后,我没有立即开始 ko-KR,而是先连续完成新增语言与首次生产流程的优化

(57) 法语版上线后,我没有马上开始韩语:A Tour of Go 新增语言流程的一轮完善与简化

图 1:根据 ko-KR 期间 76 次 Git 提交估算实际工作时间

(58) 原本预计 6 小时,最后用了约 16~18 小时:A Tour of Go 韩语版上线复盘

图 2:英文 source 与当时发生 validation failure 的 ko-KR candidate 对比

(59) Validator 报错,到底该改译文还是改规则?一次 A Tour of Go 韩语翻译实战

图 2:法语 A Tour of Go 仓库目前已经归档,页面仍保留 553 Commits 和 61 Contributors 的历史

(60) 从法语 553 次提交到韩语两代离线:A Tour of Go 社区翻译为什么难以长期维护

【图 4:es-ES 首次 Production 收口后连续完成的流程优化 commit】

(61) 从 es-ES 首次上线复盘:我把 A Tour of Go 新增语言的 Production 流程又收敛了一轮

图 1:旧公网验收链路连续出现 curl 28 超时,最终导致 public-machine 阶段失败

(62) A Tour of Go Production 公网验收踩坑:从跨境 SOCKS 链路改为 zgocloud direct

图 1:两次 Production Machine Acceptance 都已经通过,但 Headless Chrome 分别在 / 和 /tour/ 判定页面没有完成渲染

(63) 页面明明能打开,为什么 Headless Chrome 仍然判定 Production 失败?

图 3:Bing 从 Google Search Console 中识别到新的 it-IT 站点,并同时发现已有的 1 个 sitemap

(64) GSC → Bing Webmaster Tools:多语言站点如何减少重复验证

图 3:英文站 3 小时内出现 565 个 Cloudflare 来源 URL

(65) IndexNow 实战:手工提交长期不显示,Cloudflare Crawler Hints 却很快出现在 Bing Webmaster Tools

【图 1:A Tour of Go 项目首页目前的语言版本列表】

(66) 从 nl-NL 到 tr-TR:A Tour of Go 连续上线三门语言后,我又优化了哪些流程

【图 4:Go local 页面中已经出现 French、German、Korean、Simplified Chinese】

(67) 从邮件无人回复到进入 Go 官方 Go local:我的 4 个 A Tour of Go 翻译站终于被收录

图8:最终只保留一把启用的新 API Key

(68) 腾讯云 EdgeOne API 自动化:从 CAM 子用户到最小权限 API Key 的完整配置

【图 7:Production Release Batch 最终汇总】

(69) 从同步 Go 官方上游到一个命令发布 10 个语言站:A Tour of Go Production 流程的再次收敛

【图 3:Cloudflare Smart Tiered Cache 已启用】

(70) Cloudflare 缓存 HIT 很快,MISS 却不稳定:回源阿里云杭州的一次真实优化

【图 3:简体中文站 Support 页面】

(71) 广告之外,社区项目如何长期活下去?我给 A Tour of Go 多语言项目加了 Support

图5:评论成功发布

(72) 从 Go Weekly 到 Reddit、DEV 和 Go Forum:第一次系统推广 A Tour of Go 多语言项目

【图 4:RTL 桌面课程布局修复后的效果】

(73) 第一次把 A Tour of Go 做成 RTL:阿拉伯语版本上线,以及我踩过的几个坑

多语言项目应该先做哪些语言?我的 66 个语言版本商业优先级排序

(74) 多语言项目应该先做哪些语言?我的 66 个语言版本商业优先级排序

当术语一致性遇到性能瓶颈:Go 多语言翻译项目的一次架构取舍

(75) 当术语一致性遇到性能瓶颈:Go 多语言翻译项目的一次架构取舍

从 A Tour of Go 走向 Go Learning & Documentation:为什么这个多语言项目需要 v2

(76) 从 A Tour of Go 走向 Go Learning & Documentation:为什么这个多语言项目需要 v2

Markdown 明明可以拆成很多段,为什么 v2 仍然坚持一个 Page 就是一个 TranslationUnit

(77) Markdown 明明可以拆成很多段,为什么 v2 仍然坚持一个 Page 就是一个 TranslationUnit

Tour、Learn、Docs 为什么不应该各维护一份术语表:v2 的统一 Glossary 设计

(78) Tour、Learn、Docs 为什么不应该各维护一份术语表:v2 的统一 Glossary 设计

v2 术语表变更后的页面影响范围判断流程:区分 Compatible 与 Affected,只处理真正受影响的页面。

(79) 术语表改了,为什么不应该让所有页面重新翻译?v2 的影响范围判断

CLI 性能优化示意图:通过 Prepare Once、Reuse Many Times,将执行时间从 6m54.554s 降至 10.335s,约提升 40.1 倍。

(80) 从 6 分 54 秒到 10.3 秒:Go 多语言项目一次 CLI 性能优化实战

Markdown Page 经过 Parse / Protect、Generation 和 Reconstruct / Validate 的流程示意图,强调保护 inline code、链接、代码等机器语义,同时允许译文按照自然语言调整语序。

(81) Markdown 不是纯文本:Learn / Docs 为什么需要新的 parser 与结构保护

历史为什么值得保留:复用已经完成的翻译成果,而不是重新做一遍

(82) 历史为什么值得保留:复用已经完成的翻译成果,而不是重新做一遍

历史状态通过 Trusted Checkpoint 建立可信断点,旧记录继续保留用于审计和诊断,后续工作流从当前状态继续向前,不再要求无限重建过去。

(83) 历史应该被保留,而不是被反复重建:v2 为什么最终需要一个“断点”

v2 依赖与失效传播流程图:从内容变化开始,评估依赖关系和真实影响,将结果区分为“仍然有效”和“需要失效”,只让真正受影响的状态重新进入流程。

(84) 一次内容变化,到底应该让哪些状态失效?v2 的依赖与失效传播设计

v2 本地内容覆盖判断流程图:官方英文页面先检查是否已有正式本地覆盖,有覆盖时使用本地 URL,没有覆盖时直接链接 go.dev,并保持本地路径真实 404。

(85) 有英文页面,不代表一定应该有本地页面:v2 如何处理本地内容覆盖、canonical 与真实 404

v2 代码注释完整性审计流程图:从源页面建立代码块清单,分类教学注释、机器语义和无法判断的内容,再与当前译文精确对应,确认 missing、extra 和 protected mutation 均为 0。

(86) 代码块里的注释为什么不能只靠肉眼检查?v2 如何统计并验证代码注释翻译完整性

结构化语义输入扩展示意图:同一份 books.yaml 原始文件保持不变,旧 parser 识别 10 个可本地化单元,当前 parser 识别 12 个,并新增 PDF 和 GitHub,确认旧单元无删除无修改后重新进入 Generation。

(87) 原始文件一个字没变,为什么还要重新翻译?从 books.yaml 10→12 看语义输入扩展

v2 Activation 流程图:Surface PASS 后先执行只读 activation-preflight 获取 prior_sha256,activation-apply 时通过 CAS 再次比较当前状态,只有 current 等于 prior 才提交 result_sha256,否则停止并重新 preflight。

(88) 审核都通过了,为什么上线前还要再检查一次?v2 的 Activation、prior SHA 与 CAS 设计

v2 分层验证流程图:TranslationUnit、Package Closure 和 Integrated Surface 均通过后进入 Activation,再由 Preview 检查 LoadContent、Compose、Resolver 和 Renderer 的真实运行链;如果实际使用错误 renderer,即使前置内容全部通过,Preview 仍然失败。

(89) Surface 已经 PASS,为什么 Preview 还是会失败?从一次 wrong renderer 看分层验证的价值

更快不一定更好:为什么我主动撤销了一次已经明显变快的性能优化

(90) 更快不一定更好:为什么我主动撤销了一次已经明显变快的性能优化

TranslationUnit 同类问题完整性示意图:左侧 Reviewer 只列出 3 个 examples,Generation 只修这 3 处后仍留下 5 个同类问题,re-QC 再次判 B;右侧 Reviewer 明确 defect category 和 bounded scope,Generation 执行 same-class complete sweep,最终同类残留为 0 并进入 re-QC A。

(91) 为什么修完 Reviewer 指出的所有例子,下一轮还是会失败?从 B→revision→B 看同类问题完整性

immutable source 与 replacement successor 示意图:左侧直接把旧 canonical source A 覆盖成 source B,会使旧 Generation、Review 和 Closure evidence 失去准确对应;右侧保留 source A 作为 immutable predecessor,为新正文建立 source B successor,并重新进入 corpus、glossary review、Generation、QC、closure、Surface 和 Activation 生命周期。

(92) 页面明明是我自己的,为什么不能直接重写?从 /translation/ 改版看 immutable source 与 replacement successor

protected representation 修订能力示意图:左侧 http.Client 被正确保护为 token;中间普通自然语言 Documentation 被错误保护为 opaque token,导致合法 revision 被阻塞;右侧保留旧 representation,通过 representation successor 建立新的可编辑表示,再继续 Generation 和独立 re-QC。

(93) 保护机制也会保护错东西:为什么一个 Documentation 能阻塞整页修订?

一个候选快照原本只应包含 1 个首页翻译单元,却因内容包范围未显式绑定而错误纳入 122 个翻译单元;通过 --content-package site-v2-shell 明确内容包后恢复到正确范围。

(94) 一个候选快照为什么突然多出 122 个单元?从隐式范围到显式内容包契约

Shell 自动化中,当前性检查命令失败并打印 RESULT=FAILED,但由于顶层子 Shell 中错误使用 return,后续命令仍继续执行,最终又打印出错误的 RESULT=PASS。

(95) 命令明明失败了,为什么最后还是 PASS?一次 Shell 自动化的 fail-closed 教训

【图8:Google AI 概览——引用网站的课程目录页】

(96) 同一个 Go 语言之旅网站,Bing、Google 和百度的搜索表现差距有多大?

多个正式命令原本分别重复构建当前内容成员、历史审核链、回执、SHA 和身份标识等可信环境;优化后改为先建立一次已验证的执行环境,再由 current-check、result-pack、import 等连续命令安全复用。

(97) 一个命令快了还不够:为什么我的性能优化开始转向跨命令环境复用

learn-docs-v1 原本以 49 个页面完成了翻译、审核和最终确认,后来发现还缺少 /doc/ 与 /doc/install 两个页面,导致内容包必须从 49 Page 迁移到 51 Page。图片对比了“后期补齐造成迁移成本”和“在 Generation 前先完成成员完整性审计”两种方式。

(98) 只是多了 2 个页面,为什么却触发了一次 49→51 的迁移?

最近一段时间,我一直在推进自己的 A Tour of Go 多语言翻译项目。

项目地址:

https://github.com/shuijingwan/go-tour-i18n

目前已经有 11 个语言版本正式上线:

  • 巴西葡萄牙语
  • 荷兰语
  • 法语
  • 德语
  • 意大利语
  • 日语
  • 韩语
  • 简体中文
  • 西班牙语
  • 瑞典语
  • 土耳其语

其中一部分语言版本也已经出现在官方 A Tour of Go 的本地化页面中:

https://go.dev/tour/welcome/2

之前,我在推广上主要依赖几个渠道:

  • go.dev 官方页面提供的链接;
  • Google、Bing 等搜索引擎;
  • GitHub;
  • 自己的技术博客。

但随着语言越来越多,我开始意识到一个问题:

如果只是把网站上线,然后等待搜索引擎慢慢收录,增长速度可能会非常慢。

另外,从搜索引擎后台看到的数据来说,不少新语言站点的外部链接也非常少。

所以这次我决定第一次比较系统地尝试:

除了 go.dev、搜索引擎和 GitHub 之外,还有哪些地方可以主动让 Go 开发者知道这个项目?

最后实际尝试了:

  • Go Weekly
  • Golang News
  • Reddit r/golang
  • DEV Community
  • Go Forum

过程比我原本想象的有意思很多。


一、先给 Go Weekly 投稿

最先尝试的是 Go Weekly。

Go Weekly 是专门面向 Go 开发者的英文周刊,读者本身就是非常精准的 Go 用户。

这种渠道对我来说,比在一个泛技术社区到处发链接更有价值。

我最终没有针对某一个具体语言站投稿,而是推广整个:

go-tour-i18n

项目。

邮件标题使用的是:

Go Weekly link suggestion: A Tour of Go in 11 languages

正文重点说明了几件事:

  • 这是一个非官方、社区维护的多语言 A Tour of Go 项目;
  • 当前已经有 11 个 production 语言;
  • 项目持续同步 Go 官方上游;
  • 有完整的翻译、validation、语言审核和 production publishing 流程;
  • 部分语言版本已经出现在官方 A Tour of Go localization 页面中。

邮件里只保留两个核心链接:

  • GitHub 项目
  • go.dev 官方 localization 页面

而没有把 11 个站点全部塞进去。

图1:向 Go Weekly 编辑部发送项目推荐邮件,邮件服务器显示已经成功投递到对方服务器。
图1:向 Go Weekly 编辑部发送项目推荐邮件,邮件服务器显示已经成功投递到对方服务器。

我这次还特意使用了自己的企业邮箱:

admin@shuijingwanwq.com

而不是 Gmail。

原因也很简单:这是以项目维护者身份进行联系,使用和自己网站域名一致的邮箱,会更容易建立身份关联。

当然,这里的前提仍然是企业邮箱本身投递正常。

发完之后,就只能等待编辑是否采用了。

这类投稿即使最终被收录,也不一定会单独收到回复。


二、Golang News:注册后发现社区已经不太活跃

第二个尝试的是 Golang News。

这是一个专门聚合 Go 新闻、项目和文章的网站。

从定位来看,本来非常适合这个项目。

我先注册了账号。

但是注册完成后,一打开首页,就感觉有一点不对。

图2:8 users online
图2:8 users online

而首页最新的一些内容已经是几天、几十天甚至上百天以前发布的。

和 Reddit、DEV 这种社区相比,活跃程度明显低很多。

不过既然账号已经注册好了,我还是继续尝试投稿。

一开始甚至可以正常进入 Submit Story 页面,所以我一度以为新账号可以直接提交。

但真正点击提交以后,服务器才给出了最终限制。

图3:页面提示:You need to be registered and have more than 2 points to submit stories.
图3:页面提示:You need to be registered and have more than 2 points to submit stories.

也就是说,不是注册后马上就能发。

而且这里写的是:

more than 2 points

至少要达到 3 points。

我的新账号当时只有:

1 point

理论上,我可以继续在社区参与讨论,把积分慢慢提升到可以投稿。

但结合前面看到的社区活跃程度,我最终决定:

暂时不为了这 2 个积分专门花时间。

账号保留。

以后如果自然获得足够的 points,再把项目投进去即可。

这也是这次推广过程中一个挺重要的判断:

并不是所有“Go 专门社区”都值得投入同样多的时间。

渠道本身也需要评估投入产出。


三、Reddit:选择 Small Projects,而不是直接发广告帖

接下来转到 Reddit 的:

r/golang

和 Golang News 相比,这里的社区明显活跃很多。

但 Reddit 又有另外一个问题:

如果新账号一注册,就马上创建一个专门宣传自己项目的帖子,很容易显得像广告。

幸运的是,r/golang 本身有一个很适合的固定帖子:

Small Projects

这是一个每周让开发者分享自己 Go 项目的帖子,而且发帖标准比主版宽松很多。

图4:这个入口非常适合 go-tour-i18n。
图4:这个入口非常适合 go-tour-i18n。

所以我没有创建独立主题,而是在 Small Projects 下面发布了一条评论:

go-tour-i18n — A Tour of Go in 11 languages

内容简单介绍:

  • 我是项目维护者;
  • 当前有 11 个正式上线的语言版本;
  • 项目持续同步 Go 官方上游;
  • 有翻译、validation、语言审核、同步和 production publishing 流程;
  • 部分翻译也已经出现在官方 Tour localization 页面。

链接仍然只放两个:

  • GitHub
  • go.dev
图5:评论成功发布
图5:评论成功发布

评论成功发布以后,我没有继续马上在 r/golang 创建第二个独立帖子。

我觉得这样更自然。

先正常进入社区,有真实互动以后,再决定以后是否有必要写一篇更有讨论价值的独立帖子。

例如以后完全可以写:

I’m maintaining A Tour of Go in 20 languages — lessons learned from keeping translations in sync with upstream

这种帖子本身有技术讨论价值,而不是单纯:

请访问我的网站。

顺便遇到了一个 Reddit Bug

我本来还打算完善一下个人资料。

例如:

  • 上传自己的头像;
  • 设置英文简介;
  • 让别人点进账号后能知道我是项目维护者。

结果 Reddit 的个人资料保存功能一直报错。

头像可以选择,但是保存失败。

后来连个人简介也保存失败。

折腾几次以后,我决定直接放弃。

这件事情和推广本身关系不大,也没有必要为了一个头像花太多时间。


四、DEV Community:从“发链接”升级成“写一篇真正有内容的文章”

下一步是 DEV Community:

https://dev.to

这是这次尝试中,我觉得长期价值比较高的一个渠道。

因为 DEV 并不是简单的链接聚合站。

更适合的玩法是:

写一篇本身有内容、有经验、有搜索价值的文章,然后让项目自然成为文章的一部分。

我先注册账号,并把用户名设置为:

shuijingwan

这样可以和 GitHub 保持一致。

个人资料则不只介绍 Go Tour 项目,而是从我个人的方向来写:

Independent developer and technical writer. Building open-source projects, writing about software, infrastructure, and AI, and documenting what I learn along the way.

这样以后即使写其他主题,也不需要重新调整身份定位。


五、先去 Welcome Thread 做一个正常的新成员介绍

DEV 注册以后,会有一个 Signup Checklist。

其中一个任务是:

Say hi in the Welcome thread

我没有跳过。

而是先在 Welcome Thread 中做了一段很简单的自我介绍:

Hi! I’m Shiqiang Wang, an independent developer and technical writer. I work on open-source projects and write about software, infrastructure, AI, and Go. I’m currently maintaining a multilingual A Tour of Go project as well. Looking forward to learning from the community and sharing some of what I build along the way.

没有放 GitHub 链接。

也没有放 11 个站点。

目的就是:

先作为一个正常的社区成员出现,而不是账号刚创建就开始发广告。

图6:先在 Welcome Thread 中做了一段很简单的自我介绍
图6:先在 Welcome Thread 中做了一段很简单的自我介绍

这一步虽然很小,但我觉得挺有必要。

社区推广和搜索引擎提交不是一回事。

面对真人社区时,身份和互动方式仍然很重要。


六、第一篇 DEV 文章:How I Maintain A Tour of Go in 11 Languages

完成 Welcome Thread 后,我开始准备第一篇 DEV 文章。

标题最终定为:

How I Maintain A Tour of Go in 11 Languages

图7:完成 Welcome Thread 后,我开始准备第一篇 DEV 文章
图7:完成 Welcome Thread 后,我开始准备第一篇 DEV 文章

我没有把文章写成:

我的项目有 11 个网站,请大家访问。

而是把内容重点放到了:

维护 11 个语言版本以后,我发现一个多语言技术教程真正难的地方是什么?

文章里面主要谈了:

  • TranslationUnit;
  • 每个 locale 独立 glossary;
  • 为什么翻译不能随意拆成很小的文本片段;
  • 为什么 automatic validation 不等于语言质量;
  • 为什么 validator passed 不能代表 translation finished;
  • AI 可以提高翻译速度,但不能代替语言审核;
  • 如何跟踪 Go 官方 upstream;
  • stale detection;
  • UI、metadata、SEO 等 locale surface;
  • production publishing;
  • 为什么项目仍然明确标注为 unofficial。

现在正式的 TranslationUnit 流程大致是:

Plaintext
glossary preparation
→ translation
→ automatic validation
→ Candidate Snapshot
→ language quality review
→ machine finalization
→ promotion
→ deployment

这里我特别强调了一件事情:

Validation is not language quality.

机器 validation 的职责,是保护:

  • 代码;
  • Go 标识符;
  • URL;
  • link target;
  • directive;
  • protected token;
  • preformatted content;
  • 机器语义。

但是一句话即使全部通过这些检查,仍然有可能:

  • 生硬;
  • 不自然;
  • 含义有偏差;
  • 技术表达不符合当地开发者习惯。

所以语言质量必须独立审核。

这也是我现在整个多语言翻译流程里非常重要的一条原则。

文章已经正式发布:

https://dev.to/shuijingwan/how-i-maintain-a-tour-of-go-in-11-languages-ahl

这篇文章的标签使用的是 Go、Open Source、i18n、Show DEV 这一类项目相关标签。

在文章末尾,我仍然只保留:

  • GitHub
  • go.dev localization page

而没有为了“外链数量”故意堆 11 个子域名。


七、外链不是越多越好

这次推广过程中,我也重新想了一下“外链”这件事情。

最开始,我确实考虑过:

既然很多语言站在搜索引擎后台都显示几乎没有外链,那是不是每发一篇帖子,就应该把 11 个站点全部列出来?

后来还是放弃了这种做法。

因为从 SEO 的角度来说:

一个页面同时链接 11 个站点,并不等于获得了 11 个独立高质量 referring domains。

来源仍然是同一个网站。

而从真人社区的角度看,突然堆一排 URL,还很容易显得像 spam。

所以我现在更倾向于:

先推广整个 go-tour-i18n 项目。

然后未来再针对具体语言,寻找对应语言的本地开发者社区。

例如:

  • 日语版本 → 日本开发者社区
  • 巴西葡萄牙语 → 巴西开发者社区
  • 德语版本 → 德语技术社区
  • 法语版本 → 法语开发者社区
  • 西班牙语版本 → 西语社区
  • 韩语版本 → 韩国开发者社区

如果一个日语开发者社区自然链接:

ja-go-dev...

这种链接无论从真实用户还是 SEO 角度,都比在一个英文页面里一次堆 11 个网址更自然。


八、Go Forum:再增加一个 Go 垂直社区入口

完成 DEV 以后,我又去了 Go Forum。

这个论坛也是专门面向 Go 开发者的。

我把帖子发到了适合项目发布的分类,标题仍然保持非常直接:

go-tour-i18n: A Tour of Go in 11 languages

内容主要介绍:

  • 项目是什么;
  • 为什么做;
  • 现在有多少语言;
  • 项目如何维护;
  • GitHub;
  • go.dev;
  • DEV 上的详细文章。

不过因为是新账号,第一篇帖子没有立刻公开。

图8:帖子已经提交成功,但需要版主审核
图8:帖子已经提交成功,但需要版主审核

系统提示:

Post Needs Approval

以及:

You have 1 post pending.

也就是说,帖子已经提交成功,但需要版主审核。

这种新账号首帖人工审核很正常。

所以现在不重复提交,只需要等待即可。


九、这一天实际完成了哪些推广

最终,一次原本只是:

“除了 go.dev、搜索引擎、GitHub,还有什么地方可以推广?”

的讨论,变成了一轮真正的站外推广实践。

截至目前:

Go Weekly

已向编辑部发送项目推荐邮件。

状态:

已投递至对方邮件服务器。

是否收录,等待后续结果。

Golang News

账号已经注册。

但是:

  • 社区目前活跃度较低;
  • 投稿需要 more than 2 points;
  • 新账号只有 1 point。

所以暂缓,不为了积分专门投入时间。

Reddit r/golang

已经在 Small Projects 周常帖中成功发布项目介绍。

目前先观察自然互动,不马上重复发独立主题。

DEV Community

账号已经建立。

已经:

  • 完善个人资料;
  • 在 Welcome Thread 做自我介绍;
  • 正式发布第一篇英文技术文章。

文章:

https://dev.to/shuijingwan/how-i-maintain-a-tour-of-go-in-11-languages-ahl

Go Forum

项目介绍已经提交。

当前:

等待版主审核。


十、这次最大的变化:从“等搜索引擎”变成“主动去开发者所在的地方”

过去做站点的时候,我的习惯通常是:

Plaintext
上线
→ 提交 Sitemap
→ GSC
→ Bing
→ IndexNow
→ 等搜索引擎抓取

这套事情当然还要继续做。

但是对于一个完全新的子域名和新语言站来说,单纯依赖搜索引擎,可能需要非常长的时间。

尤其我的 A Tour of Go 多语言站目前还没有多少自然流量。

所以这次开始尝试另一条路线:

Plaintext
搜索引擎
+
官方链接
+
GitHub
+
Go 垂直社区
+
开发者内容社区
+
各语言本地社区

我觉得这才可能逐渐形成一个更健康的流量来源结构。

当然,一天做几次推广,并不会马上让流量出现明显变化。

甚至今天这些动作,很可能短期内一个用户都带不来。

但至少它解决了另外一个问题:

以前除了等待搜索引擎,我基本没有主动把项目放到 Go 开发者真正出现的地方。

现在开始有了。


十一、下一步不会继续一天铺几十个平台

做完这一轮以后,我反而不打算继续当天再注册十几个网站。

原因很简单。

推广也有边际成本。

每个新平台都意味着:

  • 注册账号;
  • 完善资料;
  • 了解规则;
  • 写适合平台的内容;
  • 处理审核;
  • 回复评论;
  • 后续维护。

如果只是为了制造链接,到处复制同一段文字,很快就会变成低质量推广。

所以接下来更合理的方式应该是:

  1. 观察 Go Weekly 是否采用;
  2. 等 Go Forum 审核结果;
  3. 看 Reddit 是否出现评论;
  4. 看 DEV 文章有没有阅读和互动;
  5. 继续把多语言项目推进到更多 production locale;
  6. 等语言数量达到新的里程碑以后,再考虑更大的曝光。

例如:

20 languages

或者:

30 languages

那时候再考虑 Hacker News / Show HN,新闻点会明显更强。


结语

这次最大的收获其实不是多了几条外链。

而是开始把这个项目从:

“我自己维护的一组多语言站点”

逐渐变成:

“一个可以被不同 Go 社区发现、讨论和反馈的开源项目。”

目前 A Tour of Go 多语言翻译项目仍然几乎没有多少真实流量。

搜索引擎收录也仍然需要时间。

所以现阶段还远远谈不上“推广成功”。

但至少今天迈出了比较具体的一步。

与其一直盯着搜索引擎后台等数据变化,不如同时主动去:

Go 开发者本来就在的地方。

接下来继续翻译,继续上线新语言,也继续观察这些推广渠道到底能不能真正带来用户。

如果后面 Go Weekly 收录、Go Forum 审核通过,或者 Reddit / DEV 开始带来实际访问,我再继续记录结果。

广告之外,社区项目如何长期活下去?我给 A Tour of Go 多语言项目加了 Support 第一次把 A Tour of Go 做成 RTL:阿拉伯语版本上线,以及我踩过的几个坑

Go 学习与文档多语言本地化项目

本系列完整记录 Go 学习与文档多语言本地化项目从 A Tour of Go 起步,逐步扩展到站点首页、项目说明页、学习内容、文档以及未来内容包的实际开发过程,包括架构设计、统一术语治理、整页翻译、结构保护、自动校验、独立质量审核、生产发布与长期维护。

项目源码:
✅ GitHub:shuijingwan/go-tour-i18n

语言版本:

当前跨项目目标语言池共包含 66 个语言版本。Go 项目本身目前提供 65 个社区 Production 语言版本,下面每一门 Go 语言版本都直接链接到其当前公开站点。语言列表沿用项目首页现有的展示顺序。

英语(美国)仅作为跨项目目标语言纳入列表,并不是单独的 Go Production 语言版本。当前 Go 的英文源内容仍为官方 generic English,因此英语(美国)链接到 Go 官方站点,而不是不存在的本地社区部署。

  1. 阿姆哈拉语
  2. 阿拉伯语
  3. 孟加拉语
  4. 葡萄牙语(巴西)
  5. 保加利亚语
  6. 加泰罗尼亚语
  7. 克罗地亚语
  8. 捷克语
  9. 丹麦语
  10. 荷兰语
  11. 英语(美国)(Go 官方英文站点)
  12. 英语(澳大利亚)
  13. 英语(加拿大)
  14. 英语(印度)
  15. 英语(新加坡)
  16. 英语(南非)
  17. 英语(英国)
  18. 爱沙尼亚语
  19. 菲律宾语
  20. 芬兰语
  21. 法语(法国)
  22. 法语(加拿大)
  23. 德语(德国)
  24. 德语(奥地利)
  25. 德语(瑞士)
  26. 希腊语
  27. 古吉拉特语
  28. 希伯来语
  29. 印地语
  30. 匈牙利语
  31. 印度尼西亚语
  32. 意大利语
  33. 日语
  34. 卡纳达语
  35. 哈萨克语
  36. 韩语
  37. 西班牙语(拉丁美洲)
  38. 拉脱维亚语
  39. 立陶宛语
  40. 马来语
  41. 马拉雅拉姆语
  42. 马拉地语
  43. 书面挪威语(Bokmål)
  44. 波斯语
  45. 波兰语
  46. 葡萄牙语(葡萄牙)
  47. 旁遮普语(果鲁穆奇文,印度)
  48. 罗马尼亚语
  49. 俄语
  50. 塞尔维亚语(西里尔文)
  51. 简体中文(中国大陆)
  52. 简体中文(新加坡)
  53. 斯洛伐克语
  54. 斯洛文尼亚语
  55. 西班牙语(西班牙)
  56. 斯瓦希里语(坦桑尼亚)
  57. 瑞典语
  58. 泰米尔语
  59. 泰卢固语
  60. 泰语
  61. 繁体中文(台湾)
  62. 繁体中文(香港)
  63. 土耳其语
  64. 乌克兰语
  65. 乌尔都语
  66. 越南语

项目正在持续扩展新的 Go 学习与文档内容,并长期维护各语言版本的术语一致性、翻译质量、独立审核、生产发布与后续更新。

本项目属于非官方社区多语言本地化项目,与 Go 官方无隶属、授权或背书关系。