[PATCH 0/5] docs/zh_CN: Improve language in zh_CN/process/

[PATCH 0/5] docs/zh_CN: Improve language in zh_CN/process/

[Wu XiangCheng]

There are some errors in some files in zh_CN/process/, such as grammatical 
errors, translation errors and improper use of words etc., which make it 
difficult for native speakers to understand. Many errors are caused by 
machine translation without manual correction.

This set of patchs aims to fix the above problems and synchronize them with
original files. Some structure modifications need to rewrite the whole 
sentences, so here are a lot of changes.

Wu XiangCheng (5):
  docs/zh_CN: Improve zh_CN/process/index.rst
  docs/zh_CN: Improve zh_CN/process/1.Intro.rst
  docs/zh_CN: Improve zh_CN/process/2.Process.rst
  docs/zh_CN: Improve zh_CN/process/3.Early-stage.rst
  docs/zh_CN: Improve zh_CN/process/4.Coding.rst

 .../translations/zh_CN/process/1.Intro.rst    | 146 ++++-----
 .../translations/zh_CN/process/2.Process.rst  | 296 +++++++++---------
 .../zh_CN/process/3.Early-stage.rst           | 120 +++----
 .../translations/zh_CN/process/4.Coding.rst   | 251 ++++++++-------
 .../translations/zh_CN/process/index.rst      |  10 +-
 5 files changed, 412 insertions(+), 411 deletions(-)

-- 
2.20.1

[PATCH 1/5] docs/zh_CN: Improve zh_CN/process/index.rst

[Wu XiangCheng]

Improve language and grammar of zh_CN/process/index.rst

Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
---
 Documentation/translations/zh_CN/process/index.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst
index 8051a7b322c5..995e1e508d9c 100644
--- a/Documentation/translations/zh_CN/process/index.rst
+++ b/Documentation/translations/zh_CN/process/index.rst
@@ -13,11 +13,11 @@
 与Linux 内核社区一起工作
 ========================
 
-那么你想成为Linux内核开发人员？ 欢迎！ 不但从技术意义上讲有很多关于内核的知识
-需要学，而且了解我们社区的工作方式也很重要。 阅读这些文章可以让您以更轻松地,
-麻烦最少的方式将更改合并到内核。
+你想成为Linux内核开发人员吗？ 欢迎之至！ 在学习许多关于内核的技术知识的同时，
+了解我们社区的工作方式也很重要。 阅读这些文档可以让您以更轻松的、麻烦更少的
+方式将更改合并到内核。
 
-以下是每位开发人员应阅读的基本指南。
+以下是每位开发人员都应阅读的基本指南：
 
 .. toctree::
    :maxdepth: 1
@@ -47,7 +47,7 @@
    management-style
    embargoed-hardware-issues
 
-这些是一些总体技术指南，由于缺乏更好的地方，现在已经放在这里
+这些是一些总体性技术指南，由于不大好分类而放在这里：
 
 .. toctree::
    :maxdepth: 1
-- 
2.20.1

[PATCH 2/5] docs/zh_CN: Improve zh_CN/process/1.Intro.rst

[Wu XiangCheng]

Improve language and grammar of zh_CN/process/1.Intro.rst

Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
---
 .../translations/zh_CN/process/1.Intro.rst    | 146 +++++++++---------
 1 file changed, 74 insertions(+), 72 deletions(-)

diff --git a/Documentation/translations/zh_CN/process/1.Intro.rst b/Documentation/translations/zh_CN/process/1.Intro.rst
index 10a15f3dc282..abbd6d6d51d6 100644
--- a/Documentation/translations/zh_CN/process/1.Intro.rst
+++ b/Documentation/translations/zh_CN/process/1.Intro.rst
@@ -5,76 +5,77 @@
 
 .. _cn_development_process_intro:
 
-介绍
+引言
 ====
 
-执行摘要
+内容提要
 --------
 
-本节的其余部分涵盖了内核开发过程的范围，以及开发人员及其雇主在这方面可能遇
-到的各种挫折。内核代码应该合并到正式的（“主线”）内核中有很多原因，包括对用
+本节的其余部分涵盖了内核开发的过程，以及开发人员及其雇主在这方面可能遇到
+的各种挫折。有很多原因使内核代码应被合并到正式的（“主线”）内核中，包括对用
 户的自动可用性、多种形式的社区支持以及影响内核开发方向的能力。提供给Linux
 内核的代码必须在与GPL兼容的许可证下可用。
 
 :ref:`cn_development_process` 介绍了开发过程、内核发布周期和合并窗口的机制。
-涵盖了补丁开发、审查和合并周期中的各个阶段。有一些关于工具和邮件列表的讨论。
-鼓励希望开始内核开发的开发人员作为初始练习跟踪并修复bug。
+涵盖了补丁开发、审查和合并周期中的各个阶段。还介绍了一些工具和邮件列表。
+鼓励希望开始内核开发的开发人员跟踪并修复缺陷以作为初步练习。
 
 
-:ref:`cn_development_early_stage` 包括早期项目规划，重点是尽快让开发社区参与
+:ref:`cn_development_early_stage` 包括早期的项目规划，重点是尽快让开发社区
+参与进来。
 
-:ref:`cn_development_coding` 是关于编码过程的；讨论了其他开发人员遇到的几个
-陷阱。对补丁的一些要求已经涵盖，并且介绍了一些工具，这些工具有助于确保内核
+:ref:`cn_development_coding` 是关于编程过程的；介绍了其他开发人员遇到的几个
+陷阱。也涵盖了对补丁的一些要求，并且介绍了一些工具，这些工具有助于确保内核
 补丁是正确的。
 
-:ref:`cn_development_posting` 讨论发布补丁以供评审的过程。为了让开发社区
-认真对待，补丁必须正确格式化和描述，并且必须发送到正确的地方。遵循本节中的
-建议有助于确保为您的工作提供最好的接纳。
+:ref:`cn_development_posting` 描述发布补丁以供评审的过程。为了让开发社区能
+认真对待，补丁必须被正确格式化和描述，并且必须发送到正确的地方。遵循本节中的
+建议有助于确保您的工作能被较好地接纳。
 
-:ref:`cn_development_followthrough` 介绍了发布补丁之后发生的事情；该工作
-在这一点上还远远没有完成。与审阅者一起工作是开发过程中的一个重要部分；本节
+:ref:`cn_development_followthrough` 介绍了发布补丁之后发生的事情；工作
+在这时还远远没有完成。与审阅者一起工作是开发过程中的一个重要部分；本节
 提供了一些关于如何在这个重要阶段避免问题的提示。当补丁被合并到主线中时，
-开发人员要注意不要假定任务已经完成。
+开发人员要注意不要认为任务已经完成。
 
-:ref:`cn_development_advancedtopics` 介绍了两个“高级”主题：
+:ref:`cn_development_advancedtopics` 介绍了两个“进阶”主题：
 使用Git管理补丁和查看其他人发布的补丁。
 
-:ref:`cn_development_conclusion` 总结了有关内核开发的更多信息，附带有带有
-指向资源的链接.
+:ref:`cn_development_conclusion` 总结了有关内核开发的更多信息，附带有
+资源链接。
 
 这个文件是关于什么的
 --------------------
 
 Linux内核有超过800万行代码，每个版本的贡献者超过1000人，是现存最大、最活跃
 的免费软件项目之一。从1991年开始，这个内核已经发展成为一个最好的操作系统
-组件，运行在袖珍数字音乐播放器、台式PC、现存最大的超级计算机以及所有类型的
+组件，运行在袖珍数字音乐播放器、台式电脑、现存最大的超级计算机以及所有类型的
 系统上。它是一种适用于几乎任何情况的健壮、高效和可扩展的解决方案。
 
 随着Linux的发展，希望参与其开发的开发人员（和公司）的数量也在增加。硬件供应商
 希望确保Linux能够很好地支持他们的产品，使这些产品对Linux用户具有吸引力。嵌入
 式系统供应商使用Linux作为集成产品的组件，希望Linux能够尽可能地胜任手头的任务。
-分销商和其他基于Linux的软件供应商对Linux内核的功能、性能和可靠性有着明确的
-兴趣。最终用户也常常希望修改Linux，使之更好地满足他们的需求。
+分销商和其他基于Linux的软件供应商切实关心Linux内核的功能、性能和可靠性。
+最终用户也常常希望修改Linux，使之年能更好地满足他们的需求。
 
 Linux最引人注目的特性之一是这些开发人员可以访问它；任何具备必要技能的人都可以
 改进Linux并影响其开发方向。专有产品不能提供这种开放性，这是自由软件的一个特点。
-但是，如果有什么不同的话，内核比大多数其他自由软件项目更开放。一个典型的三个月
+如果有什么不同的话，那就是内核比大多数其他自由软件项目更开放。一个典型的三个月
 内核开发周期可以涉及1000多个开发人员，他们为100多个不同的公司
-（或者根本没有公司）工作。
+（或者根本不隶属公司）工作。
 
-与内核开发社区合作并不是特别困难。但是，尽管如此，许多潜在的贡献者在尝试做
-内核工作时遇到了困难。内核社区已经发展了自己独特的操作方式，使其能够在每天
+与内核开发社区合作并不是特别困难。但尽管如此，仍有许多潜在的贡献者在尝试做
+内核工作时遇到了困难。内核社区已经发展出自己独特的操作方式，使其能够在每天
 都要更改数千行代码的环境中顺利运行（并生成高质量的产品）。因此，Linux内核开发
-过程与专有的开发方法有很大的不同也就不足为奇了。
+过程与专有的开发模式有很大的不同也就不足为奇了。
 
-对于新开发人员来说，内核的开发过程可能会让人感到奇怪和恐惧，但这个背后有充分的
-理由和坚实的经验。一个不了解内核社区的方式的开发人员（或者更糟的是，他们试图
-抛弃或规避内核社区的方式）会有一个令人沮丧的体验。开发社区, 在帮助那些试图学习
+对于新开发人员来说，内核的开发过程可能会让人感到奇怪和恐惧，但这背后有充分的
+理由和坚实的经验。一个不了解内核社区工作方式的开发人员（或者更糟的是，他们
+试图抛弃或规避之）会得到令人沮丧的体验。开发社区在帮助那些试图学习
 的人的同时，没有时间帮助那些不愿意倾听或不关心开发过程的人。
 
-希望阅读本文的人能够避免这种令人沮丧的经历。这里有很多材料，但阅读时所做的
+希望阅读本文的人能够避免这种令人沮丧的经历。这些材料很长，但阅读它们时所做的
 努力会在短时间内得到回报。开发社区总是需要能让内核变更好的开发人员；下面的
-文本应该帮助您或为您工作的人员加入我们的社区。
+文字应该帮助您或为您工作的人员加入我们的社区。
 
 致谢
 ----
@@ -85,77 +86,77 @@ Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson,
 Andrew Morton, Andrew Price, Tsugikazu Shibata, 和 Jochen Voß.
 
 这项工作得到了Linux基金会的支持，特别感谢Amanda McPherson，他看到了这项工作
-的价值并把它变成现实。
+的价值并将其变成现实。
 
 代码进入主线的重要性
 --------------------
 
 有些公司和开发人员偶尔会想，为什么他们要费心学习如何与内核社区合作，并将代码
 放入主线内核（“主线”是由Linus Torvalds维护的内核，Linux发行商将其用作基础）。
-在短期内，贡献代码看起来像是一种可以避免的开销；仅仅将代码分开并直接支持用户
+在短期内，贡献代码看起来像是一种可以避免的开销；维护独立代码并直接支持用户
 似乎更容易。事实上，保持代码独立（“树外”）是在经济上是错误的。
 
-作为说明树外代码成本的一种方法，下面是内核开发过程的一些相关方面；本文稍后将
-更详细地讨论其中的大部分内容。考虑：
+为了说明树外代码成本，下面给出内核开发过程的一些相关方面；本文稍后将
+更详细地讨论其中的大部分内容。请考虑：
 
 - 所有Linux用户都可以使用合并到主线内核中的代码。它将自动出现在所有启用它的
-  发行版上。不需要驱动程序磁盘、下载，也不需要为多个发行版的多个版本提供支持；
-  对于开发人员和用户来说，这一切都是可行的。并入主线解决了大量的分布和支持问题
+  发行版上。无需驱动程序磁盘、额外下载，也不需要为多个发行版的多个版本提供
+  支持；这一切将方便所有开发人员和用户。并入主线解决了大量的分发和支持问题。
 
-- 当内核开发人员努力维护一个稳定的用户空间接口时，内部内核API处于不断变化之中.
-  缺乏一个稳定的内部接口是一个深思熟虑的设计决策；它允许在任何时候进行基本的改
-  进，并产生更高质量的代码。但该策略的一个结果是，如果要使用新的内核，任何树外
-  代码都需要持续的维护。维护树外代码需要大量的工作才能使代码保持工作状态。
+- 当内核开发人员努力维护一个稳定的用户空间接口时，内核内部API处于不断变化之中。
+  不维持稳定的内部接口是一个慎重的设计决策；它允许在任何时候进行基本的改
+  进，并产出更高质量的代码。但该策略导致结果是，若要使用新的内核，任何树外
+  代码都需要持续的维护。维护树外代码会需要大量的工作才能使代码保持正常运行。
 
-  相反，位于主线中的代码不需要这样做，因为一个简单的规则要求进行API更改的任何
+  相反，位于主线中的代码不需要这样做，因为基本规则要求进行API更改的任何
   开发人员也必须修复由于该更改而破坏的任何代码。因此，合并到主线中的代码大大
   降低了维护成本。
 
-- 除此之外，内核中的代码通常会被其他开发人员改进。令人惊讶的结果可能来自授权
-  您的用户社区和客户改进您的产品。
+- 除此之外，内核中的代码通常会被其他开发人员改进。您授权的用户社区和客户
+  对您产品的改进可能会令人惊喜。
 
-- 内核代码在合并到主线之前和之后都要经过审查。不管原始开发人员的技能有多强，
+- 内核代码在合并到主线之前和之后都要经过审查。无论原始开发人员的技能有多强，
   这个审查过程总是能找到改进代码的方法。审查经常发现严重的错误和安全问题。
-  这对于在封闭环境中开发的代码尤其如此；这种代码从外部开发人员的审查中获益
+  对于在封闭环境中开发的代码尤其如此；这种代码从外部开发人员的审查中获益
   匪浅。树外代码是低质量代码。
 
 - 参与开发过程是您影响内核开发方向的方式。旁观者的抱怨会被听到，但是活跃的
   开发人员有更强的声音——并且能够实现使内核更好地满足其需求的更改。
 
 - 当单独维护代码时，总是存在第三方为类似功能提供不同实现的可能性。如果发生
-  这种情况，合并代码将变得更加困难——甚至到了不可能的地步。然后，您将面临以下
+  这种情况，合并代码将变得更加困难——甚至成为不可能。之后，您将面临以下
   令人不快的选择：（1）无限期地维护树外的非标准特性，或（2）放弃代码并将用户
   迁移到树内版本。
 
-- 代码的贡献是使整个过程工作的根本。通过贡献代码，您可以向内核添加新功能，并
+- 代码的贡献是使整个流程顺畅的根本。通过贡献代码，您可以向内核添加新功能，并
   提供其他内核开发人员使用的功能和示例。如果您已经为Linux开发了代码（或者
   正在考虑这样做），那么您显然对这个平台的持续成功感兴趣；贡献代码是确保成功
   的最好方法之一。
 
 上述所有理由都适用于任何树外内核代码，包括以专有的、仅二进制形式分发的代码。
-然而，在考虑任何类型的纯二进制内核代码分布之前，还需要考虑其他因素。这些包括：
+然而，在考虑任何类型的纯二进制内核代码分布之前，还需要考虑其他因素。包括：
 
-- 围绕专有内核模块分发的法律问题充其量是模糊的；相当多的内核版权所有者认为，
-  大多数仅限二进制的模块是内核的派生产品，因此，它们的分发违反了GNU通用公共
-  许可证（下面将详细介绍）。您的作者不是律师，本文档中的任何内容都不可能被
+- 围绕专有内核模块分发的法律问题其实较为模糊；相当多的内核版权所有者认为，
+  大多数仅二进制的模块是内核的派生产品，因此，它们的分发违反了GNU通用公共
+  许可证（下面将详细介绍）。本文作者不是律师，本文档中的任何内容都不可能被
   视为法律建议。封闭源代码模块的真实法律地位只能由法院决定。但不管怎样，困扰
   这些模块的不确定性仍然存在。
 
 - 二进制模块大大增加了调试内核问题的难度，以至于大多数内核开发人员甚至都不会
   尝试。因此，只分发二进制模块将使您的用户更难从社区获得支持。
 
-- 对于只支持二进制的模块的发行者来说，支持也更加困难，他们必须为他们希望支持
-  的每个发行版和每个内核版本提供一个版本的模块。为了提供相当全面的覆盖范围，
+- 对于仅二进制的模块的发行者来说，支持也更加困难，他们必须为他们希望支持
+  的每个发行版和每个内核版本提供不同版本的模块。为了提供较为全面的覆盖范围，
   可能需要一个模块的几十个构建，并且每次升级内核时，您的用户都必须单独升级
-  您的模块。
+  这些模块。
 
-- 上面提到的关于代码评审的所有问题都更加存在于封闭源代码。由于该代码根本不可
-  用，因此社区无法对其进行审查，毫无疑问，它将存在严重问题。
+- 上面提到的关于代码评审的所有问题都无疑存在于封闭源代码中。由于该代码根本
+  不可得，因此社区无法对其进行审查，毫无疑问，它将存在严重问题。
 
-尤其是嵌入式系统的制造商，可能会倾向于忽视本节中所说的大部分内容，因为他们
+尤其是嵌入式系统的制造商，可能会倾向于忽视本节中所说的大部分内容；因为他们
 相信自己正在商用一种使用冻结内核版本的独立产品，在发布后不需要再进行开发。
 这个论点忽略了广泛的代码审查的价值以及允许用户向产品添加功能的价值。但这些
