nodejs · SEWeiTung · Nov 30, 2019 · Nov 30, 2019
diff --git a/locale/zh-cn/about/community.md b/locale/zh-cn/about/community.md
@@ -7,13 +7,13 @@ layout: about.hbs
 
 社区委员会（CommComm）是 Node.js 最高级别的委员会。委员会对外拥有一定的权利，其中包括：
 
-* 社区 [布道](https://github.com/nodejs/evangelism)
+* 社区[布道](https://github.com/nodejs/evangelism)
 * 教育倡议
 * Node.js 基础的文化指导
 * 社区组织拓展
 * 翻译及国际化项目
 * 项目审核 / 调解
-* 公共拓展以及 [出版物](https://medium.com/the-node-js-collection)
+* 公共拓展以及[出版物](https://medium.com/the-node-js-collection)
 
 参与社区委员会类型总共分为四类：
 
@@ -28,30 +28,30 @@ layout: about.hbs
 
 发展壮大 Node.js 社区是社区委员会的使命。当你读到这时，你其实已经是社区的一份子了 —— 同时也是 Node.js 社区的一份子。我们热爱你的帮助！
 
-在 [nodejs/community-committee](https://github.com/nodejs/community-committee) 中，GitHub 是一个很好的开始。请查看 [标记为“首要议题”](https://github.com/nodejs/community-committee/labels/good%20first%20issue) 相关内容以便了解我们需要在哪里需要你的帮助。如果你有关于我们如何更好地鼓励和构建我们社区的建议，放心大胆地提出议题并向我们已有的工作提出 PR。或者通过我们在 GitHub 上已有的讨论中分享你的相关想法。
+在 [nodejs/community-committee](https://github.com/nodejs/community-committee) 中，GitHub 是一个很好的开始。请查看[标记为“首要议题”](https://github.com/nodejs/community-committee/labels/good%20first%20issue)相关内容以便了解我们需要在哪里需要你的帮助。如果你有关于我们如何更好地鼓励和构建我们社区的建议，放心大胆地提出议题并向我们已有的工作提出 PR。或者通过我们在 GitHub 上已有的讨论中分享你的相关想法。
 
 你可以进一步参与我们持续构建社区的活动 —— 像本地化、布道、Node.js 意见收集和其它活动 —— 通过对 Node.js 源仓库的深入挖掘开始融入其中！
 
-在此之前，请确认你已经细读了 [合作者指南](https://github.com/nodejs/community-committee/blob/master/governance/COLLABORATOR_GUIDE.md)。
+在此之前，请确认你已经细读了[合作者指南](https://github.com/nodejs/community-committee/blob/master/governance/COLLABORATOR_GUIDE.md)。
 
-如果你对以社区会员身份参与社区委员会活动感兴趣的话，你应该阅读以下 **观察者与会员** 相关章节部分。随后发出请求希望成为我们下一届社区委员会的观察者。你可以在 [此处](https://github.com/nodejs/community-committee/issues/142) 寻找到相关的内容。
+如果你对以社区会员身份参与社区委员会活动感兴趣的话，你应该阅读以下 **观察者与会员** 相关章节部分。随后发出请求希望成为我们下一届社区委员会的观察者。你可以在[此处](https://github.com/nodejs/community-committee/issues/142)寻找到相关的内容。
 
 ## 观察者与会员
 
 如果你对更进一步参与社区委员会以及相关项目感兴趣的话，我们鼓励你成为一个活跃的观察者，为直接成为会员而努力工作。要想成为一个会员，你必须做到：
 
 1. 参与每周两次的会议，探讨那些标记为首要议题、会议文件以及 PR。并通过 GitHub，以贡献者或者合作者的身份凸显你的洞察力。
-2. 通过发起请求成为一个观察者。一旦作为观察者被邀请加入参与会议，我们会持续三个月跟踪记录你的参与度以符合我们的治理准则。你可以在 [此处](https://github.com/nodejs/community-committee/issues/142) 寻找到有关于此的绝好例子。
+2. 通过发起请求成为一个观察者。一旦作为观察者被邀请加入参与会议，我们会持续三个月跟踪记录你的参与度以符合我们的治理准则。你可以在[此处](https://github.com/nodejs/community-committee/issues/142) 寻找到有关于此的绝好例子。
 3. 当你已经符合了三个月的最低考勤条件，且符合期望参与度，社区委员会将投票把你纳入会员。
 
-会员身份可以保持六个月。小组会定期询问逾期会员是否继续愿意留任。会员只需回复“留任”即可。社区委员会虽无固定大小限制，但是，希望的人数最好在九到十二人之间。你可以在 [治理准则](https://github.com/nodejs/community-committee/blob/master/GOVERNANCE.md) 中阅读更多有关会员身份的资料信息，以及其它管理信息。
+会员身份可以保持六个月。小组会定期询问逾期会员是否继续愿意留任。会员只需回复“留任”即可。社区委员会虽无固定大小限制，但是，希望的人数最好在九到十二人之间。你可以在[治理准则](https://github.com/nodejs/community-committee/blob/master/GOVERNANCE.md)中阅读更多有关会员身份的资料信息，以及其它管理信息。
 
 定期社区委员会的会议每两个月通过变焦视频举行，然后会在 YouTube 上向公众播放。任何一个社区会员或者贡献者都可以通过 GitHub 发起请求参与下一次的会议议程。
 
 在会议开始前，相关的宣告以及议程都将在相关组织 [GitHub 议题](https://github.com/nodejs/community-committee/issues) 中列出。你也可以在 [Node.js 会议安排](https://nodejs.org/calendar) 中找到相关计划会议。为跟上 YouTube 上的 Node.js 实时会议，你应该订阅 [YouTube 频道](https://www.youtube.com/channel/UCQPYJluYC_sn_Qz_XE-YbTQ)。请勿忘记点击铃铛，这样每次有新的会议你就会收到提醒了！
 
 ## 寻求协商一致的过程
 
-社区委员会遵循着 [寻求共识](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) 的原则来决定规划。
+社区委员会遵循着[寻求共识](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) 的原则来决定规划。
 
 当任意一个议题将进入达成共识的阶段时，主持人会问大家“有人有不同意见吗？”作为最后的提醒，确保达成了共识而没有异议。如果实在无法达成共识但是又没有异议，那么只能采取多数投票。但是我们希望多数的决议是通过寻求共识做出的，而投票只是最后的备选方案。
diff --git a/locale/zh-cn/about/governance.md b/locale/zh-cn/about/governance.md
@@ -7,7 +7,7 @@ layout: about.hbs
 
 ## 追求一致协商
 
-Node.js 项目遵循 [一致协商][] 的工作模式。
+Node.js 项目遵循[一致协商][] 的工作模式。
 
 ## 贡献者
 
@@ -21,7 +21,7 @@ Node.js 项目遵循 [一致协商][] 的工作模式。
 
 ## 最高级别的委员会
 
-本项目由 [技术指导委员会（TSC）][] 和 [社区委员会（CommComm）][] 共同管理。前者对于项目中高级别的技术负责指导，后者则对指导和扩展社区进行负责。
+本项目由[技术指导委员会（TSC）][]和[社区委员会（CommComm）][]共同管理。前者对于项目中高级别的技术负责指导，后者则对指导和扩展社区进行负责。
 
 [COLLABORATOR_GUIDE.md]: https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md
 [社区委员会（CommComm）]: https://github.com/nodejs/community-committee/blob/master/Community-Committee-Charter.md

diff --git a/locale/zh-cn/about/index.md b/locale/zh-cn/about/index.md
@@ -25,19 +25,19 @@ server.listen(port, hostname, () => {
 });
 ```
 
-这与今天使用 OS 线程的更常见并发模型形成了对比。基于线程的网络效率相对低下，使用起来非常困难。此外，Node.js 的用户不必担心死锁过程, 因为没有锁。Node 中几乎没有函数直接执行 I/O 操作，因此进程从不阻塞。由于没有任何阻塞，可伸缩系统在 Node 中开发是非常合理的。
+这与今天使用 OS 线程的更常见并发模型形成了对比。基于线程的网络效率相对低下，使用起来非常困难。此外，Node.js 的用户不必担心死锁过程，因为没有锁。Node 中几乎没有函数直接执行 I/O 操作，因此进程从不阻塞。由于没有任何阻塞，可伸缩系统在 Node 中开发是非常合理的。
 
-如果你对这门语言其中的一部分尚未熟悉理解，这里有一篇专门关于 [阻塞对比非阻塞][] 的文章供你参考。
+如果你对这门语言其中的一部分尚未熟悉理解，这里有一篇专门关于[阻塞对比非阻塞][]的文章供你参考。
 
 ---
-Node.js 在设计上类似于 Ruby 的 [事件机][] 或 Python 的 [Twisted][] 之类的系统。 Node.js 更深入地考虑事件模型。它呈现一个 [事件轮询][] 作为运行时构造而不是库。在其它系统中，总是有一个阻止调用来启动事件循环。
+Node.js 在设计上类似于 Ruby 的[事件机][] 或 Python 的 [Twisted][]之类的系统。 Node.js 更深入地考虑事件模型。它呈现一个[事件轮询][]作为运行时构造而不是库。在其它系统中，总是有一个阻止调用来启动事件循环。
 
 通常 Node.js 的行为是通过在脚本开头的回调定义的，在结束时通过阻塞调用（如 `EventMachine::run()` ）启动服务器。在 Node.js 中没有这样的启动-事件循环调用。Node.js 在执行输入脚本后只需输入事件循环即可。
 当没有更多要执行的回调时，Node.js 退出事件循环。此行为类似于浏览器中的 JavaScript ——事件循环总是对用户不可见的。
 
 HTTP 是 Node.js 中的一等公民。它设计的是流式和低延迟。这使得 Node.js 非常适合于 web 库或框架的基础。
 
-仅仅因为 Node.js 是在没有线程的情况下设计的，这并不意味着您无法利用环境中的多个内核。子进程可以通过使用我们的 [`child_process.fork()`][] API 来生成, 并且被设计为易于沟通。建立在同一接口上的是 [`cluster`][] 模块, 它允许您在进程之间共享套接字, 以便在核心上启用负载平衡。
+仅仅因为 Node.js 是在没有线程的情况下设计的，这并不意味着您无法利用环境中的多个内核。子进程可以通过使用我们的 [`child_process.fork()`][] API 来生成，并且被设计为易于沟通。建立在同一接口上的是 [`cluster`][] 模块，它允许您在进程之间共享套接字，以便在核心上启用负载平衡。
 
 [阻塞对比非阻塞]: /zh-cn/docs/guides/blocking-vs-non-blocking/
 [`child_process.fork()`]: https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

diff --git a/locale/zh-cn/about/releases.md b/locale/zh-cn/about/releases.md
@@ -20,6 +20,6 @@ schedule-footer: 日期可能会发生变化。
 # 发布
 
 主版本的 Node.js 进入 _当前版_ 将持续六个月的时间，在此期间库作者可以对其进行支持。
-六个月之后，奇数版本（诸如9、11等）将变为不支持状态，只有偶数版本（诸如10、12等）变成 _活跃LTS_ 状态，并且准备投入使用。
-_LTS_ 发布版的状态是“长期维护版”，这意味着重大的Bug将在后续的30个月内持续得到不断地修复。
-上线应该仅使用 _活跃LTS_ 或者是 _维护LTS_ 版。
+六个月之后，奇数版本（诸如9、11等）将变为不支持状态，只有偶数版本（诸如10、12等）变成 _活跃 LTS_ 状态，并且准备投入使用。
+_LTS_ 发布版的状态是“长期维护版”，这意味着重大的 Bug 将在后续的 30 个月内持续得到不断地修复。
+上线应该仅使用 _活跃 LTS_ 或者是 _维护 LTS_ 版。
diff --git a/locale/zh-cn/about/resources.md b/locale/zh-cn/about/resources.md
@@ -7,9 +7,9 @@ title: 商标和图像
 
 ## 商标下载
 
-请查看相关 [商标政策](/zh-cn/about/trademark/) 以便了解许可范围内的 Node.js®；商标以及标记等。
+请查看相关[商标政策](/zh-cn/about/trademark/)以便了解许可范围内的 Node.js®；商标以及标记等。
 
-对于 Node.js 标志的可视化展示指南也在 [可视化指南](/static/documents/foundation-visual-guidelines.pdf) 有所描述。
+对于 Node.js 标志的可视化展示指南也在[可视化指南](/static/documents/foundation-visual-guidelines.pdf)有所描述。
 
 <table class="logos">
   <tr>

diff --git a/locale/zh-cn/about/trademark.md b/locale/zh-cn/about/trademark.md
@@ -9,6 +9,6 @@ Node.js 的商标、服务性标志，以及图像商标等都是质量、性能
 
 与此同时，我们期望社区成员们可以随意轻松地传播 Node.js 的任何消息，并且参与 Node.js 的社区活动。请始终牢记关键点：我们已试图把政策制定得尽可能地弹性化、容易理解并且合法化。
 
-请阅读相关 [完整版政策](/static/documents/trademark-policy.pdf)。如果你有任何疑问，请不要犹豫并 [给我们来信](mailto:trademark@nodejs.org)。
+请阅读相关[完整版政策](/static/documents/trademark-policy.pdf)。如果你有任何疑问，请不要犹豫并[给我们来信](mailto:trademark@nodejs.org)。
 
-对于 Node.js 标志的可视化展示指南也在 [可视化指南](/static/documents/foundation-visual-guidelines.pdf) 中有所描述。
+对于 Node.js 标志的可视化展示指南也在[可视化指南](/static/documents/foundation-visual-guidelines.pdf) 中有所描述。
diff --git a/locale/zh-cn/about/working-groups.md b/locale/zh-cn/about/working-groups.md
@@ -6,15 +6,15 @@ title: 工作组
 # 核心工作组
 <!-- Information here should mostly mirror: https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md -->
 
-核心工作组由 [技术指导委员会(TSC)](https://github.com/nodejs/TSC/blob/master/TSC-Charter.md) 创建。
+核心工作组由[技术指导委员会(TSC)](https://github.com/nodejs/TSC/blob/master/TSC-Charter.md)创建。
 
 ## 现有工作组
 
 * [API 插件组](#addon-api)
 * [基准测试组](#benchmarking)
 * [构建组](#build)
 * [诊断组](#diagnostics)
-* [Docker组](#docker)
+* [Docker 组](#docker)
 * [宣传组](#evangelism)
 * [国际化翻译组](#i18n)
 * [发布组](#release)
@@ -30,7 +30,7 @@ title: 工作组
 * 维护 [NAN](https://github.com/nodejs/nan) Git 仓库，包含代码、议题以及文档。
 * 维护 [addon-examples](https://github.com/nodejs/node-addon-examples) Git 仓库，包含代码、议题以及文档。
 * 维护在 Node.js 项目中从属于 Node.js TSC 的 C++ 插件。
-* 维护在 Node.js 项目中从属于 Node.js TSC 的 文档。
+* 维护在 Node.js 项目中从属于 Node.js TSC 的文档。
 * 维护 npm 中的 _nan_ 包，在合适的时候发布新版本。
 * 传递有关 Node.js 和 NAN 接口的未来消息，给社区提前通知变更。
 
@@ -77,7 +77,7 @@ title: 工作组
 * 定义并添加接口 / API 函数，在需要时允许产生转储。
 * 定义并向生成的转储添加公共结构，对这些转储进行内省的工具给予支持。
 
-### <!--docker--> [Docker组](https://github.com/nodejs/docker-node)
+### <!--docker--> [Docker 组](https://github.com/nodejs/docker-node)
 
 Docker 工作组的目的是为节点建立、维护和改进官方的 Docker 镜像。
 
@@ -169,7 +169,7 @@ Docker 工作组的目的是为节点建立、维护和改进官方的 Docker
 承担职责：
 
 * 为以下情况制定及维护安全性协议与流程：
-  * 核心 Node.js 项目the core Node.js project
+  * 核心 Node.js 项目
   * 由技术指导委员会（TSC）维护的其它项目。
 * 与 Node 安全平台合作，将社区汇报的安全隐患相关数据作为共享协助带入到基础库中。
 * 确保隐患数据以一个有效定时的方式更新。

diff --git a/locale/zh-cn/docs/es6.md b/locale/zh-cn/docs/es6.md
@@ -13,7 +13,7 @@ Node.js 是针对 [V8](https://v8.dev/) 引擎构建的。为了与此引擎保
 * **Staged**：这些是将要完成的特性，并且在 V8 团队看来并不一定稳定，需要一个 `--harmony` 标记。
 * **In progress**：这些特性可以通过各自单独的 harmony 标记被激活使用。除非为了测试用途，否则绝不鼓励这样做。值得注意的是这些标记是借由 V8 引擎公开，将来或许会有潜在的变化而不会有任何免责声明或者协议。
 
-## 默认情况下什么特性随着 Node.js一起发布？
+## 默认情况下什么特性随着 Node.js 一起发布？
 
 [node.green](https://node.green/) 提供了非常完整、几乎涵盖了不同版本的 Node.js 中所支持的 ECMAScript 特性。它基于 kangax 的兼容性对照表构建。
 
@@ -31,7 +31,7 @@ node --v8-options | grep "in progress"
 
 V8 团队现正在努力持续工作，他们借助 EcmaScript 5 或是更早时代的语言规范，利用转译或是本地相当的技术以提高新语言的功能特性，使之达到平衡。目前研发进度记录可以在 [six-speed](https://fhinkel.github.io/six-speed) 查询到，它会告诉你 ES2015 和 ESNext 的性能究竟如何（和本地的 ES5 同等技术相比）。
 
-特性优化的工作也随着 ES2015 到来，以上计划是通过 [执行计划](https://docs.google.com/document/d/1EA9EbfnydAmmU_lM8R_uEMQ-U_v4l9zulePSBkeYWmY)，有一个 V8 团队在那儿收集整理相关信息，并协调需要提高性能、设计追踪问题的文稿等部门。
+特性优化的工作也随着 ES2015 到来，以上计划是通过[执行计划](https://docs.google.com/document/d/1EA9EbfnydAmmU_lM8R_uEMQ-U_v4l9zulePSBkeYWmY)，有一个 V8 团队在那儿收集整理相关信息，并协调需要提高性能、设计追踪问题的文稿等部门。
 
 ## 我有我自己的基本框架，可以利用 --harmony，所以我可以移除这个标记吗？