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

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

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

作者:

在

,

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 的迁移?

2026 年 8 月 2 日,我正式开始推进 go-tour-i18n 项目的简体中文翻译。

今天原本的目标只是翻译第一个页面,但实际推进过程中先后暴露出了页面投影、条件内容、术语一致性、校验规则、重试策略以及 ChatGPT 与 Codex 协作方式等多个问题。

经过一整天的开发和校准,项目最终完成了第一个简体中文页面 welcome/1 的完整翻译闭环,并将经过验证的代码、译文和项目状态提交并推送到了 GitHub。

一、项目当前采用的 upstream 基线

项目继续以官方 Go 网站仓库中的 Tour 源码为基线:

  • 官方仓库:golang/website
  • 分支:master
  • 固定提交:e11dacba76c5aae474746e9eedee19693f492803
  • Go 环境:go1.26.0 linux/amd64

当前项目已经确认:

  • 共有 7 个 .article 文件;
  • standalone 模式下共有 101 个正式课程页面;
  • 另外保留 2 个 App Engine 条件页面;
  • 共有 92 个 .play 示例引用;
  • 共有 1 个 .image 引用。

右侧的 Go 示例代码继续保持官方原样,本阶段只翻译左侧课程正文和后续公共 UI 文案。

二、先解决项目状态如何可靠保存

今天重新开启 ChatGPT 会话后,我发现了一个很现实的问题。

虽然同一个项目此前已经完成了不少工作,但新的聊天未必能够完整恢复上一轮会话的全部细节。如果项目进度主要依靠:

  • ChatGPT 记忆;
  • Codex 会话记录;
  • 已发布的博客文章;
  • 人工复制粘贴的执行报告;

那么随着项目逐渐变长,很容易出现上下文遗漏或判断偏差。

今天就曾经因为上下文没有完整恢复,把当天早些时候生成的代码称为“旧模块”,并一度产生了另一套 CLI、页面身份和 upstream 读取逻辑。

经过只读审计后确认,中断任务留下了两套存在重叠的架构:

  • 原有 cmd/tour-i18n、internal/i18n、internal/tour;
  • 新生成的 cmd/go-tour-i18n、internal/translation、internal/projector 和 internal/upstream。

随后对这些实现进行了整合,最终重新确定:

  • 唯一 CLI 为 cmd/tour-i18n;
  • 唯一页面身份使用持久 page_id,例如 welcome/1;
  • 页面来源为仓库内 _content 和 data/tour-pages.tsv;
  • 外部 upstream checkout 只用于同步与核对,不作为翻译运行时依赖;
  • internal/i18n.ValidateCandidate 继续作为唯一 candidate 校验入口。

为了让项目状态不再依赖聊天记录,仓库中新增了:

Plaintext
docs/PROJECT_STATE.md

该文档记录当前已经由代码和测试验证的项目状态、已完成能力、当前页面状态以及唯一下一步。

代码和测试仍然是最终事实来源,而 PROJECT_STATE.md 负责把这些事实整理成 ChatGPT、Codex 和我都更容易读取的状态快照。

三、为 GLM-5.2 增加持久、安全的密钥配置

最初执行真实翻译时,Codex 发现:

Plaintext
ZHIPU_API_KEY 未设置

如果每次重启 VS Code 都手工输入环境变量,会比较麻烦。

因此,项目增加了本地 .env 自动加载:

Plaintext
go-tour-i18n/
├── .env
└── .env.example

其中:

  • .env 保存本机真实密钥;
  • .env.example 只保存变量名称;
  • .env 被 /.env 规则明确加入 .gitignore;
  • 系统环境变量优先于 .env;
  • .env 不会覆盖已经存在的环境变量;
  • 密钥不会写入 request、日志或 Git。

本地 .env 权限设置为:

Plaintext
600 .env

经过检查,.env 没有出现在 Git 状态和最终提交中。

四、第一次真实翻译暴露了 standalone 页面源错误

首次调用 GLM-5.2 时,模型输出通过了当时的结构校验,并进入了 ready。

但译文中出现了:

Plaintext
#appengine: 远程服务器上的
你电脑上的

调查发现,问题不在模型,而在输入给模型的完整英文页面本身。

