系列帖子
完成 A Tour of Go 法语版以后，我对下一门语言其实是比较乐观的。
法语版从初始化、翻译、Quality Check、Final Review，一直到首次 production 验收，大约用了 9 小时。更重要的是，法语完成以后，我没有马上开始下一门语言，而是又专门花时间完善了一轮流程：
- 新增 locale 的机械骨架改为正式命令生成；
- 首次 production 继续自动化；
- production identity 进一步收敛；
- 一些 CLI 默认输出开始精简；
- 增加 Deferred Issues，避免已经发现但暂缓的问题只留在聊天记录里。
所以真正开始韩语时，我的预期反而比法语更激进。
我当时觉得：
大约 6 小时，应该有机会完成。
结果完全不是这样。
最终，韩语从 2026 年 9 月 1 日下午开始，一直做到 9 月 3 日上午才完成 production 收尾，随后还增加了 Naver Search Advisor。
如果只看墙钟时间，整个过程跨了约 44 小时。
但当然不能说我连续工作了 44 小时。
因此这次写复盘前，我专门重新根据 Git 提交时间估算了一遍真正的投入。
一、先算清楚：韩语到底用了多久
这次我把：
2026-09-01 14:58:18
feat: 初始化 ko-KR locale作为起点。
把：
2026-09-03 11:04:39
docs: 完成 ko-KR 课程目录修复生产验收记录作为 Git 仓库中这一轮工作的结束点。
中间共有 76 次提交。
从起点到终点：
墙钟跨度：44 小时 6 分 21 秒这个数字显然不能直接当成工作时间。
里面包含：
- 睡觉；
- 吃饭；
- 离开电脑；
- 等待模型额度恢复；
- 其他没有持续工作的时间。
所以我又采用了一个比较保守的估算方法：
相邻两次 Git 提交之间，如果间隔不超过 30 分钟，就按照真实时间计算；如果超过 30 分钟，则最多只记 30 分钟。
这样既不会把晚上睡觉的几个小时算进去，也不会武断地认为：
commit 完以后，我立刻就离开电脑了。
因为在实际工作中，一次 Codex 修改、ChatGPT Quality Check、浏览器验收或者服务器排查，本来就可能三四十分钟都没有新的 Git commit。
按照这个口径，结果是：
15 小时 43 分 25 秒而且这仍然只是一个保守估算。
Git 无法记录很多真实操作，例如：
ChatGPT Quality Check
Codex 执行过程
浏览器检查
服务器命令
Cloudflare Dashboard
Naver Search Advisor尤其是 Naver 的站点登记和 Sitemap 提交，本身就发生在 Git production 收尾之后。
因此，我最后更愿意把这次韩语版的实际投入记作：
约 16～18 小时。
这已经接近原计划 6 小时的 3 倍，也是法语约 9 小时的接近 2 倍。
那么问题就来了：
明明流程已经比法语阶段更完善了，为什么韩语反而慢了这么多？
二、不是“翻译模型慢”，而是整个质量回流次数明显增加了
如果只看“把 122 个 TranslationUnit 翻译出来需要多久”，其实很容易误判一门语言的真实成本。
正式流程里，模型生成第一版译文只是开始。
后面还有：
automatic validation
→ Candidate Snapshot
→ Quality Check
→ revision
→ Quality Check
→ Final Review
→ 必要时再次 revision
→ promotion韩语最明显的问题，就是这条回流链真的跑了很多次。
第一次正式 Quality Check：
qc-001没有直接进入 Final Review。
后面连续导出了：
revision batch 006
revision batch 007
revision batch 008
revision batch 009
revision batch 010修订以后，又进入：
qc-002然后还有：
revision batch 011再进入：
qc-003随后：
revision batch 012之后到了：
qc-004这时候 Quality Check 已经能够进入 Final Review。
但事情仍然没有结束。
qc-004 的 Final Review 又发现了问题，于是流程再次回到：
revision batch 013完成以后重新：
qc-005
→ Final Review qc-005最后才真正通过。
这也是这一轮最让我有感触的地方之一。
以前写流程规范的时候，很容易觉得：
Quality Check
→ Final Review
→ promotion是一条很清晰的线。
但到了真实语言上，它真正的含义其实是：
只要质量没有达到门槛，就必须允许它正确地变慢。
韩语就是这样。
如果为了完成“6 小时目标”，在 qc-001 以后降低门槛，那么当然可以更快。
但那样 6 小时这个数字就没有什么意义了。
三、韩语还暴露了此前没有遇到过的 validator 边界
韩语阶段另一个比较明显的时间消耗来自 automatic validation。
这里需要先说明一点：
中文和日文同样属于非拉丁语系，所以不能说韩语是项目“第一次遇到非拉丁语系”。
真正不同的是：
韩语暴露了一种此前中文、日文阶段没有触发的具体语言边界。
这段 Git 历史非常典型：
完成 ko-KR retranslation batch 004 翻译
→ 记录 batch 004 validation failure
→ 支持 ko-KR 注释标识符韩语后缀
→ 增加 retranslation revalidate 正式流程
→ 记录 batch 004 revalidation evidence
→ 完成 batch 004最开始看到 validation failure 时，很自然的反应是：
翻译哪里把 Go 标识符弄坏了？
但继续检查以后才发现，并不是所有失败都应该通过“修改译文”解决。
韩语有一种非常自然的语言现象：
Go 标识符后面可能直接连接韩语助词。
从韩语语法来看，这是正常写法。
但原来的 validator 更偏向按照拉丁字符词边界识别标识符，于是某些实际上没有被修改的 Go identifier，也可能被判断成“丢失”。
这时候就出现了一个很重要的分界：
如果是真正修改了 protected identifier
→ 必须修改翻译
如果 identifier 完整存在，只是自然连接韩语语法成分
→ 应该检查 validator这件事情后来值得单独写一篇，因为它涉及一个我现在越来越重视的问题：
validator 的目标不是逼所有语言长得像英文，而是检测真正的技术结构损坏。
当然，这也不能走向另一个极端：
只要是韩语 validation failure，就认为 validator 错了。
韩语这次仍然有不少问题确实需要修改译文。
所以正确做法是逐个区分：
到底是语言质量问题，还是验证规则边界问题。
这部分我准备放到下一篇 validator 专题里详细整理，这里先不展开。
四、5 小时额度第一次真正影响了整个生产节奏
韩语阶段还有一个非常现实的问题：
模型额度。
这里的“5 小时额度”很容易被理解错。
它并不是：
我可以连续使用模型 5 个小时。
而是一个使用额度窗口。
在韩语这种 TranslationUnit 数量多、正式翻译之后又需要多轮 revision 的情况下，消耗速度明显比我之前预想得快。
实际工作中，我甚至遇到过：
真正高强度使用一个多小时以后，当前 5 小时额度就已经基本用完。
这会直接改变生产节奏。
正常情况下，我本来可以：
Quality Check
→ export revision
→ Codex 重译
→ process
→ 再次 Quality Check连续推进。
但额度耗尽以后，就会变成：
发现 B
→ 准备 revision
→ 当前额度不足
→ 等待下一个窗口
→ 再继续于是墙钟时间被明显拉长。
这也解释了为什么：
实际投入约 16～18 小时但整个过程却跨了：
44 小时 6 分两者并不矛盾。
这也是我之前单纯用“今天能不能做完一门语言”思考时没有充分考虑的问题。
一门语言真正的生产周期，不只取决于：
TranslationUnit 数量 × 单次翻译速度还取决于：
首次翻译
+ Quality Check
+ revision 数量
+ Final Review
+ 模型额度窗口
+ production 阶段实际问题韩语把这些因素一次性叠加起来了。
五、TranslationUnit promotion 完成以后，事情还远远没有结束
9 月 2 日 18:23 左右，韩语 TranslationUnit 已经完成 promotion。
如果只把“翻译完成”理解成项目完成，那么到这里其实已经可以庆祝了。
但实际上，后面还有很长一段工作。
从提交历史看，后面连续发生了：
自动化 preview Surface Review 验收
记录 ko-KR production 前 Surface Review
提升 shared-assets 生产验收网络稳定性
修复首次生产 Nginx 路径
复用 shared-assets 公网验收核心
兼容 aliyun Python 3.6 预检
修复 ZgoCloud Nginx 路径
简化 Cloudflare 缓存资格验收
提升 production 公网验收稳定性
完善课程目录预渲染与 SEO 元数据
修正课程目录浏览器验收语义
更新 ko-KR 课程目录修复验收记录
完成 ko-KR production 状态收尾
完成 ko-KR 课程目录修复生产验收记录这些问题有些尤其有代表性。
六、法语以后已经优化过 production，但没有经过韩语这次实战
上一篇我刚刚写过，法语完成以后，我专门完善并简化了一轮新增 locale 与首次 production 流程。
从逻辑上讲，韩语应该是第一个真正享受到这轮优化红利的 locale。
它确实享受到了。
但是另一个事实也同时出现了：
写完自动化，不等于自动化已经经历过所有真实环境。
例如首次 production 的 Nginx 路径。
脚本已经存在，流程也已经明确。
但真正跑到新 locale 时，仍然发现路径假设需要修正。
随后又遇到了 ZgoCloud Nginx 路径。
再例如服务器预检。
本地开发环境使用的 Python 版本比较新，但阿里云真实服务器上仍然是 Python 3.6，于是自动化脚本又必须兼容生产环境中的真实版本。
还有 Cloudflare。
理论上的缓存资格检查和真实公网环境中的可稳定验收，并不完全是一回事。
这些都属于：
只有真实跑一次，才会知道原来的假设是否真的成立。
所以法语之后的流程优化并没有白做。
相反，正因为有了自动化，韩语暴露出来的问题才更集中地变成：
脚本失败在哪里？
假设错在哪里？
应该修共享实现，还是 locale-specific 配置？而不是重新手工拼一遍整个 production。
七、连“验收成功”本身，也需要检查验收的是不是正确语义
韩语最后阶段还有一个我觉得很值得记录的问题：
/tour/list。
当时浏览器验收脚本已经能够读取课程目录页面，也能够检查一些结构。
但真实运行以后发现：
脚本检查到“页面里有内容”，不代表它验证的就是我们真正想保证的内容。
后来又专门出现了一次：
fix: 修正课程目录浏览器验收语义这个事情看起来很小，却非常典型。
自动化测试最危险的一种情况并不是：
FAIL因为 FAIL 会逼着我去处理。
真正危险的是：
PASS但这个 PASS 验证的是错误的东西。
例如：
页面存在几个 wrapper。
和：
课程目录正确展示了所有应该展示的 module / lesson。
这两个语义完全不同。
所以这次韩语 production 也再次提醒我：
自动验收不是检查越多越好，而是必须验证正确的业务语义。
八、韩语上线以后，还第一次正式增加了 Naver
等 production、课程目录以及浏览器验收全部完成以后，韩语还有一项其他语言没有的额外工作：
Naver Search Advisor。
对于中文站，我会关注百度。
通用海外 locale 主要关注 Google 和 Bing。
到了韩语，如果仍然完全照搬：
Google Search Console
+ Bing其实并不完整。
因此这次我把：
ko-go-dev.shuijingwanwq.com加入了 Naver Search Advisor，并提交：
https://ko-go-dev.shuijingwanwq.com/sitemap.xml这件事情也让我开始重新理解“新增一门语言”的范围。
最开始容易把它想象成：
把 122 个 TranslationUnit 翻译成另一种语言。
但做到现在，它实际上已经变成：
语言
+ glossary
+ TranslationUnit
+ UI
+ metadata
+ SEO
+ domain
+ CDN
+ Playground
+ production
+ ads
+ search ecosystem其中最后这个 search ecosystem 甚至还不一定能完全共享。
新增韩语，就要考虑 Naver。
以后如果新增其他语言，也可能存在当地占比较高的搜索引擎或者内容生态。
所以所谓“locale-specific”，并不只发生在译文里面。
九、为什么韩语比法语慢，并不能归结成一个原因
如果现在重新看这次 16～18 小时，我已经不太愿意用一句：
“因为韩语比较难翻译。”
来解释。
语言复杂度当然是其中一部分。
我自己也明显感觉到，韩语阶段模型消耗速度比法语、德语更快。
但真正导致总时间增加的是多个因素叠加。
大致可以拆成：
1. 韩语语言本身带来了新的边界
不是项目第一次遇到非拉丁语系，因为此前已经有中文和日文。
但韩语暴露了此前没有遇到的具体语法现象，导致部分 validator 规则需要重新校准。
2. Quality Check 的回流次数明显增加
不是：
qc-001
→ 全 A
→ Final Review而是一直跑到：
qc-005中间还有多批 revision。
3. Final Review 真的独立发现了问题
qc-004 已经进入 Final Review，但并没有因为 Quality Check 已经过关就自动放行。
它重新发现问题，又回到了 revision 013。
这一点虽然增加了时间，但反而证明 Final Review 并不是形式上的第二次盖章。
4. 5 小时额度限制开始明显影响节奏
高强度翻译和 revision 很快消耗当前窗口，必须等待后续额度。
5. production 自动化还处于第一次真正大规模实战阶段
法语之后刚完成的优化，在韩语阶段继续暴露：
Nginx
Python 3.6
shared-assets
Cloudflare
公网验收
课程目录
浏览器验收语义6. 韩语还有 Naver
这部分本身甚至不会留下 Git commit，却同样属于正式上线工作。
所以 16～18 小时并不是“翻译 122 个文件用了 18 小时”。
而是：
把一门新的语言从零推进到真正可以长期维护的 production locale，大约用了 16～18 小时。
这两个概念差别很大。
十、这次真正改变的是我对“6 小时目标”的理解
韩语开始以前，我确实希望：
法语约 9 小时，流程又优化了一轮，那么韩语能不能做到 6 小时？
现在看来，6 小时并不是完全没有意义。
但它只能作为：
happy path 的效率目标。
不能变成硬性上线时间。
如果某一门语言：
首次翻译质量很高
validator 没有新边界
Quality Check 一轮全 A
Final Review 一次通过
Surface Review 没发现新问题
production 基线全部复用成功那么未来做到 6 小时甚至更快，我觉得仍然有可能。
但如果真实 evidence 表明：
有 B
有 validation failure
有 Final Review rejection
有 production failure那正确的流程就应该允许它：
变成 10 小时、15 小时，甚至更久。
这不是流程失败。
真正的流程失败反而是：
为了守住预估时间，把真实失败解释成“不重要”。
十一、流程成熟，不意味着每门语言越来越快
做完法语以后，我一度有一个比较自然的预期：
前一门 9 小时
→ 再优化流程
→ 下一门 6 小时
→ 再下一门 5 小时好像只要继续自动化，新增语言的耗时就应该一路下降。
韩语打破了这种很线性的想象。
我现在更倾向于这样理解：
流程优化降低的是已经理解问题的重复成本，而不能消灭未知问题。
例如：
新增 locale 骨架已经自动化了。
那么韩语不需要再花时间手工搭目录。
首次 production 已经有正式入口。
那么韩语不需要重新设计 deployment。
共享广告架构已经稳定。
那么韩语不需要重新研究广告 SPA 生命周期。
这些时间确实都省掉了。
但与此同时，韩语又第一次把：
韩语助词与 Go identifier 边界
Final Review revision export
真实 production Python 3.6
课程目录预渲染
浏览器验收语义
Naver这些新问题带进了项目。
所以从整个项目来看，这 16～18 小时并不只是：
“韩语比较慢。”
其中还有一部分时间，其实是在替未来的第五门、第六门语言继续修路。
十二、这也是为什么我现在更愿意记录“问题类型”，而不是只记录耗时
如果只看数字：
法语：约 9 小时
韩语：约 16～18 小时很容易得出：
韩语效率退步了。
但如果看这些时间最终留下了什么：
validator 更理解韩语语法边界
revalidate 流程正式化
Quality Check revision evidence 更完整
Final Review failure 可以正式回 revision
preview Surface Review 自动化
shared-assets 验收继续复用
首次 production 的真实环境兼容继续加强
Cloudflare 验收更稳定
课程目录 prerender 与 SEO 更完整
浏览器 acceptance 验证了更正确的语义
Naver 正式进入韩语 locale 生命周期那么这 16～18 小时里有相当一部分，并不是一次性的韩语成本。
它们会继续被后续 locale 复用。
这也是长期项目和单次翻译最大的区别。
小结
韩语版开始以前，我原本预计大约 6 小时。
最终从 Git 记录看：
开始：
2026-09-01 14:58:18
Git production 收尾：
2026-09-03 11:04:39
墙钟跨度：
44 小时 6 分 21 秒
76 次 Git 提交
30 分钟封顶活跃估算：
15 小时 43 分 25 秒考虑 ChatGPT、Codex、浏览器、服务器、Cloudflare、Naver 等没有完整进入 Git 时间线的操作，我最终把真实投入记作：
约 16～18 小时。
它接近最初 6 小时目标的 3 倍。
但这次真正值得记录的，并不是“韩语做慢了”。
而是为什么会慢：
新的语言边界
+ 更多 Quality Check revision
+ Final Review 再次返工
+ 5 小时额度窗口
+ production 自动化首次真实实战
+ 新的课程目录与验收问题
+ Naver 搜索生态法语让我看到：
当流程成熟以后，一门新语言确实可以很快上线。
韩语则补上了另一半：
真正成熟的流程，不是保证每门语言都越来越快，而是在遇到新问题时，仍然知道应该正确地慢在哪里。
对我来说，这比“6 小时上线一门语言”这个数字本身重要得多。
下一篇我准备单独整理这次最典型的技术问题：
当 Go identifier 遇到韩语助词时，为什么一部分看起来“不通过”的翻译，真正需要修改的其实是 validator；又为什么另外一些问题仍然必须回到译文本身修正。
Go 学习与文档多语言本地化项目
本系列完整记录 Go 学习与文档多语言本地化项目从 A Tour of Go 起步，逐步扩展到站点首页、项目说明页、学习内容、文档以及未来内容包的实际开发过程，包括架构设计、统一术语治理、整页翻译、结构保护、自动校验、独立质量审核、生产发布与长期维护。
项目源码：
✅ GitHub：shuijingwan/go-tour-i18n
语言版本：
当前跨项目目标语言池共包含 66 个语言版本。Go 项目本身目前提供 65 个社区 Production 语言版本，下面每一门 Go 语言版本都直接链接到其当前公开站点。语言列表沿用项目首页现有的展示顺序。
英语（美国）仅作为跨项目目标语言纳入列表，并不是单独的 Go Production 语言版本。当前 Go 的英文源内容仍为官方 generic English，因此英语（美国）链接到 Go 官方站点，而不是不存在的本地社区部署。
- 阿姆哈拉语
- 阿拉伯语
- 孟加拉语
- 葡萄牙语（巴西）
- 保加利亚语
- 加泰罗尼亚语
- 克罗地亚语
- 捷克语
- 丹麦语
- 荷兰语
- 英语（美国）（Go 官方英文站点）
- 英语（澳大利亚）
- 英语（加拿大）
- 英语（印度）
- 英语（新加坡）
- 英语（南非）
- 英语（英国）
- 爱沙尼亚语
- 菲律宾语
- 芬兰语
- 法语（法国）
- 法语（加拿大）
- 德语（德国）
- 德语（奥地利）
- 德语（瑞士）
- 希腊语
- 古吉拉特语
- 希伯来语
- 印地语
- 匈牙利语
- 印度尼西亚语
- 意大利语
- 日语
- 卡纳达语
- 哈萨克语
- 韩语
- 西班牙语（拉丁美洲）
- 拉脱维亚语
- 立陶宛语
- 马来语
- 马拉雅拉姆语
- 马拉地语
- 书面挪威语（Bokmål）
- 波斯语
- 波兰语
- 葡萄牙语（葡萄牙）
- 旁遮普语（果鲁穆奇文，印度）
- 罗马尼亚语
- 俄语
- 塞尔维亚语（西里尔文）
- 简体中文（中国大陆）
- 简体中文（新加坡）
- 斯洛伐克语
- 斯洛文尼亚语
- 西班牙语（西班牙）
- 斯瓦希里语（坦桑尼亚）
- 瑞典语
- 泰米尔语
- 泰卢固语
- 泰语
- 繁体中文（台湾）
- 繁体中文（香港）
- 土耳其语
- 乌克兰语
- 乌尔都语
- 越南语
项目正在持续扩展新的 Go 学习与文档内容，并长期维护各语言版本的术语一致性、翻译质量、独立审核、生产发布与后续更新。
本项目属于非官方社区多语言本地化项目，与 Go 官方无隶属、授权或背书关系。