简介ECMAScript 6ES2015官方语言规范的中文翻译资料包面向需要精读规范的前端开发者、JavaScript 学习者及框架源码研究者旨在解决英文原版篇幅长、术语多、查阅不便的问题。压缩包内共18个文件涵盖按章节拆分的 htm 格式中文译文、完整 PDF 版、配套 CSS 样式与 SVG/PNG 图表以及 README 说明文档核心内容覆盖 Scope、Conformance、Normative references 等正式规范章节并有完整的目录索引总大小约 6.66MB结构清晰便于本地离线检索。目前已有 261 人学习下载。对希望逐条理解 ES6 语法定义、类型系统与执行语义的读者来说这份翻译稿可作日常参考手册其中保留的图表与样式文件还原了原版排版适合对照英文原文学习或二次校对也能帮助梳理规范整体逻辑。 在JavaScript圈子里如果你想了解一门语言的“真相”几乎只有一个去处ECMA-262规范也就是ECMAScript语言规范。尤其是ES6ES2015之后Promise、Generator、class、Module这些机制突然堆满网上的二手教程各说各话有矛盾的地方太多了。最后真正能拍板的只有规范原文。而这个项目——ecma262-6-cn就是把ECMA-262第6版规范翻译成中文的社区开源工程。说明项目一般对应GitHub上以“ecma262-6-cn”命名的仓库内容为ECMAScript 6ES2015规范的中文翻译版。文中提到的流程、实践均基于这类社区翻译项目常见做法来补全。翻译一本给引擎开发者看的规范看起来是“英语转中文”的问题做起来你就知道它本质上是一个“必须先精通JavaScript执行模型再做语言转换”的工程问题。如果只是拿机器翻译铺一遍术语前后打架被动语态生硬那么这份译文不但帮不到人还会把初学读者带到坑里。所以这个项目更值得聊的不是最终产出的PDF或网页而是它背后关于术语取舍、结构对应、审校流程那一整套经验。这篇博文我打算从项目定位、翻译思路、实操流程、易错点、社区协作五个维度展开。无论你是想读这份中文规范还是自己打算维护一个技术文档翻译项目我下面写的这些坑和心得应该都能派上用场。1. 项目定位与背景为什么“旧标准”的翻译到现在还有价值1.1 ES6规范到底解决什么问题ES6是ECMAScript第六版的俗称官方编号是ECMA-262 Edition 6发布于2015年因此也叫ES2015。这版不是一次简单的增量更新而是JavaScript语言历史上最大的一次语法和语义扩展块级作用域、箭头函数、类、模板字符串、解构赋值、Symbol、Proxy、Reflect、Promise、Iterator、Generator、Module一次性全塞了进来。这套语法今天大家都当家常便饭但它的底层语义非常微妙。比如Generator的yield什么时候挂起、挂起后next()参数从哪里传入、return()和throw()到底走哪个分支这些细节在MDN文档里通常只给结果不给过程。想弄明白就得回到规范的“生成器函数求值”那一节看算法步骤。规范原文是几百页英文术语密集句式拗口。比如“If Type(value) is Object, then return true.”这种句子单独看还行但要连续理解“抽象操作”“内部槽”“完成记录”这些概念对英文非母语的开发者门槛非常高。ecma262-6-cn这类翻译项目的价值就是把门槛放低让更多中文开发者能够对照权威定义理解语言机制本身的运行规则而不是停留在“会用某个API”的层面。1.2 项目形态与目标读者这个项目不是一个教程也不打算替代MDN或各种ES6入门书。它的定位非常清楚一份与原文结构一一对应的中文参考书甚至可以看作英文规范的超链接式中文镜像。使用方式通常是你遇到一个规范细节先翻到对应章节看中文遇到不确定的术语再看原文最终以原文为准。目标读者大致有三类。第一类是写框架、写编译工具、写Babel插件或类型声明文件的“高级应用开发者”他们需要精确理解语法语义第二类是技术写作者要把规范内容转述成博客或课程中文版能帮他们快速定位原意第三类是刚接触语言底层机制的进阶学习者英文还没到能顺畅啃原文的程度需要一份高质量译文作为过渡。做这个项目之前有个常识要记住它不是官方文件中文翻译版从法律效力上和原版没有任何关系。真正有约束力的规范始终是ECMA International发布的那份英文原文。因此项目里必须明确写清楚“以英文原版为准”这不是客套是法律上也是使用场景上的一个必要提示。2. 翻译思路从“字面能看懂”到“语义不歧义”2.1 术语体系先于正文我见过不少翻译项目最大的败笔就是边翻边定术语。第10章把“property”翻成“属性”第24章又翻成“性质”读者根本不知道这两个词在规范里指的是同一个东西。ecma262-6-cn这类成熟项目的做法是先做一张术语表再动手翻译。术语表里至少需要列出三类条目必须中文且无争议的type类型、value值、object对象、function函数、property属性、method方法。保持英文或用括号括注的Promise、Symbol、Proxy、Reflect这些在中文语境里已经直接使用强行翻译成“承诺对象”“符号”反而制造混乱。容易翻错必须严格统一的internal slot内部槽、exotic object外来对象/非常规对象、abrupt completion突然完成/异常完成、early error早期错误、tail position尾位置/尾部位置。术语表不是一次性做完就完事。每次翻译新章节或者审校反馈中出现术语不统一项目维护者需要把新译法补充进表里并标注“第一次出现在哪个章节”。这样后来的人接手时不需要从头猜哪些词是约定译法直接查表就行。2.2 保留英文术语的边界这里要强调一个很容易走极端的点不是所有词都必须翻成中文。规范语言里有很多“基础术语词”它们在正式翻译中的正确处理方式其实是“首次出现时给中文译法并保留英文原文后续重复出现时只用中文”。例如“lexical environment”译成“词法环境”但第一次出现时最好写成“词法环境lexical environment”“Execution Context”译成“执行上下文”同样需要括注。还有一批更特殊的词建议原文保留不做翻译比如“closure”闭包本身可以翻译但很多地方直接用“闭包”已经足够、“spread”展开语法/扩展元素、“tagged template”带标签的模板字符串。这些词在社区讨论中本来就不存在统一的中文叫法强行翻译只会让中文译文的读者和中文社区里的其他开发者“语言隔离”。规范翻译最重要的目标永远是“准确、可对照”而不是“完全本土化”。2.3 章节结构与原版一一对应ECMA-262有它自己的目录结构第1-3章是范围、引用、定义第4-7章是语言概览第8章之后才是类型/抽象操作/词法语法/执行上下文这些核心内容。翻译项目最简单的做法就是保持原版的章、节、子节编号不变。不要重新编排章节序号否则当读者想对照英文原版查同一段内容时会完全找不到北。文件组织上常见的方式是按照chapter拆分Markdown文件比如chapter-08-types.md、chapter-09-ordinary-and-exotic-objects-behaviours.md。每一章内部也严格使用和原文一致的编号标题。这样Git提交时diff更清晰有人翻译了一半退出另一个贡献者可以直接接手不存在“只有原作者知道下一段翻到哪”的问题。标题本身就是索引这对开源协作非常关键。3. 实操怎么把一份规范翻译得又准又稳3.1 源文件与版本选型2020年后的ECMA-262英文原版直接用Ecmarkup语法维护在GitHub仓库tc39/ecma262里。但ecma262-6-cn这类项目翻译的是ES6版本也就是说源文件可能是类似的HTML/Markdown形式也可能是从PDF导出的纯文本。不同来源整理出来的“可编辑底稿”差别很大直接决定了翻译工作量。我的建议是选择单一且完整的源文件比如官方release的HTML版本然后按章节抽取文本。千万不要自己手打原文也不要从二手网站复制粘贴因为格式错乱会导致后面所有审校步骤都失效。手头没有同版本源文件的情况下宁可先去补源也不要直接开翻。版本选型上还有一件事值得留意你翻的是Edition 6不是别的版本。ES6之后还有ES7、ES8一直到现在的ES2025。有些章节在后来的版本里被重写、整合甚至废弃如果底稿混入了新版内容译文就会和原版对不上。项目里最好写明“当前对齐的原文版本号如ECMA-262 6th Edition / June 2015”并在提交PR时同步记录源文件commit号。3.2 翻译一份章节的具体步骤以翻译第25章“Promise对象”为例我的实战顺序是这样第一步通读原文两遍。第一遍只看算法步骤不看注释第二遍再结合例子、注解看完整章节。目标是让整个“执行流程”在脑子里面跑通。如果读完还是不懂这段规范在干什么不要急着写中文先把理解问题解决掉。第二步对照术语表标记关键词。作者自己脑补出一个和术语表不一致的译法是很常见的事。最好把“术语表”和“原文”分屏逐句翻译每当遇到表内术语用同一个中文词替换不要临场发挥。第三步动笔翻译句子。规范原文最头疼的是嵌套从句比如“Return the result of evaluating the VariableDeclarationList in the first production in the expanded list of productions.”直译出来是“返回求值扩展产生式列表中第一个产生式内的变量声明列表的结果”这显然非常生硬。在规范翻译里遇到这种结构我通常的处理是拆分成两层先译“返回值是什么”——一个VariableDeclarationList的求值结果再补充“哪里来的”——它在展开的产生式列表中对应第一个产生式。可以用自然中文表达但不要改变信息层级也不要把“Return”这种语义词丢掉。第四步用伪代码或者注释方式给自己讲一遍译文。如果你能不看原文用中文把这段规范说清楚而且步骤之间的因果没错那这段翻译大概率合格。说不清楚就回头重读原文。3.3 用代码验证译文规范翻译有个很大的优势你可以用真实代码去验证你对原文的理解。比如你在翻译“Promise.resolve如果接收一个thenable对象会以该对象为this调用它的then方法”这句时可以直接在Node里跑一段测试代码const thenable { then(onFulfilled, onRejected) { onFulfilled(42); } }; Promise.resolve(thenable).then(v console.log(v)); // 42跑出来的输出和文档描述一致就说明这句译文没有语义偏差。如果测试结果和你大概率理解的译文冲突那就要回过头仔细看原文字眼比如“调用then方法时使用了谁作为this值”这类细节。我一直觉得规范翻译项目应该把“验证代码”作为审校流程的一环而不只是靠人眼比对中英文。人都可能看错但测试不会。4. 踩坑与避坑实录那些容易翻“妖”的地方4.1 一批翻出来就很尴尬的术语直接举个例子。Completion Record在ES6规范里指函数返回时附带的一个记录包含「类型」normal/return/throw/break/continue和「值」。有人把它翻成“完成记录”有人译成“完成态对象”但这俩术语容易让读者联想到“异步任务是否完成”。更贴近语义的译法可能是“完成结果记录”或者“完成记录Completion Record”并解释它和完成状态的关联。这种词必须靠项目内术语表拍板不能各翻各的。再比如argument和parameter。普通教程经常混着说但规范里是有明确区分的parameter是函数声明里的形参argument是调用时传递的实际参数。如果翻译时都用“参数”读者就会漏掉这层差异。规范翻译对术语的敏感度必须高到病态。还有strict mode里的strict有人译为“严格”有人译为“严谨”。在正式翻译中统一用“严格模式”问题不大但如果章节中出现“use strict directive”直译成“使用严格指令”也别扭不如处理成“use strict指令”并保留原文形式。4.2 语法和语义不能互译ECMA-262规范里有很多地方描述的不是“语言行为”而是“语法产生式”。比如“BindingIdentifier : Identifier”这表示一种语法结构你不能把它翻译成“绑定标识符就是普通标识符”就算完。这里最好保留产生式本身并附加说明性翻译BindingIdentifier : Identifier译注该产生式表示BindingIdentifier在这种情况下与Identifier具有相同的词法形态。之所以要保留产生式是因为读者需要借助这个语法记号才能在上下文里对照原文理解“这里为什么少了一个?”之类的细节。把语法结构翻译成纯文字会在读者查对原版时制造很大麻烦。另一些看似好翻的句子也容易栽。比如“The abstract operation StringToNumber converts a String to a Number.”如果你翻成“抽象操作StringToNumber将一个字符串转换为一个数字”已经不错了但要警觉这里的“抽象操作”四个字是规范术语它有特定含义代表的是规范内定义的内部步骤不是可被用户直接调用的方法。如果漏掉“抽象操作”而只写“方法”语义就变了。4.3 中文表达与“被翻译感”的平衡翻译规范最容易出现两类问题一类是过度直译把英文语序原封不动搬过来中文念起来像机翻另一类是过度意译把原文中严谨的法律性口气全删了变成一个活泼的博客语调。规范翻译的正确方向是“专业但自然”。我的做法是把长句强拆。原文一个从句套从句的句子拆成两个甚至三个中文短句然后用“如果……则……”“当……时……”这些术语性的连词串起来。中文句子之间不需要像英文那样频繁用that/which体现修饰关系。只要所有关键信息点都覆盖到读起来顺畅不绕口就能同时满足准确和可读性。另外语气上尽量克制。原文的“It is an error for host code to use these features”不能被翻译成“宿主代码是不允许使用这些特性的哦”这个“哦”字会毁掉整段规范的权威感。保持中性、禁止口语化扩展是规范翻译的铁律。5. 社区协作与后续维护5.1 提PR之前应该自己检查三遍开源翻译项目最大的灰色地带是“每个人看觉得自己翻得没毛病”。实际项目里一个合格的PR至少需要经过这样一轮自检术语检查稿子里所有关键词跟术语表比对过没有漏掉或新增的术语有没有同步到表里编号检查章节编号和原版完全一致内部交叉引用比如“见第9.4.1节”能不能跳到正确位置回读检查把译文从头念一遍不用看原文信息是否完整、逻辑是否通顺第二遍再对照原文逐句核对有没有句子被漏掉或误合并很多第一次参与的贡献者喜欢只提交自己翻的那几章但又不更新目录文件、索引文件结果PR合进去后站点页面整体导航崩掉。因此项目维护者往往会有一个补充要求新增或修改章节必须同时更新对应SRC目录下的导航文件或索引页面并把术语表中涉及的新词补上。提PR时说明“影响的章节范围”对维护者来说是最友好的做法。5.2 常见误区和成果沉淀在社区翻译项目里最常见的误区有三个。第一个误区是“过度追求100%与原文对齐”。规范里大量存在“Implementation defined behavior”翻译成“由实现定义的行为”是准确的但有的贡献者非要进一步解释“即不同浏览器可能有不同表现”避免不能乱写。如果原文没有的就不该加。第二个误区是“不去理解背景就翻译”。有的人翻到HostEnsureCanCompileStrings这种操作完全不知道它和CSP内容安全策略的关系直接照字面翻译出来。结果读者根本看不懂“宿主确保可以编译字符串”是什么鬼。这种情况下保留英文术语并添加译注比硬译一个中文名要负责得多。第三个误区是“翻译完就不管了”。规范是一套活的文档它的算法语义在不同Edition之间会互相影响。即便只维护ES6版当上游仓库更新了目录结构或勘误表翻译项目仍然需要跟进校正。翻译项目的寿命取决于维护者能否建立“长期定期同步”的机制。我个人在参与这类项目时最大的收获是对JavaScript语言的理解彻底从“表面的用法”下沉到了“规范算法执行”的层面。翻译一段GeneratorYield的过程远比读十个关于Generator的博客更管用。如果你也想参与进来不用去当什么大而全的协调者先挑一个自己天天用还很感兴趣的小章节比如Map、Set、Promise.resolve那一段翻译完跑一遍测试提一个PR就会发现自己对ES6的理解有了质的变化。本文还有配套的精品资源点击获取
简介ECMAScript 6ES2015官方语言规范的中文翻译资料包面向需要精读规范的前端开发者、JavaScript 学习者及框架源码研究者旨在解决英文原版篇幅长、术语多、查阅不便的问题。压缩包内共18个文件涵盖按章节拆分的 htm 格式中文译文、完整 PDF 版、配套 CSS 样式与 SVG/PNG 图表以及 README 说明文档核心内容覆盖 Scope、Conformance、Normative references 等正式规范章节并有完整的目录索引总大小约 6.66MB结构清晰便于本地离线检索。目前已有 261 人学习下载。对希望逐条理解 ES6 语法定义、类型系统与执行语义的读者来说这份翻译稿可作日常参考手册其中保留的图表与样式文件还原了原版排版适合对照英文原文学习或二次校对也能帮助梳理规范整体逻辑。 在JavaScript圈子里如果你想了解一门语言的“真相”几乎只有一个去处ECMA-262规范也就是ECMAScript语言规范。尤其是ES6ES2015之后Promise、Generator、class、Module这些机制突然堆满网上的二手教程各说各话有矛盾的地方太多了。最后真正能拍板的只有规范原文。而这个项目——ecma262-6-cn就是把ECMA-262第6版规范翻译成中文的社区开源工程。说明项目一般对应GitHub上以“ecma262-6-cn”命名的仓库内容为ECMAScript 6ES2015规范的中文翻译版。文中提到的流程、实践均基于这类社区翻译项目常见做法来补全。翻译一本给引擎开发者看的规范看起来是“英语转中文”的问题做起来你就知道它本质上是一个“必须先精通JavaScript执行模型再做语言转换”的工程问题。如果只是拿机器翻译铺一遍术语前后打架被动语态生硬那么这份译文不但帮不到人还会把初学读者带到坑里。所以这个项目更值得聊的不是最终产出的PDF或网页而是它背后关于术语取舍、结构对应、审校流程那一整套经验。这篇博文我打算从项目定位、翻译思路、实操流程、易错点、社区协作五个维度展开。无论你是想读这份中文规范还是自己打算维护一个技术文档翻译项目我下面写的这些坑和心得应该都能派上用场。1. 项目定位与背景为什么“旧标准”的翻译到现在还有价值1.1 ES6规范到底解决什么问题ES6是ECMAScript第六版的俗称官方编号是ECMA-262 Edition 6发布于2015年因此也叫ES2015。这版不是一次简单的增量更新而是JavaScript语言历史上最大的一次语法和语义扩展块级作用域、箭头函数、类、模板字符串、解构赋值、Symbol、Proxy、Reflect、Promise、Iterator、Generator、Module一次性全塞了进来。这套语法今天大家都当家常便饭但它的底层语义非常微妙。比如Generator的yield什么时候挂起、挂起后next()参数从哪里传入、return()和throw()到底走哪个分支这些细节在MDN文档里通常只给结果不给过程。想弄明白就得回到规范的“生成器函数求值”那一节看算法步骤。规范原文是几百页英文术语密集句式拗口。比如“If Type(value) is Object, then return true.”这种句子单独看还行但要连续理解“抽象操作”“内部槽”“完成记录”这些概念对英文非母语的开发者门槛非常高。ecma262-6-cn这类翻译项目的价值就是把门槛放低让更多中文开发者能够对照权威定义理解语言机制本身的运行规则而不是停留在“会用某个API”的层面。1.2 项目形态与目标读者这个项目不是一个教程也不打算替代MDN或各种ES6入门书。它的定位非常清楚一份与原文结构一一对应的中文参考书甚至可以看作英文规范的超链接式中文镜像。使用方式通常是你遇到一个规范细节先翻到对应章节看中文遇到不确定的术语再看原文最终以原文为准。目标读者大致有三类。第一类是写框架、写编译工具、写Babel插件或类型声明文件的“高级应用开发者”他们需要精确理解语法语义第二类是技术写作者要把规范内容转述成博客或课程中文版能帮他们快速定位原意第三类是刚接触语言底层机制的进阶学习者英文还没到能顺畅啃原文的程度需要一份高质量译文作为过渡。做这个项目之前有个常识要记住它不是官方文件中文翻译版从法律效力上和原版没有任何关系。真正有约束力的规范始终是ECMA International发布的那份英文原文。因此项目里必须明确写清楚“以英文原版为准”这不是客套是法律上也是使用场景上的一个必要提示。2. 翻译思路从“字面能看懂”到“语义不歧义”2.1 术语体系先于正文我见过不少翻译项目最大的败笔就是边翻边定术语。第10章把“property”翻成“属性”第24章又翻成“性质”读者根本不知道这两个词在规范里指的是同一个东西。ecma262-6-cn这类成熟项目的做法是先做一张术语表再动手翻译。术语表里至少需要列出三类条目必须中文且无争议的type类型、value值、object对象、function函数、property属性、method方法。保持英文或用括号括注的Promise、Symbol、Proxy、Reflect这些在中文语境里已经直接使用强行翻译成“承诺对象”“符号”反而制造混乱。容易翻错必须严格统一的internal slot内部槽、exotic object外来对象/非常规对象、abrupt completion突然完成/异常完成、early error早期错误、tail position尾位置/尾部位置。术语表不是一次性做完就完事。每次翻译新章节或者审校反馈中出现术语不统一项目维护者需要把新译法补充进表里并标注“第一次出现在哪个章节”。这样后来的人接手时不需要从头猜哪些词是约定译法直接查表就行。2.2 保留英文术语的边界这里要强调一个很容易走极端的点不是所有词都必须翻成中文。规范语言里有很多“基础术语词”它们在正式翻译中的正确处理方式其实是“首次出现时给中文译法并保留英文原文后续重复出现时只用中文”。例如“lexical environment”译成“词法环境”但第一次出现时最好写成“词法环境lexical environment”“Execution Context”译成“执行上下文”同样需要括注。还有一批更特殊的词建议原文保留不做翻译比如“closure”闭包本身可以翻译但很多地方直接用“闭包”已经足够、“spread”展开语法/扩展元素、“tagged template”带标签的模板字符串。这些词在社区讨论中本来就不存在统一的中文叫法强行翻译只会让中文译文的读者和中文社区里的其他开发者“语言隔离”。规范翻译最重要的目标永远是“准确、可对照”而不是“完全本土化”。2.3 章节结构与原版一一对应ECMA-262有它自己的目录结构第1-3章是范围、引用、定义第4-7章是语言概览第8章之后才是类型/抽象操作/词法语法/执行上下文这些核心内容。翻译项目最简单的做法就是保持原版的章、节、子节编号不变。不要重新编排章节序号否则当读者想对照英文原版查同一段内容时会完全找不到北。文件组织上常见的方式是按照chapter拆分Markdown文件比如chapter-08-types.md、chapter-09-ordinary-and-exotic-objects-behaviours.md。每一章内部也严格使用和原文一致的编号标题。这样Git提交时diff更清晰有人翻译了一半退出另一个贡献者可以直接接手不存在“只有原作者知道下一段翻到哪”的问题。标题本身就是索引这对开源协作非常关键。3. 实操怎么把一份规范翻译得又准又稳3.1 源文件与版本选型2020年后的ECMA-262英文原版直接用Ecmarkup语法维护在GitHub仓库tc39/ecma262里。但ecma262-6-cn这类项目翻译的是ES6版本也就是说源文件可能是类似的HTML/Markdown形式也可能是从PDF导出的纯文本。不同来源整理出来的“可编辑底稿”差别很大直接决定了翻译工作量。我的建议是选择单一且完整的源文件比如官方release的HTML版本然后按章节抽取文本。千万不要自己手打原文也不要从二手网站复制粘贴因为格式错乱会导致后面所有审校步骤都失效。手头没有同版本源文件的情况下宁可先去补源也不要直接开翻。版本选型上还有一件事值得留意你翻的是Edition 6不是别的版本。ES6之后还有ES7、ES8一直到现在的ES2025。有些章节在后来的版本里被重写、整合甚至废弃如果底稿混入了新版内容译文就会和原版对不上。项目里最好写明“当前对齐的原文版本号如ECMA-262 6th Edition / June 2015”并在提交PR时同步记录源文件commit号。3.2 翻译一份章节的具体步骤以翻译第25章“Promise对象”为例我的实战顺序是这样第一步通读原文两遍。第一遍只看算法步骤不看注释第二遍再结合例子、注解看完整章节。目标是让整个“执行流程”在脑子里面跑通。如果读完还是不懂这段规范在干什么不要急着写中文先把理解问题解决掉。第二步对照术语表标记关键词。作者自己脑补出一个和术语表不一致的译法是很常见的事。最好把“术语表”和“原文”分屏逐句翻译每当遇到表内术语用同一个中文词替换不要临场发挥。第三步动笔翻译句子。规范原文最头疼的是嵌套从句比如“Return the result of evaluating the VariableDeclarationList in the first production in the expanded list of productions.”直译出来是“返回求值扩展产生式列表中第一个产生式内的变量声明列表的结果”这显然非常生硬。在规范翻译里遇到这种结构我通常的处理是拆分成两层先译“返回值是什么”——一个VariableDeclarationList的求值结果再补充“哪里来的”——它在展开的产生式列表中对应第一个产生式。可以用自然中文表达但不要改变信息层级也不要把“Return”这种语义词丢掉。第四步用伪代码或者注释方式给自己讲一遍译文。如果你能不看原文用中文把这段规范说清楚而且步骤之间的因果没错那这段翻译大概率合格。说不清楚就回头重读原文。3.3 用代码验证译文规范翻译有个很大的优势你可以用真实代码去验证你对原文的理解。比如你在翻译“Promise.resolve如果接收一个thenable对象会以该对象为this调用它的then方法”这句时可以直接在Node里跑一段测试代码const thenable { then(onFulfilled, onRejected) { onFulfilled(42); } }; Promise.resolve(thenable).then(v console.log(v)); // 42跑出来的输出和文档描述一致就说明这句译文没有语义偏差。如果测试结果和你大概率理解的译文冲突那就要回过头仔细看原文字眼比如“调用then方法时使用了谁作为this值”这类细节。我一直觉得规范翻译项目应该把“验证代码”作为审校流程的一环而不只是靠人眼比对中英文。人都可能看错但测试不会。4. 踩坑与避坑实录那些容易翻“妖”的地方4.1 一批翻出来就很尴尬的术语直接举个例子。Completion Record在ES6规范里指函数返回时附带的一个记录包含「类型」normal/return/throw/break/continue和「值」。有人把它翻成“完成记录”有人译成“完成态对象”但这俩术语容易让读者联想到“异步任务是否完成”。更贴近语义的译法可能是“完成结果记录”或者“完成记录Completion Record”并解释它和完成状态的关联。这种词必须靠项目内术语表拍板不能各翻各的。再比如argument和parameter。普通教程经常混着说但规范里是有明确区分的parameter是函数声明里的形参argument是调用时传递的实际参数。如果翻译时都用“参数”读者就会漏掉这层差异。规范翻译对术语的敏感度必须高到病态。还有strict mode里的strict有人译为“严格”有人译为“严谨”。在正式翻译中统一用“严格模式”问题不大但如果章节中出现“use strict directive”直译成“使用严格指令”也别扭不如处理成“use strict指令”并保留原文形式。4.2 语法和语义不能互译ECMA-262规范里有很多地方描述的不是“语言行为”而是“语法产生式”。比如“BindingIdentifier : Identifier”这表示一种语法结构你不能把它翻译成“绑定标识符就是普通标识符”就算完。这里最好保留产生式本身并附加说明性翻译BindingIdentifier : Identifier译注该产生式表示BindingIdentifier在这种情况下与Identifier具有相同的词法形态。之所以要保留产生式是因为读者需要借助这个语法记号才能在上下文里对照原文理解“这里为什么少了一个?”之类的细节。把语法结构翻译成纯文字会在读者查对原版时制造很大麻烦。另一些看似好翻的句子也容易栽。比如“The abstract operation StringToNumber converts a String to a Number.”如果你翻成“抽象操作StringToNumber将一个字符串转换为一个数字”已经不错了但要警觉这里的“抽象操作”四个字是规范术语它有特定含义代表的是规范内定义的内部步骤不是可被用户直接调用的方法。如果漏掉“抽象操作”而只写“方法”语义就变了。4.3 中文表达与“被翻译感”的平衡翻译规范最容易出现两类问题一类是过度直译把英文语序原封不动搬过来中文念起来像机翻另一类是过度意译把原文中严谨的法律性口气全删了变成一个活泼的博客语调。规范翻译的正确方向是“专业但自然”。我的做法是把长句强拆。原文一个从句套从句的句子拆成两个甚至三个中文短句然后用“如果……则……”“当……时……”这些术语性的连词串起来。中文句子之间不需要像英文那样频繁用that/which体现修饰关系。只要所有关键信息点都覆盖到读起来顺畅不绕口就能同时满足准确和可读性。另外语气上尽量克制。原文的“It is an error for host code to use these features”不能被翻译成“宿主代码是不允许使用这些特性的哦”这个“哦”字会毁掉整段规范的权威感。保持中性、禁止口语化扩展是规范翻译的铁律。5. 社区协作与后续维护5.1 提PR之前应该自己检查三遍开源翻译项目最大的灰色地带是“每个人看觉得自己翻得没毛病”。实际项目里一个合格的PR至少需要经过这样一轮自检术语检查稿子里所有关键词跟术语表比对过没有漏掉或新增的术语有没有同步到表里编号检查章节编号和原版完全一致内部交叉引用比如“见第9.4.1节”能不能跳到正确位置回读检查把译文从头念一遍不用看原文信息是否完整、逻辑是否通顺第二遍再对照原文逐句核对有没有句子被漏掉或误合并很多第一次参与的贡献者喜欢只提交自己翻的那几章但又不更新目录文件、索引文件结果PR合进去后站点页面整体导航崩掉。因此项目维护者往往会有一个补充要求新增或修改章节必须同时更新对应SRC目录下的导航文件或索引页面并把术语表中涉及的新词补上。提PR时说明“影响的章节范围”对维护者来说是最友好的做法。5.2 常见误区和成果沉淀在社区翻译项目里最常见的误区有三个。第一个误区是“过度追求100%与原文对齐”。规范里大量存在“Implementation defined behavior”翻译成“由实现定义的行为”是准确的但有的贡献者非要进一步解释“即不同浏览器可能有不同表现”避免不能乱写。如果原文没有的就不该加。第二个误区是“不去理解背景就翻译”。有的人翻到HostEnsureCanCompileStrings这种操作完全不知道它和CSP内容安全策略的关系直接照字面翻译出来。结果读者根本看不懂“宿主确保可以编译字符串”是什么鬼。这种情况下保留英文术语并添加译注比硬译一个中文名要负责得多。第三个误区是“翻译完就不管了”。规范是一套活的文档它的算法语义在不同Edition之间会互相影响。即便只维护ES6版当上游仓库更新了目录结构或勘误表翻译项目仍然需要跟进校正。翻译项目的寿命取决于维护者能否建立“长期定期同步”的机制。我个人在参与这类项目时最大的收获是对JavaScript语言的理解彻底从“表面的用法”下沉到了“规范算法执行”的层面。翻译一段GeneratorYield的过程远比读十个关于Generator的博客更管用。如果你也想参与进来不用去当什么大而全的协调者先挑一个自己天天用还很感兴趣的小章节比如Map、Set、Promise.resolve那一段翻译完跑一遍测试提一个PR就会发现自己对ES6的理解有了质的变化。本文还有配套的精品资源点击获取