请求中实际包含:

Plaintext
to compile and run the program on
#appengine: a remote server.
your computer.

也就是说,standalone 的 welcome/1 错误保留了 App Engine 条件分支。

根因位于页面拆分逻辑:

  • 原实现只识别 #appengine: * 开头的条件页面标题;
  • 正文中的 #appengine: a remote server. 没有被排除;
  • present 又会把以 # 开头的行视作注释;
  • 因此错误 candidate 仍然能够成功解析并通过结构校验。

最终同时修复了两个问题。

第一,standalone 页面源会排除所有 #appengine: 行,同时继续单独保留两个条件页面。

第二,validator 增加防御性规则:

  • standalone source 中不得出现 #appengine:;
  • standalone candidate 中不得出现 #appengine:。

修复后,welcome/1 的 source hash 更新为:

Plaintext
3fbd64163f0301d60fcf1440c8aa65a79358e7028fec433aee49ae0c364d3034

新的页面源:

  • 保留 your computer.;
  • 不再包含 #appengine:;
  • 不再包含 a remote server.。

旧 source 的运行记录按 source hash 保留,既不会覆盖,也不会占用新 source 的翻译记录。

五、结构正确不代表译文可以直接发布

修复页面源以后,GLM-5.2 很快生成了一份结构正确的译文。

但译文仍存在多项术语问题:

  • A Tour of Go 没有翻译;
  • previous 和 next 仍保留英文;
  • Run、Format 没有翻译;
  • slides 被翻译成“幻灯片”;
  • tour 的含义出现丢失或机械翻译。

这说明 present 结构、链接 target、.play 和行内代码全部正确,并不代表中文术语已经满足发布标准。

项目随后建立了最小中文术语表:

  • A Tour of Go → Go 语言之旅
  • previous → 上一页
  • next → 下一页
  • Run → 运行
  • Format → 格式化
  • slides → 页面

并将“幻灯片”列为禁用译法。

Validator 也开始根据链接 target 和 label 的结构关系检查术语,而不是简单进行全文字符串匹配。

六、为固定 UI 标签增加确定性术语锁定

开启强制术语校验后,GLM-5.2 连续两次把:

Plaintext
A Tour of Go

翻译成:

Plaintext
Go 之旅

而项目要求的是:

Plaintext
Go 语言之旅

由于请求设置了:

Plaintext
do_sample: false

相同输入很可能稳定生成相同结果。继续单纯重试只会浪费 Tokens。

这时没有选择在译后进行字符串替换,而是把少量必须严格一致的链接 label 纳入 protected token 流程。

例如:

Plaintext
[[javascript:highlight(".logo")][A Tour of Go]]

在提交给模型前,链接 target 和显示 label 分别受到保护。

模型完成整页翻译后,label 确定性恢复为:

Plaintext
[[javascript:highlight(".logo")][Go 语言之旅]]

当前被锁定的固定 UI 标签包括:

  • A Tour of Go
  • previous
  • next
  • Run
  • Format

带引号的 "previous" 和 "next" 在恢复中文时仍然保留原有引号。

普通正文没有被大范围锁定,正文仍然交给 GLM-5.2 完整翻译。

七、区分专有名称和普通正文中的 tour

固定标签解决后,下一次译文虽然通过了术语校验,但出现了多处:

Plaintext
本之旅分为……
在本之旅中……
本之旅是交互式的……

问题在于 tour 在不同语境下不能采用同一种译法。

最终明确:

  • 专有名称 A Tour of Go → Go 语言之旅
  • 普通正文 tour → 教程
  • 普通正文 the tour → 本教程

并将以下表达加入禁用译法:

  • 本之旅
  • 欢迎使用 Go 编程语言之旅
  • 幻灯片

固定链接中的 A Tour of Go 继续通过 protected token 恢复为“Go 语言之旅”,普通正文中的 tour 则仍由模型根据提示词翻译。

八、开发阶段取消三次重试限制

最初的正式工作流规定:

Plaintext
完整页面翻译
→ 最多 3 次完整重试
→ 仍失败则 blocked
→ ChatGPT 完整页面兜底

这个规则适合流程稳定后的正式批量翻译,但今天仍处于开发和校准阶段。