-产品也有有限的商业寿命，之后必须发布新版本的产品。在这一点上，代码在主线上
+产品的商业寿命有限，之后必须发布新版本的产品。在这一点上，代码在主线上
 并得到良好维护的供应商将能够更好地占位，以使新产品快速上市。
 
 许可
@@ -163,24 +164,25 @@ Andrew Morton, Andrew Price, Tsugikazu Shibata, 和 Jochen Voß.
 
 代码是根据一些许可证提供给Linux内核的，但是所有代码都必须与GNU通用公共许可
 证（GPLV2）的版本2兼容，该版本是覆盖整个内核分发的许可证。在实践中，这意味
-着所有代码贡献都由GPLv2（可选地，语言允许在更高版本的GPL下分发）或3子句BSD
-许可（New BSD License, 译者注）覆盖。任何不包含在兼容许可证中的贡献都不会
+着所有代码贡献都由GPLv2（原则上允许在更高版本的GPL下分发，可选）或3子句BSD
+许可（New BSD License，译者注）覆盖。任何不包含在兼容许可证中的贡献都不会
 被接受到内核中。
 
 贡献给内核的代码不需要（或请求）版权分配。合并到主线内核中的所有代码都保留
 其原始所有权；因此，内核现在拥有数千个所有者。
 
-这种所有权结构的一个暗示是，任何改变内核许可的尝试都注定会失败。很少有实际
-的场景可以获得所有版权所有者的同意（或者从内核中删除他们的代码）。因此，特
-别是，在可预见的将来，不可能迁移到GPL的版本3。
+这种所有权结构也暗示着，任何改变内核许可的尝试都注定会失败。很少有实际
+情况可以获得所有版权所有者的同意（或者从内核中删除他们的代码）。因此，尤其
+是在可预见的将来，许可证不大可能迁移到GPL的版本3。
 
-所有贡献给内核的代码都必须是合法的免费软件。因此，不接受匿名（或匿名）贡献
-者的代码。所有贡献者都需要在他们的代码上“sign off”，声明代码可以在GPL下与内
-核一起分发。无法提供未被其所有者许可为免费软件的代码，或可能为内核造成版权
-相关问题的代码（例如，由缺乏适当保护的反向工程工作派生的代码）不能被接受。
+所有贡献给内核的代码都必须是合法的免费软件。因此，不接受匿名（或化名）贡献
+者的代码。所有贡献者都需要在他们的代码上“sign off（签发）”，声明代码可以
+在GPL下与内核一起分发。无法提供未被其所有者许可为免费软件的代码，或可能为
+内核造成版权相关问题的代码（例如，由缺乏适当保护的逆向工程工作派生的代码）
+不能被接受。
 
-有关版权相关问题的问题在Linux开发邮件列表中很常见。这样的问题通常会得到不少
-答案，但要记住，回答这些问题的人不是律师，不能提供法律咨询。如果您有关于
-Linux源代码的法律问题，那么与了解该领域的律师交流是无法替代的。依靠从技术
-邮件列表中获得的答案是一件冒险的事情。
+有关版权问题的提问在Linux开发邮件列表中很常见。这样的问题通常会得到不少
+答案，但请记住，回答这些问题的人不是律师，不能提供法律咨询。如果您有关于
+Linux源代码的法律问题，没有什么可以代替咨询了解这一领域的律师。依赖从
+技术邮件列表中获得的答案是一件冒险的事情。
 
-- 
2.20.1

[PATCH 3/5] docs/zh_CN: Improve zh_CN/process/2.Process.rst

[Wu XiangCheng]

Sync and improve language & grammar of zh_CN/process/2.Process.rst

Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
---
 .../translations/zh_CN/process/2.Process.rst  | 296 +++++++++---------
 1 file changed, 149 insertions(+), 147 deletions(-)

diff --git a/Documentation/translations/zh_CN/process/2.Process.rst b/Documentation/translations/zh_CN/process/2.Process.rst
index ebe2e0254b3e..4b73c35da5e0 100644
--- a/Documentation/translations/zh_CN/process/2.Process.rst
+++ b/Documentation/translations/zh_CN/process/2.Process.rst
@@ -5,13 +5,13 @@
 
 .. _cn_development_process:
 
-开发流程如何工作
+开发流程如何进行
 ================
 
-90年代早期的Linux内核开发是一件相当松散的事情，涉及的用户和开发人员相对较
-少。由于拥有数以百万计的用户群，并且在一年的时间里有大约2000名开发人员参与
-进来，内核因此必须发展许多流程来保持开发的顺利进行。要成为流程的有效组成
-部分，需要对流程的工作方式有一个扎实的理解。
+90年代早期的Linux内核开发是一件相当松散的事情，涉及的用户和开发人员相对
+较少。由于拥有数以百万计的用户群，且每年有大约2000名开发人员参与进来，
+内核因此必须发展出许多既定流程来保证开发的顺利进行。要参与到流程中来，
+需要对此流程的进行方式有一个扎实的理解。
 
 总览
 ----
@@ -20,25 +20,25 @@
 内核版本。最近的发布历史记录如下：
 
 	======  =================
-	4.11	四月 30, 2017
-	4.12	七月 2, 2017
-	4.13	九月 3, 2017
-	4.14	十一月 12, 2017
-	4.15	一月 28, 2018
-	4.16	四月 1, 2018
+	5.0	2019年3月3日
+	5.1	2019年5月5日
+	5.2	2019年7月7日
+	5.3	2019年9月15日
+	5.4	2019年11月24日
+	5.5	2020年1月6日
 	======  =================
 
-每4.x版本都是一个主要的内核版本，具有新特性、内部API更改等等。一个典型的4.x
+每个4.x版本都是一个主要的内核版本，具有新特性、内部API更改等等。一个典型的4.x
 版本包含大约13000个变更集，变更了几十万行代码。因此，4.x是Linux内核开发的前
 沿；内核使用滚动开发模型，不断集成重大变化。
 
-对于每个版本的补丁合并，遵循一个相对简单的规则。在每个开发周期的开始，“合并
+对于每个版本的补丁合并，遵循一个相对简单的规则。在每个开发周期的开头，“合并
 窗口”被打开。当时，被认为足够稳定（并且被开发社区接受）的代码被合并到主线内
 核中。在这段时间内，新开发周期的大部分变更（以及所有主要变更）将以接近每天
 1000次变更（“补丁”或“变更集”）的速度合并。
 
-（顺便说一句，值得注意的是，合并窗口期间集成的更改并不是凭空产生的；它们是
-提前收集、测试和分级的。稍后将详细描述该过程的工作方式）。
+（顺便说一句，值得注意的是，合并窗口期间集成的更改并不是凭空产生的；它们是经
+提前收集、测试和分级的。稍后将详细描述该过程的工作方式。）
 
 合并窗口持续大约两周。在这段时间结束时，LinusTorvalds将声明窗口已关闭，并
 释放第一个“rc”内核。例如，对于目标为4.14的内核，在合并窗口结束时发生的释放
@@ -46,84 +46,86 @@
 个内核的时间已经开始。
 
 在接下来的6到10周内，只有修复问题的补丁才应该提交给主线。有时会允许更大的
-更改，但这种情况很少发生；试图在合并窗口外合并新功能的开发人员往往会受到不
+更改，但这种情况很少发生；试图在合并窗口外合并新功能的开发人员往往受不到
 友好的接待。一般来说，如果您错过了给定特性的合并窗口，最好的做法是等待下一
-个开发周期。（对于以前不支持的硬件，偶尔会对驱动程序进行例外；如果它们不
-改变已有代码，则不会导致回归，并且应该可以随时安全地添加）。
+个开发周期。（偶尔会对未支持硬件的驱动程序进行例外；如果它们不改变已有代码，
+则不会导致回退，应该可以随时被安全地加入）。
 
 随着修复程序进入主线，补丁速度将随着时间的推移而变慢。Linus大约每周发布一次
-新的-rc内核；一个正常的系列将在-rc6和-rc9之间，内核被认为足够稳定并最终发布。
+新的-rc内核；在内核被认为足够稳定并最终发布前，一般会达到-rc6到-rc9之间。
 然后，整个过程又重新开始了。
 
-例如，这里是4.16的开发周期进行情况（2018年的所有日期）:
+例如，这里是5.4的开发周期进行情况（2019年）:
 
 	==============  ==============================
-	一月 28	        4.15 稳定版发布
-	二月 11	        4.16-rc1, 合并窗口关闭
-	二月 18	        4.16-rc2
-	二月 25	        4.16-rc3
-	三月 4		4.16-rc4
-	三月 11	        4.16-rc5
-	三月 18	        4.16-rc6
-	三月 25	        4.16-rc7
-	四月 1		4.16 稳定版发布
+	九月 15         5.3 稳定版发布
+	九月 30         5.4-rc1, 合并窗口关闭
+	十月 6          5.4-rc2
+	十月 13         5.4-rc3
+	十月 20         5.4-rc4
+	十月 27         5.45.4-rc5
+	十一月 3        5.45.4-rc6
+	十一月 10       5.45.4-rc7
+	十一月 17       5.45.4-rc8
+	十一月 24       5.45.4 稳定版发布
 	==============  ==============================
 
-开发人员如何决定何时结束开发周期并创建稳定的版本？使用的最重要的指标是以前
-版本的回归列表。不欢迎出现任何错误，但是那些破坏了以前能工作的系统的错误被
-认为是特别严重的。因此，导致回归的补丁是不受欢迎的，很可能在稳定期内删除。
+开发人员如何决定何时结束开发周期并创建稳定版本？最重要的指标是以前版本的
+回退列表。不欢迎出现任何错误，但是那些破坏了以前能工作的系统的错误被
+认为是特别严重的。因此，导致回退的补丁是不受欢迎的，很可能在稳定期内删除。
 
-开发人员的目标是在稳定发布之前修复所有已知的回归。在现实世界中，这种完美是
-很难实现的；在这种规模的项目中，变量太多了。有一点，延迟最终版本只会使问题
-变得更糟；等待下一个合并窗口的一堆更改将变大，从而在下次创建更多的回归错误。
-因此，大多数4.x内核都有一些已知的回归错误，不过，希望没有一个是严重的。
+开发人员的目标是在稳定发布之前修复所有已知的回退。在现实世界中，这种完美是
+很难实现的；在这种规模的项目中，变数太多了。需要说明的是，延迟最终版本只会
+使问题变得更糟；等待下一个合并窗口的更改将变多，导致下次出现更多的回退错误。
+因此，大多数5.x内核都有一些已知的回退错误，不过，希望没有一个是严重的。
 
-一旦一个稳定的版本发布，它正在进行的维护工作就被移交给“稳定团队”，目前由
-Greg Kroah-Hartman组成。稳定团队将使用4.x.y编号方案不定期的发布稳定版本的更
-新。要加入更新版本，补丁程序必须（1）修复一个重要的bug，（2）已经合并到
-下一个开发主线中。内核通常会在超过其初始版本的一个以上的开发周期内接收稳定
-的更新。例如，4.13内核的历史如下
+一旦一个稳定的版本发布，它的持续维护工作就被移交给“稳定团队”，目前由
+Greg Kroah-Hartman领导。稳定团队将使用5.x.y编号方案不定期地发布稳定版本的
+更新。要合入更新版本，补丁必须（1）修复一个重要的bug，且（2）已经合并到
+下一个开发版本主线中。内核通常会在其初始版本后的一个以上的开发周期内收到
+稳定版更新。例如，5.2内核的历史如下（2019年）：
 
 	==============  ===============================
-        九月 3 	        4.13 稳定版发布
-	九月 13	        4.13.1
-	九月 20	        4.13.2
-	九月 27	        4.13.3
-	十月 5	        4.13.4
-	十月 12         4.13.5
+        七月 7 	        5.2 稳定版发布
+	七月 13	        5.2.1
+	七月 21	        5.2.2
+	七月 26	        5.2.3
+	七月 28	        5.2.4
+	七月 31	        5.2.5
 	...	        ...
-	十一月 24       4.13.16
+	十月 11         5.2.21
 	==============  ===============================
 
-4.13.16是4.13版本的最终稳定更新。
+5.2.21是5.2版本的最终稳定更新。
 
 有些内核被指定为“长期”内核；它们将得到更长时间的支持。在本文中，当前的长期
 内核及其维护者是：
 
-	======  ======================  ==============================
-	3.16	Ben Hutchings		(长期稳定内核)
-	4.1	Sasha Levin
-	4.4	Greg Kroah-Hartman	(长期稳定内核)
-	4.9	Greg Kroah-Hartman
-	4.14	Greg Kroah-Hartman
-	======  ======================  ==============================
+	======  ================================	================
+	3.16	Ben Hutchings				（长期稳定内核）
+	4.4	Greg Kroah-Hartman & Sasha Levin	（长期稳定内核）
+	4.9	Greg Kroah-Hartman & Sasha Levin
+	4.14	Greg Kroah-Hartman & Sasha Levin
+	4.19	Greg Kroah-Hartman & Sasha Levin
+	5.4	Greg Kroah-Hartman & Sasha Levin
+	======  ================================	================
 
-为长期支持选择内核纯粹是维护人员有必要和时间来维护该版本的问题。目前还没有
-为即将发布的任何特定版本提供长期支持的已知计划。
+长期支持内核的选择纯粹是维护人员是否有需求和时间来维护该版本的问题。
+目前还没有为即将发布的任何特定版本提供长期支持的已知计划。
 
 补丁的生命周期
 --------------
 
 补丁不会直接从开发人员的键盘进入主线内核。相反，有一个稍微复杂（如果有些非
 正式）的过程，旨在确保对每个补丁进行质量审查，并确保每个补丁实现了一个在主线
-中需要的更改。对于小的修复，这个过程可能会很快发生，或者，在大的和有争议的
-变更的情况下，会持续数年。许多开发人员的挫折来自于对这个过程缺乏理解或者
+中需要的更改。对于小的修复，这个过程可能会很快完成，，而对于较大或有争议的
+变更，可能会持续数年。许多开发人员的沮丧来自于对这个过程缺乏理解或者
 试图绕过它。
 
-为了减少这种挫折感，本文将描述补丁如何进入内核。下面是一个介绍，它以某种
+为了减少这种挫败，本文将描述补丁如何进入内核。下面的介绍以一种较为
 理想化的方式描述了这个过程。更详细的过程将在后面的章节中介绍。
 
-补丁程序经历的阶段通常是：
+补丁通常要经历以下阶段：
 
 - 设计。这就是补丁的真正需求——以及满足这些需求的方式——的所在。设计工作通常
   是在不涉及社区的情况下完成的，但是如果可能的话，最好是在公开的情况下完成
@@ -134,25 +136,25 @@ Greg Kroah-Hartman组成。稳定团队将使用4.x.y编号方案不定期的发
 
 - 更广泛的评审。当补丁接近准备好纳入主线时，它应该被相关的子系统维护人员
   接受——尽管这种接受并不能保证补丁会一直延伸到主线。补丁将出现在维护人员的
-  子系统树中，并进入 -next 树（如下所述）。当流程工作时，此步骤将导致对补丁
-  进行更广泛的审查，并发现由于将此补丁与其他人所做的工作集成而导致的任何
+  子系统树中，并进入 -next 树（如下所述）。当流程进行时，此步骤将会对补丁
+  进行更广泛的审查，并发现由于将此补丁与其他人所做的工作合并而导致的任何
   问题。
 
-- 请注意，大多数维护人员也有日常工作，因此合并补丁可能不是他们的最高优先级。
-  如果您的补丁程序得到了关于所需更改的反馈，那么您应该进行这些更改，或者为
-  不应该进行这些更改的原因辩护。如果您的补丁没有评审意见，但没有被其相应的
-  子系统或驱动程序维护者接受，那么您应该坚持不懈地将补丁更新到当前内核，使
-  其干净地应用，并不断地将其发送以供审查和合并。
+- 请注意，大多数维护人员也有日常工作，因此合并补丁可能不是他们的最优先工作。
+  如果您的补丁得到了需要更改的反馈，那么您应该进行这些更改，或者解释为何
+  不应该进行这些更改。如果您的补丁没有评审意见，也没有被其相应的子系统或
+  驱动程序维护者接受，那么您应该坚持不懈地将补丁更新到当前内核使其可被正常
+  应用，并不断地发送它以供审查和合并。
 
 - 合并到主线。最终，一个成功的补丁将被合并到由LinusTorvalds管理的主线存储库
-  中。此时可能会出现更多的评论和/或问题；开发人员应对这些问题并解决出现的
-  任何问题很重要。
+  中。此时可能会出现更多的评论和/或问题；对开发人员来说应对这些问题并解决
+  出现的任何问题仍很重要。
 
-- 稳定版发布。可能受补丁影响的用户数量现在很大，因此可能再次出现新的问题。
+- 稳定版发布。大量用户可能受此补丁影响，因此可能再次出现新的问题。
 
 - 长期维护。虽然开发人员在合并代码后可能会忘记代码，但这种行为往往会给开发
-  社区留下不良印象。合并代码消除了一些维护负担，因为其他代码将修复由API
-  更改引起的问题。但是，如果代码要长期保持有用，原始开发人员应该继续为
+  社区留下不良印象。合并代码消除了一些维护负担，因为其他人将修复由API
+  更改引起的问题。但是，如果代码要长期保持可用，原始开发人员应该继续为
   代码负责。
 
 内核开发人员（或他们的雇主）犯的最大错误之一是试图将流程简化为一个
@@ -163,23 +165,23 @@ Greg Kroah-Hartman组成。稳定团队将使用4.x.y编号方案不定期的发
 
 只有一个人可以将补丁合并到主线内核存储库中：LinusTorvalds。但是，在进入
 2.6.38内核的9500多个补丁中，只有112个（大约1.3%）是由Linus自己直接选择的。
-内核项目已经发展到一个规模，没有一个开发人员可以在没有支持的情况下检查和
-选择每个补丁。内核开发人员处理这种增长的方式是通过使用围绕信任链构建的
+内核项目已经发展到一个没有一个开发人员可以在没有支持的情况下检查和选择
+每个补丁的规模。内核开发人员处理这种增长的方式是使用围绕信任链构建的
 助理系统。
 
