经过前面的代表页面校准、保护规则调整、结构校验完善以及多轮普通页面批量翻译之后，A Tour of Go 多语言翻译项目终于到达了一个非常明确的里程碑：
ready=103pending=0blocked=0
也就是说，当前上游基线中的 103 个 A Tour of Go 课程页面已经全部完成简体中文翻译，并通过项目统一的自动校验流程。
需要特别强调的是，这还不代表中文版已经正式发布。
当前完成的是课程正文翻译阶段。下一阶段还要继续进行发布前全局验收，包括整体生成、浏览器渲染、公共 UI 文案、页面导航、发布产物以及生产部署边界等。
不过，仅就课程正文而言，这一阶段已经真正跑完了。
这次最终收尾过程中还连续遇到了两个很有代表性的案例：一个发生在行内代码结构恢复阶段，另一个发生在完整链接结构校验阶段。
它们最后都证明了一件事：
多语言翻译系统不能简单要求目标语言严格复制源语言的结构出现顺序。只要一个完整受保护结构本身没有遭到破坏，为适应目标语言自然语序而发生整体换位，本来就应该被允许。
这也是这轮全量翻译收尾阶段最有价值的两个发现。
一、从批量试跑进入真正的全量翻译
在代表页面以及前几批普通页面已经验证稳定之后，我继续按照每批 10 页的节奏推进剩余 pending 页面。
这一阶段没有再采用逐页人工翻译，而是继续沿用已经建立起来的统一流程：
完整课程页面 → GLM-5.2 整页翻译 → 保存 candidate → 自动结构和页面校验 → ready
如果失败，则继续：
有限整页重试 → 仍失败则进入 blocked
而 blocked 并不意味着一定要人工直接修改译文。
如果后来确认问题来自恢复逻辑或校验器本身，还可以直接利用已经保存下来的历史模型响应重新校验，而不需要再次调用模型。
这次后半程的状态推进非常直观：
| 阶段 | ready | pending | blocked |
|---|---|---|---|
| 第 4 批完成 | 55 | 48 | 0 |
| 第 5 批完成 | 65 | 38 | 0 |
| 第 6 批完成 | 75 | 28 | 0 |
| 第 7 批完成 | 85 | 18 | 0 |
| 第 8 批完成 | 95 | 8 | 0 |
| 最后 8 页完成 | 103 | 0 | 0 |
越到后面，普通页面的一次通过率也越来越稳定。
例如第 8 批 10 页全部 attempt-001 一次通过；最后剩余的 8 个 concurrency 页面同样全部首轮通过。
不过在真正到达 103 / 0 / 0 之前，还有两个不能简单当作“模型翻译失败”的问题需要解决。
二、moretypes/18：模型没有少翻代码，恢复逻辑却把两个代码结构合并了
第 5 批处理中，moretypes/18 连续进行了 3 次翻译，最终都得到相同的错误：
inline code count mismatch: expected 9, actual 8
从结果表面看，很容易得出一个判断：
GLM-5.2 连续三次漏掉了一个行内代码结构。
但进一步检查三份原始响应后发现，事实恰恰相反。
源页面一共有 9 个行内代码：
Picdydx(x+y)/2x*yx^y[]uint8[][]uint8uint8(intValue)
三次模型响应都完整保留了 9 对行内代码保护标记，token_valid=true。
真正发生的问题来自中文自然语序调整。
原文中存在：
each `[]uint8` inside the `[][]uint8`
模型自然地翻译成了类似：
为 `[][]uint8` 中的每个 `[]uint8`
也就是说，两个完整行内代码结构发生了整体换位。
这本身完全正确。
与此同时，另外几个函数被模型输出成：
`(x+y)/2`、`x*y` 和 `x^y`
问题就出现在这里。
原来的 normalizeInlineTokenBoundaries 会按照源文本中的 pair 顺序逐个寻找保护标记。
当它搜索到后面的 []uint8 与 [][]uint8 时，因为这两个 pair 已经按中文语序交换位置，搜索失败，函数直接提前退出。
结果就是：
前面本来应该进行的行内代码边界规范化也没有完成。
因此：
`(x+y)/2`、`x*y`
最终被 legacy present 解析器识别成了一个 program span。
于是才出现：
expected 9, actual 8
moretypes/18 中完整行内代码换位暴露恢复边界问题，修复后原历史响应重新校验通过三、修复方式：按照响应中的实际位置处理，而不是假定源顺序永远不变
既然当前设计本来就允许完整行内代码 pair 为适应目标语言语序发生换位，那么恢复逻辑也应该遵守同样的原则。
最终修改后的算法不再按照源顺序串行搜索全部 pair，而是：
- 独立查找每一个合法 opening / closing pair；
- 获取它们在模型响应中的实际位置；
- 按实际位置重新排序；
- 根据真正的相邻关系计算是否需要补 ASCII 空格；
- 再统一执行边界规范化。
与此同时，原来的严格校验并没有放松。
以下情况仍然必须拒绝：
- token 缺失；
- token 重复；
- 开闭标记不匹配；
- pair 交叉；
- pair 内容被修改。
也就是说：
放宽的是“完整结构出现的顺序”，而不是结构完整性本身。
修复完成后，没有重新调用 GLM-5.2，而是直接把 moretypes/18 已经保存的 3 份历史响应重新送入恢复和统一 candidate 校验。
结果三份全部能够恢复出 9 个行内代码，并通过校验。
随后通过正式的 translate revalidate-response 流程，选择最早的 attempt-001 恢复 candidate，最终把：
blocked → ready
而模型的原始 response 一个字都没有改。
这正是我希望这个项目具备的能力：
如果失败来自翻译基础设施，而不是译文本身，就修基础设施，然后让原始历史响应重新进入统一校验，而不是人工篡改结果让某一个页面“过关”。
四、methods/17：第二次遇到“完整结构换位”
到了第 7 批，又出现了一个非常相似的问题。
methods/17 的原始内容包括两个链接：
[[/pkg/fmt/#Stringer][`Stringer`]]
以及：
[[/pkg/fmt/][`fmt`]]
英文表达大致是：
Stringer defined by fmt
而自然的中文表达显然更倾向于：
由 fmt 包定义的 Stringer
因此模型在第三次尝试中，将两个完整链接结构交换了位置。
旧校验器看到的源顺序是：
/pkg/fmt/#Stringer → /pkg/fmt/
而候选译文中的顺序变成：
/pkg/fmt/ → /pkg/fmt/#Stringer
于是报告：
link targets mismatch at index 1
一开始看起来像是：
模型把
/pkg/fmt/#Stringer错误改成了/pkg/fmt/。
但检查完整结构后才发现，并没有。
模型实际上仍然保持了：
/pkg/fmt/#Stringer对应Stringer/pkg/fmt/对应fmt
两个链接目标都没有丢失，没有被修改，也没有与错误的链接文本配对。
只是两个完整链接为了中文语序交换了位置。
methods/17 中两个完整链接按中文语序换位，修正校验逻辑后历史响应成功恢复五、不能简单把链接目标改成无序集合比较
这次修复还有一个需要格外小心的地方。
既然两个链接可以整体换位，是不是直接把：
link target
改成无序集合比较就可以？
不行。
因为仅仅确认：
/pkg/fmt/#Stringer存在；/pkg/fmt/存在；
还不够。
假如模型错误地生成：
/pkg/fmt/→Stringer/pkg/fmt/#Stringer→fmt
那么两个 target 虽然一个都没少，却已经发生了错误配对。
因此新的校验逻辑采用的并不是简单 target 集合，而是把完整链接身份考虑进去。
对于包含受保护行内代码 payload 的链接，使用类似：
target + link 内 inline-code payload 多重集合
作为完整 link identity，再进行无序比较。
这样就能够同时满足两个要求：
允许：
完整链接结构整体换位。
但仍然拒绝：
target 与链接文本交叉错配。
而普通没有受保护 payload 的链接仍然保留原来的顺序校验，并没有无条件把所有链接都变成无序比较。
修复后，methods/17 的 attempt-003 历史响应直接通过统一 candidate validation。
随后同样使用正式 revalidate-response 恢复：
blocked → ready
整个过程也没有重新调用 GLM-5.2。
六、这两个问题其实指向同一条设计原则
moretypes/18 和 methods/17 表面看是两个完全不同的问题。
一个是行内代码：
[]uint8
[][]uint8
一个是完整链接：
Stringer
fmt
但它们背后的根因完全一致：
源语言结构顺序不能被误认为目标语言必须保持的语义约束。
最初为了保证翻译安全，我们不断增加 Protected Token、结构签名以及各种校验。
这些保护本身当然有价值。
但是当校验规则开始默认：
A 在英文里出现在 B 前面，那么中文里 A 也必须永远出现在 B 前面。
保护机制本身就可能制造新的误判。
这两次修复最终形成的原则是：
结构身份必须保持，结构内部绑定关系必须保持，但完整结构之间允许按照目标语言的自然语序重新排列。
这比简单地“放宽顺序限制”更准确。
我们并没有降低结构安全要求，而是在区分：
- 什么才是真正不可破坏的结构；
- 什么只是源语言表达顺序带来的偶然排列。
这对未来增加日语或其他语言也非常重要。
七、最后 28 页反而变得非常稳定
这两个边界问题解决以后，剩余页面推进速度明显加快。
第 6 批中，只有 methods/6 第一次出现一个 Protected Token 缺失，第二次通过；这是正常的模型重试场景。
第 8 批的 10 个页面：
methods/18methods/19methods/21methods/22methods/23methods/25methods/26generics/2generics/3concurrency/1
全部 attempt-001 一次通过。
最后剩余的 8 个页面：
concurrency/2concurrency/3concurrency/4concurrency/5concurrency/6concurrency/8concurrency/9concurrency/10
同样全部首轮通过。
至此，状态正式来到：
ready=103pending=0blocked=0
最终提交：
584ce7d6f22c68f983d4199deee8f36aec450be5
并已经推送到项目仓库。
八、103 页到底是不是全部页面？
完成 103 / 0 / 0 之后，我突然又想到一个问题：
A Tour of Go 中还有
#appengine:条件内容，那么实际课程页面会不会不止 103 页？
这个问题值得认真确认。
因为如果状态文件本身就是从一个不完整的页面集合建立出来的，那么：
pending=0
也不能证明真的全部翻译完了。
于是我重新从当前固定的官方 upstream 源码核对页面拓扑。
当前上游基线：
master@e11dacba76c5aae474746e9eedee19693f492803
A Tour of Go 使用 7 个 .article 文件：
basics.articleconcurrency.articleflowcontrol.articlegenerics.articlemethods.articlemoretypes.articlewelcome.article
重新统计顶层 Section 后得到：
- 普通顶层 Section：101
#appengine条件顶层 Section：2- 总计：103
两个条件顶层 Section 都位于 welcome.article：
Go offline (optional)The Go Playground
虽然 concurrency.article 和 flowcontrol.article 中同样存在 #appengine: 条件内容，但它们只是现有页面内部的条件正文，没有形成新的顶层 Section，因此不会增加课程页面数量。
换句话说：
101 + 2 = 103
这次才真正从官方源码层面确认：
当前
ready=103确实对应当前上游基线下完整的 A Tour of Go 课程页面集合，而不是只把一个不完整的状态表处理完了。
ready=103、pending=0、blocked=0九、现在完成的是“翻译阶段”，还不是“发布完成”
到这里，A Tour of Go 多语言翻译项目第一阶段中的课程正文翻译已经完成。
当前可以明确确认：
- 103 个课程页面全部存在；
- 103 个页面全部完成 zh-CN 翻译；
- 所有页面均经过相同的 Protected Token 恢复流程；
- 所有页面均经过 present 解析；
- 所有页面均经过结构比较；
- 所有 candidate 均经过统一页面校验；
pending=0；blocked=0；- 工作区干净；
- 最终翻译结果已经提交并推送。
不过项目还没有到正式发布的时候。
接下来要进入的是另一个阶段：
zh-CN 发布前全局验收。
它关注的重点将不再是“某个页面有没有翻译成功”，而是整个站点作为一个完整产品是否已经具备发布条件，例如：
- 103 页最终构建结果；
- 页面导航与课程拓扑；
- 浏览器实际渲染；
- 公共 UI 文案；
- 链接与静态资源；
- 右侧 Go 示例；
- 单语言构建产物；
- 生产环境部署方式；
- 本地
/socket代码执行接口的生产边界； - 最终发布前的整体回归。
因此我暂时不会把现在的状态称为“中文版已经完成”。
更准确的说法是：
A Tour of Go 简体中文的 103 个课程页面已经全部完成翻译并进入
ready，课程正文翻译阶段正式结束。
下一步，再开始发布前的全局验收。
十、阶段总结
从最初开始设计这个项目时，我并不希望最终得到的只是：
调用大模型，把英文批量换成中文。
真正困难的部分一直是：
怎样允许模型正常使用中文表达能力，同时又能证明代码、链接、指令、页面结构等关键内容没有被破坏。
而真实跑完 103 页之后，反而更加确认了这一点。
如果保护太少，模型可能破坏结构。
但如果保护和校验过于机械，又会把正常的中文语序调整判定为错误。
moretypes/18 与 methods/17 正好分别从恢复阶段和校验阶段证明了这一点。
最终得到的不是“中文必须服从英文顺序”，而是一套更加明确的边界：
真正不可翻译、不可破坏的内容必须严格保持；完整受保护结构之间，则应该允许为了目标语言自然表达而调整顺序。
现在，当前 upstream 基线下的 103 个页面已经全部跑过了这套流程。
ready=103。
pending=0。
blocked=0。
课程正文翻译阶段，到这里终于可以告一段落了。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ Brazilian Portuguese — Português (Brasil)
✅ Dutch — Nederlands
✅ French — Français
✅ German — Deutsch
✅ Italian — Italiano
✅ Japanese — 日本語
✅ Korean — 한국어
✅ Simplified Chinese — 简体中文
✅ Spanish — Español
✅ Turkish — Türkçe
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
项目正在持续扩展更多语言版本，并长期维护翻译质量、生产发布与后续更新。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。