如果开发期间每调整一次 glossary、prompt 或 validator,都继续受三次限制,很快就会把页面送入 blocked,也不利于逐次观察问题。

因此,translate run 增加了开发模式:

Bash
go run ./cmd/tour-i18n translate run \
  -id welcome/1 \
  -locale zh-CN \
  -dev

正式模式仍然:

  • 最多执行 3 次完整页面翻译;
  • 三次失败后进入 blocked;
  • blocked 页面不能继续正式重试。

开发模式则:

  • 可以从 pending 或 blocked 继续;
  • 每次命令只调用模型一次;
  • attempt 编号持续递增;
  • 不覆盖旧记录;
  • 失败后回到 pending;
  • 成功后进入 ready。

这样既能继续开发调试,也能避免一次命令连续消耗多次 GLM Tokens。

九、第六次开发 attempt 最终通过

经过页面源、validator、glossary、protected token 和 prompt 的逐步校准后,attempt-006 最终通过全部校验。

本次调用信息:

  • Request ID:2026080221252064d5a523175a438a
  • finish_reason:stop
  • prompt tokens:1052
  • completion tokens:715
  • total tokens:1767

最终 candidate 为:

Plaintext
* Hello, 世界

欢迎来到 [[/][Go 编程语言]]之旅。

本教程分为一系列模块,你可以点击页面左上方的
[[javascript:highlight(".logo")][Go 语言之旅]]来访问它们。

你还可以随时点击页面右上方的 [[javascript:highlightAndClick(".nav")][菜单]] 来查看目录。

在本教程中,你将看到一系列页面和练习供你完成。

你可以使用以下方式浏览它们:

- [[javascript:highlight(".prev-page")]["上一页"]] 或 `PageUp` 转到上一页,

- [[javascript:highlight(".next-page")]["下一页"]] 或 `PageDown` 转到下一页。

本教程是交互式的。现在点击
[[javascript:highlightAndClick("#run")][运行]] 按钮
(或按 `Shift` + `Enter`)来编译并运行你电脑上的程序。
结果会显示在代码下方。

这些示例程序展示了 Go 的不同方面。教程中的程序旨在作为你自己实验的起点。

编辑程序并再次运行。

当你点击 [[javascript:highlightAndClick("#format")][格式化]]
(快捷键:`Ctrl` + `Enter`)时,编辑器中的文本会使用
[[/cmd/gofmt/][gofmt]] 工具进行格式化。你可以通过点击
[[javascript:highlightAndClick(".syntax-checkbox")][语法]] 按钮来开启或关闭语法高亮。

当你准备好继续时,点击下方的 [[javascript:highlightAndClick(".next-page")][右箭头]] 或按 `PageDown` 键。

.play welcome/hello.go

最终检查结果:

  • Go 语言之旅 正确;
  • 上一页、下一页 正确;
  • 运行、格式化 正确;
  • 普通正文使用“教程”和“本教程”;
  • 不含“本之旅”;
  • 不含“幻灯片”;
  • .play welcome/hello.go 保持原样;
  • JavaScript target、普通链接 target 和行内代码全部保持一致;
  • present 解析和页面结构校验通过。

虽然个别句子未来仍有润色空间,但已经不存在必须退回重译的结构或术语错误。

welcome/1 最终进入:

Plaintext
ready

十、完成首个 zh-CN 页面翻译闭环

最终项目完成了以下闭环:

Plaintext
仓库内完整 Section
→ standalone 页面投影
→ GLM-5.2 整页翻译
→ protected token 恢复
→ present 解析
→ 结构与引用比较
→ glossary 术语检查
→ candidate 落盘
→ ready 状态

生成的 candidate 位于:

Plaintext
locales/zh-CN/candidates/welcome-1.article

所有 request、response 和 validation 记录均保留下来,作为开发过程的审计依据。

项目完整测试通过,并完成提交:

Plaintext
23b168beb29fbaa99a9b953a41d425558d8f91e6
feat: 完成首个 zh-CN 页面翻译闭环

随后已经推送到 GitHub:

Plaintext
d7f851d..23b168b  main -> main

最终工作区状态为:

Plaintext
## main...origin/main

十一、今天最重要的收获