-内核代码库在逻辑上被分解为一组子系统：网络、特定的体系结构支持、内存管理、
-视频设备等。大多数子系统都有一个指定的维护人员，开发人员对该子系统中的代码
-负有全部责任。这些子系统维护者（松散地）是他们所管理的内核部分的守护者；
+内核代码库在逻辑上被分解为一组子系统：网络、特定体系结构支持、内存管理、
+视频设备等。大多数子系统都有一个指定的维护人员，其总体负责该子系统中的
+代码。这些子系统维护者（松散地）是他们所管理的内核部分的“守门员”；
 他们（通常）会接受一个补丁以包含到主线内核中。
 
-子系统维护人员每个人都使用git源代码管理工具管理自己版本的内核源代码树。Git
-等工具（以及Quilt或Mercurial等相关工具）允许维护人员跟踪补丁列表，包括作者
+子系统维护人员每个人都管理着自己版本的内核源代码树，通常（并非总是）使用Git。
+Git等工具（以及Quilt或Mercurial等相关工具）允许维护人员跟踪补丁列表，包括作者
 信息和其他元数据。在任何给定的时间，维护人员都可以确定他或她的存储库中的哪
 些补丁在主线中找不到。
 
-当合并窗口打开时，顶级维护人员将要求Linus从其存储库中“拉出”他们为合并选择
+当合并窗口打开时，顶级维护人员将要求Linus从存储库中“拉出”他们为合并选择
 的补丁。如果Linus同意，补丁流将流向他的存储库，成为主线内核的一部分。
-Linus对拉操作中接收到的特定补丁的关注程度各不相同。很明显，有时他看起来很
+Linus对拉取中接收到的特定补丁的关注程度各不相同。很明显，有时他看起来很
 关注。但是，作为一般规则，Linus相信子系统维护人员不会向上游发送坏补丁。
 
 子系统维护人员反过来也可以从其他维护人员那里获取补丁。例如，网络树是由首先
@@ -195,26 +197,26 @@ Next 树
 
 子系统树链引导补丁流到内核，但它也提出了一个有趣的问题：如果有人想查看为
 下一个合并窗口准备的所有补丁怎么办？开发人员将感兴趣的是，还有什么其他的
-更改有待解决，以查看是否存在需要担心的冲突；例如，更改核心内核函数原型的
+更改有待解决，以了解是否存在需要担心的冲突；例如，更改核心内核函数原型的
 修补程序将与使用该函数旧形式的任何其他修补程序冲突。审查人员和测试人员希望
-在所有这些变更到达主线内核之前，能够访问它们的集成形式中的变更。您可以从所有
-有趣的子系统树中提取更改，但这将是一项大型且容易出错的工作。
+在所有这些变更到达主线内核之前，能够访问它们的集成形式的变更。您可以从所有
+相关的子系统树中提取更改，但这将是一项复杂且容易出错的工作。
 
-答案以-next树的形式出现，在这里子系统树被收集以供测试和审查。Andrew Morton
-维护的这些旧树被称为“-mm”（用于内存管理，这就是它的启动名字）。-mm 树集成了
-一长串子系统树中的补丁；它还包含一些旨在帮助调试的补丁。
+解决方案以-next树的形式出现，在这里子系统树被收集以供测试和审查。这些树中
+由Andrew Morton维护的较老的一个，被称为“-mm”（用于内存管理，创建时为此）。
+-mm 树集成了一长串子系统树中的补丁；它还包含一些旨在帮助调试的补丁。
 
 除此之外，-mm 还包含大量由Andrew直接选择的补丁。这些补丁可能已经发布在邮件
-列表上，或者它们可能应用于内核中没有指定子系统树的部分。结果，-mm 作为一种
-最后手段的子系统树运行；如果没有其他明显的路径可以让补丁进入主线，那么它很
-可能以-mm 结束。累积在-mm 中的各种补丁最终将被转发到适当的子系统树，或者直接
+列表上，或者它们可能应用于内核中未指定子系统树的部分。同时，-mm 作为最后
+手段的子系统树；如果没有其他明显的路径可以让补丁进入主线，那么它很可能最
+终选择-mm 树。累积在-mm 中的各种补丁最终将被转发到适当的子系统树，或者直接
 发送到Linus。在典型的开发周期中，大约5-10%的补丁通过-mm 进入主线。
 
-当前-mm 补丁可在“mmotm”（-mm of the moment）目录中找到，地址：
+当前-mm 补丁可在“mmotm”（-mm of the moment）目录中找到：
 
         https://www.ozlabs.org/~akpm/mmotm/
 
-然而，使用mmotm树可能是一种令人沮丧的体验；它甚至可能无法编译。
+然而，使用MMOTM树可能会十分令人头疼；它甚至可能无法编译。
 
 下一个周期补丁合并的主要树是linux-next，由Stephen Rothwell 维护。根据设计
 linux-next 是下一个合并窗口关闭后主线的快照。linux-next树在Linux-kernel 和
@@ -228,33 +230,33 @@ Linux-next 已经成为内核开发过程中不可或缺的一部分；在一个
 Staging 树
 ----------
 
-内核源代码树包含drivers/staging/directory，其中有许多驱动程序或文件系统的
-子目录正在被添加到内核树中。它们然需要更多的工作的时候可以保留在
+内核源代码树包含drivers/staging/ 目录，其中有许多驱动程序或文件系统的
+子目录正在被添加到内核树中。它们在仍然需要更多的修正的时候可以保留在
 driver/staging目录中；一旦完成，就可以将它们移到内核中。这是一种跟踪不符合
-Linux内核编码或质量标准的驱动程序的方法，但人们可能希望使用它们并跟踪开发。
+Linux内核编码或质量标准的驱动程序的方法，人们可能希望使用它们并跟踪开发。
 
-Greg Kroah Hartman 目前负责维护staging 树。仍需要工作的驱动程序将发送给他，
+Greg Kroah Hartman 目前负责维护staging 树。仍需要修正的驱动程序将发送给他，
 每个驱动程序在drivers/staging/中都有自己的子目录。除了驱动程序源文件之外，
-目录中还应该有一个TODO文件。todo文件列出了驱动程序需要接受的挂起的工作，
+目录中还应该有一个TODO文件。TODO文件列出了驱动程序即将进行的工作，
 以及驱动程序的任何补丁都应该抄送的人员列表。当前的规则要求，staging的驱动
 程序必须至少正确编译。
 
-Staging 是一种相对容易的方法，可以让新的驱动程序进入主线，幸运的是，他们会
+Staging 是一种让新的驱动程序进入主线的相对容易的方法，他们会幸运地
 引起其他开发人员的注意，并迅速改进。然而，进入staging并不是故事的结尾；
 staging中没有看到常规进展的代码最终将被删除。经销商也倾向于相对不愿意使用
-staging驱动程序。因此，在成为一名合适的主线驱动的路上，staging 充其量只是
-一个停留。
+staging驱动程序。因此，在成为一个合适的主线驱动的路上，staging 仅是
+一个中转站。
 
 工具
 ----
 
 从上面的文本可以看出，内核开发过程在很大程度上依赖于在不同方向上聚集补丁的
 能力。如果没有适当强大的工具，整个系统将无法在任何地方正常工作。关于如何使用
-这些工具的教程远远超出了本文档的范围，但是还是有一些指南的空间。
+这些工具的教程远远超出了本文档的范围，但还是用一点篇幅介绍一些关键点。
 
 到目前为止，内核社区使用的主要源代码管理系统是git。Git是在自由软件社区中开发
 的许多分布式版本控制系统之一。它非常适合内核开发，因为它在处理大型存储库和
-大量补丁时性能非常好。它还有一个难以学习和使用的名声，尽管随着时间的推移它
+大量补丁时性能非常好。它也以难以学习和使用而著称，尽管随着时间的推移它
 变得更好了。对于内核开发人员来说，对Git的某种熟悉几乎是一种要求；即使他们不
 将它用于自己的工作，他们也需要Git来跟上其他开发人员（以及主线）正在做的事情。
 
@@ -262,15 +264,15 @@ staging驱动程序。因此，在成为一名合适的主线驱动的路上，s
 
         https://git-scm.com/
 
-那个页面有指向文档和教程的指针。
+此页面包含了文档和教程的链接。
 
-在不使用git的内核开发人员中，最流行的选择几乎肯定是mercurial：
+在不使用git的内核开发人员中，最流行的选择几乎肯定是Mercurial：
 
         http://www.seleric.com/mercurial/
 
 Mercurial与Git共享许多特性，但它提供了一个界面，许多人觉得它更易于使用。
 
-另一个值得了解的工具是quilt:
+另一个值得了解的工具是Quilt:
 
         https://savannah.nongnu.org/projects/quilt
 
@@ -282,47 +284,47 @@ Quilt 是一个补丁管理系统，而不是源代码管理系统。它不会
 邮件列表
 --------
 
-大量的Linux内核开发工作是通过邮件列表完成的。如果不在某个地方加入至少一个列表，
-就很难成为社区中一个功能完备的成员。但是，Linux邮件列表对开发人员来说也是一个
-潜在的危险，他们可能会被一堆电子邮件淹没，违反Linux列表上使用的约定，或者
-两者兼而有之。
+大量的Linux内核开发工作是通过邮件列表完成的。如果不加入至少一个某个列表，
+就很难成为社区中的一个“全功能”成员。但是，Linux邮件列表对开发人员来说也是
+一个潜在的危险，他们可能会被一堆电子邮件淹没、违反Linux列表上使用的约定，
+或者两者兼而有之。
 
 大多数内核邮件列表都在vger.kernel.org上运行；主列表位于：
 
         http://vger.kernel.org/vger-lists.html
 
-不过，也有一些列表托管在别处；其中一些列表位于lists.redhat.com。
+不过，也有一些列表托管在别处；其中一些列表位于
+redhat.com/mailman/listinfo。
 
-当然，内核开发的核心邮件列表是linux-kernel。这个名单是一个令人生畏的地方；
-每天的信息量可以达到500条，噪音很高，谈话技术性很强，参与者并不总是表现出
+当然，内核开发的核心邮件列表是linux-kernel。这个列表是一个令人生畏的地方；
+每天的信息量可以达到500条，非常热闹，谈话技术性很强，且参与者并不总是表现出
 高度的礼貌。但是，没有其他地方可以让内核开发社区作为一个整体聚集在一起；
-避免使用此列表的开发人员将错过重要信息。
+不使用此列表的开发人员将错过重要信息。
 
-有一些提示可以帮助在linux-kernel生存：
+以下一些提示可以帮助在linux-kernel生存：
 
-- 将邮件转移到单独的文件夹，而不是主邮箱。我们必须能够持续地忽略洪流。
+- 将邮件转移到单独的文件夹，而不是主邮箱文件夹。我们必须能够持续地忽略洪流。
 
-- 不要试图跟踪每一次谈话-其他人都不会。重要的是要对感兴趣的主题（尽管请
-  注意，长时间的对话可以在不更改电子邮件主题行的情况下偏离原始主题）和参与
-  的人进行筛选。
+- 不要试图跟上每一次谈话——没人会这样。重要的是要筛选感兴趣的主题（但请注意
+  长时间的对话可能会偏离原来的主题，尽管未改变电子邮件的主题）和参与的人。
 
-- 不要挑事。如果有人试图激起愤怒的反应，忽略他们。
+- 不要回复挑事的人。如果有人试图激起愤怒，请忽略他们。
 
-- 当响应Linux内核电子邮件（或其他列表上的电子邮件）时，请为所有相关人员保留
-  cc:header。如果没有强有力的理由（如明确的请求），则不应删除收件人。一定要
-  确保你要回复的人在cc:list中。这个惯例也使你不必在回复邮件时明确要求被抄送。
+- 当回复Linux内核电子邮件（或其他列表上的电子邮件）时，请为所有相关人员保留
+  Cc: 抄送头。如果没有确实的理由（如明确的请求），则不应删除收件人。一定要
+  确保你要回复的人在抄送列表中。这个惯例也使你不必在回复邮件时明确要求被抄送。
 
-- 在提出问题之前，搜索列表档案（和整个网络）。有些开发人员可能会对那些显然
+- 在提出问题之前，搜索列表存档（和整个网络）。有些开发人员可能会对那些显然
   没有完成家庭作业的人感到不耐烦。
 
-- 避免贴顶帖（把你的答案放在你要回复的引文上面的做法）。这会让你的回答更难
+- 避免顶部回复（把你的答案放在你要回复的引文上面的做法）。这会让你的回答更难
   理解，印象也很差。
 
-- 询问正确的邮件列表。linux-kernel 可能是通用的讨论点，但它不是从所有子系统
-  中寻找开发人员的最佳场所。
+- 在正确的邮件列表发问。linux-kernel 可能是通用的讨论场所，但它不是寻找所有
+  子系统开发人员的最佳场所。
 
-最后一点——找到正确的邮件列表——是开发人员出错的常见地方。在Linux内核上提出与
-网络相关的问题的人几乎肯定会收到一个礼貌的建议，转而在netdev列表上提出，
+最后一点——找到正确的邮件列表——是开发人员常见出错的地方。在linux-kernel上提出
+与网络相关的问题的人几乎肯定会收到一个礼貌的建议，转到netdev列表上提出，
 因为这是大多数网络开发人员经常出现的列表。还有其他列表可用于scsi、
 video4linux、ide、filesystem等子系统。查找邮件列表的最佳位置是与内核源代码
 一起打包的MAINTAINERS文件。
@@ -330,31 +332,31 @@ video4linux、ide、filesystem等子系统。查找邮件列表的最佳位置
 开始内核开发
 ------------
 
-关于如何开始内核开发过程的问题很常见——来自个人和公司。同样常见的是错误，这
-使得关系的开始比必须的更困难。
+关于如何开始内核开发过程的问题很常见——个人和公司皆然。同样常见的是失误，这
+使得关系的开始比本应的更困难。
 
 公司通常希望聘请知名的开发人员来启动开发团队。实际上，这是一种有效的技术。
-但它也往往是昂贵的，而且没有增长经验丰富的内核开发人员储备。考虑到时间的
-投入，可以让内部开发人员加快Linux内核的开发速度。花这个时间可以让雇主拥有
-一批了解内核和公司的开发人员，他们也可以帮助培训其他人。从中期来看，这往往
-是更有利可图的方法。
+但它也往往是昂贵的，而且对增加有经验的内核开发人员的数量没有多大帮助。
+考虑到时间投入，可以让内部开发人员加快Linux内核的开发速度。利用这段时间可以
+让雇主拥有一批既了解内核又了解公司的开发人员，还可以帮助培训其他人。从中期
+来看，这通常是更有利可图的方法。
 
 可以理解的是，单个开发人员往往对起步感到茫然。从一个大型项目开始可能会很
-吓人；人们往往想先用一些较小的东西来测试水域。这是一些开发人员开始创建修补
-拼写错误或轻微编码风格问题的补丁的地方。不幸的是，这样的补丁会产生一定程度
-的噪音，这会分散整个开发社区的注意力，因此，越来越多的人看不起它们。希望向
-社区介绍自己的新开发人员将无法通过这些方式获得他们想要的那种接待。
+吓人；人们往往想先用一些较小的东西来试试水。由此，一些开发人员开始创建修补
+拼写错误或轻微编码风格问题的补丁。不幸的是，这样的补丁会产生一定程度的干扰，
+这会分散整个开发社区的注意力，因此，它们越来越被人不看重。希望向社区介绍
+自己的新开发人员将无法通过这些方式获得他们期待的反响。
 
-Andrew Morton 为有抱负的内核开发人员提供了这个建议
+Andrew Morton 为有抱负的内核开发人员提供了如下建议
 
 ::
 
