蓝牙协议5.0的英文规范光第6卷就够你翻一整天的。我记得第一次展开那份PDF时的感受满屏的Link Layer、PDU、Connection Event、Channel Selection Algorithm每个单词都认识但它们连成句子之后就是不知道在说什么。我所在的小团队做低功耗蓝牙外设每次调试都离不开这份规范可十几个人里真正能流畅读英文原版的没几个遇到链路层问题就集中到我一个人头上。后来我们干脆组了一个翻译小组把蓝牙协议5.0第6卷从头到尾翻译成了中文。做完之后最大的体会是这个活儿表面上没有技术含量实际非常考验对协议本身的理解翻译过程中逼着我们把之前含糊的概念全部过了一遍。这篇文章就把我们整个翻译过程、踩过的坑、定下来的措辞规范、以及翻译成果怎么反哺开发工作的经验都写出来。想啃规范原文、想做团队知识沉淀的朋友可以参考我们的做法。1. 为什么放着现成的资料不用偏要去翻第6卷1.1 第6卷在整套规范里扮演什么角色蓝牙核心规范本身是分卷发行的第6卷对应“低功耗控制器”这一层也就是常说的LE Controller。它主要规范两块内容一块是低功耗物理层PHY规定无线电信号怎么调制、信道怎么划分、三种PHY模式各自什么参数另一块是低功耗链路层Link Layer规定设备状态怎么切换、广播和扫描报文怎么封装、连接事件怎么调度、加密怎么协商。理解这一层的重要性在于我们平时用厂商SDK开发BLE产品调的大多是Host层的API比如GATT、GAP的抽象接口。可是设备一旦出现连接不稳定、广播不出去、功耗异常这类问题最终都要下沉到第6卷的规则里去解释。SDK有时候会对底层细节做封装甚至简化让开发者远离这些概念这当然友好但出了问题也容易让人无从下手。我们团队当时正准备把一个老旧的外设产品从蓝牙4.2升级到蓝牙5.0。新方案需要支持2M PHY、扩展广播和更大的数据包。这些功能全是第6卷新增或修订的内容。看原版规范是绕不过去的可大家的阅读效率实在太低我才提了一句“要不我们直接把这一卷翻译了”没想到最后真做成了。1.2 团队的真实痛点中文资料太碎术语不统一没做过这个动作之前我低估了术语不统一带来的沟通成本。团队里有人把Advertising叫“广播”有人叫“广告”还有人叫“通告”。开会的时候光确认对方说的是不是同一个概念就要浪费好几分钟。网上中文技术文章写BLE的不少但水平参差不齐同一个术语在A文章里叫“连接事件”在B文章里叫“连接时间窗”在C文章里很可能直接不翻译留着Connection Event。对一个要长期维护的产品线来说这种碎片化的认知是非常危险的。开发、测试、技术支持各按各的理解去处理问题出的文档互相看不懂新人进来更是两眼一抹黑。自己动手翻译第6卷本质上不是做慈善而是把团队里所有关于BLE链路层和物理层的公共认知统一成一套可检索、可引用的内部文档。1.3 自己翻译的收益不止是“有中文版”翻译过程中我们被迫做的最有价值的一件事是给每个关键术语写定义和上下文备注。比如“Channel Selection Algorithm”不能只译成“信道选择算法”还要备注它决定的是每个连接事件在哪个物理信道上传数据5.0新增的CSA#2和旧版CSA#1差别在哪。这些备注最终沉淀成了一份几十页的术语手册比译文本身还好用。另外一个隐藏收益是翻译到哪一章就相当于把那一章精读了一遍。以前我读规范常常跳着读只看自己关心的参数范围对前后文的约束关系并不敏感。翻译不允许这样一个模棱两可的词都可能被别人挑出来问逼着我把语境里的因果关系搞清楚。2. 从协议栈分层看第6卷管到哪一层2.1 协议栈的分工Host和Controller是不一样的世界读第6卷之前我先给团队画了一条非常粗的分层线。BLE协议栈从上到下大致是应用层、主机层Host、主机控制器接口HCI、控制器层Controller。其中Controller里核心的部分就是PHY和Link Layer这两个模块恰好都在第6卷。Host解决的是“数据怎么组织、服务怎么暴露”的问题Controller解决的是“数据到底怎么通过无线电发出去、怎么保证收包对方能正确解调”的问题。两者之间通过HCI分包控制器给主机提供命令和事件主机不直接操作物理层。这里有一个很常见的误区很多人以为BLE的“广播”和“扫描”逻辑都写在应用代码里。实际上应用层只是通过GAP层发起请求真正完成广播包发送、扫描窗口调度、接收地址过滤的都是Controller里Link Layer的状态机。第6卷的链路层部分就是描述这个状态机的。2.2 物理层部分到底写了什么第6卷物理层部分描述的无非是几件事频段和信道、调制方式和发射接收指标。BLE工作在2.4GHz ISM频段信道带宽2MHz一共40个物理信道其中3个广播信道、37个数据信道。物理层规定调制方式是GFSK调制指数约0.5并规定了不同PHY模式下的数据传输速率比如1M PHY、2M PHY以及用于长距离场景的Coded PHY。翻译这部分时最大的坑是“给数字当搬运工”。物理层表格里有大量dbm、微安、微秒级别的参数差一个小数点都是事故。我们当时的做法是不重新排版表格直接在原文表格基础上做双语对照把所有数字原封不动保留中文只处理表头和注释。2.3 链路层部分状态机、事件和时序链路层部分是第6卷的绝对大头。它定义了设备在一段时间内可以处于什么状态待机Standby、广播Advertising、扫描Scanning、发起Initiating、连接Connection。状态之间的迁移由报文的接收和超时定时器触发。除此之外链路层还规定了广播信道的数据单元PDU格式、数据信道的PDU格式、链路层控制过程比如连接参数更新、加密启动、信道地图更新、连接事件调度机制以及地址类型和过滤策略。翻译这部分让我觉得最难的是“把状态机的时序关系讲清楚”。链路层行为像一张复杂的时序图某一时刻能不能发包、收到包之后下一步做什么都由Precise的条件约束着。译成中文时如果只翻译字面描述读者大概率还是看不懂我们就在每个关键事件后面补了简短的时序说明。2.4 谁最需要关注第6卷的内容做蓝牙产品并不是所有人都需要读第6卷。我自己给团队做了一个划分做应用层开发的同学知道广播、连接、扩展广播的概念就够了做协议栈适配的工程师必须精读链路层章节做认证和测试的同事至少要把第6卷物理层里的指标要求看完。这样不同角色各取所需不用被整卷内容吓退。3. 翻译最容易翻车的三类规范句式以及我的取舍3.1 shall/should/may中文怎么译才不产生歧义蓝牙规范里最折磨人的不是生僻词而是大量“法律条文式”的情态动词。英文原版的shall、should、may、can、must在不同章节能把人绕晕。翻译之前我们先统一了规则英文原文我们统一译法语义级别shall必须强制要求不符合就不合规shall not不得强制禁止should应推荐做法正常情况应当遵守但不绝对强制should not不应推荐不要做may可以允许性表述可做可不做can能够表示能力或可能性must必须与原版中少数must保持一致但我们尽可能不主动使用为什么不用很多中文翻译者习惯的“应”来对shall因为我发现“应”在中文里语气不够强。读到“设备应支持XX”的时候经验不足的开发者很容易当成一句建议实际它是一条硬性要求。用“必须”后新人至少不会误判强制力。后来我们做内部评审大家一致认为这个选择是翻译质量最关键的决策之一。3.2 嵌套条件句先拆结构再翻译规范里经常出现这类描述“若设备处于连接状态且已收到包含有效LLData的包则除非某个定时器未启动否则该设备应执行事件A。”翻译这种句子硬按英文语序会变成“中文长难句”读三遍都理不清。我们的处理方式是先拆主干再补条件。先把“设备应执行事件A”放前面然后在后面列出前置条件处于连接状态、收到有效包、定时器已启动。用列表方式展开条件让人一眼看清逻辑。这种操作在翻译时看起来很机械但对读者非常友好。不要试图美化这些句子。规范原文的表达很严谨中文译文的目标是“严谨优先、流畅第二”。一旦为了顺口增删逻辑关系很可能把约束条件写漏。3.3 参数表和时序图最不能自由发挥的地方第6卷里有大量表格像连接间隔的可选范围、超时时间的上下限、PDU类型编码值等。翻译时我们规定表格里所有数值、枚举值、单位符号一律不允许改动中文只处理表头、列名和脚注。时序图也一样。图里的状态名可以翻译但事件箭头的触发条件要保持和原文一模一样不能因为中文表达习惯去合并或简化分支。这块我吃过亏。早期有一张链路层状态迁移图我图省事把“收到无效广播地址时回到待机状态”和“收到超时事件时回到待机状态”合并成了一条“异常时回到待机状态”。技术审校直接给我打回来了因为两个条件后续跳转的时序完全不同。自那以后图和表都改为逐条对照翻译宁慢勿错。3.4 专有名词为什么“Advertising”不译成“广告”行业里把“Advertising”译成“广告”的例子不少。但在蓝牙协议语境下广告的含义容易和商业广告混淆而且“广播”能更自然地和“广播信道”“广播包”组成系列词群。我们在术语表里统一Advertising广播Advertiser广播者Advertisement广播报文。同理Scanner不叫“扫描仪”叫“扫描者”Initiator叫“发起者”不叫“初始化器”。这些词看着小但统一之后就变成了团队内部的共同语言后面做技术文档、写代码注释都受益。4. 十几个人合译不打架的流程术语表与翻译记忆库4.1 先花一周定术语表后面省三个月翻译启动的头一周我们没有让任何人动正文全部精力都用来建术语表。我们把第6卷目录和索引里出现的高频术语整理出来每一条都讨论翻译讨论结果投票决定。这一周看起来进度为零实际是整套流程里最值得的一周。术语表的形式不复杂英文术语、中文翻译、缩写形式、适用上下文、备注和示例。我摘几条当时定下的内容英文术语中文翻译备注Link Layer链路层特指LE Controller中的协议层Connection Event连接事件指定连接中一次收发时机的集合Anchor Point锚点连接事件参考起点Access Address接入地址数据信道PDU的起始字段Supervision Timeout监管超时超过该时间未收到有效包则断开连接Whitelist白名单控制器内部地址过滤机制术语表定完之后所有译者翻译时遇到术语只能往里填不能临时发明新词。谁想新增或修改术语必须先提交讨论再更新表。这样做的结果是十几个人分头翻译的不同章节术语口径完全一致。4.2 用CAT工具加Git每条译文都可追溯翻译的第6卷正文拆成了大约十几个子任务按链路层状态机、广播与扫描、连接与数据、物理层等模块分给不同的人。人一多版本管理就成了大问题。我们采用“CAT工具留存句段翻译记忆 Git做版本管理”的组合。翻译记忆库最大的好处是规范里反复出现“设备必须支持XX”之类的高频句式第一遍翻译后后续相同句段能直接复用或只做微调。光这一项就省了大概三成工作量。Git负责多人协作和回溯。每个人的译文先放自己的分支每周合一次合并时用diff工具检查有没有人误改别人的章节。某天发现物理层一章的发射功率数字对不上原版我们用git历史直接定位到是哪个改动引入的几分钟内完成回滚这在普通网盘协作里不可想象。4.3 版权红线内部译文别外传在这里必须提醒一句蓝牙规范文本的版权归蓝牙技术联盟所有没有授权的情况下完整翻译稿不能公开分享、打包传播。我们翻译的目的纯粹是团队内部技术学习和开发参考成稿只放在内部文档服务器上不对外发布也不拿它做商业用途。不过面向团队内部我们还是会做一个双语对照版方便随时回到英文原版校对。处理版权问题时思路很简单翻译是手段不是目的我们既没有脱离原版标新立异也没有靠它牟利。5. 蓝牙5.0新内容的翻译实战扩展广播、Coded PHY和数据长度扩展5.1 扩展广播Primary、Secondary和Auxiliary的关系蓝牙5.0新增的LE Advertising Extensions是我们翻译时最吃力的一块。它的机制是让广播可以“变大”但又不能占用太多广播信道资源于是引入了主广播信道和次广播信道。最初我们内部把“Primary Advertising”译成“主广播”、“Secondary Advertising”译成“次广播”结果越往下翻译越别扭因为很多句子里需要强调在哪个物理信道上发送。后来改成了“主信道广播”和“次信道广播”一下子清晰了不少。“Auxiliary Packet”我们也纠结了很久直译是“辅助包”但在实际上下文里它承载广告数据主体一点都不“辅助”。最终我们选择了“扩展广播包”并在术语表里注明它和传统ADV_IND广播包的区别。术语翻译不必拘泥于字面重要的是让读者能准确理解它在一个机制里的作用。5.2 LE Coded PHY长距离模式下的编码与速率5.0带来的另一个大变化是LE Coded PHY。它在物理层增加了前向纠错编码用降低速率换传输距离。规范里定义了两档速率一档用S2编码实际速率500kbps另一档用S8编码实际速率125kbps。翻译编码参数时我们差点译错一个关键概念“Coded PHY”不等于“更高功率”它本质上是通过冗余编码让接收端在更差信噪比下仍能解调。很多中文文章把它简单描述成“增大发射功率”从这个角度理解长距离模式是错的。我们特意在译文里加了一句译注提醒研发同事不要误解。5.3 数据长度扩展251字节背后的语义变化LE Data Length ExtensionDLE让单包数据长度从27字节增加到251字节。翻译这一章比较轻松但随后我们发现代码注释、模块设计文档里几乎没人用对“有效载荷”这个概念。规范原文里“payload”在不同章节指的位置不完全一样在广播报文里指除去报头的完整MAC层数据在L2CAP层又指去掉L2CAP头之后的用户数据。翻译时我们给“有效载荷”加了上下文限定词MAC层有效载荷、HCI数据包有效载荷、L2CAP有效载荷。就这一个动作避免了很多后续开发沟通歧义。5.4 新术语从无到有的决策过程翻译新特性时最忌讳一个人拍脑袋。我们遇到“Advertising Extensions”这类没有标准译法的词会先在小组里讨论大家各自说一遍对这个机制的理解确认所有人都理解一致后再定译名。有一次围绕“Extended Advertising”和“Periodic Advertising”的区别我们讨论了整整一个小时。前者是广播包的扩展发送机制后者是周期性的广播序列两者中文名称容易混淆最终我们定下“扩展广播”和“周期性广播”并在术语表里用一句话做了严格区分。6. 双层审校和那些写不尽的勘误6.1 技术审校让懂协议栈的人逐条挑刺初稿完成后第一道关是技术审校。做法是让组里最熟悉链路层的工程师对照英文原版逐章过稿重点检查三条有没有漏译条件句有没有参数抄错有没有把“连接事件”和“广播事件”这类概念混用。印象最深的一次审校发现我们把“connection supervision timeout”译成了“连接监控超时”本身不算错但和术语表里定的“监管超时”不一致。这种不一致在单章里看不出来跨章节放一起就容易困惑。技术审校要做的就是用同一把尺子量所有章节把术语偏离的地方全部揪出来。技术审校还会追问“这句是什么意思”。如果译者自己都没理解译文大概率是照着字面硬译的。对这一类句子我们要求译者写一段白话解释放在译注里哪怕译文本身没问题也要通过这个动作确认译者真读懂了。6.2 语言审校中文表达不够顺的地方再磨一遍技术审校通过后语言审校负责“读起来不像翻译腔”。这一步会调整句子的语序把过长的定语拆开把被动语态改成主动语态。语言审校不能动数字不能动术语。它只负责让一个懂技术但英文一般的人读中文就能顺畅理解规则逻辑。我们当时有一句译文“在连接事件期间如果该设备没有接收到任何包含有效消息的数据包该设备不得在事件结束前发送任何数据。”语言审校改成了“连接事件中若本设备未收到任何有效数据包则事件结束前不得发送数据。”意思一样阅读负担降低不少。6.3 勘误机制翻译完成不等于翻译结束我们必须接受一个事实几千页的规范翻译完一定有错一定有没读懂的地方。所以建立勘误机制非常必要。我们在内部wiki上给译文每章挂了一个勘误区任何人读的时候发现问题随时登记标清原文页码和问题描述再由对应章节负责人确认和更新。这个机制不花多少钱却保证了译文是“活”的。半年里我们陆陆续续修正过十几个点有的是术语统一问题有的是翻译时漏了一个限定条件还有一处是状态迁移的箭头描述错误。开发人员直接受益因为他们不需要每次都被迫回原版核对。最后说点个人体会。翻译完成之后的半年里第6卷中文版成了组里最受欢迎的文档没有之一。我后来带新人看协议的时候基本路线都是先看中文译文建立概念再回到英文原版校准细节。有一次我们做设备断连排查问题出在连接事件窗口太小而广播又太密工程师直接对照译文里链路层那一章的时序描述定位了问题比我以前口头解释半天高效太多。如果你想做类似的事我的建议是别贪多先只翻译第6卷的链路层部分拿到成果、建好术语库之后再考虑碰其他卷。目标小见效快团队也更愿意继续投入。始终记得术语表要“活着”维护不要定完就锁死随着阅读深入对同一个英文术语的理解会越来越精准术语表跟着迭代才是常态。