标签： AI 翻译
-
本次重新评估 A Tour of Go 的 TranslationUnit 翻译方案，根本原因不是单纯比较模型能力，而是 ChatGPT 作为批量翻译引擎在实际工作中出现持续稳定性问题，即使从 ZIP 交付简化为 JSON，翻译任务仍可能卡住。实验使用 5 个正式 TranslationUnit、完整 zh-CN glossary、protected token、独立随机匿名和 Engineering Gate，对 ChatGPT GPT-5.6 High、Codex GPT-5.6 Sol High 与 Extra High 进行四模型匿名评审。结果显示，ChatGPT High 的外部评审平均分为 96.67，Codex High 为 95.73，Extra High 为 95.87，三者已进入相近的高质量梯队，而 Extra High 并未表现出稳定优势。综合翻译质量与本地批量执行能力，后续默认翻译引擎准备调整为 Codex GPT-5.6 Sol High，ChatGPT 则重点用于统一 Quality Check，并以所有 TranslationUnit 最终达到 A 作为质量验收目标。
-
在 go-tour-i18n 多语言翻译项目推进过程中，我曾经通过 ChatGPT + GitHub batch 完成 A Tour of Go 简体中文 103 页全量重译验证。后续扩展 ja-JP 翻译时，继续沿用了基于 TranslationUnit 的翻译流程，并尝试从 GitHub 写入调整为 raw-responses artifact 导入模式。实际测试发现，ChatGPT 能够理解项目流程、读取 batch 和 manifest，但在新任务中无法稳定完成从 TranslationUnit 翻译结果到 raw-responses 文件和 artifact 交付的完整闭环。本文记录这次 AI 辅助翻译流程稳定性验证过程，并分析翻译能力与工程执行能力之间的差异。
-
在 A Tour of Go 多语言翻译项目中，最初版本主要完成左侧课程正文的简体中文翻译，但右侧 Playground 示例代码仍然保留英文注释。 对于编程教程而言，课程正文和代码示例是一个完整学习单元。如果代码注释仍然是英文，即使代码可以正常运行，整体学习体验仍然不完整。 本次更新将 Playground Example 纳入统一翻译体系，作为独立 TranslationUnit 管理。项目通过 Go scanner 识别真实注释，只开放普通自然语言注释参与翻译，同时保护代码、字符串、布局以及机器语义内容，确保翻译后仍然保持合法 Go source。 最终，右侧 Playground 示例代码注释也完成中文本地化，实现从课程正文到代码示例的完整学习体验。
-
在 A Tour of Go 多语言翻译项目中，最初的自动化流程主要关注结构完整性和页面可发布性，例如 present 解析、代码保护、链接校验以及页面渲染验证。 随着翻译规模扩大，仅依靠自动验证已经无法完全保证译文质量。因此，项目进一步引入 Translation Quality Review，将翻译质量检查正式加入发布流程。 本次更新建立了独立的质量评审阶段，通过 A/B/C/D 四级质量评级、Review evidence 和 Promotion gate，对候选译文进行质量控制，使自动翻译流程从“结构正确”进一步提升到“质量可控”。
-
A Tour of Go 多语言翻译项目最初以固定版本的 Go 官方源码为基础完成简体中文翻译。随着课程内容持续演进，仅保存当前译文已经无法满足长期维护需求。 本次更新为项目引入 upstream 同步机制，通过记录官方源码基线 commit、检测 source revision 变化、标记 stale 翻译单元、重新生成翻译批次，并经过 validation、Translation Quality Review 与 promotion 流程，最终生成新的 production release。 此次实践使 go-tour-i18n 从一次性的课程翻译项目，进一步演变为具备持续同步能力的多语言维护系统。
-
在完成 A Tour of Go 简体中文 103 个正式课程页面的 ChatGPT 全量重译后，我没有立即覆盖现有正式译文，而是继续进行了完整语义质量审核，并使用 A/B/C/D 四级标准区分“可以直接发布”“可选优化”“建议修订”和“必须修复”。审核过程中曾有 2 页处于 B 级，本身已经达到发布质量，但由于最终只剩少量页面且修改成本很低，仍继续 revision，最终达到 A=103、B/C/D=0。随后项目进一步完善 canonical promotion 的 evidence chain、retry provenance 与 EOF normalization，确认每个正式 candidate 都能追溯到对应的 ChatGPT 原始译文和最终有效 attempt。正式 apply 后 103 页中 102 页发生变化，80 页完成确定性 EOF normalization，再次 dry-run 得到 0 changed、103 unchanged，完整测试最终通过。结合 103 页全量重译、完整语义审核和统一工程验证，我对当前 zh-CN 的内部综合质量评价由原来的约 94 分提高到约 98 分。
-
在 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 个课程页面后，我继续验证如何把现有约 94 分的工程性翻译质量进一步提升到 96～97 分。最初重点研究 minimal-protect，希望通过减少 protected token、保留更多原始上下文改善 GLM-5.2 译文，但后续对 157 个 protected token 的信息损失审计、Static Context 实验以及重复请求测试均未显示稳定质量优势，因此优化重点从 Protection Policy 转向 Translation Engine。本轮选取 methods/24、concurrency/7、concurrency/11 三个代表页，由 ChatGPT、Codex Sol 和 GLM-5.2 独立生成最终译文，再交给 ChatGPT、DeepSeek、GLM-5.2 和豆包进行 12 次匿名质量评审。ChatGPT 获得 8/12 第一名，即使排除自身作为评审模型后仍获得 5/9 第一名。现阶段不会立即覆盖已有 103 页，而是准备进一步验证自动化 ChatGPT retranslation staging，在统一 validator 和页面验证基础上评估是否值得全量重译。
-
在 A Tour of Go 简体中文翻译流程中，我一直担心大量 protected token 会遮挡模型上下文，从而影响 GLM-5.2 的翻译质量。为验证这一点，我先将保护策略缩减到 minimal-v1，又进一步设计了只额外暴露静态代码的 Static Context 单变量实验。结果却逐渐指向另一个问题：7 个代表页中的 157 个保护标记并没有隐藏任何可翻译英文自然语言，而完全相同的 API Request 在 5 个页面上全部生成了不同的 Response。随后通过 5 页、2 种模式、3 次独立运行共 30 个计划样本，并对所有通过结构校验的译文进行匿名多候选排名，最终发现模型自身的运行间波动明显大于目前能够观察到的 Static Context 质量收益。基于这一结果，正式翻译流程继续保留成熟的 Default protected-token 方案，而 minimal-v1 与 Static Context 保留为开发实验能力。
-
在一篇包含大量 Gutenberg 段落、引用、列表、图片和 90 个 Code Block Pro 区块的超长文章中，我继续验证 WordPress 中文到英文整篇 AI 翻译流程。排查过程中先后发现受保护标记过多、普通段落边界过度保护、Plaintext Code Block Pro 内容字段被误判为结构变化，以及空白 freeform 导致 PARAGRAPH_RUN 结构签名漂移等问题。通过引入普通段落区域、区分内容字段与结构配置、修正最终 Gutenberg 结构签名后，受保护标记降至 506 个，最终仍以一次完整 GLM-5.2 请求成功生成英文译文，并通过 Gutenberg 编辑器实际验证。