-        所有内核初学者的No.1项目肯定是“确保内核在所有的机器上，你可以触摸
-        到的，始终运行良好" 通常这样做的方法是与其他人一起解决问题（这
-        可能需要坚持！）但这很好——这是内核开发的一部分
+	所有内核开发者的第一个项目肯定应该是“确保内核在您可以操作的所有
+	机器上始终完美运行”。通常的方法是和其他人一起解决问题（这可能需
+	要坚持！），但就是如此——这是内核开发的一部分。
 
 (http://lwn.net/articles/283982/)
 
-在没有明显问题需要解决的情况下，建议开发人员查看当前的回归和开放式错误列表.
-解决需要修复的问题没有任何缺点；通过解决这些问题，开发人员将获得处理过程的
-经验，同时与开发社区的其他人建立尊重。
+在没有明显问题需要解决的情况下，通常建议开发人员查看当前的回退和开放缺陷
+列表。从来都不缺少需要解决的问题；通过解决这些问题，开发人员将从该过程获得
+经验，同时与开发社区的其他成员建立相互尊重。
-- 
2.20.1

[PATCH 4/5] docs/zh_CN: Improve zh_CN/process/3.Early-stage.rst

[Wu XiangCheng]

Improve language and grammar of zh_CN/process/3.Early-stage.rst

Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
---
 .../zh_CN/process/3.Early-stage.rst           | 120 +++++++++---------
 1 file changed, 60 insertions(+), 60 deletions(-)

diff --git a/Documentation/translations/zh_CN/process/3.Early-stage.rst b/Documentation/translations/zh_CN/process/3.Early-stage.rst
index b8676aec6005..5c522d245a7f 100644
--- a/Documentation/translations/zh_CN/process/3.Early-stage.rst
+++ b/Documentation/translations/zh_CN/process/3.Early-stage.rst
@@ -9,45 +9,45 @@
 ========
 
 当考虑一个Linux内核开发项目时，很可能会直接跳进去开始编码。然而，与任何重要
-的项目一样，成功的许多基础最好是在第一行代码编写之前就做好了。在早期计划和
-沟通中花费一些时间可以节省更多的时间。
+的项目一样，许多成功的基础最好是在第一行代码编写之前就打下。在早期计划和
+沟通中花费一些时间可以在之后节省更多的时间。
 
 详述问题
 --------
 
-与任何工程项目一样，成功的内核增强从要解决的问题的清晰描述开始。在某些情况
-下，这个步骤很容易：例如，当某个特定硬件需要驱动程序时。不过，在其他方面，
-将实际问题与建议的解决方案混淆是很有诱惑力的，这可能会导致困难。
+与任何工程项目一样，成功的内核改善从清晰描述要解决的问题开始。在某些情况
+下，这个步骤很容易：例如当某个特定硬件需要驱动程序时。不过，在其他情况下，
+很容易将实际问题与建议的解决方案混在一起，这可能会导致麻烦。
 
-举个例子：几年前，使用Linux音频的开发人员寻求一种方法来运行应用程序，而不因
-系统延迟过大而导致退出或其他工件。他们得到的解决方案是一个内核模块，旨在连
-接到Linux安全模块（LSM）框架中；这个模块可以配置为允许特定的应用程序访问
-实时调度程序。这个模块被实现并发送到Linux内核邮件列表，在那里它立即遇到问题。
+举个例子：几年前，Linux音频的开发人员寻求一种方法来运行应用程序，而不会因
+系统延迟过大而导致退出或其他问题。他们得到的解决方案是一个连接到Linux安全
+模块（LSM）框架中的内核模块；这个模块可以配置为允许特定的应用程序访问实时
+调度程序。这个模块被实现并发到linux-kernel邮件列表，在那里它立即遇到了麻烦。
 
 对于音频开发人员来说，这个安全模块足以解决他们当前的问题。但是，对于更广泛的
 内核社区来说，这被视为对LSM框架的滥用（LSM框架并不打算授予他们原本不具备的
 进程特权），并对系统稳定性造成风险。他们首选的解决方案包括短期的通过rlimit
-机制进行实时调度访问，以及长期的减少延迟的工作。
+机制进行实时调度访问，以及长期的减少延迟的改进。
 
-然而，音频社区看不到他们实施的特定解决方案的过去；他们不愿意接受替代方案。
+然而，音频社区无法超越他们实施的特定解决方案来看问题；他们不愿意接受替代方案。
 由此产生的分歧使这些开发人员对整个内核开发过程感到失望；其中一个开发人员返回
-到音频列表并发布了以下内容：
+到audio列表并发布了以下内容：
 
-        有很多非常好的Linux内核开发人员，但他们往往会被一群傲慢的傻瓜所压倒。
-        试图向这些人传达用户需求是浪费时间。他们太“聪明”了，根本听不到少数人
-        的话。
+	这里有很多非常好的Linux内核开发人员，但他们往往会被一群傲慢的傻瓜所
+	压倒。试图向这些人传达用户需求是浪费时间。他们太“聪明”了，根本听不
+	到少数人的话。
 
 （http://lwn.net/articles/131776/）
 
-实际情况不同；与特定模块相比，内核开发人员更关心系统稳定性、长期维护以及找到
-正确的问题解决方案。这个故事的寓意是把重点放在问题上——而不是具体的解决方案
-上——并在投入创建代码之前与开发社区讨论这个问题。
+实际情况却是不同的；与特定模块相比，内核开发人员更关心系统稳定性、长期维护
+以及找到问题的正确解决方案。这个故事的寓意是把重点放在问题上——而不是具体的
+解决方案上——并在开始编写代码之前与开发社区讨论这个问题。
 
 因此，在考虑一个内核开发项目时，我们应该得到一组简短问题的答案：
 
- - 究竟需要解决的问题是什么？
+ - 需要解决的问题究竟是什么？
 
- - 受此问题影响的用户是谁？解决方案应该解决哪些用例？
+ - 受此问题影响的用户有哪些？解决方案应该解决哪些使用案例？
 
  - 内核现在为何没能解决这个问题？
 
@@ -62,11 +62,11 @@
 
  - 很可能问题是由内核以您不理解的方式解决的。Linux内核很大，具有许多不明显
    的特性和功能。并不是所有的内核功能都像人们所希望的那样有文档记录，而且很
-   容易遗漏一些东西。你的作者发出了一个完整的驱动程序，复制了一个新作者不
-   知道的现有驱动程序。重新设计现有轮子的代码不仅浪费，而且不会被接受到主线
+   容易遗漏一些东西。某作者发布了一个完整的驱动程序，重复了一个其不
+   知道的现有驱动程序。重新发明现有轮子的代码不仅浪费，而且不会被接受到主线
    内核中。
 
- - 建议的解决方案中可能有一些元素不适用于主线合并。在编写代码之前，最好先
+ - 建议的解决方案中可能有一些要素不适合并入主线。在编写代码之前，最好先
    了解这样的问题。
 
  - 其他开发人员完全有可能考虑过这个问题；他们可能有更好的解决方案的想法，并且
@@ -74,87 +74,87 @@
 
 在内核开发社区的多年经验给了我们一个明确的教训：闭门设计和开发的内核代码总是
 有一些问题，这些问题只有在代码发布到社区中时才会被发现。有时这些问题很严重，
-需要数月或数年的努力才能使代码达到内核社区的标准。一些例子包括：
+需要数月或数年的努力才能使代码达到内核社区的标准。例如：
 
  - 设计并实现了单处理器系统的DeviceScape网络栈。只有使其适合于多处理器系统，
-   才能将其合并到主线中。在代码中改装锁等等是一项困难的任务；因此，这段代码
+   才能将其合并到主线中。在代码中修改锁等等是一项困难的任务；因此，这段代码
    （现在称为mac80211）的合并被推迟了一年多。
 
  - Reiser4文件系统包含许多功能，核心内核开发人员认为这些功能应该在虚拟文件
    系统层中实现。它还包括一些特性，这些特性在不将系统暴露于用户引起的死锁的
-   情况下是不容易实现的。这些问题的最新发现——以及对其中一些问题的拒绝——已经
-   导致Reiser4远离了主线内核。
+   情况下是不容易实现的。这些问题过迟发现——以及拒绝处理其中一些问题——已经
+   导致Reiser4无法进入主线内核。
 
  - Apparmor安全模块以被认为不安全和不可靠的方式使用内部虚拟文件系统数据结构。
-   这种担心（包括其他）使Apparmor多年不在主线上。
+   这种担心（包括其他）使Apparmor多年来无法进入主线。
 
-在每一种情况下，通过与内核开发人员的早期讨论，可以避免大量的痛苦和额外的工作。
+在这些情况下，与内核开发人员的早期讨论，可以避免大量的痛苦和额外的工作。
 
-找谁交流
---------
+找谁交流？
+----------
 
 当开发人员决定公开他们的计划时，下一个问题是：我们从哪里开始？答案是找到正确
 的邮件列表和正确的维护者。对于邮件列表，最好的方法是在维护者(MAINTAINERS)文件
-中查找要发布的相关位置。如果有一个合适的子系统列表，那么发布它通常比在Linux
-内核上发布更可取；您更有可能接触到在相关子系统中具有专业知识的开发人员，并且
-环境可能具支持性。
+中查找要发布的相关位置。如果有一个合适的子系统列表，那么其上发布通常比在
+linux-kernel上发布更可取；您更有可能接触到在相关子系统中具有专业知识的开发
+人员，并且环境可能具支持性。
 
-找到维护人员可能会有点困难。同样，维护者文件是开始的地方。但是，该文件往往不总
-是最新的，并且并非所有子系统都在那里表示。实际上，维护者文件中列出的人员可能
+找到维护人员可能会有点困难。同样，维护者文件是开始的地方。但是，该文件往往不
+是最新的，并且并非所有子系统都在那里显示。实际上，维护者文件中列出的人员可能
 不是当前实际担任该角色的人员。因此，当对联系谁有疑问时，一个有用的技巧是使用
-git（尤其是“git-log”）查看感兴趣的子系统中当前活动的用户。看看谁在写补丁，
-如果有人的话，谁会在这些补丁上加上用线签名的。这些人将是帮助新开发项目的最佳
-人选。
+git（尤其是“git-log”）查看感兴趣的子系统中当前活动的用户。看看谁在写补丁、
+谁会在这些补丁上加上Signed-off-by行签名（如有）。这些人将是帮助新开发项目的
+最佳人选。
 
-找到合适的维护者的任务有时是非常具有挑战性的，以至于内核开发人员添加了一个
-脚本来简化过程：
+找到合适的维护者有时是非常具有挑战性的，以至于内核开发人员添加了一个
+脚本来简化这个过程：
 
 ::
 
 	.../scripts/get_maintainer.pl
 
-当给定“-f”选项时，此脚本将返回给定文件或目录的当前维护者。如果在命令行上传递
+当给定“-f”选项时，此脚本将返回指定文件或目录的当前维护者。如果在命令行上给出
 了一个补丁，它将列出可能接收补丁副本的维护人员。有许多选项可以调节
-get_maintainer.pl搜索维护者的难易程度；请小心使用更具攻击性的选项，因为最终
+get_maintainer.pl搜索维护者的严格程度；请小心使用更激进的选项，因为最终结果
 可能会包括对您正在修改的代码没有真正兴趣的开发人员。
 
-如果所有其他方法都失败了，那么与Andrew Morton交谈可以成为一种有效的方法来跟踪
-特定代码段的维护人员。
+如果所有其他方法都失败了，那么与Andrew Morton交流是跟踪特定代码段维护人员
+的一种有效方法。
 
-何时邮寄？
+何时发布？
 ----------
 
-如果可能的话，在早期阶段发布你的计划只会有帮助。描述正在解决的问题以及已经
+如果可能的话，在早期阶段发布你的计划只会更有帮助。描述正在解决的问题以及已经
 制定的关于如何实施的任何计划。您可以提供的任何信息都可以帮助开发社区为项目
 提供有用的输入。
 
-在这个阶段可能发生的一件令人沮丧的事情不是敌对的反应，而是很少或根本没有
-反应。可悲的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划和很少
-代码（甚至代码前景）支持他们的人；（3）没有人有义务审查或评论别人发表的
-想法。除此之外，高级设计常常隐藏一些问题，这些问题只有在有人真正尝试实现
-这些设计时才会被发现；因此，内核开发人员宁愿看到代码。
+在这个阶段可能发生的一件令人沮丧的事情不是得到反对意见，而是很少或根本没有
+反馈。令人伤心的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划但
+代码（甚至代码设想）很少的人去支持他们；（3）没有人有义务审查或评论别人发表
+的想法。除此之外，高层级的设计常常隐藏着一些问题，这些问题只有在有人真正尝试
+实现这些设计时才会被发现；因此，内核开发人员宁愿看到代码。
 
-如果发表评论的请求在评论的方式上没有什么效果，不要假设这意味着对项目没有
-兴趣。不幸的是，你也不能假设你的想法没有问题。在这种情况下，最好的做法是
+如果发布请求评论（RFC）并没得到什么有用的评论，不要以为这意味着无人对此项目
+有兴趣，同时你也不能假设你的想法没有问题。在这种情况下，最好的做法是
 继续进行，把你的进展随时通知社区。
 
 获得官方认可
 -----------------------
 
 如果您的工作是在公司环境中完成的，就像大多数Linux内核工作一样，显然，在您将
-公司的计划或代码发布到公共邮件列表之前，必须获得适当授权的经理的许可。发布
-不确定是否兼容GPL的代码可能是有特别问题的；公司的管理层和法律人员越早能够就
+公司的计划或代码发布到公共邮件列表之前，必须获得有适当权利经理的许可。发布
+不确定是否兼容GPL的代码尤其会带来问题；公司的管理层和法律人员越早能够就
 发布内核开发项目达成一致，对参与的每个人都越好。
 
 一些读者可能会认为他们的核心工作是为了支持还没有正式承认存在的产品。将雇主
 的计划公布在公共邮件列表上可能不是一个可行的选择。在这种情况下，有必要考虑
 保密是否真的是必要的；通常不需要把开发计划关在门内。
 
-也就是说，有些情况下，一家公司在开发过程的早期就不能合法地披露其计划。拥有
-经验丰富的内核开发人员的公司可以选择以开环的方式进行，前提是他们以后能够避免
+也就是说，有些情况下一家公司在开发过程的早期无法合法地披露其计划。拥有经验
+丰富的内核开发人员的公司可能选择以开环的方式进行开发，前提是他们以后能够避免
 严重的集成问题。对于没有这种内部专业知识的公司，最好的选择往往是聘请外部
-开发商根据保密协议审查计划。Linux基金会运行了一个NDA程序，旨在帮助解决这种
-情况；
+开发者根据保密协议审查计划。Linux基金会运行了一个NDA程序，旨在帮助解决这种
+情况；更多信息参见：
 
     http://www.linuxfoundation.org/en/NDA_program
 
-- 
2.20.1

[PATCH 5/5] docs/zh_CN: Improve zh_CN/process/4.Coding.rst

[Wu XiangCheng]

Improve language and grammar of zh_CN/process/4.Coding.rst

Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
---
 .../translations/zh_CN/process/4.Coding.rst   | 251 +++++++++---------
 1 file changed, 124 insertions(+), 127 deletions(-)

diff --git a/Documentation/translations/zh_CN/process/4.Coding.rst b/Documentation/translations/zh_CN/process/4.Coding.rst
index 959a06ba025c..0e9fa3fd5c2f 100644
--- a/Documentation/translations/zh_CN/process/4.Coding.rst
+++ b/Documentation/translations/zh_CN/process/4.Coding.rst
@@ -5,150 +5,149 @@
 
 .. _cn_development_coding:
 
-使代码正确
+保持代码正确
 ======================
 
-虽然对于一个坚实的、面向社区的设计过程有很多话要说，但是任何内核开发项目的
-证明都在生成的代码中。它是将由其他开发人员检查并合并（或不合并）到主线树中
+虽然一个坚实的、面向社区的设计过程有很多值得说道的，但是任何内核开发项目工作
+的证明都反映在代码中。它是将由其他开发人员检查并合并（或不合并）到主线树中
 的代码。所以这段代码的质量决定了项目的最终成功。
 
-本节将检查编码过程。我们将从内核开发人员出错的几种方式开始。然后重点将转移
-到正确的事情和可以帮助这个任务的工具上。
+本节将检查编码过程。我们将从内核开发人员常犯的几种错误开始。然后重点将转移
+到正确的做法和相关实用工具上。
 
 陷阱
 ----
 
-编码风格
+代码风格
 ********
 
-内核长期以来都有一种标准的编码风格，如
+内核长期以来都有其标准的代码风格，如
 :ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>`
-中所述。在大部分时间里，该文件中描述的政策被认为至多是建议性的。因此，内核
-中存在大量不符合编码风格准则的代码。代码的存在会给内核开发人员带来两个独立
+中所述。在多数时候，该文件中描述的准则至多被认为是建议性的。因此，内核中存在
+大量不符合代码风格准则的代码。这种代码的存在会给内核开发人员带来两方面
 的危害。
 
-首先，要相信内核编码标准并不重要，也不强制执行。事实上，如果没有按照标准对代
-码进行编码，那么向内核添加新代码是非常困难的；许多开发人员甚至会在审查代码之
-前要求对代码进行重新格式化。一个与内核一样大的代码库需要一些统一的代码，以使
-开发人员能够快速理解其中的任何部分。所以已经没有空间来存放奇怪的格式化代码了。
+首先是错误相信内核代码标准并不重要，也不强制执行。但事实上，如果没有按照标准
+编写代码，那么很难将新代码加入到内核中；许多开发人员甚至会在审查代码之前要求
+对代码进行重新格式化。一个像内核这么大的代码库需要一些统一格式的代码，以使
+开发人员能够快速理解其中的任何部分。所以再也经不起奇怪格式的代码的折腾了。
 
-偶尔，内核的编码风格会与雇主的强制风格发生冲突。在这种情况下，内核的风格必须
-在代码合并之前获胜。将代码放入内核意味着以多种方式放弃一定程度的控制权——包括
-控制代码的格式化方式。
+内核的代码风格偶尔会与雇主的强制风格发生冲突。在这种情况下，必须在代码合并
+之前遵从内核代码风格。将代码放入内核意味着以多种方式放弃一定程度的控制权——
+包括控制代码样式。
 
-另一个陷阱是假定已经在内核中的代码迫切需要编码样式的修复。开发人员可能会开始
-生成重新格式化补丁，作为熟悉过程的一种方式，或者作为将其名称写入内核变更日志
-的一种方式，或者两者兼而有之。但是纯编码风格的修复被开发社区视为噪音；它们往
-往受到冷遇。因此，最好避免使用这种类型的补丁。由于其他原因，在处理一段代码的
-同时修复它的样式是很自然的，但是编码样式的更改不应该仅为了更改而进行。
+另一个危害是认为已经在内核中的代码迫切需要修复代码样式。开发者可能会开始编写
+重新格式化补丁，作为熟悉开发过程的一种方式，或者作为将其名字写入内核变更日志
+的一种方式，或者两者兼而有之。但是纯代码风格的修复被开发社区视为干扰，它们往
+往受到冷遇。因此，最好避免编写这种类型的补丁。在由于其他原因处理一段代码的
+同时顺带修复其样式是很自然的，但是不应该仅为了更改代码样式而更改之。
 
-编码风格的文档也不应该被视为绝对的法律，这是永远不会被违反的。如果有一个很好
-的理由反对这种样式（例如，如果拆分为适合80列限制的行，那么它的可读性就会大大
-降低），那么就这样做。
+代码风格文档也不应该被视为绝对不可违反的规则。如果有一个足够的理由反对这种
+样式（例如为了80列限制拆分行会导致可读性大大降低），那么就这样做吧。
 
-请注意，您还可以使用 ``clang-format`` 工具来帮助您处理这些规则，自动重新格式
-化部分代码，并查看完整的文件，以发现编码样式错误、拼写错误和可能的改进。它还
-可以方便地进行排序，包括对齐变量/宏、回流文本和其他类似任务。有关详细信息，请
-参阅文件 :ref:`Documentation/process/clang-format.rst <clangformat>`
+注意您还可以使用 ``clang-format`` 工具来帮助您处理这些规则，快速自动重新格式
+化部分代码，和审阅完整的文件以发现代码样式错误、拼写错误和可能的改进。它还
+可以方便地排序 ``#includes`` 、对齐变量/宏、重排文本和其他类似任务。有关详细
+信息，请参阅文件 :ref:`Documentation/process/clang-format.rst <clangformat>`
 
 抽象层
 ******
 
 计算机科学教授教学生以灵活性和信息隐藏的名义广泛使用抽象层。当然，内核广泛
-地使用了抽象；任何涉及数百万行代码的项目都不能做到这一点并存活下来。但经验
-表明，过度或过早的抽象可能和过早的优化一样有害。抽象应用于所需的级别，
+地使用了抽象；任何涉及数百万行代码的项目都必须做到这一点以存续下来。但经验
+表明，过度或过早的抽象可能和过早的优化一样有害。抽象应用在适当层级，
 不要过度。
 
-在一个简单的级别上，考虑一个函数的参数，该参数总是由所有调用方作为零传递。
-我们可以保留这个论点: 以防有人最终需要使用它提供的额外灵活性。不过，到那时，
-实现这个额外参数的代码很有可能以某种从未被注意到的微妙方式被破坏——因为它从
-未被使用过。或者，当需要额外的灵活性时，它不会以符合程序员早期期望的方式来
-这样做。内核开发人员通常会提交补丁来删除未使用的参数；一般来说，首先不应该
-添加这些参数。
+简单点，先考虑一个调用时始终只有一个参数且总为零的函数。我们可以保留这个参数，
+以在需要使用它时提供的额外灵活性。不过，在那时实现了这个额外参数的代码很有
+可能以某种从未被注意到的微妙方式被破坏——因为它从未被使用过。或者当需要额外
+的灵活性时，它并未以符合程序员当初期望的方式来实现。内核开发人员通常会提交
+补丁来删除未使用的参数；一般来说，一开始就不应该添加这些参数。
 
-隐藏硬件访问的抽象层——通常允许大量的驱动程序在多个操作系统中使用——尤其不受
+隐藏硬件访问的抽象层——通常允许大量的驱动程序兼容在多个操作系统——尤其不受
 欢迎。这样的层使代码变得模糊，可能会造成性能损失；它们不属于Linux内核。
 
-另一方面，如果您发现自己从另一个内核子系统复制了大量的代码，那么现在是时候
-问一下，事实上，将这些代码中的一些提取到单独的库中，或者在更高的层次上实现
+另一方面，如果您发现自己从另一个内核子系统复制了大量的代码，那么是时候
+了解一下：将这些代码中的部分提取到单独的库中，或者在更高的层次上实现
 这些功能是否有意义。在整个内核中复制相同的代码没有价值。
 
 #ifdef 和预处理
 ***************
 
-C预处理器似乎给一些C程序员带来了强大的诱惑，他们认为它是一种有效地将大量灵
-活性编码到源文件中的方法。但是预处理器不是C，大量使用它会导致代码对其他人来
-说更难读取，对编译器来说更难检查正确性。大量的预处理器几乎总是代码需要一些
+C预处理器似乎给一些C程序员带来了强大的诱惑，他们认为它是一种将大量灵活性加入
+源代码中的方法。但是预处理器不是C，大量使用它会导致代码对其他人来说更难阅读，
+对编译器来说更难检查正确性。使用了大量预处理器几乎总是代码需要一些
 清理工作的标志。
 
-使用ifdef的条件编译实际上是一个强大的功能，它在内核中使用。但是很少有人希望
-看到代码被大量地撒上ifdef块。作为一般规则，ifdef的使用应尽可能限制在头文件
-中。有条件编译的代码可以限制函数，如果代码不存在，这些函数就会变成空的。然后
-编译器将悄悄地优化对空函数的调用。结果是代码更加清晰，更容易理解。
+使用#ifdef的条件编译实际上是一个强大的功能，它在内核中使用。但是很少有人希望
+看到代码被铺满#ifdef块。一般规定，ifdef的使用应尽可能限制在头文件中。条件
+编译代码可以限制函数，如果代码不存在，这些函数就直接变成空的。然后编译器将
+悄悄地优化对空函数的调用。使得代码更加清晰，更容易理解。
 
-C预处理器宏存在许多危险，包括可能对具有副作用且没有类型安全性的表达式进行多
-重评估。如果您试图定义宏，请考虑创建一个内联函数。结果相同的代码，但是内联
-函数更容易读取，不会多次计算其参数，并且允许编译器对参数和返回值执行类型检查。
+C预处理器宏存在许多危险性，包括可能对具有副作用且没有类型安全的表达式进行多
+重评估。如果您试图定义宏，请考虑创建一个内联函数替代。结果相同的代码，内联
+函数更容易阅读，不会多次计算其参数，并且允许编译器对参数和返回值执行类型检查。
 
 内联函数
 ********
 
 不过，内联函数本身也存在风险。程序员可以倾心于避免函数调用和用内联函数填充源
 文件所固有的效率。然而，这些功能实际上会降低性能。因为它们的代码在每个调用站
-点都被复制，所以它们最终会增加编译内核的大小。反过来，这会对处理器的内存缓存
-造成压力，从而大大降低执行速度。通常，内联函数应该非常小，而且相对较少。毕竟，
-函数调用的成本并不高；大量内联函数的创建是过早优化的典型例子。
+点都被复制一遍，所以最终会增加编译内核的大小。此外，这也对处理器的内存缓存
+造成压力，从而大大降低执行速度。通常内联函数应该非常小，而且相对较少。毕竟
+函数调用的成本并不高；大量创建内联函数是过早优化的典型例子。
 
-一般来说，内核程序员会忽略缓存效果，这会带来危险。在开始的数据结构课程中，经
-典的时间/空间权衡通常不适用于当代硬件。空间就是时间，因为一个大的程序比一个
+一般来说，内核程序员会自冒风险忽略缓存效果。在数据结构课程开头中的经典
+时间/空间权衡通常不适用于当代硬件。空间 *就是* 时间，因为一个大的程序比一个
 更紧凑的程序运行得慢。
 
-最近的编译器在决定一个给定函数是否应该被内联方面扮演着越来越积极的角色。
-因此，“inline”关键字的自由放置可能不仅仅是过度的，它也可能是无关的。
+较新的编译器越来越激进地决定一个给定函数是否应该内联。因此，随意放置使用
+“inline”关键字可能不仅仅是过度的，也可能是无关紧要的。
 
 锁
 **
 
-2006年5月，“deviceescape”网络堆栈在GPL下发布，并被纳入主线内核。这是一个受
-欢迎的消息；对Linux中无线网络的支持充其量被认为是不合格的，而deviceescape
-堆栈提供了修复这种情况的承诺。然而，直到2007年6月（2.6.22），这段代码才真
+2006年5月，“deviceescape”网络堆栈在前呼后拥下以GPL发布，并被纳入主线内核。
+这是一个受欢迎的消息；Linux中对无线网络的支持充其量被认为是不合格的，而
+Deviceescape堆栈承诺修复这种情况。然而直到2007年6月（2.6.22），这段代码才真
 正进入主线。发生了什么？
 
-这段代码显示了许多闭门造车的迹象。但一个特别大的问题是，它并不是设计用于多
-处理器系统。在合并这个网络堆栈（现在称为mac80211）之前，需要对其进行一个锁
+这段代码出现了许多闭门造车的迹象。但一个大麻烦是，它并不是为多处理器系统
+而设计。在合并这个网络堆栈（现在称为mac80211）之前，需要对其进行一个锁
 方案的改造。
 
 曾经，Linux内核代码可以在不考虑多处理器系统所带来的并发性问题的情况下进行
-开发。然而，现在，这个文件是写在双核笔记本电脑上的。即使在单处理器系统上，
+开发。然而现在，这个文档就是在双核笔记本电脑上写的。即使在单处理器系统上，
 为提高响应能力所做的工作也会提高内核内的并发性水平。编写内核代码而不考虑锁
 的日子已经过去很长了。
 
 可以由多个线程并发访问的任何资源（数据结构、硬件寄存器等）必须由锁保护。新
-的代码应该记住这一要求；事后改装锁是一项相当困难的任务。内核开发人员应该花
-时间充分了解可用的锁原语，以便为作业选择正确的工具。显示对并发性缺乏关注的
-代码进入主线将很困难。
+的代码应该谨记这一要求；事后修改锁是一项相当困难的任务。内核开发人员应该花
+时间充分了解可用的锁原语，以便为工作选择正确的工具。对并发性缺乏关注的代码
+很难进入主线。
 
-回归
+回退
 ****
 
-最后一个值得一提的危险是：它可能会引起改变（这可能会带来很大的改进），从而
-导致现有用户的某些东西中断。这种变化被称为“回归”，回归已经成为主线内核最不
-受欢迎的。除少数例外情况外，如果回归不能及时修正，会导致回归的变化将被取消。
-最好首先避免回归。
+最后一个值得一提的危险是回退：它可能会引起导致现有用户的某些东西中断的
+改变（这也可能会带来很大的改进）。这种变化被称为“回退”，回退已经成为主线内核
+最不受欢迎的问题。除了少数例外情况，如果回退不能及时修正，会导致回退的修改将
+被取消。最好首先避免回退发生。
 
-人们常常争论，如果回归让更多人可以工作，远超过产生问题，那么回归是合理的。
-如果它破坏的一个系统却为十个系统带来新的功能，为什么不进行更改呢？2007年7月，
+人们常常争论，如果回退带来的功能远超过产生的问题，那么回退是否可接受的。
+如果它破坏了一个系统却为十个系统带来新的功能，为何不改改态度呢？2007年7月，
 Linus对这个问题给出了最佳答案:
 
 ::
-        所以我们不会通过引入新问题来修复错误。那样的谎言很疯狂，没有人知道
-        你是否真的有进展。是前进两步，后退一步，还是向前一步，向后两步？
+
+	所以我们不会通过引入新问题来修复错误。这种方式是靠不住的，没人知道
+	是否真的有进展。是前进两步、后退一步，还是向前一步、向后两步？
 
 （http://lwn.net/articles/243460/）
 
-一种特别不受欢迎的回归类型是用户空间ABI的任何变化。一旦接口被导出到用户空间，
+特别不受欢迎的一种回退类型是用户空间ABI的任何变化。一旦接口被导出到用户空间，
 就必须无限期地支持它。这一事实使得用户空间接口的创建特别具有挑战性：因为它们
-不能以不兼容的方式进行更改，所以必须第一次正确地进行更改。因此，用户空间界面
+不能以不兼容的方式进行更改，所以必须一次就对。因此，用户空间接口
 总是需要大量的思考、清晰的文档和广泛的审查。
 
 
@@ -157,13 +156,13 @@ Linus对这个问题给出了最佳答案:
 
 至少目前，编写无错误代码仍然是我们中很少人能达到的理想状态。不过，我们希望做
 的是，在代码进入主线内核之前，尽可能多地捕获并修复这些错误。为此，内核开发人
-员已经组装了一系列令人印象深刻的工具，可以自动捕获各种各样的模糊问题。计算机
+员已经提供了一系列令人印象深刻的工具，可以自动捕获各种各样的隐藏问题。计算机
 发现的任何问题都是一个以后不会困扰用户的问题，因此，只要有可能，就应该使用
 自动化工具。
 
-第一步只是注意编译器产生的警告。当代版本的GCC可以检测（并警告）大量潜在错误。
-通常，这些警告都指向真正的问题。提交以供审阅的代码通常不会产生任何编译器警告。
-在消除警告时，注意了解真正的原因，并尽量避免“修复”，使警告消失而不解决其原因。
+第一步是注意编译器产生的警告。当前版本的GCC可以检测（并警告）大量潜在错误。
+通常，这些警告都指向真正的问题。提交以供审阅的代码一般不会产生任何编译器警告。
+在消除警告时，注意了解真正的原因，并尽量避免仅“修复”使警告消失而不解决其原因。
 
 请注意，并非所有编译器警告都默认启用。使用“make EXTRA_CFLAGS=-W”构建内核以
 获得完整集合。
@@ -172,45 +171,43 @@ Linus对这个问题给出了最佳答案:
 子菜单中。对于任何用于开发或测试目的的内核，都应该启用其中几个选项。特别是，
 您应该打开：
 
- - 启用 ENABLE_MUST_CHECK and FRAME_WARN 以获得一组额外的警告，以解决使用不
-   推荐使用的接口或忽略函数的重要返回值等问题。这些警告生成的输出可能是冗长
-   的，但您不必担心来自内核其他部分的警告。
+ - FRAME_WARN 获取大于给定数量的堆栈帧的警告。
+   这些警告生成的输出可能比较冗长，但您不必担心来自内核其他部分的警告。
 
- - DEBUG_OBJECTS 将添加代码，以跟踪内核创建的各种对象的生存期，并在出现问题时
-   发出警告。如果要添加创建（和导出）自己的复杂对象的子系统，请考虑添加对对象
-   调试基础结构的支持。
+ - DEBUG_OBJECTS 将添加代码以跟踪内核创建的各种对象的生命周期，并在出现问题时
+   发出警告。如果你要添加创建（和导出）关于其自己的复杂对象的子系统，请考虑
+   打开对象调试基础结构的支持。
 
  - DEBUG_SLAB 可以发现各种内存分配和使用错误；它应该用于大多数开发内核。
 
- - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP and DEBUG_MUTEXES 会发现许多常见的
-   锁定错误.
+ - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP 和 DEBUG_MUTEXES 会发现许多常见的
+   锁错误。
 
-还有很多其他调试选项，其中一些将在下面讨论。其中一些具有显著的性能影响，不应
-一直使用。但是，在学习可用选项上花费的一些时间可能会在短期内得到多次回报。
+还有很多其他调试选项，其中一些将在下面讨论。其中一些有显著的性能影响，不应
+一直使用。在学习可用选项上花费一些时间，可能会在短期内得到许多回报。
 
-其中一个较重的调试工具是锁定检查器或“lockdep”。该工具将跟踪系统中每个锁
+其中一个较重的调试工具是锁检查器或“lockdep”。该工具将跟踪系统中每个锁
 （spinlock或mutex）的获取和释放、获取锁的相对顺序、当前中断环境等等。然后，
-它可以确保总是以相同的顺序获取锁，相同的中断假设适用于所有情况，等等。换句话
-说，lockdep可以找到许多场景，在这些场景中，系统很少会死锁。在部署的系统中，
-这种问题可能会很痛苦（对于开发人员和用户而言）；LockDep允许提前以自动方式
-发现问题。具有任何类型的非普通锁定的代码在提交包含前应在启用lockdep的情况
-下运行。
+它可以确保总是以相同的顺序获取锁，相同的中断假设适用于所有情况等等。换句话
+说，lockdep可以找到许多导致系统死锁的场景。在部署的系统中，这种问题可能会
+很痛苦（对于开发人员和用户而言）；LockDep允许提前以自动方式发现问题。
+具有任何类型的非普通锁的代码在提交合并前应在启用lockdep的情况下运行测试。
 
 作为一个勤奋的内核程序员，毫无疑问，您将检查任何可能失败的操作（如内存分配）
-的返回状态。然而，事实上，最终的故障恢复路径可能完全没有经过测试。未测试的
-代码往往会被破坏；如果所有这些错误处理路径都被执行了几次，那么您可能对代码
+的返回状态。然而，事实上，最终的故障复现路径可能完全没有经过测试。未测试的
+代码往往会出问题；如果所有这些错误处理路径都被执行了几次，那么您可能对代码
 更有信心。
 
 内核提供了一个可以做到这一点的错误注入框架，特别是在涉及内存分配的情况下。
-启用故障注入后，内存分配的可配置百分比将失败；这些失败可以限制在特定的代码
+启用故障注入后，内存分配的可配置失败的百分比；这些失败可以限定在特定的代码
 范围内。在启用了故障注入的情况下运行，程序员可以看到当情况恶化时代码如何响
 应。有关如何使用此工具的详细信息，请参阅
 Documentation/fault-injection/fault-injection.rst。
 
-使用“sparse”静态分析工具可以发现其他类型的错误。对于sparse，可以警告程序员
-用户空间和内核空间地址之间的混淆、big endian和small endian数量的混合、在需
-要一组位标志的地方传递整数值等等。sparse必须单独安装(如果您的分发服务器没
-有将其打包，可以在 https://sparse.wiki.kernel.org/index.php/Main_page)找到,
+“sparse”静态分析工具可以发现其他类型的错误。sparse可以警告程序员
+用户空间和内核空间地址之间的混淆、大端序与小端序的混淆、在需要一组位标志
+的地方传递整数值等等。sparse必须单独安装(如果您的分发服务器没有将其打包，
+可以在 https://sparse.wiki.kernel.org/index.php/Main_page 找到）,
 然后可以通过在make命令中添加“C=1”在代码上运行它。
 
 “Coccinelle”工具 :ref:`http://coccinelle.lip6.fr/ <devtools_coccinelle>`
@@ -221,8 +218,8 @@ scripts/coccinelle目录下已经打包了相当多的内核“语义补丁”
 
 
 其他类型的可移植性错误最好通过为其他体系结构编译代码来发现。如果没有S/390系统
-或Blackfin开发板，您仍然可以执行编译步骤。可以在以下位置找到一组用于x86系统的
-大型交叉编译器：
+或Blackfin开发板，您仍然可以执行编译步骤。可以在以下位置找到一大组用于x86系统的
+交叉编译器：
 
         https://www.kernel.org/pub/tools/crosstool/
 
@@ -233,22 +230,22 @@ scripts/coccinelle目录下已经打包了相当多的内核“语义补丁”
 
 文档通常比内核开发规则更为例外。即便如此，足够的文档将有助于简化将新代码合并
 到内核中的过程，使其他开发人员的生活更轻松，并对您的用户有所帮助。在许多情况
-下，文件的添加已基本上成为强制性的。
+下，添加文档已基本上是强制性的。
 
 任何补丁的第一个文档是其关联的变更日志。日志条目应该描述正在解决的问题、解决
 方案的形式、处理补丁的人员、对性能的任何相关影响，以及理解补丁可能需要的任何
-其他内容。确保changelog说明了为什么补丁值得应用；大量开发人员未能提供这些信息。
+其他内容。确保变更日志说明了*为什么*补丁值得应用；大量开发者未能提供这些信息。
 
-任何添加新用户空间界面的代码（包括新的sysfs或/proc文件）都应该包含该界面的
-文档，该文档使用户空间开发人员能够知道他们在使用什么。请参阅
-Documentation/ABI/README，了解如何格式化此文档以及需要提供哪些信息。
+任何添加新用户空间接口的代码——包括新的sysfs或/proc文件——都应该包含该
+接口的文档，该文档使用户空间开发人员能够知道他们在使用什么。请参阅
+Documentation/ABI/README，了解如何此文档格式以及需要提供哪些信息。
 
-文件 :ref:`Documentation/admin-guide/kernel-parameters.rst <kernelparameters>`
+文档 :ref:`Documentation/admin-guide/kernel-parameters.rst <kernelparameters>`
 描述了内核的所有引导时间参数。任何添加新参数的补丁都应该向该文件添加适当的
 条目。
 
-任何新的配置选项都必须附有帮助文本，帮助文本清楚地解释了这些选项以及用户可能
-希望何时选择它们。
+任何新的配置选项都必须附有帮助文本，帮助文本需清楚地解释这些选项以及用户可能
+希望何时使用它们。
 
 许多子系统的内部API信息通过专门格式化的注释进行记录；这些注释可以通过
 “kernel-doc”脚本以多种方式提取和格式化。如果您在具有kerneldoc注释的子系统中
@@ -257,31 +254,31 @@ Documentation/ABI/README，了解如何格式化此文档以及需要提供哪
 来说是一个有用的活动。这些注释的格式以及如何创建kerneldoc模板的一些信息可以在
 :ref:`Documentation/doc-guide/ <doc_guide>` 上找到。
 
-任何阅读大量现有内核代码的人都会注意到，注释的缺失往往是最值得注意的。再一次，
-对新代码的期望比过去更高；合并未注释的代码将更加困难。这就是说，人们几乎不希望
-用语言注释代码。代码本身应该是可读的，注释解释了更微妙的方面。
+任何阅读大量现有内核代码的人都会注意到，注释的缺失往往是最值得注意的。同时，
+对新代码的要求比过去更高；合并未注释的代码将更加困难。这就是说，人们并不期望
+详细注释的代码。代码本身应该是自解释的，注释阐释了更微妙的方面。
 
 某些事情应该总是被注释。使用内存屏障时，应附上一行文字，解释为什么需要设置内存
-屏障。数据结构的锁定规则通常需要在某个地方解释。一般来说，主要数据结构需要全面
-的文档。应该指出单独代码位之间不明显的依赖性。任何可能诱使代码看门人进行错误的
-“清理”的事情都需要一个注释来说明为什么要这样做。等等。
+屏障。数据结构的锁规则通常需要在某个地方解释。一般来说，主要数据结构需要全面
+的文档。应该指出代码中分立的位之间不明显的依赖性。任何可能诱使代码管理人进行
+错误的“清理”的事情都需要一个注释来说明为什么要这样做。等等。
 
 
 内部API更改
 -----------
 
-内核提供给用户空间的二进制接口不能被破坏，除非在最严重的情况下。相反，内核的
-内部编程接口是高度流动的，当需要时可以更改。如果你发现自己不得不处理一个内核
-API，或者仅仅因为它不满足你的需求而不使用特定的功能，这可能是API需要改变的一
-个标志。作为内核开发人员，您有权进行此类更改。
+内核提供给用户空间的二进制接口不能被破坏，除非逼不得已。而内核的内部编程
+接口是高度流动的，当需要时可以更改。如果你发现自己不得不处理一个内核API，
+或者仅仅因为它不满足你的需求导致无法使用特定的功能，这可能是API需要改变的
+一个标志。作为内核开发人员，您有权进行此类更改。
 
-当然, 可以进行API更改，但它们必须是合理的。因此，任何进行内部API更改的补丁都
-应该附带一个关于更改内容和必要原因的描述。这种变化也应该分解成一个单独的补丁，
+的确可以进行API更改，但更改必须是合理的。因此任何进行内部API更改的补丁都
+应该附带关于更改内容和必要原因的描述。这种变化也应该拆分成一个单独的补丁，
 而不是埋在一个更大的补丁中。
 
 另一个要点是，更改内部API的开发人员通常要负责修复内核树中被更改破坏的任何代码。
-对于一个广泛使用的函数，这个职责可以导致成百上千的变化，其中许多变化可能与其他
-开发人员正在做的工作相冲突。不用说，这可能是一项大工作，所以最好确保理由是
+对于一个广泛使用的函数，这个责任可以导致成百上千的变化，其中许多变化可能与其他
+开发人员正在做的工作相冲突。不用说，这可能是一项大工程，所以最好确保理由是
 可靠的。请注意，coccinelle工具可以帮助进行广泛的API更改。
 
 在进行不兼容的API更改时，应尽可能确保编译器捕获未更新的代码。这将帮助您确保找
-- 
2.20.1

Re: [PATCH 0/5] docs/zh_CN: Improve language in zh_CN/process/

[Alex Shi]

Hi Xiangcheng,

Thanks for polishing patchset, but i can find your patches in my email box.
and even in lkml. Except https://lkml.org/lkml/2021/2/14/33 the first patch.
Do I missed others?


在 2021/2/18 下午6:24, Wu XiangCheng 写道:
> There are some errors in some files in zh_CN/process/, such as grammatical 
> errors, translation errors and improper use of words etc., which make it 

Could you like to point out each of specific incorrect words with reasons?
Like the following incorrect I found in your patch:

A, And end users, too, will often wish to change Linux to make it
   better suit their needs.
  
   +最终用户也常常希望修改Linux，使之年能更好地满足他们的需求。
   I couldn't find a word means '年'/year in original context, do you?

B, Contribution of code is the fundamental action which makes the whole
   process work.

+- 代码的贡献是使整个流程顺畅的根本

the point of the process is 工作/workable, your transltion change it to
process 顺畅/fluency, why?


Thanks! 

> difficult for native speakers to understand. Many errors are caused by 
> machine translation without manual correction.
> 
> This set of patchs aims to fix the above problems and synchronize them with
> original files. Some structure modifications need to rewrite the whole 
> sentences, so here are a lot of changes.
> 
> Wu XiangCheng (5):
>   docs/zh_CN: Improve zh_CN/process/index.rst
>   docs/zh_CN: Improve zh_CN/process/1.Intro.rst
>   docs/zh_CN: Improve zh_CN/process/2.Process.rst
>   docs/zh_CN: Improve zh_CN/process/3.Early-stage.rst
>   docs/zh_CN: Improve zh_CN/process/4.Coding.rst
> 
>  .../translations/zh_CN/process/1.Intro.rst    | 146 ++++-----
>  .../translations/zh_CN/process/2.Process.rst  | 296 +++++++++---------
>  .../zh_CN/process/3.Early-stage.rst           | 120 +++----
>  .../translations/zh_CN/process/4.Coding.rst   | 251 ++++++++-------
>  .../translations/zh_CN/process/index.rst      |  10 +-
>  5 files changed, 412 insertions(+), 411 deletions(-)
> 

Re: [PATCH 0/5] docs/zh_CN: Improve language in zh_CN/process/

[Wu X.C.]

On Fri, Feb 19, 2021 at 11:23:02AM +0800, Alex Shi wrote:
> Hi Xiangcheng,
> 
> Thanks for polishing patchset, but i can find your patches in my email box.
> and even in lkml. Except https://lkml.org/lkml/2021/2/14/33 the first patch.
> Do I missed others?
> 
No, that's all. I sent first patch in 02-14 and got no comment, so keep 
working and re-sent this one without cc kernel-list. You can simply skip 
the previous one.
> 
> 在 2021/2/18 下午6:24, Wu XiangCheng 写道:
> > There are some errors in some files in zh_CN/process/, such as grammatical 
> > errors, translation errors and improper use of words etc., which make it 
> 
> Could you like to point out each of specific incorrect words with reasons?
> Like the following incorrect I found in your patch:
> 
> A, And end users, too, will often wish to change Linux to make it
>    better suit their needs.
>   
>    +最终用户也常常希望修改Linux，使之年能更好地满足他们的需求。
>    I couldn't find a word means '年'/year in original context, do you?
>
Sorry, I will correct such typo.
> 
> B, Contribution of code is the fundamental action which makes the whole
>    process work.
> 
> +- 代码的贡献是使整个流程顺畅的根本
> 
> the point of the process is 工作/workable, your transltion change it to
> process 顺畅/fluency, why?
> 
In fact, I did some free translation rather than literal translation. 
It's up to you to point out what you don't think is appropriate, we can 
change that. Like 'work' also can be translated as '工作起来', '起作用' etc.

As for:
> Could you like to point out each of specific incorrect words with reasons?
> Like the following incorrect I found in your patch:
It is hard to give all words one by one, here are the main points as 
example:

[Patch 1/5]
1. 
These are some overall technical guides that have been put here for now 
for lack of a better place.
-这些是一些总体技术指南，由于缺乏更好的地方，现在已经放在这里
+这些是一些总体性技术指南，由于不大好分类而放在这里：
	paraphrase

[Patch 2/5]
2.
Introduction
-介绍
+引言
	According to the purpose of this article

3.
Executive summary
-执行摘要
+内容提要
	Idiomatic words

4. 
There is some discussion of tools and mailing lists. 
-涵盖了补丁开发、审查和合并周期中的各个阶段。有一些关于工具和邮件列表的讨论。
+涵盖了补丁开发、审查和合并周期中的各个阶段。还介绍了一些工具和邮件列表。
	Need to translate "discussion" according to the situation, same as
	"interest", "work"

5. 
Developers are cautioned against assuming that the job is done...
-开发人员要注意不要假定任务已经完成。
+开发人员要注意不要认为任务已经完成。
	Idiomatic words

6. 
introduces a couple of "advanced" topics:
-:ref:`cn_development_advancedtopics` 介绍了两个“高级”主题：
+:ref:`cn_development_advancedtopics` 介绍了两个“进阶”主题：
	Idiomatic words

7.
-- 围绕专有内核模块分发的法律问题充其量是模糊的；相当多的内核版权所有者认为，
+- 围绕专有内核模块分发的法律问题其实较为模糊；相当多的内核版权所有者认为，
	There are many "充其量" in the original translation, not always suitable.

8.
by GPLv2 (with, optionally, language allowing distribution under later 
versions of the GPL) 
-着所有代码贡献都由GPLv2（可选地，语言允许在更高版本的GPL下分发）或3子句BSD
+着所有代码贡献都由GPLv2（原则上允许在更高版本的GPL下分发，可选）或3子句BSD
	Hard to understand

9.
(such as code which derives from reverse-engineering efforts lacking
proper safeguards) 
-相关问题的代码（例如，由缺乏适当保护的反向工程工作派生的代码）不能被接受。
+内核造成版权相关问题的代码（例如，由缺乏适当保护的逆向工程工作派生的代码）
	Idiomatic words

[Patch 3/5]
10. 
How the development process works
-开发流程如何工作
+开发流程如何进行
	According to the situation

11.
in order to be an effective part of it.
-进来，内核因此必须发展许多流程来保持开发的顺利进行。要成为流程的有效组成
+内核因此必须发展出许多既定流程来保证开发的顺利进行。要参与到流程中来，

12.
they cannot cause regressions
-改变已有代码，则不会导致回归，并且应该可以随时安全地添加）。
+则不会导致回退，应该可以随时被安全地加入）。
	regression, see (28.)

13.
its ongoing maintenance
-一旦一个稳定的版本发布，它正在进行的维护工作就被移交给“稳定团队”，目前由
+一旦一个稳定的版本发布，它的持续维护工作就被移交给“稳定团队”，目前由

14.
The selection of a kernel for long-term support is purely a matter of a
maintainer having the need and the time to maintain that release.
-为长期支持选择内核纯粹是维护人员有必要和时间来维护该版本的问题。目前还没有
+长期支持内核的选择纯粹是维护人员是否有需求和时间来维护该版本的问题。
	Mechanical translation

15.
Use of the MMOTM tree is likely to be a frustrating experience, though;
-然而，使用mmotm树可能是一种令人沮丧的体验；它甚至可能无法编译。
+然而，使用MMOTM树可能会十分令人头疼；它甚至可能无法编译。
	paraphrase

16.
The TODO file lists the pending work that the driver needs for 
acceptance into the kernel proper
-目录中还应该有一个TODO文件。todo文件列出了驱动程序需要接受的挂起的工作，
+目录中还应该有一个TODO文件。TODO文件列出了驱动程序即将进行的工作，
	Mechanical translation

17.
but there is space for a few pointers.
-这些工具的教程远远超出了本文档的范围，但是还是有一些指南的空间。
+这些工具的教程远远超出了本文档的范围，但还是用一点篇幅介绍一些关键点。
	Mechanical translation

18.
the amount of noise is high
-每天的信息量可以达到500条，噪音很高，谈话技术性很强，参与者并不总是表现出
+每天的信息量可以达到500条，非常热闹，谈话技术性很强，且参与者并不总是表现出
	"noise" actually is "热闹"、"干扰"

[Patch 4/5]
19.
it is tempting to confuse the real problem with the proposed solution, 
and that can lead to difficulties.
-将实际问题与建议的解决方案混淆是很有诱惑力的，这可能会导致困难。
+很容易将实际问题与建议的解决方案混在一起，这可能会导致麻烦。
	Mechanical translation

20.
and ongoing latency reduction work in the long term.
-机制进行实时调度访问，以及长期的减少延迟的工作。
+机制进行实时调度访问，以及长期的减少延迟的改进。

21.
has caused Reiser4 to stay out of the mainline kernel.
-   导致Reiser4远离了主线内核。
+   导致Reiser4无法进入主线内核。
	paraphrase

22.
When to post?
-何时邮寄？
+何时发布？
	post, polysemes

23.
(2) there is no shortage of people with grand plans and little code (or 
even prospect of code) to back them up
-反应。可悲的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划和很少
-代码（甚至代码前景）支持他们的人；（3）没有人有义务审查或评论别人发表的
+反馈。令人伤心的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划但
+代码（甚至代码设想）很少的人去支持他们；（3）没有人有义务审查或评论别人发表

[Patch 5/5]
24.
Then the focus will shift toward doing things right and the tools which can 
help in that quest.
-到正确的事情和可以帮助这个任务的工具上。
+到正确的做法和相关实用工具上。
	paraphrase

25.
Coding style
-编码风格
+代码风格
	Idiomatic words, also 代码规范

26.
... two independent hazards for kernel developers.
The first of these is to believe that the kernel coding standards do not
matter and are not enforced. 
-首先，要相信内核编码标准并不重要，也不强制执行。事实上，如果没有按照标准对代
+首先是错误相信内核代码标准并不重要，也不强制执行。但事实上，如果没有按照标准
	The meaning is totally wrong

27.
sorting ``#includes``, for aligning variables/macros, for reflowing text 
and other similar tasks
-可以方便地进行排序，包括对齐变量/宏、回流文本和其他类似任务。有关详细信息，请
+可以方便地排序 ``#includes`` 、对齐变量/宏、重排文本和其他类似任务。有关详细
	reflowing text

28.
Regressions
-回归
+回退
	"Regression" as a software term can be translated to "回归", but "回归" 
	often refers to the mathematical name or belonging state, and we also
	use "回归测试" as "regression test". 
	Besides, there is also "rollback" but rollback is obviously different 
	from regression, so we can't use "回滚". 
	So, which word should we use to translate the proper term for kernel 
	error, "回退" or just use "回归" ?


> 
> Thanks! 
> 
> > difficult for native speakers to understand. Many errors are caused by 
> > machine translation without manual correction.
> > 
> > This set of patchs aims to fix the above problems and synchronize them with
> > original files. Some structure modifications need to rewrite the whole 
> > sentences, so here are a lot of changes.
> > 
> > Wu XiangCheng (5):
> >   docs/zh_CN: Improve zh_CN/process/index.rst
> >   docs/zh_CN: Improve zh_CN/process/1.Intro.rst
> >   docs/zh_CN: Improve zh_CN/process/2.Process.rst
> >   docs/zh_CN: Improve zh_CN/process/3.Early-stage.rst
> >   docs/zh_CN: Improve zh_CN/process/4.Coding.rst
> > 
> >  .../translations/zh_CN/process/1.Intro.rst    | 146 ++++-----
> >  .../translations/zh_CN/process/2.Process.rst  | 296 +++++++++---------
> >  .../zh_CN/process/3.Early-stage.rst           | 120 +++----
> >  .../translations/zh_CN/process/4.Coding.rst   | 251 ++++++++-------
> >  .../translations/zh_CN/process/index.rst      |  10 +-
> >  5 files changed, 412 insertions(+), 411 deletions(-)
> > 

Re: [PATCH 0/5] docs/zh_CN: Improve language in zh_CN/process/

[Alex Shi]

在 2021/2/19 下午5:09, Wu X.C. 写道:
> On Fri, Feb 19, 2021 at 11:23:02AM +0800, Alex Shi wrote:
>> Hi Xiangcheng,
>>
>> Thanks for polishing patchset, but i can find your patches in my email box.
>> and even in lkml. Except https://lkml.org/lkml/2021/2/14/33 the first patch.
>> Do I missed others?
>>
> No, that's all. I sent first patch in 02-14 and got no comment, so keep 
> working and re-sent this one without cc kernel-list. You can simply skip 
> the previous one.

well, send out your cover letter with patches is a standard process in kernel
community. follow this could make reviewer more happy.

>>
>> 在 2021/2/18 下午6:24, Wu XiangCheng 写道:
>>> There are some errors in some files in zh_CN/process/, such as grammatical 
>>> errors, translation errors and improper use of words etc., which make it 
>>
>> Could you like to point out each of specific incorrect words with reasons?
>> Like the following incorrect I found in your patch:
>>
>> A, And end users, too, will often wish to change Linux to make it
>>    better suit their needs.
>>   
>>    +最终用户也常常希望修改Linux，使之年能更好地满足他们的需求。
>>    I couldn't find a word means '年'/year in original context, do you?
>>
> Sorry, I will correct such typo.
>>
>> B, Contribution of code is the fundamental action which makes the whole
>>    process work.
>>
>> +- 代码的贡献是使整个流程顺畅的根本
>>
>> the point of the process is 工作/workable, your transltion change it to
>> process 顺畅/fluency, why?
>>
> In fact, I did some free translation rather than literal translation. 

What means 'free' translation?

> It's up to you to point out what you don't think is appropriate, we can 
> change that. Like 'work' also can be translated as '工作起来', '起作用' etc.
> 

Nope, work never have meaning of fluency. There is a standard in Chinese-English
translation industry： 信，达，雅， it is fidelity, fluency, elegance in English.
Let's not change the original meaning. At last we should hang on the fidelity
and then try fluency and elegance.

> As for:
>> Could you like to point out each of specific incorrect words with reasons?
>> Like the following incorrect I found in your patch:
> It is hard to give all words one by one, here are the main points as 
> example:

No explanation is fine for first translation, but better to have for each of
correctness.

> 
> [Patch 1/5]
> 1. 
> These are some overall technical guides that have been put here for now 
> for lack of a better place.
> -这些是一些总体技术指南，由于缺乏更好的地方，现在已经放在这里
> +这些是一些总体性技术指南，由于不大好分类而放在这里：

it's ok for better fluency.

> 	paraphrase
> 
> [Patch 2/5]
> 2.
> Introduction
> -介绍
> +引言

Ok.

> 	According to the purpose of this article
> 
> 3.
> Executive summary
> -执行摘要
> +内容提要

for better Chinese custom, ok.

> 	Idiomatic words
> 
> 4. 
> There is some discussion of tools and mailing lists. 
> -涵盖了补丁开发、审查和合并周期中的各个阶段。有一些关于工具和邮件列表的讨论。
> +涵盖了补丁开发、审查和合并周期中的各个阶段。还介绍了一些工具和邮件列表。

twisted the word 'discusion', change to 还有一些关于工具和邮件列表的讨论？

> 	Need to translate "discussion" according to the situation, same as
> 	"interest", "work"
> 
> 5. 
> Developers are cautioned against assuming that the job is done...
> -开发人员要注意不要假定任务已经完成。
> +开发人员要注意不要认为任务已经完成。

Nope, don't see the reason.

> 	Idiomatic words
> 
> 6. 
> introduces a couple of "advanced" topics:
> -:ref:`cn_development_advancedtopics` 介绍了两个“高级”主题：
> +:ref:`cn_development_advancedtopics` 介绍了两个“进阶”主题：

ditto

> 	Idiomatic words
> 
> 7.
> -- 围绕专有内核模块分发的法律问题充其量是模糊的；相当多的内核版权所有者认为，
> +- 围绕专有内核模块分发的法律问题其实较为模糊；相当多的内核版权所有者认为，

ok for better fluency.

> 	There are many "充其量" in the original translation, not always suitable.
> 
> 8.
> by GPLv2 (with, optionally, language allowing distribution under later 
> versions of the GPL) 
> -着所有代码贡献都由GPLv2（可选地，语言允许在更高版本的GPL下分发）或3子句BSD
> +着所有代码贡献都由GPLv2（原则上允许在更高版本的GPL下分发，可选）或3子句BSD

Nope, I got struggle here, but still have no idea if yours correct.
'language' has no meaning of principle, maybe the old translation with
a comment or attach with the original English words?

> 	Hard to understand
> 
> 9.
> (such as code which derives from reverse-engineering efforts lacking
> proper safeguards) 
> -相关问题的代码（例如，由缺乏适当保护的反向工程工作派生的代码）不能被接受。
> +内核造成版权相关问题的代码（例如，由缺乏适当保护的逆向工程工作派生的代码）

Nope, 反向工程 is used a lot.
and why add extra words?

> 	Idiomatic words
> 
> [Patch 3/5]
> 10. 
> How the development process works
> -开发流程如何工作
> +开发流程如何进行

ok for fluency.

> 	According to the situation
> 
> 11.
> in order to be an effective part of it.
> -进来，内核因此必须发展许多流程来保持开发的顺利进行。要成为流程的有效组成
> +内核因此必须发展出许多既定流程来保证开发的顺利进行。要参与到流程中来，

could you give more context here, can't judge for pieces of words.

> 
> 12.
> they cannot cause regressions
> -改变已有代码，则不会导致回归，并且应该可以随时安全地添加）。
> +则不会导致回退，应该可以随时被安全地加入）。
> 	regression, see (28.)
> 

nope.

> 13.
> its ongoing maintenance
> -一旦一个稳定的版本发布，它正在进行的维护工作就被移交给“稳定团队”，目前由
> +一旦一个稳定的版本发布，它的持续维护工作就被移交给“稳定团队”，目前由

good on custom.

> 
> 14.
> The selection of a kernel for long-term support is purely a matter of a
> maintainer having the need and the time to maintain that release.
> -为长期支持选择内核纯粹是维护人员有必要和时间来维护该版本的问题。目前还没有
> +长期支持内核的选择纯粹是维护人员是否有需求和时间来维护该版本的问题。

good on fluency.

> 	Mechanical translation
> 
> 15.
> Use of the MMOTM tree is likely to be a frustrating experience, though;
> -然而，使用mmotm树可能是一种令人沮丧的体验；它甚至可能无法编译。
> +然而，使用MMOTM树可能会十分令人头疼；它甚至可能无法编译。

don't see reasons except the MMOTM change.

> 	paraphrase
> 
> 16.
> The TODO file lists the pending work that the driver needs for 
> acceptance into the kernel proper
> -目录中还应该有一个TODO文件。todo文件列出了驱动程序需要接受的挂起的工作，
> +目录中还应该有一个TODO文件。TODO文件列出了驱动程序即将进行的工作，

nope for fidelity.

> 	Mechanical translation
> 
> 17.
> but there is space for a few pointers.
> -这些工具的教程远远超出了本文档的范围，但是还是有一些指南的空间。
> +这些工具的教程远远超出了本文档的范围，但还是用一点篇幅介绍一些关键点。

ok.

> 	Mechanical translation
> 
> 18.
> the amount of noise is high
> -每天的信息量可以达到500条，噪音很高，谈话技术性很强，参与者并不总是表现出
> +每天的信息量可以达到500条，非常热闹，谈话技术性很强，且参与者并不总是表现出
> 	"noise" actually is "热闹"、"干扰"

Nope, fidelity issue. and noise has much more meaning than it's in
dictionary.

> 
> [Patch 4/5]
> 19.
> it is tempting to confuse the real problem with the proposed solution, 
> and that can lead to difficulties.
> -将实际问题与建议的解决方案混淆是很有诱惑力的，这可能会导致困难。
> +很容易将实际问题与建议的解决方案混在一起，这可能会导致麻烦。

ok for custom.

> 	Mechanical translation
> 
> 20.
> and ongoing latency reduction work in the long term.
> -机制进行实时调度访问，以及长期的减少延迟的工作。
> +机制进行实时调度访问，以及长期的减少延迟的改进。

more context?

> 
> 21.
> has caused Reiser4 to stay out of the mainline kernel.
> -   导致Reiser4远离了主线内核。
> +   导致Reiser4无法进入主线内核。

Reiser4 is in kernel now?

> 	paraphrase
> 
> 22.
> When to post?
> -何时邮寄？
> +何时发布？

Nope, 邮寄 is more common words for continue patches resending.

> 	post, polysemes
> 
> 23.
> (2) there is no shortage of people with grand plans and little code (or 
> even prospect of code) to back them up
> -反应。可悲的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划和很少
> -代码（甚至代码前景）支持他们的人；（3）没有人有义务审查或评论别人发表的
> +反馈。令人伤心的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划但
> +代码（甚至代码设想）很少的人去支持他们；（3）没有人有义务审查或评论别人发表

more context?

> 
> [Patch 5/5]
> 24.
> Then the focus will shift toward doing things right and the tools which can 
> help in that quest.
> -到正确的事情和可以帮助这个任务的工具上。
> +到正确的做法和相关实用工具上。

more context?

> 	paraphrase
> 
> 25.
> Coding style
> -编码风格
> +代码风格
> 	Idiomatic words, also 代码规范

Nope, didn't see much idiomatic for word coding. and code is different from
coding.

> 
> 26.
> ... two independent hazards for kernel developers.
> The first of these is to believe that the kernel coding standards do not
> matter and are not enforced. 
> -首先，要相信内核编码标准并不重要，也不强制执行。事实上，如果没有按照标准对代
> +首先是错误相信内核代码标准并不重要，也不强制执行。但事实上，如果没有按照标准
> 	The meaning is totally wrong

Nope, fidelity.

> 
> 27.
> sorting ``#includes``, for aligning variables/macros, for reflowing text 
> and other similar tasks
> -可以方便地进行排序，包括对齐变量/宏、回流文本和其他类似任务。有关详细信息，请
> +可以方便地排序 ``#includes`` 、对齐变量/宏、重排文本和其他类似任务。有关详细
> 	reflowing text

more context?

> 
> 28.
> Regressions
> -回归
> +回退
> 	"Regression" as a software term can be translated to "回归", but "回归" 
> 	often refers to the mathematical name or belonging state, and we also
> 	use "回归测试" as "regression test". 
> 	Besides, there is also "rollback" but rollback is obviously different 
> 	from regression, so we can't use "回滚". 
> 	So, which word should we use to translate the proper term for kernel 
> 	error, "回退" or just use "回归" ?

'regression' here has same meaningful with 'regression test'. better no change.

Thanks!
Alex

> 
> 
>>
>> Thanks! 
>>
>>> difficult for native speakers to understand. Many errors are caused by 
>>> machine translation without manual correction.
>>>
>>> This set of patchs aims to fix the above problems and synchronize them with
>>> original files. Some structure modifications need to rewrite the whole 
>>> sentences, so here are a lot of changes.
>>>
>>> Wu XiangCheng (5):
>>>   docs/zh_CN: Improve zh_CN/process/index.rst
>>>   docs/zh_CN: Improve zh_CN/process/1.Intro.rst
>>>   docs/zh_CN: Improve zh_CN/process/2.Process.rst
>>>   docs/zh_CN: Improve zh_CN/process/3.Early-stage.rst
>>>   docs/zh_CN: Improve zh_CN/process/4.Coding.rst
>>>
>>>  .../translations/zh_CN/process/1.Intro.rst    | 146 ++++-----
>>>  .../translations/zh_CN/process/2.Process.rst  | 296 +++++++++---------
>>>  .../zh_CN/process/3.Early-stage.rst           | 120 +++----
>>>  .../translations/zh_CN/process/4.Coding.rst   | 251 ++++++++-------
>>>  .../translations/zh_CN/process/index.rst      |  10 +-
>>>  5 files changed, 412 insertions(+), 411 deletions(-)
>>>

Re: [PATCH 0/5] docs/zh_CN: Improve language in zh_CN/process/

[Wu X.C.]

On Sat, Feb 20, 2021 at 03:21:04PM +0800, Alex Shi wrote:
> 
> 
> 在 2021/2/19 下午5:09, Wu X.C. 写道:
> > On Fri, Feb 19, 2021 at 11:23:02AM +0800, Alex Shi wrote:
> >> Hi Xiangcheng,
> >>
> >> Thanks for polishing patchset, but i can find your patches in my email box.
> >> and even in lkml. Except https://lkml.org/lkml/2021/2/14/33 the first patch.
> >> Do I missed others?
> >>
> > No, that's all. I sent first patch in 02-14 and got no comment, so keep 
> > working and re-sent this one without cc kernel-list. You can simply skip 
> > the previous one.
> 
> well, send out your cover letter with patches is a standard process in kernel
> community. follow this could make reviewer more happy.
> 
> >>
> >> 在 2021/2/18 下午6:24, Wu XiangCheng 写道:
> >>> There are some errors in some files in zh_CN/process/, such as grammatical 
> >>> errors, translation errors and improper use of words etc., which make it 
> >>
> >> Could you like to point out each of specific incorrect words with reasons?
> >> Like the following incorrect I found in your patch:
> >>
> >> A, And end users, too, will often wish to change Linux to make it
> >>    better suit their needs.
> >>   
> >>    +最终用户也常常希望修改Linux，使之年能更好地满足他们的需求。
> >>    I couldn't find a word means '年'/year in original context, do you?
> >>
> > Sorry, I will correct such typo.
> >>
> >> B, Contribution of code is the fundamental action which makes the whole
> >>    process work.
> >>
> >> +- 代码的贡献是使整个流程顺畅的根本
> >>
> >> the point of the process is 工作/workable, your transltion change it to
> >> process 顺畅/fluency, why?
> >>
> > In fact, I did some free translation rather than literal translation. 
> 
> What means 'free' translation?
free translation 意译 literal translation 直译
> 
> > It's up to you to point out what you don't think is appropriate, we can 
> > change that. Like 'work' also can be translated as '工作起来', '起作用' etc.
> > 
> 
> Nope, work never have meaning of fluency. There is a standard in Chinese-English
> translation industry： 信，达，雅， it is fidelity, fluency, elegance in English.
> Let's not change the original meaning. At last we should hang on the fidelity
> and then try fluency and elegance.
Yeah. But fidelity could not solve all problems, sometimes, word by word 
translation make the sentences and names incomprehensible and very strange.
For Chinese, one need to eat the texts, chew them up, and then spit them out.
If the mean is incomprehensible, then the translation is meaningless.
Especially (26.) 
> 
> > As for:
> >> Could you like to point out each of specific incorrect words with reasons?
> >> Like the following incorrect I found in your patch:
> > It is hard to give all words one by one, here are the main points as 
> > example:
> 
> No explanation is fine for first translation, but better to have for each of
> correctness.
Got that. There will be more patch when next update. I'll try to give that for 
additional new patch.
> 
> > 
> > [Patch 1/5]
> > 1. 
> > These are some overall technical guides that have been put here for now 
> > for lack of a better place.
> > -这些是一些总体技术指南，由于缺乏更好的地方，现在已经放在这里
> > +这些是一些总体性技术指南，由于不大好分类而放在这里：
> 
> it's ok for better fluency.
> 
> > 	paraphrase
> > 
> > [Patch 2/5]
> > 2.
> > Introduction
> > -介绍
> > +引言
> 
> Ok.
> 
> > 	According to the purpose of this article
> > 
> > 3.
> > Executive summary
> > -执行摘要
> > +内容提要
> 
> for better Chinese custom, ok.
> 
> > 	Idiomatic words
> > 
> > 4. 
> > There is some discussion of tools and mailing lists. 
> > -涵盖了补丁开发、审查和合并周期中的各个阶段。有一些关于工具和邮件列表的讨论。
> > +涵盖了补丁开发、审查和合并周期中的各个阶段。还介绍了一些工具和邮件列表。
> 
> twisted the word 'discusion', change to 还有一些关于工具和邮件列表的讨论？
OK.
> 
> > 	Need to translate "discussion" according to the situation, same as
> > 	"interest", "work"
> > 
> > 5. 
> > Developers are cautioned against assuming that the job is done...
> > -开发人员要注意不要假定任务已经完成。
> > +开发人员要注意不要认为任务已经完成。
                       ^
> 
> Nope, don't see the reason.
更改一下习惯用词。
> 
> > 	Idiomatic words
> > 
> > 6. 
> > introduces a couple of "advanced" topics:
> > -:ref:`cn_development_advancedtopics` 介绍了两个“高级”主题：
> > +:ref:`cn_development_advancedtopics` 介绍了两个“进阶”主题：
> 
> ditto
Ok, keep it.
> 
> > 	Idiomatic words
> > 
> > 7.
> > -- 围绕专有内核模块分发的法律问题充其量是模糊的；相当多的内核版权所有者认为，
> > +- 围绕专有内核模块分发的法律问题其实较为模糊；相当多的内核版权所有者认为，
> 
> ok for better fluency.
> 
> > 	There are many "充其量" in the original translation, not always suitable.
> > 
> > 8.
> > by GPLv2 (with, optionally, language allowing distribution under later 
> > versions of the GPL) 
> > -着所有代码贡献都由GPLv2（可选地，语言允许在更高版本的GPL下分发）或3子句BSD
> > +着所有代码贡献都由GPLv2（原则上允许在更高版本的GPL下分发，可选）或3子句BSD
> 
> Nope, I got struggle here, but still have no idea if yours correct.
> 'language' has no meaning of principle, maybe the old translation with
> a comment or attach with the original English words?
Maybe, I also confused with it.
Ok, simply keep it.
> 
> > 	Hard to understand
> > 
> > 9.
> > (such as code which derives from reverse-engineering efforts lacking
> > proper safeguards) 
> > -相关问题的代码（例如，由缺乏适当保护的反向工程工作派生的代码）不能被接受。
> > +内核造成版权相关问题的代码（例如，由缺乏适当保护的逆向工程工作派生的代码）
> 
> Nope, 反向工程 is used a lot.
See，
《计算机科学技术名词 (第三版)》
规范用词：逆向工程
英语名：  reverse engineering
台湾名：  反向工程
定义：    通过分析软件系统后期制品，获取更高抽象度的前期模型的过程。
          是软件开发周期的反向过程。
学科： 	  计算机科学技术_软件工程
公布年度：2018
  ——全国科学技术名词审定委员会
> and why add extra words?
> 
> > 	Idiomatic words
> > 
> > [Patch 3/5]
> > 10. 
> > How the development process works
> > -开发流程如何工作
> > +开发流程如何进行
> 
> ok for fluency.
> 
> > 	According to the situation
> > 
> > 11.
> > in order to be an effective part of it.
> > -进来，内核因此必须发展许多流程来保持开发的顺利进行。要成为流程的有效组成
> > +内核因此必须发展出许多既定流程来保证开发的顺利进行。要参与到流程中来，
> 
> could you give more context here, can't judge for pieces of words.
（某人）要成为流程的有效组成部分
（某人）要参与到流程中来
Clear?
> 
> > 
> > 12.
> > they cannot cause regressions
> > -改变已有代码，则不会导致回归，并且应该可以随时安全地添加）。
> > +则不会导致回退，应该可以随时被安全地加入）。
> > 	regression, see (28.)
> > 
> 
> nope.
Ok.
> 
> > 13.
> > its ongoing maintenance
> > -一旦一个稳定的版本发布，它正在进行的维护工作就被移交给“稳定团队”，目前由
> > +一旦一个稳定的版本发布，它的持续维护工作就被移交给“稳定团队”，目前由
> 
> good on custom.
> 
> > 
> > 14.
> > The selection of a kernel for long-term support is purely a matter of a
> > maintainer having the need and the time to maintain that release.
> > -为长期支持选择内核纯粹是维护人员有必要和时间来维护该版本的问题。目前还没有
> > +长期支持内核的选择纯粹是维护人员是否有需求和时间来维护该版本的问题。
> 
> good on fluency.
> 
> > 	Mechanical translation
> > 
> > 15.
> > Use of the MMOTM tree is likely to be a frustrating experience, though;
> > -然而，使用mmotm树可能是一种令人沮丧的体验；它甚至可能无法编译。
> > +然而，使用MMOTM树可能会十分令人头疼；它甚至可能无法编译。
> 
> don't see reasons except the MMOTM change.
译文中满地都是直译“沮丧的体验”，太难受了，换个词表述
> 
> > 	paraphrase
> > 
> > 16.
> > The TODO file lists the pending work that the driver needs for 
> > acceptance into the kernel proper
> > -目录中还应该有一个TODO文件。todo文件列出了驱动程序需要接受的挂起的工作，
> > +目录中还应该有一个TODO文件。TODO文件列出了驱动程序即将进行的工作，
> 
> nope for fidelity.
What is "挂起的工作" ? Need a better word to change that.
> 
> > 	Mechanical translation
> > 
> > 17.
> > but there is space for a few pointers.
> > -这些工具的教程远远超出了本文档的范围，但是还是有一些指南的空间。
> > +这些工具的教程远远超出了本文档的范围，但还是用一点篇幅介绍一些关键点。
> 
> ok.
> 
> > 	Mechanical translation
> > 
> > 18.
> > the amount of noise is high
> > -每天的信息量可以达到500条，噪音很高，谈话技术性很强，参与者并不总是表现出
> > +每天的信息量可以达到500条，非常热闹，谈话技术性很强，且参与者并不总是表现出
> > 	"noise" actually is "热闹"、"干扰"
> 
> Nope, fidelity issue. and noise has much more meaning than it's in
> dictionary.
Please explain the extra meaning, otherwise double quotes are required.
> 
> > 
> > [Patch 4/5]
> > 19.
> > it is tempting to confuse the real problem with the proposed solution, 
> > and that can lead to difficulties.
> > -将实际问题与建议的解决方案混淆是很有诱惑力的，这可能会导致困难。
> > +很容易将实际问题与建议的解决方案混在一起，这可能会导致麻烦。
> 
> ok for custom.
> 
> > 	Mechanical translation
> > 
> > 20.
> > and ongoing latency reduction work in the long term.
                                  ^
> > -机制进行实时调度访问，以及长期的减少延迟的工作。
                                               ^
> > +机制进行实时调度访问，以及长期的减少延迟的改进。
                                               ^
> 
> more context?
> 
> > 
> > 21.
> > has caused Reiser4 to stay out of the mainline kernel.
> > -   导致Reiser4远离了主线内核。
> > +   导致Reiser4无法进入主线内核。
> 
> Reiser4 is in kernel now?
I don't know, or change to 导致Reiser4置身主线内核之外。
> 
> > 	paraphrase
> > 
> > 22.
> > When to post?
> > -何时邮寄？
> > +何时发布？
> 
> Nope, 邮寄 is more common words for continue patches resending.
?
This chapter aims to post your early plan to community, not only the patch.
Even if it's a patch, usually email only says "发送", not "邮寄".
> 
> > 	post, polysemes
> > 
> > 23.
> > (2) there is no shortage of people with grand plans and little code (or 
> > even prospect of code) to back them up
> > -反应。可悲的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划和很少
> > -代码（甚至代码前景）支持他们的人；（3）没有人有义务审查或评论别人发表的
> > +反馈。令人伤心的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划但
> > +代码（甚至代码设想）很少的人去支持他们；（3）没有人有义务审查或评论别人发表
> 
> more context?
only need to read (2)

One discouraging thing which can happen at this stage is not a hostile
reaction, but, instead, little or no reaction at all.  The sad truth of the
matter is (1) kernel developers tend to be busy, (2) there is no shortage
of people with grand plans and little code (or even prospect of code) to
back them up, and (3) nobody is obligated to review or comment on ideas
posted by others.  Beyond that, high-level designs often hide problems
which are only revealed when somebody actually tries to implement those
designs; for that reason, kernel developers would rather see the code.
> 
> > 
> > [Patch 5/5]
> > 24.
> > Then the focus will shift toward doing things right and the tools which can 
> > help in that quest.
> > -到正确的事情和可以帮助这个任务的工具上。
> > +到正确的做法和相关实用工具上。
> 
> more context?
> 
> > 	paraphrase
> > 
> > 25.
> > Coding style
> > -编码风格
> > +代码风格
> > 	Idiomatic words, also 代码规范
> 
> Nope, didn't see much idiomatic for word coding. and code is different from
> coding.
See linux/Documentation/translations/zh_CN/process/coding-style.rst,
the title is "代码风格"
> 
> > 
> > 26.
> > ... two independent hazards for kernel developers.
> > The first of these is to believe that the kernel coding standards do not
> > matter and are not enforced. 
> > -首先，要相信内核编码标准并不重要，也不强制执行。事实上，如果没有按照标准对代
> > +首先是错误相信内核代码标准并不重要，也不强制执行。但事实上，如果没有按照标准
> > 	The meaning is totally wrong
> 
> Nope, fidelity.
Please read the original document *carefully*. 
The meaning of the translation here is completely wrong, even contrary.
The fidelity is clearly not appropriate here.
==
As a result, there is a substantial amount of code in the kernel
which does not meet the coding style guidelines.  The presence of that code
leads to two independent hazards for kernel developers.

The first of these is to believe that the kernel coding standards do not
matter and are not enforced.  The truth of the matter is that adding new
code to the kernel is very difficult if that code is not coded according to
the standard; many developers will request that the code be reformatted
before they will even review it.  A code base as large as the kernel
requires some uniformity of code to make it possible for developers to
quickly understand any part of it.  So there is no longer room for
strangely-formatted code.

> 
> > 
> > 27.
> > sorting ``#includes``, for aligning variables/macros, for reflowing text 
                                                              ^
> > and other similar tasks
> > -可以方便地进行排序，包括对齐变量/宏、回流文本和其他类似任务。有关详细信息，请
                                          ^
> > +可以方便地排序 ``#includes`` 、对齐变量/宏、重排文本和其他类似任务。有关详细
                                                 ^
> > 	reflowing text
> 
> more context?
Only one word.
==
Note that you can also use the ``clang-format`` tool to help you with
these rules, to quickly re-format parts of your code automatically,
and to review full files in order to spot coding style mistakes,
typos and possible improvements. It is also handy for sorting ``#includes``,
for aligning variables/macros, for reflowing text and other similar tasks.
See the file :ref:`Documentation/process/clang-format.rst <clangformat>`
for more details.

> 
> > 
> > 28.
> > Regressions
> > -回归
> > +回退
> > 	"Regression" as a software term can be translated to "回归", but "回归" 
> > 	often refers to the mathematical name or belonging state, and we also
> > 	use "回归测试" as "regression test". 
> > 	Besides, there is also "rollback" but rollback is obviously different 
> > 	from regression, so we can't use "回滚". 
> > 	So, which word should we use to translate the proper term for kernel 
> > 	error, "回退" or just use "回归" ?
> 
> 'regression' here has same meaningful with 'regression test'. better no change.
Ok. 

Thanks!
Wu X.C.
>
> >>> difficult for native speakers to understand. Many errors are caused by 
> >>> machine translation without manual correction.
> >>>
> >>> This set of patchs aims to fix the above problems and synchronize them with
> >>> original files. Some structure modifications need to rewrite the whole 
> >>> sentences, so here are a lot of changes.
> >>>
> >>> Wu XiangCheng (5):
> >>>   docs/zh_CN: Improve zh_CN/process/index.rst
> >>>   docs/zh_CN: Improve zh_CN/process/1.Intro.rst
> >>>   docs/zh_CN: Improve zh_CN/process/2.Process.rst
> >>>   docs/zh_CN: Improve zh_CN/process/3.Early-stage.rst
> >>>   docs/zh_CN: Improve zh_CN/process/4.Coding.rst
> >>>
> >>>  .../translations/zh_CN/process/1.Intro.rst    | 146 ++++-----
> >>>  .../translations/zh_CN/process/2.Process.rst  | 296 +++++++++---------
> >>>  .../zh_CN/process/3.Early-stage.rst           | 120 +++----
> >>>  .../translations/zh_CN/process/4.Coding.rst   | 251 ++++++++-------
> >>>  .../translations/zh_CN/process/index.rst      |  10 +-
> >>>  5 files changed, 412 insertions(+), 411 deletions(-)
> >>>

Re: [PATCH 0/5] docs/zh_CN: Improve language in zh_CN/process/

[Alex Shi]

在 2021/2/20 下午5:30, Wu X.C. 写道:
> On Sat, Feb 20, 2021 at 03:21:04PM +0800, Alex Shi wrote:
>>
>>
>> 在 2021/2/19 下午5:09, Wu X.C. 写道:
<snip>

>>> It's up to you to point out what you don't think is appropriate, we can 
>>> change that. Like 'work' also can be translated as '工作起来', '起作用' etc.
>>>
>>
>> Nope, work never have meaning of fluency. There is a standard in Chinese-English
>> translation industry： 信，达，雅， it is fidelity, fluency, elegance in English.
>> Let's not change the original meaning. At last we should hang on the fidelity
>> and then try fluency and elegance.
> Yeah. But fidelity could not solve all problems, sometimes, word by word 
> translation make the sentences and names incomprehensible and very strange.
> For Chinese, one need to eat the texts, chew them up, and then spit them out.
> If the mean is incomprehensible, then the translation is meaningless.
> Especially (26.) 

May you have some misunderstanding on 'fidelity', it means faithful on the original
meaning, not the word by word translation. 
And still didn't see 'work' has this meaning of 'fluency' here.


>>
>>>
>>> 5. 
>>> Developers are cautioned against assuming that the job is done...
>>> -开发人员要注意不要假定任务已经完成。
>>> +开发人员要注意不要认为任务已经完成。
>                        ^
>>
>> Nope, don't see the reason.
> 更改一下习惯用词。

May we don't bother to change, if new words aren't clearly better than old one, 
otherwise we may get busy on changes without much benefits.

>>> 	Hard to understand
>>>
>>> 9.
>>> (such as code which derives from reverse-engineering efforts lacking
>>> proper safeguards) 
>>> -相关问题的代码（例如，由缺乏适当保护的反向工程工作派生的代码）不能被接受。
>>> +内核造成版权相关问题的代码（例如，由缺乏适当保护的逆向工程工作派生的代码）
>>
>> Nope, 反向工程 is used a lot.
> See，
> 《计算机科学技术名词 (第三版)》
> 规范用词：逆向工程
> 英语名：  reverse engineering
> 台湾名：  反向工程
> 定义：    通过分析软件系统后期制品，获取更高抽象度的前期模型的过程。
>           是软件开发周期的反向过程。
> 学科： 	  计算机科学技术_软件工程
> 公布年度：2018
>   ——全国科学技术名词审定委员会

search google online, I got "About 7,820,000 results (0.31 seconds)"
for 逆向工程， and "About 64,900,000 results (0.33 seconds)" for 反向工程.
Clearly the latter used more common.
Let's pay more attention on interesting thing first. :) 

>>> 11.
>>> in order to be an effective part of it.
>>> -进来，内核因此必须发展许多流程来保持开发的顺利进行。要成为流程的有效组成
>>> +内核因此必须发展出许多既定流程来保证开发的顺利进行。要参与到流程中来，
>>
>> could you give more context here, can't judge for pieces of words.
> （某人）要成为流程的有效组成部分
> （某人）要参与到流程中来
> Clear?

ok.

>>
>>>
>>
>> don't see reasons except the MMOTM change.
> 译文中满地都是直译“沮丧的体验”，太难受了，换个词表述

ok.

>>
>>> 	paraphrase
>>>
>>> 16.
>>> The TODO file lists the pending work that the driver needs for 
>>> acceptance into the kernel proper
>>> -目录中还应该有一个TODO文件。todo文件列出了驱动程序需要接受的挂起的工作，
>>> +目录中还应该有一个TODO文件。TODO文件列出了驱动程序即将进行的工作，
>>
>> nope for fidelity.
> What is "挂起的工作" ? Need a better word to change that.

暂停的工作？

>>>
>>> 18.
>>> the amount of noise is high
>>> -每天的信息量可以达到500条，噪音很高，谈话技术性很强，参与者并不总是表现出
>>> +每天的信息量可以达到500条，非常热闹，谈话技术性很强，且参与者并不总是表现出
>>> 	"noise" actually is "热闹"、"干扰"
>>
>> Nope, fidelity issue. and noise has much more meaning than it's in
>> dictionary.
> Please explain the extra meaning, otherwise double quotes are required.

Someone 'make some noise' doesn't mean he/she's work is useless, it could
be a praise with a bit jealous. 'noise' here is a kind of modest, not 
meaning these emails are useless or annonying.

>>
>>>
>>>
>>> 20.
>>> and ongoing latency reduction work in the long term.
>                                   ^
>>> -机制进行实时调度访问，以及长期的减少延迟的工作。
>                                                ^
>>> +机制进行实时调度访问，以及长期的减少延迟的改进。
>

no much improvement, let's keep the old one.
>
>>>
>>> 21.
>>> has caused Reiser4 to stay out of the mainline kernel.
>>> -   导致Reiser4远离了主线内核。
>>> +   导致Reiser4无法进入主线内核。
>>
>> Reiser4 is in kernel now?
> I don't know, or change to 导致Reiser4置身主线内核之外。
>>
>>> 	paraphrase
>>>
>>> 22.
>>> When to post?
>>> -何时邮寄？
>>> +何时发布？
>>
>> Nope, 邮寄 is more common words for continue patches resending.
> ?
> This chapter aims to post your early plan to community, not only the patch.
> Even if it's a patch, usually email only says "发送", not "邮寄".

'post' may a trandtion usage here. If you use a English email client, you will
find a button name 'send' not 'post'. That's different word.

This word do bother me at first time. it used with a English prof's suggestion.

>>
>>> 	post, polysemes
>>>
>>> 23.
>>> (2) there is no shortage of people with grand plans and little code (or 
>>> even prospect of code) to back them up
>>> -反应。可悲的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划和很少
>>> -代码（甚至代码前景）支持他们的人；（3）没有人有义务审查或评论别人发表的
>>> +反馈。令人伤心的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划但
>>> +代码（甚至代码设想）很少的人去支持他们；（3）没有人有义务审查或评论别人发表

the 2nd item could be better. but seems no much improvement yet.

>>
>> more context?
> only need to read (2)
> 
> One discouraging thing which can happen at this stage is not a hostile
> reaction, but, instead, little or no reaction at all.  The sad truth of the
> matter is (1) kernel developers tend to be busy, (2) there is no shortage
> of people with grand plans and little code (or even prospect of code) to
> back them up, and (3) nobody is obligated to review or comment on ideas
> posted by others.  Beyond that, high-level designs often hide problems
> which are only revealed when somebody actually tries to implement those
> designs; for that reason, kernel developers would rather see the code.
>>
>>>
>>> [Patch 5/5]
>>> 24.
>>> Then the focus will shift toward doing things right and the tools which can 
>>> help in that quest.
>>> -到正确的事情和可以帮助这个任务的工具上。
>>> +到正确的做法和相关实用工具上。
>>
>> more context?
>>
>>> 	paraphrase
>>>
>>> 25.
>>> Coding style
>>> -编码风格
>>> +代码风格
>>> 	Idiomatic words, also 代码规范
>>
>> Nope, didn't see much idiomatic for word coding. and code is different from
>> coding.
> See linux/Documentation/translations/zh_CN/process/coding-style.rst,
> the title is "代码风格"

ok.

>>
>>>
>>> 26.
>>> ... two independent hazards for kernel developers.
>>> The first of these is to believe that the kernel coding standards do not
>>> matter and are not enforced. 
>>> -首先，要相信内核编码标准并不重要，也不强制执行。事实上，如果没有按照标准对代
>>> +首先是错误相信内核代码标准并不重要，也不强制执行。但事实上，如果没有按照标准
>>> 	The meaning is totally wrong
>>
>> Nope, fidelity.
> Please read the original document *carefully*. 
> The meaning of the translation here is completely wrong, even contrary.
> The fidelity is clearly not appropriate here.

Uh, I hit the Murphy's Law here. and believe the English word may has the same
issue.  :)
According the context, reader should understood this action is incorrect, as
you already knew. Adding a word '错误/falsely' could make meaning more clear. 
but since the original doc doesn't do this.... 
Maybe another way could make it clear too? 

首先，相信内核编码标准并不重要，也不强制执行。但是事实上，如果没有按照标准对。。。

> ==
> As a result, there is a substantial amount of code in the kernel
> which does not meet the coding style guidelines.  The presence of that code
> leads to two independent hazards for kernel developers.
> 
> The first of these is to believe that the kernel coding standards do not
> matter and are not enforced.  The truth of the matter is that adding new
> code to the kernel is very difficult if that code is not coded according to
> the standard; many developers will request that the code be reformatted
> before they will even review it.  A code base as large as the kernel
> requires some uniformity of code to make it possible for developers to
> quickly understand any part of it.  So there is no longer room for
> strangely-formatted code.
> 
>>
>>>
>>> 27.
>>> sorting ``#includes``, for aligning variables/macros, for reflowing text 
>                                                               ^
>>> and other similar tasks
>>> -可以方便地进行排序，包括对齐变量/宏、回流文本和其他类似任务。有关详细信息，请
>                                           ^
>>> +可以方便地排序 ``#includes`` 、对齐变量/宏、重排文本和其他类似任务。有关详细
>                                                  ^
>>> 	reflowing text
>>
>> more context?
> Only one word.

I see. fine.

Thanks
Alex