从决定为 A Tour of Go 多语言翻译项目增加第二门语言开始，到今天正式上线，日语版前后已经经历了多轮翻译流程调整、自动化改进和翻译质量实验。
前面的文章已经记录过为什么选择日语、ChatGPT 与 Codex 的协作方式、翻译自动化流程的问题，以及最终为什么将正式 TranslationUnit 翻译引擎调整为 Codex GPT-5.6 Sol High。
因此这一篇不再重复前面的选择和实验过程，只记录一个阶段性结果：
2026 年 8 月 24 日，A Tour of Go ja-JP 第一版正式完成生产上线。
日语版正式地址：
https://ja-go-dev.shuijingwanwq.com
从第二门语言开始，项目才真正进入多语言阶段
在开始 ja-JP 之前，项目已经有完整的简体中文版本，也已经建立了 locale、TranslationUnit、automatic validation、Quality Check、Final Review、promotion、projection 和 publish 等基础能力。
但只有一门社区语言的时候，这些设计究竟是不是能够真正扩展到第二门语言，其实还没有得到完整验证。
从开始增加日语以后，我也连续写了几篇相关记录。
这几轮工作的重点已经逐渐从“能不能翻译”变化为：
- 如何让一整个 TranslationUnit 在不破坏 present、代码和链接结构的情况下完成翻译；
- 如何减少人工复制粘贴；
- 如何区分工程失败和语言质量问题；
- 如何让 automatic validation 与语言质量审核各自承担清晰的职责；
- ChatGPT 与 Codex 在正式翻译中的职责如何划分；
- 选择什么模型作为长期默认生产翻译引擎。
最终，当前正式 TranslationUnit 翻译方案已经确定为：
Codex GPT-5.6 Sol High
而 ChatGPT 主要承担统一的 Quality Check 和后续语言质量审核。
ja-JP 正式生产站完成上线
这一次日语版不是单独复制一个页面或者做一个静态演示，而是按照项目现有架构构建了独立的 ja-JP 生产站。
当前首页已经能够根据 locale 使用对应的日语 UI，包括项目介绍、当前语言、课程入口、项目状态以及语言版本等内容。
生产域名采用：
https://ja-go-dev.shuijingwanwq.com
简体中文站继续使用：
https://go-dev.shuijingwanwq.com
当前采用的是“一个语言，一个独立站点”的构建和部署方式，而不是让多个 locale 在同一个运行实例中动态切换。
这样不同语言可以分别维护、构建、部署和使用 CDN，同时服务端核心代码仍然尽量共享。
103 个课程页面已经完整进入日语版本
课程目录也已经完成了 ja-JP 本地化。
/tour/list 课程目录从图中可以看到，包括基础、流程控制、方法与接口等课程结构已经完整呈现为日语版本。
这里的课程页面并不是简单把几个标题翻译一下。
项目中的 Page TranslationUnit 仍然以一个完整的顶层 present.Section 作为最小翻译单位。
也就是说，一个页面必须作为完整上下文一起翻译，并且需要保留：
- present 结构；
- Go 代码；
- Go 标识符；
- 链接 target；
- URL 和路径；
- directive；
- protected token；
- 其他不可翻译的机器语义内容。
TranslationUnit 不会被拆成若干句子分别处理。
不只是静态页面，Playground 也能够正常使用
A Tour of Go 的一个重要特点就是可以直接在浏览器里修改和运行 Go 示例。
因此，只完成页面翻译还不能算真正完成上线。
日语生产站还需要保证编辑器、执行按钮、格式化、运行结果以及 Playground 代理全部能够正常工作。
图中可以看到，课程正文已经是日语，编辑器相关 UI 也已经本地化，例如：
実行フォーマットリセット
实际点击运行后，可以正常得到：
Hello, 世界并显示日语运行状态：
プログラムが終了しました。这一步也验证了浏览器到 Playground 代理之间的完整生产链路。
日语站上线时还专门增加了 ja-JP production Origin 的 CORS 支持，否则页面虽然可以正常打开，Run 和 Format 仍然会失败。
所以这一轮最终验收并不只是“网页 HTTP 200”，还包括真实浏览器中的实际运行。
122 个 TranslationUnit 全部进入正式状态
ja-JP 当前完整翻译集合一共包含：
- 103 个 Page；
- 19 个 eligible Example；
- 合计 122 个 TranslationUnit。
本地最终状态检查结果如下。
正式输出为：
status OK: 122 translation units for ja-JP (103 pages, 19 examples)这些 TranslationUnit 并不是模型生成译文以后就直接发布。
当前正式生产链路大致是：
retranslation export
↓
Codex GPT-5.6 Sol High
↓
raw-responses
↓
retranslation process
↓
automatic validation
↓
Candidate Snapshot
↓
ChatGPT Quality Check
↓
Final Review
↓
promotion
↓
ready
↓
projection / publishautomatic validation 主要负责可以由机器严格验证的安全性，例如 protected token、present 结构、代码、链接 target、directive、source identity、candidate identity 和 render 等。
但 automatic validation 通过并不代表译文语言质量已经达到正式发布标准。
所以每一个 TranslationUnit 之后仍然需要独立进行语言质量审核。
当前生产门槛是严格的 A-only：
Quality Check 中，只要出现 B、C 或 D，都不能直接进入最终发布，而必须创建新的 revision batch，重新翻译，再重新经过 validation 和 Quality Check。
Final Review 同样要求最终 TranslationUnit 达到 A。
ja-JP 最终完成的是全部 122 个 TranslationUnit 的正式审核和 promotion。
非中文语言开始共享生产基础设施
ja-JP 也是项目第一次真正验证第二门语言的独立生产部署。
简体中文目前继续使用 EdgeOne。
ja-JP 则采用 Cloudflare Free。
同时，为了避免每增加一种语言都重复发布完全相同的 CSS、图片和部分公共资源，还建立了非中文站点共享静态资源域名：
https://assets-go-dev.shuijingwanwq.com
当前只共享经过明确 allowlist 管理的静态资源。
而像 /tour/script.js 这种包含 locale 相关运行时信息的动态内容，并没有为了“共享”而强行拆分。
这个边界在实际部署第二门语言以后变得更加清楚：
能安全共享的资源共享，和 locale、运行时行为有关的资源继续由各语言站点自己生成。
sitemap 共包含 105 个公开 URL
生产部署完成以后，还对 ja-JP 的 SEO 输出进行了完整检查。
这里曾经发现过一个很典型的问题：
日语站虽然已经正常运行，但 sitemap 最初仍然使用了简体中文站的 hostname。
后来将 SEO origin 正式改为从 locale 的语言 registry 中获取，而不是使用固定的 zh-CN hostname。
修复以后，ja-JP 的：
robots.txt- sitemap
- canonical host
html lang
都能够根据当前 locale 正确生成。
当前 ja-JP sitemap 共包含 105 个公开 URL。
这里的 105 与前面的 122 并不是同一个概念：
122
= TranslationUnit 数量
= 103 Page + 19 Example
105
= sitemap 中对外公开的 URL 数量Example TranslationUnit 并不会简单对应一个新的独立公开页面，因此两个数字并不需要相同。
Google Search Console 已经成功读取 sitemap
上线以后，我也将 ja-JP 独立添加到了 Google Search Console。
当前结果为：
站点地图：/sitemap.xml
状态：已成功处理站点地图
已发现的网页：105这与生产环境自己的 sitemap 验收结果一致。
Bing Webmaster Tools 中也已经提交 ja-JP sitemap，目前让搜索引擎自行抓取即可。
这一次没有继续使用 IndexNow。之前已经做过相关测试，短期效果并不明显，所以没有必要为了主动推送继续增加维护工作。
从“中文翻译项目”变成真正经过验证的多语言项目
我觉得 ja-JP 上线最重要的意义，其实并不只是“多了一个日语网站”。
zh-CN 完成以后，项目已经在代码层面为多语言做了很多准备。
但只有第一门语言时，很难判断哪些设计是真正可复用的，哪些只是因为第一门语言恰好能够工作。
ja-JP 完整走完以后，很多问题才真正暴露出来。
比如：
- 新语言首次生产部署仍然需要重新确认不少服务器环境；
- OneinStack 自动生成的 Nginx 配置可能带入不适合当前应用的静态 location；
- Cloudflare Universal SSL 会直接影响子域名层级设计；
- sitemap hostname 不能继续假定只有 zh-CN；
- Playground 的 CORS Origin 必须随着语言站点扩展；
- TranslationUnit 的语言质量审核已经很严格，但首页、公共 UI、
/tour/list、runtime message 等内容以前没有同等级的独立审核阶段； - glossary 中虽然已经存在正式术语决定，但以前并没有明确要求这些决定覆盖整个 locale 的公共 UI。
这些问题很多只有真的添加第二门语言以后才会出现。
因此我现在更愿意把 ja-JP 看成一次完整的多语言架构验证，而不只是一次翻译任务。
第一版上线以后，先不急着开始第三门语言
ja-JP 正式上线以后，我没有立即开始第三门语言。
因为第二门语言已经暴露出一个新的问题：
虽然现在已经知道怎样把一门语言做出来，但“新增下一门语言”的过程仍然过度依赖临时分析和此前的上下文。
于是上线以后，我又专门整理了一轮项目文档，并正式增加：
docs/NEW_LOCALE_RUNBOOK.md
docs/LOCALE_SURFACE_REVIEW.md开始把“新增一门语言”本身变成一条正式流程。
其中也新增了 TranslationUnit 之外的 Locale Surface Review，用来覆盖：
- 公共 UI；
- 首页；
/tour/；/tour/list；- 导航；
- 语言选择器；
- 编辑器；
- runtime message；
- article metadata；
- SEO；
- 桌面端和移动端实际页面。
这一部分值得单独整理，因此准备放到下一篇继续记录。
如果说这一篇记录的是：
ja-JP 最终做成了什么。
那么下一篇更想记录的是：
做完 ja-JP 以后，怎样让第三门语言不需要重新踩一遍这些坑。
小结
2026 年 8 月 24 日，A Tour of Go ja-JP 第一版正式完成上线。
当前这一版已经完成：
- 103 个课程 Page；
- 19 个 eligible Example；
- 122 个 TranslationUnit；
- 全量 automatic validation；
- 全量 TranslationUnit Quality Check；
- Final Review；
- promotion；
- ja-JP 公共 UI；
- 日语首页和课程目录；
- 独立生产部署；
- Cloudflare Free；
- 非中文共享静态资源；
- HTTPS；
- locale-specific SEO；
- 105 个 sitemap URL；
robots.txt；- Playground Run / Format；
- 真实浏览器运行验收；
- Google Search Console sitemap 提交。
从这一刻开始，go-tour-i18n 不再只是一个已经为“未来多语言”做好代码准备的中文翻译项目。
第二门社区语言已经真正运行在生产环境中。
而接下来的重点，也会逐渐从“如何完成第二门语言”，转向另一个更长期的问题：
如何让新增第三门、第四门以及更多语言，变成一件能够按照规范重复执行的事情。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。