Deploying to gh-pages from @ Klipper3d/klipper@434770eaf9 🚀

zh/CONTRIBUTING.html

@@ -1447,7 +1447,8 @@
 <p>审核员通常会检查这些：</p>
 <ol>
 <li>
-<p>提交是否没有缺陷，是否准备好广泛部署？提交者应在提交之前测试其更改。审核员会查找提交中的错误，但通常不会测试提交的实际内容。接受的提交通常会在被接受后的几周内部署到数千台打印机。因此，提交的质量极为重要。</p>
+<p>提交是否没有缺陷，是否准备好广泛部署？</p>
+<p>提交者应在提交之前测试其更改。审核员会查找提交中的错误，但通常不会测试提交的实际内容。接受的提交通常会在被接受后的几周内部署到数千台打印机。因此，提交的质量极为重要。</p>
 <p>主<a href="https://github.com/Klipper3d/klipper">Klipper3d/klipper</a> GitHub仓库不接受实验性代码。提交者应该在他们自己的仓库中进行实验、调试和测试。<a href="Contact.html">Klipper Discourse</a>论坛可以帮助你找到其他有兴趣的开发者和可以提供真实世界反馈的用户，或者让更多人了解你的工作。</p>
 <p>提交必须通过所有<a href="Debugging.html">回归测试用例</a>。</p>
 <p>在修复代码中的缺陷时，提交者应该对该缺陷的根本原因有一个大致的了解，并且修复应该针对该根本原因。</p>
@@ -1456,7 +1457,8 @@
 <p>对文件的更新不应该声明它们是一项正在进行的工作。</p>
 </li>
 <li>
-<p>提交的文件是否为执行真实世界任务的用户提供了 "高影响力"的改进？评审员需要确定，至少在他们自己的脑海中，大致的"目标受众"，"受众的规模"，受众将获得的"利益"，“如何衡量利益"，以及”这些测试的结果“。在大多数情况下，这对提交者和评审者来说都是显而易见的，而且在评审过程不需要明确的说明。</p>
+<p>提交的文件是否为执行真实世界任务的用户提供了 "高影响力"的改进？</p>
+<p>评审员需要确定，至少在他们自己的脑海中，大致的"目标受众"，"受众的规模"，受众将获得的"利益"，“如何衡量利益"，以及”这些测试的结果“。在大多数情况下，这对提交者和评审者来说都是显而易见的，而且在评审过程不需要明确的说明。</p>
 <p>提交到Klipper主分支的代码应该有足够的目标受众。作为一般的经验法则，提交的内容应该针对至少100个用户的用户群体。</p>
 <p>如果审稿人询问有关提交可以带来的“好处”的细节，请不要将其视为批评。能够理解更改带来的实际好处是审查的一个自然部分。</p>
 <p>在讨论利益时，最好是讨论“事实和衡量标准”。一般而言，审查者不是在寻找“某人可能会发现选项X有用”形式的答复，也不是在寻找形式为“此提交增加了固件X实现的功能”的答复。相反，通常更可取的是讨论如何测量质量改进的细节以及这些测量的结果是什么--例如，“在Acme X1000打印机上的测试显示如图片所示的改善的角落……”，或者例如，“在Foom X900打印机上打印现实世界中的对象X的时间从4小时缩短到3.5小时”。可以理解，这种类型的测试可能会花费大量的时间和精力。Klipper的一些最重要的功能在合并到主分支之前，花了几个月的讨论、返工、测试和文档。</p>
@@ -1466,17 +1468,18 @@
 <p>新模块、新选项和新参数不应提供与现有模块类似的功能——如果差异是任意的，那么最好利用现有系统或重构现有代码。</p>
 </li>
 <li>
-<p>提交的版权是否清晰、无偿、兼容？新的 C 文件和 Python 文件应该有一个明确的版权声明。请看现有文件以了解推荐格式。不推荐在对现有文件进行小的修改时对该文件进行版权声明。</p>
+<p>提交的版权是否清晰、无偿、兼容？</p>
+<p>新的 C 文件和 Python 文件应该有一个明确的版权声明。请看现有文件以了解推荐格式。不推荐在对现有文件进行小的修改时对该文件进行版权声明。</p>
 <p>从第三方来源获取的代码必须与 Klipper 的许可证（GNU GPLv3）兼容。大型的第三方代码添加应被添加到<code>lib/</code>目录中（并遵循<a href="https://github.com/Klipper3d/klipper/blob/master/lib/README">../lib/README</a>中描述的格式）。</p>
 <p>提交者必须提供一个<a href="#format-of-commit-messages">Signed-off-by 行</a>，使用他们的真实全名。它表明提交者同意<a href="developer-certificate-of-origin">开发者源头证书</a>。</p>
 </li>
 <li>
-<p>提交的文件是否遵循 Klipper 文件中规定的准则？特别是，代码应遵循 <Code_Overview.md> 中的准则，配置文件应遵循 <Example_Configs.md> 中的准则。</p>
+<p>提交的文件是否遵循 Klipper 文件中规定的准则？</p>
+<p>特别是，代码应遵循 <Code_Overview.md> 中的准则，配置文件应遵循 <Example_Configs.md> 中的准则。</p>
 </li>
 <li>
-<p>Klipper 文档是否已更新以反映新的更改？至少，参考文件必须随着代码的相应变化而更新：</p>
-</li>
-</ol>
+<p>Klipper 文档是否已更新以反映新的更改？</p>
+<p>至少，参考文件必须随着代码的相应变化而更新：</p>
 <ul>
 <li>所有命令和命令参数必须在 <G-Code.md> 中被描述。</li>
 <li>所有面向用户的模块及其配置参数必须在<Config_Reference.md>中记录。</li>
@@ -1484,10 +1487,13 @@
 <li>所有新的 "webhooks "及其参数必须在<API_Server.md>中描述。</li>
 <li>任何对命令或配置文件设置导致无法向后兼容的改变，都必须在<Config_Changes.md>中进行说明。</li>
 </ul>
+</li>
+</ol>
 <p>新的文件应该被添加到<Overview.md>中，并被添加到网站索引<a href="https://github.com/Klipper3d/klipper/blob/master/docs/_klipper3d/mkdocs.yml">docs/_klipper3d/mkdocs.yml</a>。</p>
 <ol>
 <li>
-<p>提交的内容是否完整，每次提交只涉及一个主题，并且是独立的？提交信息应遵循<a href="#format-of-commit-messages">首选格式</a>。</p>
+<p>提交的内容是否完整，每次提交只涉及一个主题，并且是独立的？</p>
+<p>提交信息应遵循<a href="#format-of-commit-messages">首选格式</a>。</p>
 <p>提交的内容不能有合并冲突。对 Klipper 主分支的新添加总是通过 "rebase "或 "squash and rebase "完成。一般来说，提交者没有必要在每次更新Klipper主库的时候重新合并他们的提交。然而，如果有合并冲突，建议提交者使用<code>git rebase</code>来解决冲突。</p>
 <p>每一次提交都应该解决一个高层的变化。大的改动应该被分解成多个独立的提交。每个提交都应该 "自成一体"，这样才能让<code>git bisect</code>和<code>git revert</code>等工具可靠地工作。</p>
 <p>空格的修改不应该与功能修改混在一起。一般来说，无意义的空格修改是不被接受的，除非是来自被修改代码的既定 "所有者"。</p>