标签： 自动校验
-
A Tour of Go 韩语翻译在 codex-ko-KR-004 中首次出现 13 个 TranslationUnit 里 3 个 validation failure。进一步排查发现，其中 concurrency/2 与 concurrency/6 并不是 Go identifier 真正丢失，而是韩语助词直接附着在 ASCII 标识符后，触发了 validator 的词法边界误判；concurrency/4 则属于真实的 present font span 结构错误。本文记录如何区分“应该改译文”与“应该改 validator”，并通过 ko-KR 窄规则、正反测试与 revalidate 流程，将结果从 10/13 提升到 12/13，最后再修正真实 candidate 问题达到 13/13。核心原则是：validator 的目标应保护技术身份，而不是强迫目标语言适应源语言的书写边界。
-
在 A Tour of Go 简体中文项目中，上一篇实验已经确认 ChatGPT 值得作为新的 Translation Engine 继续扩大验证。本轮进一步将实验扩展到全部 103 个正式课程页面，并通过固定 retranslation batch、GitHub 数据交接、ChatGPT 整页翻译、raw response 保存、restore、统一 validator 与有限 retry，完成 103/103 全量重译。整个过程没有改变原有完整 present.Section 翻译单元和结构校验体系，而是利用 ChatGPT + GitHub 减少大量人工复制粘贴，并通过 11 个 Batch、独立 Git 提交和历史 evidence 保留，使新的 ChatGPT 译文能够进入可追踪、可校验的工程流程，为后续完整语义审核和 canonical promotion 做好准备。
-
A Tour of Go 简体中文第一阶段 103 个课程页面已经全部进入 ready 状态。在现有版本已经具备较高翻译质量和完整发布能力后，我重新评估此前暂时搁置的 minimal-protect 翻译模式。当前 zh-CN 译文工程性估计约为 94 分，而成熟的 minimal-protect 目标希望达到 96～97 分。通过 methods/24 的真实实验可以看到，raw-input 会错误修改 .play 指令，而 minimal-protect 只保护完整 .play 后成功消除了这一问题，同时让 validator 继续发现 link inline-code 和 font span 等下一层结构差异。同页对比中，默认 protected-token 使用 15 个保护 token，而 minimal-protect 仅使用 1 个，更多原始上下文可以直接交给 GLM-5.2。后续将继续使用原有 7 个代表页验证翻译质量、结构稳定性、重试成本和跨语言保护规则的复用程度，再决定是否正式切换默认模式。
-
A Tour of Go 简体中文 103 个正式发布页面完成自动翻译和结构校验后，我又进行了一轮完整的发布前正文质量审计。最终 87 页无需修改，14 页列为 C 类建议修订，2 页列为 D 类必须修订，共返修 16 页。本文记录这次审核如何区分可读性问题与技术误译，以及人工修订仍然必须经过同一套 validator 校验的过程，包括 methods/19 因少保留一个行内代码结构而被自动拒绝的代表案例。
-
在 A Tour of Go 多语言翻译项目中，随着 protected token 保护规则不断增加，我开始重新思考输入端是否有必要做如此多的结构处理。本文记录一次围绕 –raw-input、–minimal-protect 和 –dev-attempts 的真实架构实验：flowcontrol/6 证明原始输入能够直接通过统一校验，而结构更复杂的 methods/24 又暴露出 .play directive、链接标签行内代码以及 font span 等结构风险。最终没有贸然替换当前成熟方案，而是保存实验能力和真实审计，继续使用默认 protected-token 流程推进课程翻译，并将“原始页面优先、少量高风险机器结构保护、严格统一校验、针对性重试反馈”作为后续值得继续研究的简化方向。
-
继续推进 go-tour-i18n 项目的第二批 10 个普通页面翻译。flowcontrol/6 在连续 3 次翻译后因 inline code sentinel 5 opening marker missing 进入 blocked，排查后发现 GLM-5.2 并未丢失 Token，而是将英文中的 v → return 按自然中文语序调整为 return → v，暴露出 Restore 层错误要求不同 Inline Code Pair 保持源码顺序的问题。修复后允许完整 Pair 随自然语序整体换位，并新增 translate revalidate-response，可直接复用历史成功模型响应重新执行当前 Restore 与 Validator，无需再次调用 GLM。最终 flowcontrol/6 使用原 attempt-003 成功恢复为 ready，第二批 10 页实现 10/10 Ready；同时修正了已经过时的 TestCommittedStatus Ready 页面白名单测试。当前项目状态为 ready=35、pending=68、blocked=0。
-
A Tour of Go 多语言翻译项目完成最后 3 个代表页 concurrency/7、concurrency/11 和 methods/24 的真实翻译与校准，总代表页达到 7 页。本轮继续发现并修复了非尾部指令位置校验、standalone 条件源码投影、Go 普通英语词义误保护、链接显示文本内行内代码保护，以及中文全角标点与 legacy present 行内代码边界等问题。多次失败还通过保存原始模型响应、本地回放和统一校验确认了真正根因。至此代表页校准阶段结束，下一步将进入 10 个普通 pending 页面自动试跑。
-
在 A Tour of Go 多语言翻译项目继续校准 methods/20 时，GLM-5.2 第一次翻译因多处 Protected Token 顺序变化被自动校验拒绝。进一步分析发现，16 个受保护标记全部完整保留，所谓“换序”实际上来自英语与中文正常的语序差异。本文记录如何重新划分结构校验与跨语言语义的职责，取消过严的全局 Token 顺序限制，加强 present、链接、代码块、directive 与 Section 结构校验，并使用同一份历史失败响应完成确定性回放，最终证明第一次翻译本身已经正确通过。
-
本文记录 A Tour of Go 中文版项目进入代码实现后的阶段成果。通过调查六个现有翻译项目，项目最终没有复制整个 golang/website，而是从固定上游提交中提取可独立运行的 Tour 最小源码闭包，并建立文件级来源追踪。在完成英文基线、示例代码运行链路和 7 / 101 / 92 / 1 结构验证后，项目进一步为 101 个课程页面建立机器可读目录、页面级源哈希、持久 page_id、候选译文结构校验和上游变化预览机制。目前 101 个简体中文页面仍全部处于 pending，正式翻译尚未开始。