第一篇页面用了六次开发 attempt,看起来成本并不低。

但前几次失败并不意味着 GLM-5.2 以后会频繁失败,而是在帮助项目发现并解决基础设施问题:

  • standalone 页面投影不完整;
  • validator 对条件内容缺乏防御;
  • 强制 UI 术语不适合完全依赖模型;
  • 专有名称和普通词语需要区分语境;
  • 开发阶段与正式运行需要采用不同的重试策略;
  • 项目状态不能只依赖 ChatGPT 或 Codex 的会话记忆。

这些问题在第一个页面解决后,后续 100 个页面不需要再次承担同样的开发成本。

今天也进一步明确了 ChatGPT、Codex 和我自己的分工:

  • ChatGPT 负责架构分析、任务拆分和结果审核;
  • Codex 负责直接读取仓库、修改代码和运行测试;
  • 我负责监督、成本控制、决策和最终验收。

仓库中的代码、测试、状态文件和 PROJECT_STATE.md,将逐渐成为三者之间更可靠的共同事实来源。

十二、下一步:先评估 DeepSeek 新版本,再决定翻译模型

今天暂时不继续翻译第二个页面。

目前 GLM-5.2 资源包只剩下 300 多万 Tokens。按照现在的购买规则,如果继续补充资源包,需要一次性购买 1 亿 Tokens,并且必须在 3 个月内使用完。

对于仍处于开发和模型评估阶段的 go-tour-i18n 项目来说,现在立即购买这样规模的资源包并不一定合适。

另一方面,DeepSeek 官方更新记录显示,DeepSeek-V4-Flash 已于 2026 年 7 月 31 日进入公开测试;官方文档同时提到,DeepSeek-V4-Pro 计划在 8 月上旬进一步开放支持,但明天仍需根据实际 API 可用情况确认具体模型名称和接入方式。(DeepSeek API Docs)

因此,明天不会直接开始翻译 welcome/2,而是先评估 DeepSeek 新版本在这个项目中的实际表现。

测试时应继续使用今天已经建立的同一套流程:

Plaintext
完整 production 页面
→ protected token
→ 完整页面翻译
→ token 恢复
→ present 解析
→ 结构与引用比较
→ glossary 校验
→ candidate 验证

为了让比较尽可能公平,可以先使用已经熟悉的 welcome/1 作为基准页面,但测试结果应保存到独立的模型评估记录中,不能覆盖当前已经通过验证的 GLM-5.2 candidate。

重点比较:

  • protected token 是否能够完整保留;
  • present 结构是否能够一次通过;
  • 固定 UI 术语是否正确;
  • 普通中文正文是否自然;
  • 是否会出现机械翻译或擅自改写;
  • 首次通过率;
  • 输入、输出 Tokens 和实际费用;
  • 响应速度与稳定性;
  • 相同输入下的结果是否稳定。

如果 DeepSeek 新版本的翻译质量、结构稳定性和成本都可以接受,后续可以考虑将 DeepSeek 作为主要翻译模型,把 GLM-5.2 保留为备用模型或对照模型。

如果测试结果仍然明显不如 GLM-5.2,则继续使用现有剩余 GLM Tokens 完成更有代表性的小规模验证,再根据实际通过率和预计总成本决定是否购买新的资源包。

因此,明天的重点不是追求多翻译几个页面,而是先回答一个对整个项目成本影响很大的问题:

在相同的完整页面输入、结构保护、术语表和自动校验条件下,DeepSeek 新版本能否达到可以正式用于 A Tour of Go 简体中文翻译的质量标准?

确定模型路线以后,再继续第二个页面以及后续小规模页面测试。

A Tour of Go 中文版开发实战:英文基线、在线运行与 101 页上游同步体系 A Tour of Go 中文翻译项目进展:完成前 8 页、修复 present 语法,并暂缓 DeepSeek 对比

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 官方无隶属、授权或背书关系。

评论

一条对“A Tour of Go 多语言翻译项目实录:完成首个 zh-CN 页面翻译闭环”的回复

  1. […] the previous article, “A Tour of Go Multilingual Translation Project Record: Completing the First zh-CN Page Translation Lo…“, I documented the page projection, glossary, Protected Token, development-stage retry […]