Re: [PATCH v2] docs/zh_CN: Improve Cinese transolation quality.

[Alex Shi]

Reviewed-by: Alex Shi <alex.shi@xxxxxxxxxxxxxxxxx>


在 2020/12/8 下午9:16, Ran Wang 写道:
> Signed-off-by: Ran Wang <gxndwr@xxxxxxxxxxx>
> ---
> Change in v2:
>   - For 'cn_development_coding' part, change back to '是关于编码过程的'
> 
>  .../translations/zh_CN/process/1.Intro.rst    | 61 ++++++++++---------
>  1 file changed, 32 insertions(+), 29 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/process/1.Intro.rst b/Documentation/translations/zh_CN/process/1.Intro.rst
> index 10a15f3dc282..f05405d96c51 100644
> --- a/Documentation/translations/zh_CN/process/1.Intro.rst
> +++ b/Documentation/translations/zh_CN/process/1.Intro.rst
> @@ -11,33 +11,35 @@
>  执行摘要
>  --------
>  
> -本节的其余部分涵盖了内核开发过程的范围，以及开发人员及其雇主在这方面可能遇
> -到的各种挫折。内核代码应该合并到正式的（“主线”）内核中有很多原因，包括对用
> -户的自动可用性、多种形式的社区支持以及影响内核开发方向的能力。提供给Linux
> -内核的代码必须在与GPL兼容的许可证下可用。
> +本节的其余部分介绍了内核开发流程相关知识，其中包括开发者及其雇主在这方面可能遇
> +到的各种问题。内核代码合并到官方的（“主线”）仓库会有很多好处，比如能在第一时
> +间让用户获得更新，可以从社区得到多种形式的支持，以及能够以此影响内核未来发展方
> +向。需要注意提供给Linux内核的代码必须是在与GPL兼容的许可证下使用。
>  
> -:ref:`cn_development_process` 介绍了开发过程、内核发布周期和合并窗口的机制。
> -涵盖了补丁开发、审查和合并周期中的各个阶段。有一些关于工具和邮件列表的讨论。
> -鼓励希望开始内核开发的开发人员作为初始练习跟踪并修复bug。
> +: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` 介绍了两个“高级”主题：
> -使用Git管理补丁和查看其他人发布的补丁。
> +使用Git管理补丁和查看其他人提交的补丁。
>  
>  :ref:`cn_development_conclusion` 总结了有关内核开发的更多信息，附带有带有
>  指向资源的链接.
> @@ -62,19 +64,20 @@ Linux最引人注目的特性之一是这些开发人员可以访问它；任何
>  内核开发周期可以涉及1000多个开发人员，他们为100多个不同的公司
>  （或者根本没有公司）工作。
>  
> -与内核开发社区合作并不是特别困难。但是，尽管如此，许多潜在的贡献者在尝试做
> -内核工作时遇到了困难。内核社区已经发展了自己独特的操作方式，使其能够在每天
> -都要更改数千行代码的环境中顺利运行（并生成高质量的产品）。因此，Linux内核开发
> +与内核开发社区合作并不是特别困难。但是，尽管如此，许多潜在的贡献者在尝试参与
> +内核开发时遇到了困难。内核社区已经发展了自己独特的开发流程，使其能够在每天
> +都要更改数千行代码的环境中顺利运转（并生成高质量的产品）。因此，Linux内核开发
>  过程与专有的开发方法有很大的不同也就不足为奇了。
>  
> -对于新开发人员来说，内核的开发过程可能会让人感到奇怪和恐惧，但这个背后有充分的
> -理由和坚实的经验。一个不了解内核社区的方式的开发人员（或者更糟的是，他们试图
> -抛弃或规避内核社区的方式）会有一个令人沮丧的体验。开发社区, 在帮助那些试图学习
> -的人的同时，没有时间帮助那些不愿意倾听或不关心开发过程的人。
> +对于新开发者来说，内核的开发流程可能会让人感到陌生和望而生畏，但这个背后其实
> +是有充分的理由和坚实的实际经验作支撑。一个不了解内核社区工作方式的开发者（或
> +者更糟的是，如果他们试图抛弃或规避内核社区的方式）将会有一个令人沮丧的体验。
> +毕竟开发社区在帮助那些试图学习的人的同时，没有时间帮助那些不愿意倾听或不关心
> +开发流程的人。
>  
> -希望阅读本文的人能够避免这种令人沮丧的经历。这里有很多材料，但阅读时所做的
> -努力会在短时间内得到回报。开发社区总是需要能让内核变更好的开发人员；下面的
> -文本应该帮助您或为您工作的人员加入我们的社区。
> +希望大家能通过阅读本文来避免那些令人沮丧的经历。这里有很多材料，请相信阅读这
> +些所付出的努力将会在短时间内得到回报。开发社区总是需要那些能让内核变更好的
> +开发者；下面的文章应当能帮助您或为您工作的人加入我们的社区。
>  
>  致谢
>  ----
>