Deploying to gh-pages from @ Klipper3d/klipper@f3b995227a 🚀

zh-Hant/CONTRIBUTING.html

@@ -1355,7 +1355,7 @@
 <p>提交的檔案是否為執行真實世界任務的真實世界使用者提供了 "高度影響"的好處？審閱人仕需要至少在自己的腦海中確定大致的“目標受眾是誰”、“受眾規模”的粗略尺度、他們將獲得的“好處”、“好處是如何衡量的”，以及“這些測量測試的結果”。在大多數情況下，這對於提交者和審閱者來說都是顯而易見的，並且在審閱期間沒有明確說明。</p>
 <p>向 Klipper 主分支提交的內容預計會有值得注意的目標受眾。作為一般的“經驗法則”，提交內容應針對至少 100 個真實用戶的用戶群。</p>
 <p>If a reviewer asks for details on the "benefit" of a submission, please don't consider it criticism. Being able to understand the real-world benefits of a change is a natural part of a review.</p>
-<p>在討論好處時，最好討論“事實和測量”而不是“觀點和理論”。一般來說，審閱人仕不會尋找“此提交可能會因為……而提高質量”形式的回复，也不會尋找“有人可能會發現選項 X 有用”形式的回复，也不會尋找以下回复表單“此提交添加了固件 X 實現的功能”。相反，通常最好討論如何衡量質量改進的細節以及這些測量的結果 - 例如，“Acme X1000 打印機上的測試顯示改進的角落，如圖所示......”，或例如“在 Foomatic X900 打印機上打印真實世界對象 X 的時間從 4 小時變為 3.5 小時”。可以理解，這種類型的測試可能需要大量的時間和精力。在合併到主分支之前，Klipper 的一些最顯著的功能經過多年的討論、返工、測試和文檔編制。</p>
+<p>When discussing benefits it is preferable to discuss "facts and measurements". In general, reviewers are not looking for responses of the form "someone may find option X useful", nor are they looking for responses of the form "this submission adds a feature that firmware X implements". Instead, it is generally preferable to discuss details on how the quality improvement was measured and what were the results of those measurements - for example, "tests on Acme X1000 printers show improved corners as seen in picture ...", or for example "print time of real-world object X on a Foomatic X900 printer went from 4 hours to 3.5 hours". It is understood that testing of this type can take significant time and effort. Some of Klipper's most notable features took months of discussion, rework, testing, and documentation prior to being merged into the master branch.</p>
 <p>所有新模塊、配置選項、命令、命令參數和文檔都應該具有“高影響”。我們不想讓用戶負擔他們無法合理配置的選項，也不想讓他們負擔不提供顯著好處的選項。</p>
 <p>審閱者可能會要求澄清用戶如何配置選項 - 理想的回復將包含有關過程的詳細信息 - 例如，“MegaX500 的用戶預計將選項 X 設置為 99.3，而 Elite100Y 的用戶預計將使用程序校準選項 X ..."。</p>
 <p>如果選項的目標是使代碼更加模塊化，那麼更喜歡使用代碼常量而不是面向用戶的配置選項。</p>