最近我一直在推进 A Tour of Go 多语言翻译项目。
在 103 个简体中文课程页面全部完成自动翻译和结构校验之后，我开始让 ChatGPT 对这些页面进行发布前的第二轮质量审核。
原本我以为，这一阶段主要会处理一些比较明确的问题，例如：
- 某句话翻译得不够自然；
- 某个技术含义出现偏差；
- 个别英文没有翻译；
- 某些标题带有明显的机器翻译痕迹。
但真正逐页检查以后，我发现还有另一类问题比想象中更值得认真处理：
技术术语应该采用哪一种中文译法？
其中最典型的，就是 Go 中的 channel。
中文互联网里可以看到“通道”“信道”“管道”，也有不少资料干脆直接保留 channel。
如果只是为了让项目内部看起来统一，当然可以统计一下当前 103 页里哪个词出现得更多，然后全部改成那个词。
但我后来觉得，这种做法并不合理。
一个翻译项目内部现在用了什么，并不能反过来证明这个译法就是中文 Go 社区更合适的用法。
于是原本只是审核几个页面，最终又增加了一次中文 Go 核心术语的横向校准。
一、问题从 channel 开始
在审核并发课程时，我首先发现了一个很明显的不一致。
一个页面把 channel 翻译成：
信道
后面的多个页面却使用：
通道
另外还有一个练习页面直接留下了英文：
channel
从项目一致性来说，这肯定需要处理。
但当时第一个问题并不是：
“把少数的‘信道’改成多数的‘通道’就行了吗？”
而是：
中文 Go 社区里，
channel到底通常叫什么？
经过这一轮校准后，项目最终决定：
channel → 通道
并将 concurrency/2 的标题和正文统一调整。
这张页面现在的第一段是：
通道是一种带类型的通信机制，可以通过通道操作符
<-发送和接收值。
这里还顺便调整了原来的另一处表达。
之前写的是：
信道是一种带类型的管道……
从理解上并不困难，但如果项目后续还要把 pipeline 翻译成“管道”，那么再把 channel 定义成“管道”，两个概念很容易在中文里混在一起。
所以最终用了相对中性的：
带类型的通信机制
二、不能因为项目里“通道”更多，就认为它是标准答案
真正让我决定暂停页面修改、先做术语校准的原因，是我发现：
不能拿现有译文自身作为判断现有译文是否正确的依据。
假设当前 103 页中：
- “通道”出现 15 次；
- “信道”出现 2 次；
channel原文出现 1 次。
这最多只能说明：
当前翻译模型更经常生成“通道”。
它不能说明：
中文 Go 世界已经形成了“通道”这一唯一标准。
所以我开始重新查看中文 Go 社区中长期存在的资料。
很快就能看到一个非常直观的现象。
左侧的 Go 语言 101 直接把这一概念称为：
通道
右侧另一套 Go 系列教程则明确使用：
信道（channel）
而如果继续寻找，还可以看到其他资料直接使用英文 channel。
至于“管道”，在很多视频、博客和教程中也非常常见。
所以答案并不是：
某一种译法正确，剩下全部错误。
更准确的情况是：
中文 Go 社区本身就存在多种长期使用的表达。
这意味着技术翻译中的“统一”，和单纯查字典并不是一回事。
三、为什么最后还是选择了“通道”
既然有这么多译法，我最终为什么还是选择：
channel → 通道
而不是“信道”“管道”或者直接保留英文？
这里并不是依靠项目内部出现次数决定的，而是综合考虑了几个因素。
1. “通道”已经是成熟的中文 Go 术语
它并不是这个项目自己创造出来的翻译。
很多长期维护的 Go 中文资料都在使用“通道”，因此中文开发者看到这个词时，一般能够马上和 Go 的 channel 对应起来。
2. “信道”同样成立，但更像项目选择问题
“信道”并不是错误翻译。
而且它在一些中文 Go 教程中已经使用多年。
但是“信道”在中文里同时带有比较明显的通信工程语义。对于 A Tour of Go 这种面向初学者的编程教程，我个人最终还是觉得“通道”稍微自然一些。
所以我的处理不是：
“信道”是错误译法。
而是：
中文社区存在成熟分歧，本项目选择统一使用“通道”。
3. “管道”最好留给 pipeline
这也是我最后倾向“通道”的一个重要原因。
Go 并发领域还有：
pipeline
如果统一采用：
pipeline → 管道
那么再把：
channel → 管道
会让两个不同概念在中文中使用同一个核心术语。
当然，日常解释 channel 时说：
“可以把它想象成一根传递数据的管道。”
完全没有问题。
但是解释时的比喻和项目 glossary 中的正式术语，最好还是分开。
因此目前确定为：
channel→ 通道pipeline→ 管道
这样概念边界更清楚。
四、真正需要解决的不是一个 channel
查到这里以后，我发现，如果只把 channel 改完就停止，其实有点可惜。
因为 103 页审核过程中还遇到了其他类似情况。
例如：
type inference
当前某个页面把它翻译成：
类型推导
这个词能够理解，而且在中文技术资料里也不是完全没人使用。
但是经过横向检查之后，我最终决定统一为：
类型推断
还有：
untyped constant
原来的译文是：
未指定类型的常量
技术意思基本能够理解。
但在 Go 的中文术语体系里：
无类型常量
明显更加简洁，也更加稳定。
于是这次术语调查从一个 channel，逐渐扩展成了对一批核心 Go 术语的重新检查。
五、不是所有术语都应该采用同一种“强制统一”方式
这一轮调查以后，我觉得可以把 Go 中文术语大致分成三类。
第一类：中文社区已经形成较强共识
例如：
slice→ 切片array→ 数组struct→ 结构体type assertion→ 类型断言type inference→ 类型推断untyped constant→ 无类型常量interface value→ 接口值concrete type→ 具体类型type parameter→ 类型参数constraint→ 约束standard library→ 标准库built-in→ 内置
这一类没有太大必要自己创造新的译法。
项目统一使用中文社区已经长期形成的表达即可。
第二类：存在多种成熟译法，项目需要自己选一个
例如：
receiver
中文资料里经常同时看到：
- 接收者
- 接收器
两种都已经使用很长时间。
所以 A Tour of Go 项目决定继续统一使用：
接收者
并不意味着以后看到其他资料里的“接收器”就应该认为它翻错了。
另一个例子是：
type switch
中文资料里能看到：
- 类型选择
- 类型开关
- 类型分支
- 类型 switch
这个项目最终继续采用：
类型选择
它属于：
项目内部固定用法
而不是：
中文世界唯一正确答案
这个区别其实很重要。
第三类：保留 Go 自己的原生名词
最典型的是：
goroutine
中文互联网里大量资料会写：
协程
甚至直接说：
Go 协程
但 goroutine 和传统意义上的 coroutine 并不完全等价。
而且 Go 开发者真正阅读官方文档、源码、错误信息或者搜索技术问题时，最终都会不断遇到：
goroutine
所以目前项目没有强行把它全部翻成“协程”。
而是保留：
goroutine
第一次出现时，再解释：
goroutine 是由 Go 运行时管理的轻量级线程。
我觉得对于技术教程而言，这种处理比把所有英文术语都翻译掉更稳妥。
六、术语讨论最终还是要落到项目里
如果只是讨论完，然后继续依靠翻译模型自己记住这些决定，那么下一轮上游同步时，问题很可能还会重新出现。
所以确定下来以后，这些译法需要真正进入项目维护的 glossary。
这次新增了：
built-in→ 内置channel→ 通道type inference→ 类型推断untyped constant→ 无类型常量untyped numeric constant→ 无类型数值常量
这里有一个细节也挺值得记录。
这些词最终被加入了：
preferred
而不是：
mandatory
我后来还专门让 Codex 检查了项目现有 glossary 的实际实现。
结果发现，当前的 mandatory 并不是简单意味着：
“正文里只要遇到这个英文词，就必须使用指定中文译法。”
它主要参与提示词和部分受保护结构的强制校验。
而：
preferred
主要用于给翻译模型提供统一术语建议。
也就是说，如果未来真的希望做到：
普通正文中任何地方出现
channel，都自动检查是不是翻译成“通道”。
正确的方向应该是增强普通正文术语 validator，而不是简单把 glossary 中的条目从 preferred 移到 mandatory。
这也是这次调查过程中一个额外的收获：
术语表中的配置名称，不一定等于它在实际代码里的校验语义。
最终还是得看实现。
七、basics/14 是一个很典型的实际修改
术语统一真正落到页面以后，basics/14 是一个很适合作为代表的例子。
这个页面原来的标题是：
类型推导
最终改成：
类型推断
原来的正文：
在声明变量时如果不指定显式类型……
改成：
在声明变量时如果不显式指定类型……
这里不只是术语问题，也顺便把中文语序调整得更自然。
另外：
未指定类型的数值常量
被统一成：
无类型数值常量
所以这次发布前审核，并不是要为了“人工润色”而把 GLM-5.2 的译文重新写一遍。
真正的目标更像是：
找到那些确实值得修改的技术术语、语义问题和明显影响阅读的表达，然后做最小修正。
八、术语统一和“追求唯一标准答案”不是一回事
这一轮查完以后，我最大的感受反而不是：
找到了所有 Go 术语唯一正确的中文翻译。
而是：
很多技术术语本来就不存在唯一答案。
例如：
receiver用“接收者”还是“接收器”；type switch用“类型选择”“类型分支”还是直接保留 switch；goroutine是否翻译成“协程”；map是否译为“映射”，还是正文直接写 map。
如果把目标设成：
找出整个中文互联网唯一正确的译法。
最后可能根本得不到答案。
对于一个长期维护的多语言项目，我现在更倾向于采用这样的原则：
先尊重目标语言社区已经形成的习惯，再在存在多种成熟译法时选定项目自己的统一标准。
也就是说：
统一不等于宣布其他译法错误。
这个原则比单纯建立一张“英文 → 中文”的术语表更加重要。
九、这次术语校准最终没有造成大规模返工
开始调查的时候，我其实有一点担心：
会不会一查中文社区用法，发现之前 103 页很多术语都需要重新调整？
结果并没有。
绝大多数核心术语原本就已经比较稳定。
真正需要增加或调整的只是少数几个词。
这也说明前面的 GLM-5.2 整页翻译并没有出现严重的术语体系失控。
最终，这一轮术语调查只是帮助项目进一步明确了：
- 哪些词属于社区强共识；
- 哪些词属于项目自己的固定选择；
- 哪些 Go 专有术语更适合保留英文；
- glossary 应该承担什么职责；
- validator 又应该承担什么职责。
这比单独修掉一个：
信道 → 通道
更有长期价值。
十、总结
这次事情最开始非常简单。
我只是在审核 concurrency/2 时发现：
为什么这里叫“信道”，后面的页面却叫“通道”？
如果只是为了尽快完成项目，最简单的方法当然是：
看哪个出现得多，就统一成哪个。
但我后来还是决定停下来确认一下。
结果发现：
一个技术翻译项目不能拿自身现有译文作为术语是否合理的最终依据。
尤其是 Go 这种已经拥有大量中文技术资料和多年社区积累的语言，更应该先看看中文开发者长期以来究竟是怎么表达这些概念的。
最终，A Tour of Go 简体中文版本确定：
channel→ 通道
但更重要的并不是这个单独的结果。
真正形成的是一套以后还能继续使用的判断原则：
社区强共识的术语直接采用；存在成熟分歧的术语由项目统一选择；Go 原生专有名词则不为了中文化而强行翻译。
这套原则后面不仅会用于当前 zh-CN。
如果项目以后增加新的目标语言，同样需要面对：
这个语言的技术社区到底已经形成了什么样的术语习惯？
所以这一轮看似只是调整了几个词，实际上也补上了多语言翻译项目中非常重要的一块：
术语不是模型生成结果的附属品，而应该成为项目长期维护的一部分。
而完成术语校准之后，我才继续处理 103 页正文审核中真正值得修改的页面。
最终结果是：
103 页全部审计，只修改了 16 页。
这个过程，就留到下一篇继续记录。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 简体中文：A Tour of Go 简体中文版
✅ 日语：A Tour of Go 日语版
✅ 德语：A Tour of Go 德语版
✅ 法语：A Tour of Go 法语版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前已上线简体中文、日语、德语和法语版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。