标签： 多语言翻译
-
随着 Go Learning & Documentation v2 从 A Tour of Go 扩展到 Learn、Docs 以及未来更多 content package，术语治理也需要从 package 级调整到 locale 级。本文介绍为什么同一个 locale 最终只保留一份正式 glossary，以及 Unified Glossary、Terminology Discovery、术语复用和 future content package 之间的关系。同时说明，统一术语表并不意味着无限收录所有词汇，也不意味着 glossary 每次变化都要让全部 TranslationUnit 重新处理。
-
在 Go Learning & Documentation v2 中，Learn / Docs 的 Markdown 内容虽然可以被 parser 拆成标题、段落、列表、代码注释等更小的结构，但正式翻译与审核仍然坚持以完整 Page 作为 TranslationUnit。本文从上下文、自然语序、Independent Review、parser 演进和历史稳定性等角度，解释为什么机器内部的解析粒度不应该直接决定语言治理边界，以及 Page TranslationUnit 与 internal slot 应该如何分工。
-
A Tour of Go 多语言翻译项目正在进入 v2。随着翻译范围从 Tour 扩展到 Site shell、Learn、Docs 以及未来更多 content package，原有围绕 Tour 构建的架构已经不足以继续扩展。本文记录为什么需要 v2，以及 TranslationUnit、统一术语表、内容包、历史复用与网站集成等设计背后的整体思路。
-
在为 A Tour of Go 多语言项目新增阿拉伯语版本时，我第一次真正处理 RTL（从右到左）语言。翻译本身仍沿用既有 TranslationUnit、Quality Check、Course SEO 和 Locale Surface Review 流程，但 RTL 很快暴露了桌面双栏重叠、移动端编辑器被压窄、课程导航方向语义变化、代码区必须保持 LTR 等问题。最终通过调整共享布局、响应式规则和浏览器回归测试完成阿拉伯语正式上线，并在排查 PageUp/PageDown 快捷键时进一步确认了一个可在官方 go.dev/tour 复现的上游焦点问题。整门阿拉伯语实际投入约 7 小时，相比普通 LTR 语言多出的时间，主要来自首个 RTL locale 的一次性基础设施建设。
-
记录 A Tour of Go 多语言翻译项目第一次系统开展站外推广的过程。除了 go.dev、搜索引擎和 GitHub 之外，实际尝试了 Go Weekly、Golang News、Reddit r/golang、DEV Community 和 Go Forum，并记录了投稿、社区活跃度、积分限制、审核机制、内容发布和外链策略。也进一步明确了后续推广思路：不单纯为了 SEO 堆链接，而是优先进入 Go 开发者真实活跃的社区，并逐步为不同语言版本寻找对应的本地开发者渠道。
-
记录我从邮件申请无人回复，到转向 GitHub Issue，再到处理广告、Tour 与 /doc、/blog 的链接边界、统一 feedback tracker，最终让简体中文、法语、德语、韩语 4 个 A Tour of Go 翻译站正式进入 Go 官方 Go local 列表的完整过程。这次收录不仅意味着获得了 go.dev 的官方入口和高质量反向链接，也让我开始用真实数据评估“无广告 Tour ↔ 官方入口”这笔长期交换是否值得。
-
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 韩语版原本预计约 6 小时完成，但最终从初始化到 production 收尾跨越约 44 小时。根据 76 次 Git 提交按 30 分钟封顶方式估算，实际活跃投入约 15 小时 43 分，结合 ChatGPT、Codex、浏览器、服务器、Cloudflare 和 Naver 等未完整进入 Git 的操作，最终更适合记作约 16～18 小时。本文复盘韩语为什么明显慢于法语：包括多轮 Quality Check 与 revision、Final Review 后再次返工、韩语语法触发新的 validator 边界、5 小时模型额度影响生产节奏，以及 TranslationUnit 完成后仍持续出现的 preview、production、Cloudflare、课程目录和 Naver 上线问题。最终也重新认识到，成熟流程的价值并不是保证每门语言都越来越快，而是遇到真实问题时，能够正确地慢下来并留下可复用的改进。
-
A Tour of Go 法语版在约 9 小时内完成上线后，我没有立即开始下一门韩语，而是先继续完善新增 locale 的执行流程。这一轮优化不再重复讨论“如何建立一套标准流程”，而是进一步减少已经可以机械化的重复操作：新增 locale init 初始化能力、自动生成语言骨架与状态文件、完善首次 production 自动化与 production identity、精简命令执行成本，并建立 Deferred Issues 机制记录已经真实发现但暂缓处理的问题。目标不是减少 Quality Check、Final Review 或 production acceptance 等质量 gate，而是把人的时间更多留给真正需要判断的翻译质量和生产风险。
-
A Tour of Go 第三门社区语言 de-DE 已正式上线。从开始推进到完成 TranslationUnit 质量审核、Locale Surface Review、production 部署和最终验收，这一轮粗略投入约 16 小时。 但这 16 小时并不是从零开始完成一门语言的全部成本，而是建立在此前数百小时的项目开发、质量流程、服务器基础设施和第二门语言标准化工作之上的增量成本。de-DE 真正值得复盘的，是第三次完整执行以后又暴露出了哪些历史流程债、哪些人工操作已经可以交给工具，以及为什么下一门语言的目标可以进一步压缩到 8 小时以内。