* [PATCH v3 01/16] docs/zh_TW: process: localize terminology in 7.AdvancedTopics.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 02/16] docs/zh_TW: process: localize terminology in 1.Intro.rst Chen-Yu Yeh
` (15 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 軟件→軟體,
高級→進階, 項目→專案, 用戶→使用者, ...) and sync with the English
original (Github → GitHub).
update to commit 5ce70894f6ca ("Doc: correct spelling and wording
mistakes")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../zh_TW/process/7.AdvancedTopics.rst | 110 +++++++++---------
1 file changed, 56 insertions(+), 54 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
index b449d67e3ad9..8090d482c4b0 100644
--- a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
@@ -12,28 +12,29 @@
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
.. _tw_development_advancedtopics:
-高級主題
+進階主題
========
現在，希望您能夠掌握開發流程的工作方式。然而，還有更多的東西要學！本節將介紹
-一些主題，這些主題對希望成爲Linux內核開發過程常規部分的開發人員有幫助。
+一些主題，這些主題對希望成為Linux核心開發過程常規部分的開發人員有幫助。
使用Git管理補丁
---------------
-內核使用分佈式版本控制始於2002年初，當時Linus首次開始使用專有的Bitkeeper應用
-程序。雖然BitKeeper存在爭議，但它所體現的軟件版本管理方法卻肯定不是。分佈式
-版本控制可以立即加速內核開發項目。現在有好幾種免費的BitKeeper替代品。
-但無論好壞，內核項目都已經選擇了Git作爲其工具。
+核心使用分散式版本控制始於2002年初，當時Linus首次開始使用專有的Bitkeeper應用
+程式。雖然BitKeeper存在爭議，但它所體現的軟體版本管理方法卻肯定不是。分散式
+版本控制可以立即加速核心開發專案。現在有好幾種自由的BitKeeper替代品。
+但無論好壞，核心專案都已經選擇了Git作為其工具。
-使用Git管理補丁可以使開發人員的生活更加輕鬆，尤其是隨着補丁數量的增長。Git也
+使用Git管理補丁可以使開發人員的生活更加輕鬆，尤其是隨著補丁數量的增長。Git也
有其粗糙的邊角和一定的危險性，它是一個年輕和強大的工具，仍然在其開發人員完善
-中。本文檔不會試圖教會讀者如何使用git；這會是個巨長的文檔。相反，這裏的重點
-將是Git如何特別適合內核開發過程。想要加快用Git速度的開發人員可以在以下網站上
-找到更多信息：
+中。本文件不會試圖教會讀者如何使用git；這會是個巨長的文件。相反，這裡的重點
+將是Git如何特別適合核心開發過程。想要加快用Git速度的開發人員可以在以下網站上
+找到更多資訊：
https://git-scm.com/
@@ -41,44 +42,44 @@
同時網上也能找到各種各樣的教程。
-在嘗試使用它生成補丁供他人使用之前，第一要務是閱讀上述網頁，對Git的工作方式
-有一個紮實的瞭解。使用Git的開發人員應能進行拉取主線存儲庫的副本，查詢修訂
+在嘗試使用它產生補丁供他人使用之前，第一要務是閱讀上述網頁，對Git的工作方式
+有一個紮實的瞭解。使用Git的開發人員應能進行拉取主線儲存庫的副本，查詢修訂
歷史，提交對樹的更改，使用分支等操作。瞭解Git用於重寫歷史的工具（如rebase）
-也很有用。Git有自己的術語和概念；Git的新用戶應該瞭解引用、遠程分支、索引、
-快進合併、推拉、遊離頭等。一開始可能有點嚇人，但這些概念不難通過一點學習來
+也很有用。Git有自己的術語和概念；Git的新使用者應該瞭解引用、遠端分支、索引、
+快進合併、推拉、遊離頭等。一開始可能有點嚇人，但這些概念不難透過一點學習來
理解。
-使用git生成通過電子郵件提交的補丁是提高速度的一個很好的練習。
+使用git產生透過電子郵件提交的補丁是提高速度的一個很好的練習。
-當您準備好開始建立Git樹供其他人查看時，無疑需要一個可以從中拉取的服務器。
-如果您有一個可以訪問因特網的系統，那麼使用git-daemon設置這樣的服務器相對
-簡單。同時，免費的公共託管網站（例如github）也開始出現在網絡上。成熟的開發
-人員可以在kernel.org上獲得一個帳戶，但這些帳戶並不容易得到；更多有關信息，
+當您準備好開始建立Git樹供其他人查看時，無疑需要一個可以從中拉取的伺服器。
+如果您有一個可以連上網際網路的系統，那麼使用git-daemon設定這樣的伺服器相對
+簡單。同時，免費的公共託管網站（例如GitHub）也開始出現在網路上。成熟的開發
+人員可以在kernel.org上獲得一個帳戶，但這些帳戶並不容易得到；更多有關資訊，
請參閱 https://kernel.org/faq/ 。
-正常的Git工作流程涉及到許多分支的使用。每一條開發線都可以分爲單獨的“主題
+正常的Git工作流程涉及到許多分支的使用。每一條開發線都可以分為單獨的“主題
分支”，並獨立維護。Git的分支很容易使用，沒有理由不使用它們。而且，在任何
情況下，您都不應該在任何您打算讓其他人從中拉取的分支中進行開發。應該小心地
-創建公開可用的分支；當開發分支處於完整狀態並已準備好時(而不是之前）才合併
+建立公開可用的分支；當開發分支處於完整狀態並已準備好時(而不是之前）才合併
開發分支的補丁。
Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不方便的補丁（比如說，
一個打破二分法的補丁，或者有其他一些明顯的缺陷）可以在適當的位置修復，或者
完全從歷史中消失。一個補丁系列可以被重寫，就好像它是在今天的主線上寫的一樣，
即使你已經花了幾個月的時間在寫它。可以透明地將更改從一個分支轉移到另一個
-分支。等等。明智地使用git修改歷史的能力可以幫助創建問題更少的乾淨補丁集。
+分支。等等。明智地使用git修改歷史的能力可以幫助建立問題更少的乾淨補丁集。
-然而，過度使用這種功能可能會導致其他問題，而不僅僅是對創建完美項目歷史的
-簡單癡迷。重寫歷史將重寫該歷史中包含的更改，將經過測試（希望如此）的內核樹
-變爲未經測試的內核樹。除此之外，如果開發人員沒有共享項目歷史，他們就無法
-輕鬆地協作；如果您重寫了其他開發人員拉入他們存儲庫的歷史，您將使這些開發
-人員的生活更加困難。因此，這裏有一個簡單的經驗法則：被導出到其他地方的歷史
-在此後通常被認爲是不可變的。
+然而，過度使用這種功能可能會導致其他問題，而不僅僅是對建立完美專案歷史的
+簡單癡迷。重寫歷史將重寫該歷史中包含的更改，將經過測試（希望如此）的核心樹
+變為未經測試的核心樹。除此之外，如果開發人員沒有共享專案歷史，他們就無法
+輕鬆地協作；如果您重寫了其他開發人員拉入他們儲存庫的歷史，您將使這些開發
+人員的生活更加困難。因此，這裡有一個簡單的經驗法則：被導出到其他地方的歷史
+在此後通常被認為是不可變的。
-因此，一旦將一組更改推送到公開可用的服務器上，就不應該重寫這些更改。如果您
+因此，一旦將一組更改推送到公開可用的伺服器上，就不應該重寫這些更改。如果您
嘗試強制進行無法快進合併的更改（即不共享同一歷史記錄的更改），Git將嘗試強制
執行此規則。這可能覆蓋檢查，有時甚至需要重寫導出的樹。在樹之間移動變更集以
-避免linux-next中的衝突就是一個例子。但這種行爲應該是罕見的。這就是爲什麼
+避免linux-next中的衝突就是一個例子。但這種行為應該是罕見的。這就是為什麼
開發應該在私有分支中進行（必要時可以重寫）並且只有在公共分支處於合理的較新
狀態時才轉移到公共分支中的原因之一。
@@ -86,52 +87,53 @@ Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不
對於一個私有的分支，rebasing 可能是一個很容易跟上另一棵樹的方法，但是一旦
一棵樹被導出到外界，rebasing就不可取了。一旦發生這種情況，就必須進行完全
合併（merge）。合併有時是很有意義的，但是過於頻繁的合併會不必要地擾亂歷史。
-在這種情況下建議的做法是不要頻繁合併，通常只在特定的發佈點（如主線-rc發佈）
+在這種情況下建議的做法是不要頻繁合併，通常只在特定的發布點（如主線-rc發布）
合併。如果您對特定的更改感到緊張，則可以始終在私有分支中執行測試合併。在
這種情況下，git“rerere”工具很有用；它能記住合併衝突是如何解決的，這樣您
就不必重複相同的工作。
-關於Git這樣的工具的一個最大的反覆抱怨是：補丁從一個存儲庫到另一個存儲庫的
+關於Git這樣的工具的一個最大的反覆抱怨是：補丁從一個儲存庫到另一個儲存庫的
大量移動使得很容易陷入錯誤建議的變更中，這些變更避開審查雷達進入主線。當內
核開發人員看到這種情況發生時，他們往往會感到不高興；在Git樹上放置未審閱或
主題外的補丁可能會影響您將來讓樹被拉取的能力。引用Linus的話:
::
- 你可以給我發補丁，但當我從你那裏拉取一個Git補丁時，我需要知道你清楚
+ 你可以給我發補丁，但當我從你那裡拉取一個Git補丁時，我需要知道你清楚
自己在做什麼，我需要能夠相信事情而 *無需* 手動檢查每個單獨的更改。
（http://lwn.net/Articles/224135/）。
-爲了避免這種情況，請確保給定分支中的所有補丁都與相關主題緊密相關；“驅動程序
-修復”分支不應更改核心內存管理代碼。而且，最重要的是，不要使用Git樹來繞過
-審查過程。不時的將樹的摘要發佈到相關的列表中，在合適時候請求linux-next中
+為了避免這種情況，請確保給定分支中的所有補丁都與相關主題緊密相關；“驅動程式
+修復”分支不應更改核心記憶體管理程式碼。而且，最重要的是，不要使用Git樹來繞過
+審查過程。不時的將樹的摘要發布到相關的列表中，在合適時候請求linux-next中
包含該樹。
如果其他人開始發送補丁以包含到您的樹中，不要忘記審閱它們。還要確保您維護正確
-的作者信息； git “am”工具在這方面做得最好，但是如果補丁通過第三方轉發給您，
+的作者資訊； git “am”工具在這方面做得最好，但是如果補丁透過第三方轉發給您，
您可能需要在補丁中添加“From:”行。
-請求拉取時，請務必提供所有相關信息：樹的位置、要拉取的分支以及拉取將導致的
+請求拉取時，請務必提供所有相關資訊：樹的位置、要拉取的分支以及拉取將導致的
更改。在這方面 git request-pull 命令非常有用；它將按照其他開發人員所期望的
-格式化請求，並檢查以確保您已記得將這些更改推送到公共服務器。
+格式化請求，並檢查以確保您已記得將這些更改推送到公共伺服器。
審閱補丁
--------
-一些讀者顯然會反對將本節與“高級主題”放在一起，因爲即使是剛開始的內核開發人員
-也應該審閱補丁。當然，沒有比查看其他人發佈的代碼更好的方法來學習如何在內核環境
-中編程了。此外，審閱者永遠供不應求；通過審閱代碼，您可以對整個流程做出重大貢獻。
-
-審查代碼可能是一副令人生畏的圖景，特別是對一個新的內核開發人員來說，他們
-可能會對公開詢問代碼感到緊張，而這些代碼是由那些有更多經驗的人發佈的。不過，
-即使是最有經驗的開發人員編寫的代碼也可以得到改進。也許對（所有）審閱者最好
-的建議是：把審閱評論當成問題而不是批評。詢問“在這條路徑中如何釋放鎖？”
-總是比說“這裏的鎖是錯誤的”更好。
-
-不同的開發人員將從不同的角度審查代碼。部分人會主要關注代碼風格以及代碼行是
-否有尾隨空格。其他人會主要關注補丁作爲一個整體實現的變更是否對內核有好處。
-同時也有人會檢查是否存在鎖問題、堆棧使用過度、可能的安全問題、在其他地方
-發現的代碼重複、足夠的文檔、對性能的不利影響、用戶空間ABI更改等。所有類型
-的檢查，只要它們能引導更好的代碼進入內核，都是受歡迎和值得的。
+一些讀者顯然會反對將本節與“進階主題”放在一起，因為即使是剛開始的核心開發人
+員也應該審閱補丁。當然，沒有比查看其他人發布的程式碼更好的方法來學習如何在
+核心環境中撰寫程式了。此外，審閱者永遠供不應求；透過審閱程式碼，您可以對整
+個流程做出重大貢獻。
+
+審查程式碼可能是一副令人生畏的圖景，特別是對一個新的核心開發人員來說，他們
+可能會對公開詢問程式碼感到緊張，而這些程式碼是由那些有更多經驗的人發布的。
+不過，即使是最有經驗的開發人員編寫的程式碼也可以得到改進。也許對（所有）審
+閱者最好的建議是：把審閱評論當成問題而不是批評。詢問“在這條路徑中如何釋放
+鎖？”總是比說“這裡的鎖是錯誤的”更好。
+
+不同的開發人員將從不同的角度審查程式碼。部分人會主要關注程式碼風格以及程式
+碼行是否有尾隨空格。其他人會主要關注補丁作為一個整體實作的變更是否對核心有
+好處。同時也有人會檢查是否存在鎖問題、堆疊使用過度、可能的安全問題、在其他
+地方發現的程式碼重複、足夠的文件、對效能的不利影響、使用者空間ABI更改等。
+所有類型的檢查，只要它們能引導更好的程式碼進入核心，都是受歡迎和值得的。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 02/16] docs/zh_TW: process: localize terminology in 1.Intro.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 01/16] docs/zh_TW: process: localize terminology in 7.AdvancedTopics.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 03/16] docs/zh_TW: process: localize terminology in code-of-conduct-interpretation.rst Chen-Yu Yeh
` (14 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 軟件→軟體,
免費軟件→自由軟體, 操作系統→作業系統, 模塊→模組, 社區→社群, ...) and
sync with the English original: contributor identity wording now
follows commit 43e9076a00b1 ("docs: Fix conflicting contributor
identity info").
update to commit 5ce70894f6ca ("Doc: correct spelling and wording
mistakes")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../translations/zh_TW/process/1.Intro.rst | 235 +++++++++---------
1 file changed, 120 insertions(+), 115 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/1.Intro.rst b/Documentation/translations/zh_TW/process/1.Intro.rst
index 345c4cbe9b55..2639ab99793f 100644
--- a/Documentation/translations/zh_TW/process/1.Intro.rst
+++ b/Documentation/translations/zh_TW/process/1.Intro.rst
@@ -12,6 +12,7 @@
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
.. _tw_development_process_intro:
@@ -21,179 +22,183 @@
內容提要
--------
-本節的其餘部分涵蓋了內核開發的過程，以及開發人員及其僱主在這方面可能遇到的
-各種問題。有很多原因使內核代碼應被合併到正式的（“主線”）內核中，包括對用戶
-的自動可用性、多種形式的社區支持以及影響內核開發方向的能力。提供給Linux內核
-的代碼必須在與GPL兼容的許可證下可用。
+本節的其餘部分涵蓋了核心開發的過程，以及開發人員及其僱主在這方面可能遇到的
+各種問題。有很多原因使核心程式碼應被合併到正式的（“主線”）核心中，包括對使用者
+的自動可用性、多種形式的社群支援以及影響核心開發方向的能力。提供給Linux核心
+的程式碼必須在與GPL相容的許可證下可用。
-:ref:`tw_development_process` 介紹了開發過程、內核發佈週期和合並窗口的機制。
-涵蓋了補丁開發、審查和合並週期中的各個階段。還有一些關於工具和郵件列表的討論？
-鼓勵希望開始內核開發的開發人員跟蹤並修復缺陷以作爲初步練習。
+:ref:`tw_development_process` 介紹了開發過程、核心發布週期和合併視窗的機制。
+涵蓋了補丁開發、審查和合併週期中的各個階段。還有一些關於工具和郵件列表的討論。
+鼓勵希望開始核心開發的開發人員追蹤並修復缺陷以作為初步練習。
-:ref:`tw_development_early_stage` 包括項目的早期規劃，重點是儘快讓開發社區
+:ref:`tw_development_early_stage` 包括專案的早期規劃，重點是儘快讓開發社群
參與進來。
-:ref:`tw_development_coding` 是關於編程過程的；介紹了其他開發人員遇到的幾個
-陷阱。也涵蓋了對補丁的一些要求，並且介紹了一些工具，這些工具有助於確保內核
+:ref:`tw_development_coding` 是關於程式設計過程的；介紹了其他開發人員遇到的幾個
+陷阱。也涵蓋了對補丁的一些要求，並且介紹了一些工具，這些工具有助於確保核心
補丁是正確的。
-:ref:`tw_development_posting` 描述發佈補丁以供評審的過程。爲了讓開發社區能
+:ref:`tw_development_posting` 描述發布補丁以供評審的過程。為了讓開發社群能
認真對待，補丁必須被正確格式化和描述，並且必須發送到正確的地方。遵循本節中的
建議有助於確保您的工作能被較好地接納。
-:ref:`tw_development_followthrough` 介紹了發佈補丁之後發生的事情；工作在這時
+:ref:`tw_development_followthrough` 介紹了發布補丁之後發生的事情；工作在這時
還遠遠沒有完成。與審閱者一起工作是開發過程中的一個重要部分；本節提供了一些
關於如何在這個重要階段避免問題的提示。當補丁被合併到主線中時，開發人員要注意
不要假定任務已經完成。
-:ref:`tw_development_advancedtopics` 介紹了兩個“高級”主題：使用Git管理補丁
-和查看其他人發佈的補丁。
+:ref:`tw_development_advancedtopics` 介紹了兩個“進階”主題：使用Git管理補丁
+和查看其他人發布的補丁。
-:ref:`tw_development_conclusion` 總結了有關內核開發的更多信息，附帶有相關資源
-鏈接。
+:ref:`tw_development_conclusion` 總結了有關核心開發的更多資訊，附帶有相關資源
+連結。
-這個文檔是關於什麼的
+這個文件是關於什麼的
--------------------
-Linux內核有超過800萬行代碼，每個版本的貢獻者超過1000人，是現存最大、最活躍的
-免費軟件項目之一。從1991年開始，這個內核已經發展成爲一個最好的操作系統組件，
-運行在袖珍數字音樂播放器、臺式電腦、現存最大的超級計算機以及所有類型的系統上。
-它是一種適用於幾乎任何情況的健壯、高效和可擴展的解決方案。
-
-隨着Linux的發展，希望參與其開發的開發人員（和公司）的數量也在增加。硬件供應商
-希望確保Linux能夠很好地支持他們的產品，使這些產品對Linux用戶具有吸引力。嵌入
-式系統供應商使用Linux作爲集成產品的組件，希望Linux能夠儘可能地勝任手頭的任務。
-分銷商和其他基於Linux的軟件供應商切實關心Linux內核的功能、性能和可靠性。最終
-用戶也常常希望修改Linux，使之能更好地滿足他們的需求。
-
-Linux最引人注目的特性之一是這些開發人員可以訪問它；任何具備必要技能的人都可以
-改進Linux並影響其開發方向。專有產品不能提供這種開放性，這是自由軟件的一個特點。
-如果有什麼不同的話，那就是內核比大多數其他自由軟件項目更開放。一個典型的三個
-月內核開發週期可以涉及1000多個開發人員，他們爲100多個不同的公司（或者根本不
-隸屬公司）工作。
-
-與內核開發社區合作並不是特別困難。但儘管如此，仍有許多潛在的貢獻者在嘗試做
-內核工作時遇到了困難。內核社區已經發展出自己獨特的操作方式，使其能夠在每天
-都要更改數千行代碼的環境中順利運行（並生成高質量的產品）。因此，Linux內核開發
-過程與專有的開發模式有很大的不同也就不足爲奇了。
-
-對於新開發人員來說，內核的開發過程可能會讓人感到奇怪和恐懼，但這背後有充分的
-理由和堅實的經驗。一個不瞭解內核社區工作方式的開發人員（或者更糟的是，他們
-試圖拋棄或規避之）會得到令人沮喪的體驗。開發社區在幫助那些試圖學習的人的同時，
+Linux核心有超過800萬行程式碼，每個版本的貢獻者超過1000人，是現存最大、最活躍的
+自由軟體專案之一。從1991年開始，這個核心已經發展成為一個最好的作業系統元件，
+執行在袖珍數位音樂播放器、桌上型電腦、現存最大的超級電腦以及所有類型的系統上。
+它是一種適用於幾乎任何情況的強健、高效和可擴展的解決方案。
+
+隨著Linux的發展，希望參與其開發的開發人員（和公司）的數量也在增加。硬體供應商
+希望確保Linux能夠很好地支援他們的產品，使這些產品對Linux使用者具有吸引力。嵌入
+式系統供應商使用Linux作為整合產品的元件，希望Linux能夠儘可能地勝任手頭的任務。
+分銷商和其他基於Linux的軟體供應商切實關心Linux核心的功能、效能和可靠性。最終
+使用者也常常希望修改Linux，使之能更好地滿足他們的需求。
+
+Linux最引人注目的特性之一是這些開發人員可以存取它；任何具備必要技能的人都
+可以改進Linux並影響其開發方向。專有產品不能提供這種開放性，這是自由軟體的
+一個特點。如果有什麼不同的話，那就是核心比大多數其他自由軟體專案更開放。一
+個典型的三個月核心開發週期可以涉及1000多個開發人員，他們為100多個不同的公
+司（或者根本不隸屬公司）工作。
+
+與核心開發社群合作並不是特別困難。但儘管如此，仍有許多潛在的貢獻者在嘗試做
+核心工作時遇到了困難。核心社群已經發展出自己獨特的操作方式，使其能夠在每天
+都要更改數千行程式碼的環境中順利執行（並產生高品質的產品）。因此，Linux核
+心開發過程與專有的開發模式有很大的不同也就不足為奇了。
+
+對於新開發人員來說，核心的開發過程可能會讓人感到奇怪和恐懼，但這背後有充分的
+理由和堅實的經驗。一個不瞭解核心社群工作方式的開發人員（或者更糟的是，他們
+試圖拋棄或規避之）會得到令人沮喪的體驗。開發社群在幫助那些試圖學習的人的同時，
沒有時間幫助那些不願意傾聽或不關心開發過程的人。
希望閱讀本文的人能夠避免這種令人沮喪的經歷。這些材料很長，但閱讀它們時所做的
-努力會在短時間內得到回報。開發社區總是需要能讓內核變更好的開發人員；下面的
-文字應該幫助您或爲您工作的人員加入我們的社區。
+努力會在短時間內得到回報。開發社群總是需要能讓核心變更好的開發人員；下面的
+文字應該幫助您或為您工作的人員加入我們的社群。
致謝
----
-本文檔由Jonathan Corbet <corbet@lwn.net> 撰寫。以下人員的建議使之更爲完善：
+本文件由Jonathan Corbet <corbet@lwn.net> 撰寫。以下人員的建議使之更為完善：
Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap,
Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson,
Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。
-這項工作得到了Linux基金會的支持，特別感謝Amanda McPherson，他看到了這項工作
+這項工作得到了Linux基金會的支援，特別感謝Amanda McPherson，他看到了這項工作
的價值並將其變成現實。
-代碼進入主線的重要性
---------------------
+程式碼進入主線的重要性
+----------------------
-有些公司和開發人員偶爾會想，爲什麼他們要費心學習如何與內核社區合作，並將代碼
-放入主線內核（“主線”是由Linus Torvalds維護的內核，Linux發行商將其用作基礎）。
-在短期內，貢獻代碼看起來像是一種可以避免的開銷；維護獨立代碼並直接支持用戶
-似乎更容易。事實上，保持代碼獨立（“樹外”）是在經濟上是錯誤的。
+有些公司和開發人員偶爾會想，為什麼他們要費心學習如何與核心社群合作，並將程
+式碼放入主線核心（“主線”是由Linus Torvalds維護的核心，Linux發行商將其用作
+基礎）。在短期內，貢獻程式碼看起來像是一種可以避免的開銷；維護獨立程式碼並
+直接支援使用者似乎更容易。事實上，保持程式碼獨立（“樹外”）是在經濟上是錯誤
+的。
-爲了說明樹外代碼成本，下面給出內核開發過程的一些相關方面；本文稍後將更詳細地
+為了說明樹外程式碼成本，下面給出核心開發過程的一些相關方面；本文稍後將更詳細地
討論其中的大部分內容。請考慮：
-- 所有Linux用戶都可以使用合併到主線內核中的代碼。它將自動出現在所有啓用它的
- 發行版上。無需驅動程序磁盤、額外下載，也不需要爲多個發行版的多個版本提供
- 支持；這一切將方便所有開發人員和用戶。併入主線解決了大量的分發和支持問題。
+- 所有Linux使用者都可以使用合併到主線核心中的程式碼。它將自動出現在所有啟
+ 用它的發行版上。無需驅動程式磁碟、額外下載，也不需要為多個發行版的多個版
+ 本提供支援；這一切將方便所有開發人員和使用者。併入主線解決了大量的分發和
+ 支援問題。
-- 當內核開發人員努力維護一個穩定的用戶空間接口時，內核內部API處於不斷變化之中。
- 不維持穩定的內部接口是一個慎重的設計決策；它允許在任何時候進行基本的改進，
- 併產出更高質量的代碼。但該策略導致結果是，若要使用新的內核，任何樹外代碼都
- 需要持續的維護。維護樹外代碼會需要大量的工作才能使代碼保持正常運行。
+- 當核心開發人員努力維護一個穩定的使用者空間介面時，核心內部API處於不斷變
+ 化之中。不維持穩定的內部介面是一個慎重的設計決策；它允許在任何時候進行基
+ 本的改進，並產出更高品質的程式碼。但該策略導致結果是，若要使用新的核心，
+ 任何樹外程式碼都需要持續的維護。維護樹外程式碼會需要大量的工作才能使程式
+ 碼保持正常執行。
- 相反，位於主線中的代碼不需要這樣做，因爲基本規則要求進行API更改的任何開發
- 人員也必須修復由於該更改而破壞的任何代碼。因此，合併到主線中的代碼大大降低
+ 相反，位於主線中的程式碼不需要這樣做，因為基本規則要求進行API更改的任何開發
+ 人員也必須修復由於該更改而破壞的任何程式碼。因此，合併到主線中的程式碼大大降低
了維護成本。
-- 除此之外，內核中的代碼通常會被其他開發人員改進。您授權的用戶社區和客戶對您
- 產品的改進可能會令人驚喜。
+- 除此之外，核心中的程式碼通常會被其他開發人員改進。您授權的使用者社群和客
+ 戶對您產品的改進可能會令人驚喜。
-- 內核代碼在合併到主線之前和之後都要經過審查。無論原始開發人員的技能有多強，
- 這個審查過程總是能找到改進代碼的方法。審查經常發現嚴重的錯誤和安全問題。
- 對於在封閉環境中開發的代碼尤其如此；這種代碼從外部開發人員的審查中獲益匪淺。
- 樹外代碼是低質量代碼。
+- 核心程式碼在合併到主線之前和之後都要經過審查。無論原始開發人員的技能有多
+ 強，這個審查過程總是能找到改進程式碼的方法。審查經常發現嚴重的錯誤和安全
+ 問題。對於在封閉環境中開發的程式碼尤其如此；這種程式碼從外部開發人員的審
+ 查中獲益匪淺。樹外程式碼是低品質程式碼。
-- 參與開發過程是您影響內核開發方向的方式。旁觀者的抱怨會被聽到，但是活躍的
- 開發人員有更強的聲音——並且能夠實現使內核更好地滿足其需求的更改。
+- 參與開發過程是您影響核心開發方向的方式。旁觀者的抱怨會被聽到，但是活躍的
+ 開發人員有更強的聲音——並且能夠實作使核心更好地滿足其需求的更改。
-- 當單獨維護代碼時，總是存在第三方爲類似功能提供不同實現的可能性。如果發生
- 這種情況，合併代碼將變得更加困難——甚至成爲不可能。之後，您將面臨以下令人
- 不快的選擇：（1）無限期地維護樹外的非標準特性，或（2）放棄代碼並將用戶遷移
- 到樹內版本。
+- 當單獨維護程式碼時，總是存在第三方為類似功能提供不同實作的可能性。如果發
+ 生這種情況，合併程式碼將變得更加困難——甚至成為不可能。之後，您將面臨以下
+ 令人不快的選擇：（1）無限期地維護樹外的非標準特性，或（2）放棄程式碼並將
+ 使用者遷移到樹內版本。
-- 代碼的貢獻是使整個流程工作的根本。通過貢獻代碼，您可以向內核添加新功能，並
- 提供其他內核開發人員使用的功能和示例。如果您已經爲Linux開發了代碼（或者正在
- 考慮這樣做），那麼您顯然對這個平臺的持續成功感興趣；貢獻代碼是確保成功的
- 最好方法之一。
+- 程式碼的貢獻是使整個流程工作的根本。透過貢獻程式碼，您可以向核心添加新功
+ 能，並提供其他核心開發人員使用的功能和範例。如果您已經為Linux開發了程式
+ 碼（或者正在考慮這樣做），那麼您顯然對這個平臺的持續成功感興趣；貢獻程式
+ 碼是確保成功的最好方法之一。
-上述所有理由都適用於任何樹外內核代碼，包括以專有的、僅二進制形式分發的代碼。
-然而，在考慮任何類型的純二進制內核代碼分佈之前，還需要考慮其他因素。包括：
+上述所有理由都適用於任何樹外核心程式碼，包括以專有的、僅二進位形式分發的程
+式碼。然而，在考慮任何類型的純二進位核心程式碼分發之前，還需要考慮其他因素。
+包括：
-- 圍繞專有內核模塊分發的法律問題其實較爲模糊；相當多的內核版權所有者認爲，
- 大多數僅二進制的模塊是內核的派生產品，因此，它們的分發違反了GNU通用公共
- 許可證（下面將詳細介紹）。本文作者不是律師，本文檔中的任何內容都不可能被
- 視爲法律建議。封閉源代碼模塊的真實法律地位只能由法院決定。但不管怎樣，困擾
- 這些模塊的不確定性仍然存在。
+- 圍繞專有核心模組分發的法律問題其實較為模糊；相當多的核心版權所有者認為，
+ 大多數僅二進位的模組是核心的派生產品，因此，它們的分發違反了GNU通用公共
+ 許可證（下面將詳細介紹）。本文作者不是律師，本文件中的任何內容都不可能被
+ 視為法律建議。封閉原始程式碼模組的真實法律地位只能由法院決定。但不管怎樣，
+ 困擾這些模組的不確定性仍然存在。
-- 二進制模塊大大增加了調試內核問題的難度，以至於大多數內核開發人員甚至都不會
- 嘗試。因此，只分發二進制模塊將使您的用戶更難從社區獲得支持。
+- 二進位模組大大增加了除錯核心問題的難度，以至於大多數核心開發人員甚至都不會
+ 嘗試。因此，只分發二進位模組將使您的使用者更難從社群獲得支援。
-- 對於僅二進制的模塊的發行者來說，支持也更加困難，他們必須爲他們希望支持的
- 每個發行版和每個內核版本提供不同版本的模塊。爲了提供較爲全面的覆蓋範圍，
- 可能需要一個模塊的幾十個構建，並且每次升級內核時，您的用戶都必須單獨升級
- 這些模塊。
+- 對於僅二進位的模組的發行者來說，支援也更加困難，他們必須為他們希望支援的
+ 每個發行版和每個核心版本提供不同版本的模組。為了提供較為全面的覆蓋範圍，
+ 可能需要一個模組的幾十個建置，並且每次升級核心時，您的使用者都必須單獨升級
+ 這些模組。
-- 上面提到的關於代碼評審的所有問題都更加存在於封閉源代碼中。由於該代碼根本
- 不可得，因此社區無法對其進行審查，毫無疑問，它將存在嚴重問題。
+- 上面提到的關於程式碼評審的所有問題都更加存在於封閉原始程式碼中。由於該程
+ 式碼根本不可得，因此社群無法對其進行審查，毫無疑問，它將存在嚴重問題。
-尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因爲他們
-相信自己正在商用一種使用凍結內核版本的獨立產品，在發佈後不需要再進行開發。
-這個論點忽略了廣泛的代碼審查的價值以及允許用戶向產品添加功能的價值。但這些
-產品的商業壽命有限，之後必須發佈新版本的產品。在這一點上，代碼在主線上並得到
+尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因為他們
+相信自己正在商用一種使用凍結核心版本的獨立產品，在發布後不需要再進行開發。
+這個論點忽略了廣泛的程式碼審查的價值以及允許使用者向產品添加功能的價值。但這些
+產品的商業壽命有限，之後必須發布新版本的產品。在這一點上，程式碼在主線上並得到
良好維護的供應商將能夠更好地佔位，以使新產品快速上市。
許可
----
-代碼是根據一些許可證提供給Linux內核的，但是所有代碼都必須與GNU通用公共許可
-證（GPLV2）的版本2兼容，該版本是覆蓋整個內核分發的許可證。在實踐中，這意味
-着所有代碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD
-許可（New BSD License，譯者注）覆蓋。任何不包含在兼容許可證中的貢獻都不會
-被接受到內核中。
+程式碼是根據一些許可證提供給Linux核心的，但是所有程式碼都必須與GNU通用公共許可
+證（GPLv2）的版本2相容，該版本是覆蓋整個核心分發的許可證。在實踐中，這意味
+著所有程式碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD
+許可（New BSD License，譯者注）覆蓋。任何不包含在相容許可證中的貢獻都不會
+被接受到核心中。
-貢獻給內核的代碼不需要（或請求）版權分配。合併到主線內核中的所有代碼都保留
-其原始所有權；因此，內核現在擁有數千個所有者。
+貢獻給核心的程式碼不需要（或請求）版權分配。合併到主線核心中的所有程式碼都保留
+其原始所有權；因此，核心現在擁有數千個所有者。
-這種所有權結構也暗示着，任何改變內核許可的嘗試都註定會失敗。很少有實際情況
-可以獲得所有版權所有者的同意（或者從內核中刪除他們的代碼）。因此，尤其是在
+這種所有權結構也暗示著，任何改變核心許可的嘗試都註定會失敗。很少有實際情況
+可以獲得所有版權所有者的同意（或者從核心中刪除他們的程式碼）。因此，尤其是在
可預見的將來，許可證不大可能遷移到GPL的版本3。
-所有貢獻給內核的代碼都必須是合法的免費軟件。因此，不接受匿名（或化名）貢獻
-者的代碼。所有貢獻者都需要在他們的代碼上“sign off（簽發）”，聲明代碼可以
-在GPL下與內核一起分發。無法提供未被其所有者許可爲免費軟件的代碼，或可能爲
-內核造成版權相關問題的代碼（例如，由缺乏適當保護的反向工程工作派生的代碼）
-不能被接受。
+所有貢獻給核心的程式碼都必須是合法的自由軟體。因此，不接受身分不明或匿名的
+貢獻者的程式碼。所有貢獻者都需要在他們的程式碼上“sign off（簽發）”，聲明程
+式碼可以在GPL下與核心一起分發。無法提供未被其所有者許可為自由軟體的程式碼，
+或可能為核心造成版權相關問題的程式碼（例如，由缺乏適當保護的反向工程工作派
+生的程式碼）不能被接受。
-有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答案，
-但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於Linux源代碼
-的法律問題，沒有什麼可以代替諮詢瞭解這一領域的律師。依賴從技術郵件列表中獲得
-的答案是一件冒險的事情。
+有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答
+案，但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於
+Linux原始程式碼的法律問題，沒有什麼可以代替諮詢瞭解這一領域的律師。依賴從
+技術郵件列表中獲得的答案是一件冒險的事情。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 03/16] docs/zh_TW: process: localize terminology in code-of-conduct-interpretation.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 01/16] docs/zh_TW: process: localize terminology in 7.AdvancedTopics.rst Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 02/16] docs/zh_TW: process: localize terminology in 1.Intro.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 04/16] docs/zh_TW: process: localize terminology in license-rules.rst Chen-Yu Yeh
` (13 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 社區→社群,
軟件→軟體, ...) and sync with the English original: rewrite the
enforcement section to match the current committee/TAB wording and add
the "Enforcement for Unacceptable Behavior" section introduced by
commit c818d5c64c9a ("Documentation/CoC: spell out enforcement for
unacceptable behaviors").
update to commit 04c4bb90ae6e ("Documentation/CoC: Spell out the TAB
role in enforcement decisions")
Acked-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../code-of-conduct-interpretation.rst | 162 ++++++++++++------
1 file changed, 113 insertions(+), 49 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
index fbe66b001322..897faa825d12 100644
--- a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
+++ b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
@@ -5,108 +5,172 @@
:Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst <code_of_conduct_interpretation>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
+ Chen-Yu Yeh <chenyou910331@gmail.com>
.. _tw_code_of_conduct_interpretation:
-Linux內核貢獻者契約行爲準則解釋
+Linux核心貢獻者契約行為準則解釋
===============================
-:ref:`tw_code_of_conduct` 準則是一個通用文檔，旨在爲幾乎所有開源社區提供一套規則。
-每個開源社區都是獨一無二的，Linux內核也不例外。因此，本文描述了Linux內核社區中
-如何解釋它。我們也不希望這種解釋隨着時間的推移是靜態的，並將根據需要進行調整。
+:ref:`tw_code_of_conduct` 準則是一個通用文件，旨在為幾乎所有開源社群提供一套規則。
+每個開源社群都是獨一無二的，Linux核心也不例外。因此，本文描述了Linux核心社群中
+如何解釋它。我們也不希望這種解釋隨著時間的推移是靜態的，並將根據需要進行調整。
-與開發軟件的“傳統”方法相比，Linux內核開發工作是一個非常個人化的過程。你的貢獻
+與開發軟體的“傳統”方法相比，Linux核心開發工作是一個非常個人化的過程。你的貢獻
和背後的想法將被仔細審查，往往導致批判和批評。審查將幾乎總是需要改進，材料才
-能包括在內核中。要知道這是因爲所有相關人員都希望看到Linux整體成功的最佳解決方
-案。這個開發過程已經被證明可以創建有史以來最健壯的操作系統內核，我們不想做任何
-事情來導致提交質量和最終結果的下降。
+能包括在核心中。要知道這是因為所有相關人員都希望看到Linux整體成功的最佳解決方
+案。這個開發過程已經被證明可以建立有史以來最強健的作業系統核心，我們不想做任何
+事情來導致提交品質和最終結果的下降。
維護者
------
-行爲準則多次使用“維護者”一詞。在內核社區中，“維護者”是負責子系統、驅動程序或
-文件的任何人，並在內核源代碼樹的維護者文件中列出。
+行為準則多次使用“維護者”一詞。在核心社群中，“維護者”是負責子系統、驅動程式或
+文件的任何人，並在核心原始程式碼樹的維護者文件中列出。
責任
----
-《行爲準則》提到了維護人員的權利和責任，這需要進一步澄清。
+《行為準則》提到了維護人員的權利和責任，這需要進一步澄清。
-首先，最重要的是，有一個合理的期望是由維護人員通過實例來領導。
+首先，最重要的是，有一個合理的期望是由維護人員透過實例來領導。
-也就是說，我們的社區是廣闊的，對維護者沒有新的要求，他們單方面處理其他人在
-他們活躍的社區的行爲。這一責任由我們所有人承擔，最終《行爲準則》記錄了最終的
-上訴路徑，以防有關行爲問題的問題懸而未決。
+也就是說，我們的社群是廣闊的，對維護者沒有新的要求，他們單方面處理其他人在
+他們活躍的社群的行為。這一責任由我們所有人承擔，最終《行為準則》記錄了最終的
+上訴路徑，以防有關行為問題的問題懸而未決。
-維護人員應該願意在出現問題時提供幫助，並在需要時與社區中的其他人合作。如果您
+維護人員應該願意在出現問題時提供幫助，並在需要時與社群中的其他人合作。如果您
不確定如何處理出現的情況，請不要害怕聯繫技術諮詢委員會（TAB）或其他維護人員。
-除非您願意，否則不會將其視爲違規報告。如果您不確定是否該聯繫TAB 或任何其他維
+除非您願意，否則不會將其視為違規報告。如果您不確定是否該聯繫TAB 或任何其他維
護人員，請聯繫我們的衝突調解人 Mishi Choudhary <mishi@linux.com>。
-最後，“善待對方”纔是每個人的最終目標。我們知道每個人都是人，有時我們都會失敗，
-但我們所有人的首要目標應該是努力友好地解決問題。執行行爲準則將是最後的選擇。
+最後，“善待對方”才是每個人的最終目標。我們知道每個人都是人，有時我們都會失敗，
+但我們所有人的首要目標應該是努力友好地解決問題。執行行為準則將是最後的選擇。
-我們的目標是創建一個強大的、技術先進的操作系統，以及所涉及的技術複雜性，這自
+我們的目標是建立一個強大的、技術先進的作業系統，以及所涉及的技術複雜性，這自
然需要專業知識和決策。
所需的專業知識因貢獻領域而異。它主要由上下文和技術複雜性決定，其次由貢獻者和
維護者的期望決定。
-專家的期望和決策都要經過討論，但在最後，爲了取得進展，必須能夠做出決策。這一
-特權掌握在維護人員和項目領導的手中，預計將善意使用。
+專家的期望和決策都要經過討論，但在最後，為了取得進展，必須能夠做出決策。這一
+特權掌握在維護人員和專案領導的手中，預計將善意使用。
-因此，設定專業知識期望、作出決定和拒絕不適當的貢獻不被視爲違反行爲準則。
+因此，設定專業知識期望、作出決定和拒絕不適當的貢獻不被視為違反行為準則。
雖然維護人員一般都歡迎新來者，但他們幫助（新）貢獻者克服障礙的能力有限，因此
-他們必須確定優先事項。這也不應被視爲違反了行爲準則。內核社區意識到這一點，並
+他們必須確定優先事項。這也不應被視為違反了行為準則。核心社群意識到這一點，並
以各種形式提供入門級節目，如 kernelnewbies.org 。
範圍
----
-Linux內核社區主要在一組公共電子郵件列表上進行交互，這些列表分佈在由多個不同
-公司或個人控制的多個不同服務器上。所有這些列表都在內核源代碼樹中的
-MAINTAINERS 文件中定義。發送到這些郵件列表的任何電子郵件都被視爲包含在行爲
+Linux核心社群主要在一組公共電子郵件列表上進行交互，這些列表分佈在由多個不同
+公司或個人控制的多個不同伺服器上。所有這些列表都在核心原始程式碼樹中的
+MAINTAINERS 文件中定義。發送到這些郵件列表的任何電子郵件都被視為包含在行為
準則中。
-使用 kernel.org bugzilla和其他子系統bugzilla 或bug跟蹤工具的開發人員應該遵循
-行爲準則的指導原則。Linux內核社區沒有“官方”項目電子郵件地址或“官方”社交媒體
-地址。使用kernel.org電子郵件帳戶執行的任何活動必須遵循爲kernel.org發佈的行爲
+使用 kernel.org bugzilla和其他子系統bugzilla 或bug追蹤工具的開發人員應該遵循
+行為準則的指導原則。Linux核心社群沒有“官方”專案電子郵件地址或“官方”社交媒體
+地址。使用kernel.org電子郵件帳戶執行的任何活動必須遵循為kernel.org發布的行為
準則，就像任何使用公司電子郵件帳戶的個人必須遵循該公司的特定規則一樣。
-行爲準則並不禁止在郵件列表消息、內核更改日誌消息或代碼註釋中繼續包含名稱、
-電子郵件地址和相關注釋。
+行為準則並不禁止在郵件列表消息、核心更改日誌消息或程式碼註解中繼續包含名稱、
+電子郵件地址和相關註解。
-其他論壇中的互動包括在適用於上述論壇的任何規則中，通常不包括在行爲準則中。
+其他論壇中的互動包括在適用於上述論壇的任何規則中，通常不包括在行為準則中。
除了在極端情況下可考慮的例外情況。
-提交給內核的貢獻應該使用適當的語言。在行爲準則之前已經存在的內容現在不會被
-視爲違反。然而，不適當的語言可以被視爲一個bug；如果任何相關方提交補丁，
-這樣的bug將被更快地修復。當前屬於用戶/內核API的一部分的表達式，或者反映已
-發佈標準或規範中使用的術語的表達式，不被視爲bug。
+提交給核心的貢獻應該使用適當的語言。在行為準則之前已經存在的內容現在不會被
+視為違反。然而，不適當的語言可以被視為一個bug；如果任何相關方提交補丁，
+這樣的bug將被更快地修復。當前屬於使用者/核心API的一部分的表達式，或者反映已
+發布標準或規範中使用的術語的表達式，不被視為bug。
執行
----
-行爲準則中列出的地址屬於行爲準則委員會。https://kernel.org/code-of-conduct.html
-列出了在任何給定時間接收這些電子郵件的確切成員。成員不能訪問在加入委員會之前
+行為準則中列出的地址屬於行為準則委員會。https://kernel.org/code-of-conduct.html
+列出了在任何給定時間接收這些電子郵件的確切成員。成員不能存取在加入委員會之前
或離開委員會之後所做的報告。
-最初的行爲準則委員會由TAB的志願者以及作爲中立第三方的專業調解人組成。委員會
-的首要任務是建立文件化的流程，並將其公開。
+行為準則委員會由TAB任命的社群志願者成員以及作為中立第三方的專業調解人組成。
+行為準則委員會處理報告所使用的流程各不相同，將取決於個別情況，但本文件可
+作為其所使用之一般流程的說明。
如果報告人不希望將整個委員會納入投訴或關切，可直接聯繫委員會的任何成員，包括
調解人。
-行爲準則委員會根據流程審查案例（見上文），並根據需要和適當與TAB協商，例如請求
-和接收有關內核社區的信息。
+行為準則委員會根據流程審查案例（見上文），並根據需要和適當與TAB協商，例如請求
+和接收有關核心社群的資訊。
-委員會做出的任何決定都將提交到表中，以便在必要時與相關維護人員一起執行。行爲
-準則委員會的決定可以通過三分之二的投票推翻。
+任何有關執法建議的決定都將提交給TAB，以便在必要時與相關維護人員一起實施
+執法。一旦TAB以參與表決成員的三分之二多數批准了禁令範圍中列出的一項或多項
+措施，行為準則委員會將執行TAB批准的措施。任何同時在TAB任職的行為準則委員會
+成員不參與對這些措施的表決。
-每季度，行爲準則委員會和標籤將提供一份報告，概述行爲準則委員會收到的匿名報告
-及其狀態，以及任何否決決定的細節，包括完整和可識別的投票細節。
+每季度，行為準則委員會和TAB將提供一份報告，概述行為準則委員會收到的匿名
+報告及其狀態，以及任何TAB批准之決定的細節，包括完整和可識別的投票細節。
-我們希望在啓動期之後爲行爲準則委員會人員配備建立一個不同的流程。發生此情況時，
-將使用該信息更新此文檔。
+由於我們對行為準則的解釋和執行會隨著時間演變，本文件將在必要時更新，以反映
+任何變化。
+
+不可接受行為之行為準則違規的執法
+--------------------------------
+
+行為準則委員會致力於確保我們的社群持續具有包容性，促進多元的討論和觀點，並
+致力於隨著時間改進這些特質。行為準則委員會收到的大多數報告，源於對開發過程
+以及維護者的角色、責任及其對程式碼接受與否的決定權的錯誤理解。這些報告透過
+澄清開發過程和行為準則的範圍來解決。
+
+不可接受的行為可能在短時間內中斷相互尊重的協作，並對社群的健康造成長期的
+負面影響。當個人在違規發生的場合承認自己的行為並加以糾正時，不可接受的行為
+通常就能得到解決。
+
+當不可接受的行為未能透過社群討論解決時，行為準則委員會會收到相關報告。當
+不可接受的行為對相互尊重的協作關係造成負面影響時，行為準則委員會會採取措施
+恢復有成效且相互尊重的協作。
+
+行為準則委員會有義務對報告和報告者的資訊保密。報告可能來自受害方，也可能
+來自目睹不可接受行為的社群成員。行為準則委員會有責任與所有相關方合作，對這
+類報告進行調查並予以處理。
+
+行為準則委員會與當事人合作，促使其理解以下事項的重要性：修復其行為對受害方
+造成的傷害，以及對社群的長期負面影響。
+
+目標是達成所有各方都能接受的解決方案。如果與當事人的合作未能達到預期的結果，
+行為準則委員會將評估其他措施，例如要求公開道歉以修復傷害。
+
+要求為違規行為公開道歉
+~~~~~~~~~~~~~~~~~~~~~~
+
+行為準則委員會在違規發生的場合公開指出該行為，要求為違規行為公開道歉。
+
+為違規行為公開道歉是重建信任的第一步。信任對於一個以信任和尊重運作的社群的
+持續成功和健康至關重要。
+
+若未為違規行為公開道歉的補救措施
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+行為準則委員會透過向TAB建議補救措施以供批准，決定恢復健康協作的下一步行動。
+
+- 禁止違規者參與核心開發過程，期限最長可達一個完整的核心開發週期。行為準則
+ 委員會可以要求公開道歉作為解除禁令的條件。
+
+一段時間內禁令的範圍可能包括：
+
+ a. 拒絕其補丁貢獻和拉取請求
+ b. 透過忽略其貢獻和/或封鎖其電子郵件帳戶，暫停與違規者的協作
+ c. 限制其透過kernel.org平臺（如郵件列表和社交媒體網站）進行交流的能力
+
+一旦TAB以參與表決成員的三分之二多數批准了禁令範圍中列出的一項或多項措施，
+行為準則委員會將與社群、維護人員、子維護人員和kernel.org管理員合作，執行
+TAB批准的措施。任何同時在TAB任職的行為準則委員會成員不參與對這些措施的表決。
+
+行為準則委員會深知要求公開道歉和實施禁令可能對個人造成的負面影響。它也深知
+在發生此類嚴重的公開違規行為時不採取行動可能對社群造成的長期傷害。
+
+TAB批准的補救措施的有效性，取決於社群、維護人員、子維護人員和kernel.org
+管理員在執行這些措施時的信任與合作。
+
+行為準則委員會衷心希望，需要要求公開道歉的不可接受行為，在未來仍然極為罕見。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 04/16] docs/zh_TW: process: localize terminology in license-rules.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (2 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 03/16] docs/zh_TW: process: localize terminology in code-of-conduct-interpretation.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 05/16] docs/zh_TW: process: localize terminology in email-clients.rst Chen-Yu Yeh
` (12 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 文件→檔案,
標識符→識別碼, 加載→載入, ...) and sync with the English original:
mention SPDX-FileCopyrightText lines and the clarified "Proprietary"
MODULE_LICENSE wording from commit d8c949c577b5 ("docs/licensing:
Clarify wording about "GPL" and "Proprietary"").
update to commit ebf1bafd0907 ("LICENSES: Explicitly allow
SPDX-FileCopyrightText")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../zh_TW/process/license-rules.rst | 203 +++++++++---------
1 file changed, 105 insertions(+), 98 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/license-rules.rst b/Documentation/translations/zh_TW/process/license-rules.rst
index 594255856b68..d9054cff505c 100644
--- a/Documentation/translations/zh_TW/process/license-rules.rst
+++ b/Documentation/translations/zh_TW/process/license-rules.rst
@@ -5,21 +5,22 @@
:Original: :ref:`Documentation/process/license-rules.rst <kernel_licensing>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
+ Chen-Yu Yeh <chenyou910331@gmail.com>
.. _tw_kernel_licensing:
-Linux內核許可規則
+Linux核心許可規則
=================
-Linux內核根據LICENSES/preferred/GPL-2.0中提供的GNU通用公共許可證版本2
+Linux核心根據LICENSES/preferred/GPL-2.0中提供的GNU通用公共許可證版本2
（GPL-2.0）的條款提供，並在LICENSES/exceptions/Linux-syscall-note中顯式
-描述了例外的系統調用，如COPYING文件中所述。
+描述了例外的系統呼叫，如COPYING檔案中所述。
-此文檔文件提供瞭如何對每個源文件進行註釋以使其許可證清晰明確的說明。
-它不會取代內核的許可證。
+本文件提供了如何對每個原始檔進行註解以使其許可證清晰明確的說明。
+它不會取代核心的許可證。
-內核源代碼作爲一個整體適用於COPYING文件中描述的許可證，但是單個源文件可以
-具有不同的與GPL-20兼容的許可證::
+核心原始程式碼作為一個整體適用於COPYING檔案中描述的許可證，但是單個原始檔可以
+具有不同的與GPL-2.0相容的許可證::
GPL-1.0+ : GNU通用公共許可證v1.0或更高版本
GPL-2.0+ : GNU通用公共許可證v2.0或更高版本
@@ -28,43 +29,47 @@ Linux內核根據LICENSES/preferred/GPL-2.0中提供的GNU通用公共許可證
LGPL-2.1 : 僅限GNU寬通用公共許可證v2.1
LGPL-2.1+: GNU寬通用公共許可證v2.1或更高版本
-除此之外，個人文件可以在雙重許可下提供，例如一個兼容的GPL變體，或者BSD，
+除此之外，個人檔案可以在雙重許可下提供，例如一個相容的GPL變體，或者BSD，
MIT等許可。
-用戶空間API（UAPI）頭文件描述了用戶空間程序與內核的接口，這是一種特殊情況。
-根據內核COPYING文件中的註釋，syscall接口是一個明確的邊界，它不會將GPL要求
-擴展到任何使用它與內核通信的軟件。由於UAPI頭文件必須包含在創建在Linux內核
-上運行的可執行文件的任何源文件中，因此此例外必須記錄在特別的許可證表述中。
+使用者空間API（UAPI）標頭檔描述了使用者空間程式與核心的介面，這是一種特殊
+情況。根據核心COPYING檔案中的註解，syscall介面是一個明確的邊界，它不會將
+GPL要求擴展到任何使用它與核心通信的軟體。由於UAPI標頭檔必須包含在建立在
+Linux核心上執行的可執行檔案的任何原始檔中，因此此例外必須記錄在特別的許可
+證表述中。
-表達源文件許可證的常用方法是將匹配的樣板文本添加到文件的頂部註釋中。由於
-格式，拼寫錯誤等，這些“樣板”很難通過那些在上下文中使用的驗證許可證合規性
+表達原始檔許可證的常用方法是將匹配的樣板文本添加到檔案的頂部註解中。由於
+格式，拼寫錯誤等，這些“樣板”很難透過那些在上下文中使用的驗證許可證合規性
的工具。
-樣板文本的替代方法是在每個源文件中使用軟件包數據交換（SPDX）許可證標識符。
-SPDX許可證標識符是機器可解析的，並且是用於提供文件內容的許可證的精確縮寫。
-SPDX許可證標識符由Linux 基金會的SPDX 工作組管理，並得到了整個行業，工具
-供應商和法律團隊的合作伙伴的一致同意。有關詳細信息，請參閱
+樣板文本的替代方法是在每個原始檔中使用軟體套件資料交換（SPDX）許可證識別碼。
+SPDX許可證識別碼是機器可解析的，並且是用於提供檔案內容的許可證的精確縮寫。
+SPDX許可證識別碼由Linux 基金會的SPDX 工作組管理，並得到了整個行業，工具
+供應商和法律團隊的合作夥伴的一致同意。有關詳細資訊，請參閱
https://spdx.org/
-Linux內核需要所有源文件中的精確SPDX標識符。內核中使用的有效標識符在
-`許可標識符`_ 一節中進行了解釋，並且已可以在
+Linux核心需要所有原始檔中的精確SPDX識別碼。核心中使用的有效識別碼在
+`許可識別碼`_ 一節中進行了解釋，並且已可以在
https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶許可證
文本。
-許可標識符語法
+許可識別碼語法
--------------
1.安置:
- 內核文件中的SPDX許可證標識符應添加到可包含註釋的文件中的第一行。對於大多
- 數文件，這是第一行，除了那些在第一行中需要'#!PATH_TO_INTERPRETER'的腳本。
- 對於這些腳本，SPDX標識符進入第二行。
+ 核心檔案中的SPDX許可證識別碼應添加到可包含註解的檔案中的第一行。對於大多
+ 數檔案，這是第一行，除了那些在第一行中需要'#!PATH_TO_INTERPRETER'的腳本。
+ 對於這些腳本，SPDX許可證識別碼進入第二行。
+
+ 如有需要，許可證識別碼行之後可以接上一行或多行SPDX-FileCopyrightText
+ 行。
|
2. 風格:
- SPDX許可證標識符以註釋的形式添加。註釋樣式取決於文件類型::
+ SPDX許可證識別碼以註解的形式添加。註解樣式取決於檔案類型::
C source: // SPDX-License-Identifier: <SPDX License Expression>
C header: /* SPDX-License-Identifier: <SPDX License Expression> */
@@ -73,44 +78,44 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
.rst: .. SPDX-License-Identifier: <SPDX License Expression>
.dts{i}: // SPDX-License-Identifier: <SPDX License Expression>
- 如果特定工具無法處理標準註釋樣式，則應使用工具接受的相應註釋機制。這是在
- C 頭文件中使用“/\*\*/”樣式註釋的原因。過去在使用生成的.lds文件中觀察到
- 構建被破壞，其中'ld'無法解析C++註釋。現在已經解決了這個問題，但仍然有較
- 舊的彙編程序工具無法處理C++樣式的註釋。
+ 如果特定工具無法處理標準註解樣式，則應使用工具接受的相應註解機制。這是在
+ C 標頭檔中使用“/\*\*/”樣式註解的原因。過去在使用產生的.lds檔案中觀察到
+ 建置被破壞，其中'ld'無法解析C++註解。現在已經解決了這個問題，但仍然有較
+ 舊的組譯器工具無法處理C++樣式的註解。
|
3. 句法:
- <SPDX許可證表達式>是SPDX許可證列表中的SPDX短格式許可證標識符，或者在許可
- 證例外適用時由“WITH”分隔的兩個SPDX短格式許可證標識符的組合。當應用多個許
+ <SPDX許可證表達式>是SPDX許可證列表中的SPDX短格式許可證識別碼，或者在許可
+ 證例外適用時由“WITH”分隔的兩個SPDX短格式許可證識別碼的組合。當應用多個許
可證時，表達式由分隔子表達式的關鍵字“AND”，“OR”組成，並由“（”，“）”包圍。
- 帶有“或更高”選項的[L]GPL等許可證的許可證標識符通過使用“+”來表示“或更高”
- 選項來構建。::
+ 帶有“或更高”選項的[L]GPL等許可證的許可證識別碼透過使用“+”來表示“或更高”
+ 選項來建置。::
// SPDX-License-Identifier: GPL-2.0+
// SPDX-License-Identifier: LGPL-2.1+
- 當需要修正的許可證時，應使用WITH。 例如，linux內核UAPI文件使用表達式::
+ 當需要修正的許可證時，應使用WITH。 例如，linux核心UAPI檔案使用表達式::
// SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
// SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
- 其它在內核中使用WITH例外的事例如下::
+ 其它在核心中使用WITH例外的事例如下::
// SPDX-License-Identifier: GPL-2.0 WITH mif-exception
// SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0
- 例外只能與特定的許可證標識符一起使用。有效的許可證標識符列在異常文本文件
- 的標記中。有關詳細信息，請參閱 `許可標識符`_ 一章中的 `例外`_ 。
+ 例外只能與特定的許可證識別碼一起使用。有效的許可證識別碼列在異常文本檔案
+ 的標記中。有關詳細資訊，請參閱 `許可識別碼`_ 一章中的 `例外`_ 。
- 如果文件是雙重許可且只選擇一個許可證，則應使用OR。例如，一些dtsi文件在雙
+ 如果檔案是雙重許可且只選擇一個許可證，則應使用OR。例如，一些dtsi檔案在雙
許可下可用::
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
- 內核中雙許可文件中許可表達式的示例::
+ 核心中雙許可檔案中許可表達式的範例::
// SPDX-License-Identifier: GPL-2.0 OR MIT
// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
@@ -119,8 +124,8 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
// SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT
// SPDX-License-Identifier: GPL-1.0+ OR BSD-3-Clause OR OpenSSL
- 如果文件具有多個許可證，其條款全部適用於使用該文件，則應使用AND。例如，
- 如果代碼是從另一個項目繼承的，並且已經授予了將其放入內核的權限，但原始
+ 如果檔案具有多個許可證，其條款全部適用於使用該檔案，則應使用AND。例如，
+ 如果程式碼是從另一個專案繼承的，並且已經授予了將其放入核心的權限，但原始
許可條款需要保持有效::
// SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT
@@ -129,20 +134,20 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
// SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+
-許可標識符
+許可識別碼
----------
-當前使用的許可證以及添加到內核的代碼許可證可以分解爲：
+當前使用的許可證以及添加到核心的程式碼許可證可以分解為：
1. _`優先許可`:
- 應儘可能使用這些許可證，因爲它們已知完全兼容並廣泛使用。這些許可證在內核
+ 應儘可能使用這些許可證，因為它們已知完全相容並廣泛使用。這些許可證在核心
目錄::
LICENSES/preferred/
- 此目錄中的文件包含完整的許可證文本和 `元標記`_ 。文件名與SPDX許可證標識
- 符相同，後者應用於源文件中的許可證。
+ 此目錄中的檔案包含完整的許可證文本和 `元標記`_ 。檔名與SPDX許可證識別碼
+ 相同，後者應用於原始檔中的許可證。
例如::
@@ -156,28 +161,28 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
_`元標記`:
- 許可證文件中必須包含以下元標記：
+ 許可證檔案中必須包含以下元標記：
- Valid-License-Identifier:
- 一行或多行, 聲明那些許可標識符在項目內有效, 以引用此特定許可的文本。通
- 常這是一個有效的標識符，但是例如對於帶有'或更高'選項的許可證，兩個標識
+ 一行或多行, 聲明那些許可識別碼在專案內有效, 以引用此特定許可的文本。通
+ 常這是一個有效的識別碼，但是例如對於帶有'或更高'選項的許可證，兩個識別碼
符都有效。
- SPDX-URL:
- SPDX頁面的URL，其中包含與許可證相關的其他信息.
+ SPDX頁面的URL，其中包含與許可證相關的其他資訊.
- Usage-Guidance:
- 使用建議的自由格式文本。該文本必須包含SPDX許可證標識符的正確示例，因爲
- 它們應根據 `許可標識符語法`_ 指南放入源文件中。
+ 使用建議的自由格式文本。該文本必須包含SPDX許可證識別碼的正確範例，因為
+ 它們應根據 `許可識別碼語法`_ 指南放入原始檔中。
- License-Text:
- 此標記之後的所有文本都被視爲原始許可文本
+ 此標記之後的所有文本都被視為原始許可文本
- 文件格式示例::
+ 檔案格式範例::
Valid-License-Identifier: GPL-2.0
Valid-License-Identifier: GPL-2.0+
@@ -209,12 +214,12 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
2. 不推薦的許可證:
- 這些許可證只應用於現有代碼或從其他項目導入代碼。這些許可證在內核目錄::
+ 這些許可證只應用於現有程式碼或從其他專案導入程式碼。這些許可證在核心目錄::
LICENSES/other/
- 此目錄中的文件包含完整的許可證文本和 `元標記`_ 。文件名與SPDX許可證標識
- 符相同，後者應用於源文件中的許可證。
+ 此目錄中的檔案包含完整的許可證文本和 `元標記`_ 。檔名與SPDX許可證識別碼
+ 相同，後者應用於原始檔中的許可證。
例如::
@@ -230,7 +235,7 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
“其他”許可證的元標籤要求與 `優先許可`_ 的要求相同。
- 文件格式示例::
+ 檔案格式範例::
Valid-License-Identifier: ISC
SPDX-URL: https://spdx.org/licenses/ISC.html
@@ -250,50 +255,50 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
3. _`例外`:
某些許可證可以修改，並允許原始許可證不具有的某些例外權利。這些例外在
- 內核目錄::
+ 核心目錄::
LICENSES/exceptions/
- 此目錄中的文件包含完整的例外文本和所需的 `例外元標記`_ 。
+ 此目錄中的檔案包含完整的例外文本和所需的 `例外元標記`_ 。
例如::
LICENSES/exceptions/Linux-syscall-note
- 包含Linux內核的COPYING文件中記錄的Linux系統調用例外，該文件用於UAPI
- 頭文件。例如::
+ 包含Linux核心的COPYING檔案中記錄的Linux系統呼叫例外，該檔案用於UAPI
+ 標頭檔。例如::
LICENSES/exceptions/GCC-exception-2.0
- 包含GCC'鏈接例外'，它允許獨立於其許可證的任何二進制文件與標記有此例外的
- 文件的編譯版本鏈接。這是從GPL不兼容源代碼創建可運行的可執行文件所必需的。
+ 包含GCC'連結例外'，它允許獨立於其許可證的任何二進位檔案與標記有此例外的
+ 檔案的編譯版本連結。這是從GPL不相容原始程式碼建立可執行的可執行檔案所必需的。
_`例外元標記`:
- 以下元標記必須在例外文件中可用：
+ 以下元標記必須在例外檔案中可用：
- SPDX-Exception-Identifier:
- 一個可與SPDX許可證標識符一起使用的例外標識符。
+ 一個可與SPDX許可證識別碼一起使用的例外識別碼。
- SPDX-URL:
- SPDX頁面的URL，其中包含與例外相關的其他信息。
+ SPDX頁面的URL，其中包含與例外相關的其他資訊。
- SPDX-Licenses:
- 以逗號分隔的例外可用的SPDX許可證標識符列表。
+ 以逗號分隔的例外可用的SPDX許可證識別碼列表。
- Usage-Guidance:
- 使用建議的自由格式文本。必須在文本後面加上SPDX許可證標識符的正確示例，
- 因爲它們應根據 `許可標識符語法`_ 指南放入源文件中。
+ 使用建議的自由格式文本。必須在文本後面加上SPDX許可證識別碼的正確範例，
+ 因為它們應根據 `許可識別碼語法`_ 指南放入原始檔中。
- Exception-Text:
- 此標記之後的所有文本都被視爲原始異常文本
+ 此標記之後的所有文本都被視為原始異常文本
- 文件格式示例::
+ 檔案格式範例::
SPDX-Exception-Identifier: Linux-syscall-note
SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
@@ -324,49 +329,51 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
Full exception text
-所有SPDX許可證標識符和例外都必須在LICENSES子目錄中具有相應的文件。這是允許
+所有SPDX許可證識別碼和例外都必須在LICENSES子目錄中具有相應的檔案。這是允許
工具驗證（例如checkpatch.pl）以及準備好從源讀取和提取許可證所必需的, 這是
各種FOSS組織推薦的，例如 `FSFE REUSE initiative <https://reuse.software/>`_.
-_`模塊許可`
+_`模組許可`
-----------------
- 可加載內核模塊還需要MODULE_LICENSE（）標記。此標記既不替代正確的源代碼
- 許可證信息（SPDX-License-Identifier），也不以任何方式表示或確定提供模塊
- 源代碼的確切許可證。
+ 可載入核心模組還需要MODULE_LICENSE（）標記。此標記既不替代正確的原始程式碼
+ 許可證資訊（SPDX-License-Identifier），也不以任何方式表示或確定提供模組
+ 原始程式碼的確切許可證。
- 此標記的唯一目的是提供足夠的信息，該模塊是否是自由軟件或者是內核模塊加
- 載器和用戶空間工具的專有模塊。
+ 此標記的唯一目的是提供足夠的資訊，該模組是否是自由軟體或者是核心模組加
+ 載器和使用者空間工具的專有模組。
- MODULE_LICENSE（）的有效許可證字符串是:
+ MODULE_LICENSE（）的有效許可證字串是:
============================= =============================================
- "GPL" 模塊是根據GPL版本2許可的。這並不表示僅限於
+ "GPL" 模組是根據GPL版本2許可的。這並不表示僅限於
GPL-2.0或GPL-2.0或更高版本之間的任何區別。
- 最正確許可證信息只能通過相應源文件中的許可證
- 信息來確定
+ 最正確許可證資訊只能透過相應原始檔中的許可證
+ 資訊來確定
- "GPL v2" 和"GPL"相同，它的存在是因爲歷史原因。
+ "GPL v2" 和"GPL"相同，它的存在是因為歷史原因。
- "GPL and additional rights" 表示模塊源在GPL v2變體和MIT許可下雙重許可的
- 歷史變體。請不要在新代碼中使用。
+ "GPL and additional rights" 表示模組源在GPL v2變體和MIT許可下雙重許可的
+ 歷史變體。請不要在新程式碼中使用。
- "Dual MIT/GPL" 表達該模塊在GPL v2變體或MIT許可證選擇下雙重
+ "Dual MIT/GPL" 表達該模組在GPL v2變體或MIT許可證選擇下雙重
許可的正確方式。
- "Dual BSD/GPL" 該模塊根據GPL v2變體或BSD許可證選擇進行雙重
- 許可。 BSD許可證的確切變體只能通過相應源文件
- 中的許可證信息來確定。
+ "Dual BSD/GPL" 該模組根據GPL v2變體或BSD許可證選擇進行雙重
+ 許可。 BSD許可證的確切變體只能透過相應原始檔
+ 中的許可證資訊來確定。
- "Dual MPL/GPL" 該模塊根據GPL v2變體或Mozilla Public License
+ "Dual MPL/GPL" 該模組根據GPL v2變體或Mozilla Public License
（MPL）選項進行雙重許可。 MPL許可證的確切變體
- 只能通過相應的源文件中的許可證信息來確定。
-
- "Proprietary" 該模塊屬於專有許可。此字符串僅用於專有的第三
- 方模塊，不能用於在內核樹中具有源代碼的模塊。
- 以這種方式標記的模塊在加載時會使用'P'標記污
- 染內核，並且內核模塊加載器拒絕將這些模塊鏈接
- 到使用EXPORT_SYMBOL_GPL（）導出的符號。
+ 只能透過相應的原始檔中的許可證資訊來確定。
+
+ "Proprietary" 該模組屬於非GPL2相容的許可。“Proprietary
+ （專有）”應僅理解為“該許可證與GPLv2不相容”。
+ 此字串僅用於非GPL2相容的第三方模組，不能用
+ 於在核心樹中具有原始程式碼的模組。以這種方式
+ 標記的模組在載入時會使用'P'標記污染核心，並
+ 且核心模組載入器拒絕將這些模組連結到使用
+ EXPORT_SYMBOL_GPL（）匯出的符號。
============================= =============================================
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 05/16] docs/zh_TW: process: localize terminology in email-clients.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (3 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 04/16] docs/zh_TW: process: localize terminology in license-rules.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 06/16] docs/zh_TW: process: localize terminology in programming-language.rst Chen-Yu Yeh
` (11 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (文本→文字, 菜單→選單,
設置→設定, 鼠標→滑鼠, ...) and sync with the English original: mention
the Thunderbird "Toggle Line Wrap" extension as an alternative to
editing mailnews.wraplength.
update to commit 4971ca2007e3 ("docs: process: email-client: add
Thunderbird "Toggle Line Wrap" extension")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../zh_TW/process/email-clients.rst | 185 +++++++++---------
1 file changed, 97 insertions(+), 88 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/email-clients.rst b/Documentation/translations/zh_TW/process/email-clients.rst
index 4543c447d797..4fae2fdbb3bf 100644
--- a/Documentation/translations/zh_TW/process/email-clients.rst
+++ b/Documentation/translations/zh_TW/process/email-clients.rst
@@ -16,87 +16,89 @@
- Xiaochen Wang <wangxiaochen0@gmail.com>
- yaxinsn <yaxinsn@163.com>
- Hu Haowen <2023002089@link.tyut.edu.cn>
+ - Chen-Yu Yeh <chenyou910331@gmail.com>
-Linux郵件客戶端配置信息
+Linux郵件客戶端設定資訊
=======================
Git
---
現在大多數開發人員使用 ``git send-email`` 而不是常規的電子郵件客戶端。這方面
-的手冊非常好。在接收端，維護人員使用 ``git am`` 加載補丁。
+的手冊非常好。在接收端，維護人員使用 ``git am`` 載入補丁。
-如果你是 ``git`` 新手，那麼把你的第一個補丁發送給你自己。將其保存爲包含所有
-標題的原始文本。運行 ``git am raw_email.txt`` ，然後使用 ``git log`` 查看更
+如果你是 ``git`` 新手，那麼把你的第一個補丁發送給你自己。將其保存為包含所有
+標題的原始文字。執行 ``git am raw_email.txt`` ，然後使用 ``git log`` 查看更
改日誌。如果工作正常，再將補丁發送到相應的郵件列表。
-通用配置
+通用設定
--------
-Linux內核補丁是通過郵件被提交的，最好把補丁作爲郵件體的內嵌文本。有些維護者
+Linux核心補丁是透過郵件被提交的，最好把補丁作為郵件體的內嵌文字。有些維護者
接收附件，但是附件的內容格式應該是"text/plain"。然而，附件一般是不贊成的，
-因爲這會使補丁的引用部分在評論過程中變的很困難。
+因為這會使補丁的引用部分在評論過程中變得很困難。
-同時也強烈建議在補丁或其他郵件的正文中使用純文本格式。https://useplaintext.email
-有助於瞭解如何配置你喜歡的郵件客戶端，並在您還沒有首選的情況下列出一些推薦的
+同時也強烈建議在補丁或其他郵件的正文中使用純文字格式。https://useplaintext.email
+有助於瞭解如何設定你喜歡的郵件客戶端，並在您還沒有首選的情況下列出一些推薦的
客戶端。
-用來發送Linux內核補丁的郵件客戶端在發送補丁時應該處於文本的原始狀態。例如，
+用來發送Linux核心補丁的郵件客戶端在發送補丁時應該處於文字的原始狀態。例如，
他們不能改變或者刪除製表符或者空格，甚至是在每一行的開頭或者結尾。
-不要通過"format=flowed"模式發送補丁。這樣會引起不可預期以及有害的斷行。
+不要透過"format=flowed"模式發送補丁。這樣會引起不可預期以及有害的斷行。
不要讓你的郵件客戶端進行自動換行。這樣也會破壞你的補丁。
-郵件客戶端不能改變文本的字符集編碼方式。要發送的補丁只能是ASCII或者UTF-8編碼
-方式，如果你使用UTF-8編碼方式發送郵件，那麼你將會避免一些可能發生的字符集問題。
+郵件客戶端不能改變文字的字元集編碼方式。要發送的補丁只能是ASCII或者UTF-8編
+碼方式，如果你使用UTF-8編碼方式發送郵件，那麼你將會避免一些可能發生的字元
+集問題。
-郵件客戶端應該生成並且保持“References:”或者“In-Reply-To:”郵件頭，這樣郵件會話
+郵件客戶端應該產生並且保持“References:”或者“In-Reply-To:”郵件頭，這樣郵件會話
就不會中斷。
-複製粘帖(或者剪貼粘帖)通常不能用於補丁，因爲製表符會轉換爲空格。使用xclipboard,
-xclip或者xcutsel也許可以，但是最好測試一下或者避免使用複製粘帖。
+複製貼上(或者剪貼貼上)通常不能用於補丁，因為製表符會轉換為空格。使用
+xclipboard,xclip或者xcutsel也許可以，但是最好測試一下或者避免使用複製貼上。
不要在使用PGP/GPG簽名的郵件中包含補丁。這樣會使得很多腳本不能讀取和適用於你的
補丁。（這個問題應該是可以修復的）
-在給內核郵件列表發送補丁之前，給自己發送一個補丁是個不錯的主意，保存接收到的
-郵件，將補丁用'patch'命令打上，如果成功了，再給內核郵件列表發送。
+在給核心郵件列表發送補丁之前，給自己發送一個補丁是個不錯的主意，保存接收到的
+郵件，將補丁用'patch'命令打上，如果成功了，再給核心郵件列表發送。
一些郵件客戶端提示
------------------
-這裏給出一些詳細的MUA配置提示，可以用於給Linux內核發送補丁。這些並不意味是
-所有的軟件包配置總結。
+這裡給出一些詳細的MUA設定提示，可以用於給Linux核心發送補丁。這些並不意味是
+所有的軟體套件設定總結。
說明：
-- TUI = 以文本爲基礎的用戶接口
-- GUI = 圖形界面用戶接口
+- TUI = 以文字為基礎的使用者介面
+- GUI = 圖形介面使用者介面
Alpine (TUI)
************
-配置選項：
+設定選項：
-在 :menuselection:`Sending Preferences` 菜單：
+在 :menuselection:`Sending Preferences` 選單：
-- :menuselection:`Do Not Send Flowed Text` 必須開啓
+- :menuselection:`Do Not Send Flowed Text` 必須開啟
- :menuselection:`Strip Whitespace Before Sending` 必須關閉
-當寫郵件時，光標應該放在補丁會出現的地方，然後按下 `CTRL-R` 組合鍵，使指
-定的補丁文件嵌入到郵件中。
+當寫郵件時，游標應該放在補丁會出現的地方，然後按下 `CTRL-R` 組合鍵，使指
+定的補丁檔案嵌入到郵件中。
Claws Mail (GUI)
****************
可以用，有人用它成功地發過補丁。
-用 :menuselection:`Message-->Insert File` (`CTRL-I`) 或外置編輯器插入補丁。
+用 :menuselection:`Message-->Insert File` (`CTRL-I`) 或外部編輯器插入補丁。
-若要在Claws編輯窗口重修改插入的補丁，需關閉
+若要在Claws編輯視窗重修改插入的補丁，需關閉
:menuselection:`Configuration-->Preferences-->Compose-->Wrapping`
的 `Auto wrapping` 。
@@ -107,49 +109,49 @@ Evolution (GUI)
撰寫郵件時：
從 :menuselection:`格式-->段落樣式-->預格式化` (`CTRL-7`)
-或工具欄選擇 :menuselection:`預格式化` ；
+或工具列選擇 :menuselection:`預格式化` ；
然後使用：
-:menuselection:`插入-->文本文件...` (`ALT-N x`) 插入補丁文件。
+:menuselection:`插入-->文字檔...` (`ALT-N x`) 插入補丁檔案。
你還可以 ``diff -Nru old.c new.c | xclip`` ，選擇 :menuselection:`預格式化` ，
-然後使用鼠標中鍵進行粘帖。
+然後使用滑鼠中鍵進行貼上。
Kmail (GUI)
***********
一些開發者成功的使用它發送補丁。
-默認撰寫設置禁用HTML格式是合適的；不要啓用它。
+預設撰寫設定禁用HTML格式是合適的；不要啟用它。
當書寫一封郵件的時候，在選項下面不要選擇自動換行。唯一的缺點就是你在郵件中輸
-入的任何文本都不會被自動換行，因此你必須在發送補丁之前手動換行。最簡單的方法
-就是啓用自動換行來書寫郵件，然後把它保存爲草稿。一旦你在草稿中再次打開它，它
+入的任何文字都不會被自動換行，因此你必須在發送補丁之前手動換行。最簡單的方法
+就是啟用自動換行來書寫郵件，然後把它保存為草稿。一旦你在草稿中再次開啟它，它
已經全部自動換行了，那麼你的郵件雖然沒有選擇自動換行，但是還不會失去已有的自
動換行。
-在郵件的底部，插入補丁之前，放上常用的補丁定界符：三個連字符(``---``)。
+在郵件的底部，插入補丁之前，放上常用的補丁定界符：三個連字元(``---``)。
-然後在 :menuselection:`信件` 菜單，選擇 :menuselection:`插入文本文件` ，接
-着選取你的補丁文件。還有一個額外的選項，你可以通過它配置你的創建新郵件工具欄，
-加上 :menuselection:`插入文本文件` 圖標。
+然後在 :menuselection:`信件` 選單，選擇 :menuselection:`插入文字檔` ，接
+著選取你的補丁檔案。還有一個額外的選項，你可以透過它設定你的建立新郵件工具列，
+加上 :menuselection:`插入文字檔` 圖示。
-將編輯器窗口拉到足夠寬避免折行。對於KMail 1.13.5 (KDE 4.5.4)，它會在發送郵件
-時對編輯器窗口中顯示折行的地方自動換行。在選項菜單中取消自動換行仍不能解決。
-因此，如果你的補丁中有非常長的行，必須在發送之前把編輯器窗口拉得非常寬。
+將編輯器視窗拉到足夠寬避免折行。對於KMail 1.13.5 (KDE 4.5.4)，它會在發送郵件
+時對編輯器視窗中顯示折行的地方自動換行。在選項選單中取消自動換行仍不能解決。
+因此，如果你的補丁中有非常長的行，必須在發送之前把編輯器視窗拉得非常寬。
參見：https://bugs.kde.org/show_bug.cgi?id=174034
-你可以安全地用GPG簽名附件，但是內嵌補丁最好不要使用GPG簽名它們。作爲內嵌文本
+你可以安全地用GPG簽名附件，但是內嵌補丁最好不要使用GPG簽名它們。作為內嵌文字
插入的簽名補丁將使其難以從7-bit編碼中提取。
如果你非要以附件的形式發送補丁，那麼就右鍵點擊附件，然後選擇
-:menuselection:`屬性` ，打開 :menuselection:`建議自動顯示` ，使附件內聯更容
+:menuselection:`屬性` ，開啟 :menuselection:`建議自動顯示` ，使附件內聯更容
易讓讀者看到。
-當你要保存將要發送的內嵌文本補丁，你可以從消息列表窗格選擇包含補丁的郵件，然
-後右鍵選擇 :menuselection:`另存爲` 。如果整個電子郵件的組成正確，您可直接將
-其作爲補丁使用。電子郵件以當前用戶可讀寫權限保存，因此您必須 ``chmod`` ，以
-使其在複製到別處時用戶組和其他人可讀。
+當你要保存將要發送的內嵌文字補丁，你可以從訊息列表窗格選擇包含補丁的郵件，然
+後右鍵選擇 :menuselection:`另存新檔` 。如果整個電子郵件的組成正確，您可直接將
+其作為補丁使用。電子郵件以當前使用者可讀寫權限保存，因此您必須 ``chmod`` ，以
+使其在複製到別處時使用者組和其他人可讀。
Lotus Notes (GUI)
*****************
@@ -167,9 +169,9 @@ Mutt (TUI)
很多Linux開發人員使用mutt客戶端，這證明它肯定工作得非常漂亮。
Mutt不自帶編輯器，所以不管你使用什麼編輯器，不自動斷行就行。大多數編輯器都有
-:menuselection:`插入文件` 選項，它可以在不改變文件內容的情況下插入文件。
+:menuselection:`插入檔案` 選項，它可以在不改變檔案內容的情況下插入檔案。
-用 ``vim`` 作爲mutt的編輯器::
+用 ``vim`` 作為mutt的編輯器::
set editor="vi"
@@ -181,21 +183,21 @@ Mutt不自帶編輯器，所以不管你使用什麼編輯器，不自動斷行
:r filename
-把補丁插入爲內嵌文本。
-在未設置 ``set paste`` 時(a)ttach工作的很好。
+把補丁插入為內嵌文字。
+在未設定 ``set paste`` 時(a)ttach工作的很好。
-你可以通過 ``git format-patch`` 生成補丁，然後用 Mutt發送它們::
+你可以透過 ``git format-patch`` 產生補丁，然後用 Mutt發送它們::
$ mutt -H 0001-some-bug-fix.patch
-配置選項：
+設定選項：
-它應該以默認設置的形式工作。
-然而，把 ``send_charset`` 設置一下也是一個不錯的主意::
+它應該以預設設定的形式工作。
+然而，把 ``send_charset`` 設定一下也是一個不錯的主意::
set send_charset="us-ascii:utf-8"
-Mutt 是高度可配置的。 這裏是個使用mutt通過 Gmail 發送的補丁的最小配置::
+Mutt 是高度可設定的。 這裡是個使用mutt透過 Gmail 發送的補丁的最小設定::
# .muttrc
# ================ IMAP ====================
@@ -222,7 +224,7 @@ Mutt 是高度可配置的。 這裏是個使用mutt通過 Gmail 發送的補丁
set from = "username@gmail.com"
set use_from = yes
-Mutt文檔含有更多信息：
+Mutt文件含有更多資訊：
https://gitlab.com/muttmua/mutt/-/wikis/UseCases/Gmail
@@ -235,7 +237,7 @@ Pine過去有一些空格刪減問題，但是這些現在應該都被修復了
如果可以，請使用alpine（pine的繼承者）。
-配置選項：
+設定選項：
- 最近的版本需要 ``quell-flowed-text``
- ``no-strip-whitespace-before-send`` 選項也是需要的。
@@ -244,23 +246,23 @@ Pine過去有一些空格刪減問題，但是這些現在應該都被修復了
Sylpheed (GUI)
**************
-- 內嵌文本可以很好的工作（或者使用附件）。
+- 內嵌文字可以很好的工作（或者使用附件）。
- 允許使用外部的編輯器。
- 收件箱較多時非常慢。
-- 如果通過non-SSL連接，無法使用TLS SMTP授權。
-- 撰寫窗口的標尺很有用。
+- 如果透過non-SSL連接，無法使用TLS SMTP授權。
+- 撰寫視窗的標尺很有用。
- 將地址添加到通訊簿時無法正確理解顯示的名稱。
Thunderbird (GUI)
*****************
-Thunderbird是Outlook的克隆版本，它很容易損壞文本，但也有一些方法強制修正。
+Thunderbird是Outlook的翻版，它很容易損壞文字，但也有一些方法強制修正。
-在完成修改後（包括安裝擴展），您需要重新啓動Thunderbird。
+在完成修改後（包括安裝擴展），您需要重新啟動Thunderbird。
- 允許使用外部編輯器：
- 使用Thunderbird發補丁最簡單的方法是使用擴展來打開您最喜歡的外部編輯器。
+ 使用Thunderbird發補丁最簡單的方法是使用擴展來開啟您最喜歡的外部編輯器。
下面是一些能夠做到這一點的擴展樣例。
@@ -270,43 +272,50 @@ Thunderbird是Outlook的克隆版本，它很容易損壞文本，但也有一
https://addons.thunderbird.net/en-GB/thunderbird/addon/external-editor-revived/
- 它需要安裝“本地消息主機（native messaging host）”。
- 參見以下文檔:
+ 它需要安裝“本地訊息主機（native messaging host）”。
+ 參見以下文件:
https://github.com/Frederick888/external-editor-revived/wiki
- “External Editor”
https://github.com/exteditor/exteditor
- 下載並安裝此擴展，然後打開 :menuselection:`新建消息` 窗口, 用
- :menuselection:`查看-->工具欄-->自定義...` 給它增加一個按鈕，直接點擊此
- 按鈕即可使用外置編輯器。
+ 下載並安裝此擴展，然後開啟 :menuselection:`新增訊息` 視窗, 用
+ :menuselection:`查看-->工具列-->自訂...` 給它增加一個按鈕，直接點擊此
+ 按鈕即可使用外部編輯器。
請注意，“External Editor”要求你的編輯器不能fork，換句話說，編輯器必須在
- 關閉前不返回。你可能需要傳遞額外的參數或修改編輯器設置。最值得注意的是，
- 如果您使用的是gvim，那麼您必須將 :menuselection:`external editor` 設置的
- 編輯器字段設置爲 ``/usr/bin/gvim --nofork"`` （假設可執行文件在
+ 關閉前不返回。你可能需要傳遞額外的參數或修改編輯器設定。最值得注意的是，
+ 如果您使用的是gvim，那麼您必須將 :menuselection:`external editor` 設定的
+ 編輯器欄位設定為 ``/usr/bin/gvim --nofork"`` （假設可執行檔在
``/usr/bin`` ），以傳遞 ``-f`` 參數。如果您正在使用其他編輯器，請閱讀其
手冊瞭解如何處理。
若要修正內部編輯器，請執行以下操作：
-- 修改你的Thunderbird設置，不要使用 ``format=flowed`` ！
- 回到主窗口，按照
- :menuselection:`主菜單-->首選項-->常規-->配置編輯器...`
- 打開Thunderbird的配置編輯器。
+- 修改你的Thunderbird設定，不要使用 ``format=flowed`` ！
+ 回到主視窗，按照
+ :menuselection:`主選單-->偏好設定-->常規-->設定編輯器...`
+ 開啟Thunderbird的設定編輯器。
- - 將 ``mailnews.send_plaintext_flowed`` 設爲 ``false``
+ - 將 ``mailnews.send_plaintext_flowed`` 設為 ``false``
- - 將 ``mailnews.wraplength`` 從 ``72`` 改爲 ``0``
+ - 將 ``mailnews.wraplength`` 從 ``72`` 改為 ``0`` ，**或者** 安裝
+ “Toggle Line Wrap”擴展
+
+ https://github.com/jan-kiszka/togglelinewrap
+
+ https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
+
+ 以便即時控制此設定項。
- 不要寫HTML郵件！
- 回到主窗口，打開
- :menuselection:`主菜單-->賬戶設置-->你的@郵件.地址-->通訊錄/編寫&地址簿` ，
- 關掉 ``以HTML格式編寫消息`` 。
+ 回到主視窗，開啟
+ :menuselection:`主選單-->帳戶設定-->你的@郵件.地址-->通訊錄/編寫&地址簿` ，
+ 關掉 ``以HTML格式編寫訊息`` 。
-- 只用純文本格式查看郵件！
- 回到主窗口， :menuselection:`主菜單-->查看-->消息體爲-->純文本` ！
+- 只用純文字格式查看郵件！
+ 回到主視窗， :menuselection:`主選單-->查看-->訊息體為-->純文字` ！
TkRat (GUI)
***********
@@ -318,12 +327,12 @@ Gmail (Web GUI)
不要使用它發送補丁。
-Gmail網頁客戶端自動地把製表符轉換爲空格。
+Gmail網頁客戶端自動地把製表符轉換為空格。
-雖然製表符轉換爲空格問題可以被外部編輯器解決，但它同時還會使用回車換行把每行
-拆分爲78個字符。
+雖然製表符轉換為空格問題可以被外部編輯器解決，但它同時還會使用回車換行把每行
+拆分為78個字元。
-另一個問題是Gmail還會把任何含有非ASCII的字符的消息改用base64編碼，如歐洲人的
+另一個問題是Gmail還會把任何含有非ASCII的字元的訊息改用base64編碼，如歐洲人的
名字。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 06/16] docs/zh_TW: process: localize terminology in programming-language.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (4 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 05/16] docs/zh_TW: process: localize terminology in email-clients.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 07/16] docs/zh_TW: process: localize terminology in coding-style.rst Chen-Yu Yeh
` (10 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 變量→變數,
函數→函式, ...) and sync with the English original: drop the stale
icc/architecture paragraph, switch to footnote-style references as in
the English text, and add the Rust section, which now states Rust is
supported (no longer experimental) per commit 9fa7153c31a3 ("rust:
conclude the Rust experiment").
update to commit 26a4cfaff82a ("Merge tag 'docs-7.0-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../zh_TW/process/programming-language.rst | 98 ++++++++-----------
1 file changed, 43 insertions(+), 55 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/programming-language.rst b/Documentation/translations/zh_TW/process/programming-language.rst
index d2c64a5599e8..a5466047b90c 100644
--- a/Documentation/translations/zh_TW/process/programming-language.rst
+++ b/Documentation/translations/zh_TW/process/programming-language.rst
@@ -5,71 +5,59 @@
:Original: :ref:`Documentation/process/programming-language.rst <programming_language>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
+ Chen-Yu Yeh <chenyou910331@gmail.com>
.. _tw_programming_language:
-程序設計語言
-============
+程式語言
+========
-內核是用C語言 :ref:`c-language <tw_c-language>` 編寫的。更準確地說，內核通常是用 :ref:`gcc <tw_gcc>`
-在 ``-std=gnu11`` :ref:`gcc-c-dialect-options <tw_gcc-c-dialect-options>` 下編譯的：ISO C11的 GNU 方言
+Linux核心是用C程式語言 [zh_tw_c-language]_ 編寫的。更準確地說，核心通常使
+用``gcc`` [zh_tw_gcc]_ 編譯，並且使用 ``-std=gnu11``
+[zh_tw_gcc-c-dialect-options]_：這是 ISO C11 的 GNU 方言。``clang``
+[zh_tw_clang]_ 也得到了支援，詳見文件：
+:ref:`使用 Clang/LLVM 建置 Linux <kbuild_llvm>`。
-這種方言包含對語言 :ref:`gnu-extensions <tw_gnu-extensions>` 的許多擴展，當然，它們許多都在內核中使用。
-
-對於一些體系結構，有一些使用 :ref:`clang <tw_clang>` 和 :ref:`icc <tw_icc>` 編譯內核
-的支持，儘管在編寫此文檔時還沒有完成，仍需要第三方補丁。
+這種方言包含對C語言的許多擴展 [zh_tw_gnu-extensions]_，當然，它們許多都在核心
+中使用。
屬性
----
-在整個內核中使用的一個常見擴展是屬性（attributes） :ref:`gcc-attribute-syntax <tw_gcc-attribute-syntax>`
-屬性允許將實現定義的語義引入語言實體（如變量、函數或類型），而無需對語言進行
-重大的語法更改（例如添加新關鍵字） :ref:`n2049 <tw_n2049>`
-
-在某些情況下，屬性是可選的（即不支持這些屬性的編譯器仍然應該生成正確的代碼，
-即使其速度較慢或執行的編譯時檢查/診斷次數不夠）
-
-內核定義了僞關鍵字（例如， ``pure`` ），而不是直接使用GNU屬性語法（例如,
-``__attribute__((__pure__))`` ），以檢測可以使用哪些關鍵字和/或縮短代碼, 具體
-請參閱 ``include/linux/compiler_attributes.h``
-
-.. _tw_c-language:
-
-c-language
- http://www.open-std.org/jtc1/sc22/wg14/www/standards
-
-.. _tw_gcc:
-
-gcc
- https://gcc.gnu.org
-
-.. _tw_clang:
-
-clang
- https://clang.llvm.org
+在整個核心中使用的一個常見擴展是屬性（attributes）
+[zh_tw_gcc-attribute-syntax]_。屬性允許將實作定義的語義引入語言實體（如變
+數、函式或型別），而無需對語言進行重大的語法更改（例如添加新關鍵字）
+[zh_tw_n2049]_。
-.. _tw_icc:
+在某些情況下，屬性是可選的（即不支援這些屬性的編譯器仍然應該產生正確的程式碼，
+即使其速度較慢或執行的編譯時檢查/診斷次數不夠）。
-icc
- https://software.intel.com/en-us/c-compilers
+核心定義了偽關鍵字（例如， ``__pure`` ），而不是直接使用GNU屬性語法（例如,
+``__attribute__((__pure__))`` ），以檢測可以使用哪些關鍵字和/或縮短程式碼，
+具體請參閱 ``include/linux/compiler_attributes.h``
-.. _tw_gcc-c-dialect-options:
-
-c-dialect-options
- https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
-
-.. _tw_gnu-extensions:
-
-gnu-extensions
- https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
-
-.. _tw_gcc-attribute-syntax:
-
-gcc-attribute-syntax
- https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
-
-.. _tw_n2049:
-
-n2049
- http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf
+Rust
+----
+核心支援 Rust 程式語言 [zh_tw_rust-language]_，並可以透過設定選項
+``CONFIG_RUST`` 來啟用。Rust 程式碼使用 ``rustc`` [zh_tw_rustc]_ 編譯器在
+``--edition=2021`` [zh_tw_rust-editions]_ 選項下進行編譯。版本（Editions）是
+一種在語言中引入非後向相容的小型變更的方式。
+
+除此之外，核心中還使用了一些不穩定的特性 [zh_tw_rust-unstable-features]_。
+這些不穩定的特性將來可能會發生變化，因此，一個重要的目標是達到僅使用穩定特性
+的程度。
+
+具體請參閱 Documentation/rust/index.rst
+
+.. [zh_tw_c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards
+.. [zh_tw_gcc] https://gcc.gnu.org
+.. [zh_tw_clang] https://clang.llvm.org
+.. [zh_tw_gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
+.. [zh_tw_gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
+.. [zh_tw_gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
+.. [zh_tw_n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf
+.. [zh_tw_rust-language] https://www.rust-lang.org
+.. [zh_tw_rustc] https://doc.rust-lang.org/rustc/
+.. [zh_tw_rust-editions] https://doc.rust-lang.org/edition-guide/editions/
+.. [zh_tw_rust-unstable-features] https://github.com/Rust-for-Linux/linux/issues/2
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 07/16] docs/zh_TW: process: localize terminology in coding-style.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (5 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 06/16] docs/zh_TW: process: localize terminology in programming-language.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 08/16] docs/zh_TW: process: localize terminology in stable-kernel-rules.rst Chen-Yu Yeh
` (9 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 函數→函式,
宏→巨集, 枚舉→列舉, 聲明→宣告, 寄存器→暫存器, ...) and sync with the
English original: update the memory allocator list and array
allocation examples to the type-aware kmalloc_objs()/kzalloc_objs()
forms.
update to commit 323fa4b9608b ("Documentation: Fix syntax of
kmalloc_objs example in coding style doc")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../zh_TW/process/coding-style.rst | 614 +++++++++---------
1 file changed, 311 insertions(+), 303 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst
index 63c78982a1af..ef7a4cdbff37 100644
--- a/Documentation/translations/zh_TW/process/coding-style.rst
+++ b/Documentation/translations/zh_TW/process/coding-style.rst
@@ -18,39 +18,40 @@
- Li Zefan <lizf@cn.fujitsu.com>
- Wang Chen <wangchen@cn.fujitsu.com>
- Hu Haowen <2023002089@link.tyut.edu.cn>
+ - 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
-Linux 內核代碼風格
-==================
+Linux 核心程式碼風格
+====================
-這是一個簡短的文檔，描述了 linux 內核的首選代碼風格。代碼風格是因人而異的，
-而且我不願意把自己的觀點強加給任何人，但這就像我去做任何事情都必須遵循的原則
-那樣，我也希望在絕大多數事上保持這種的態度。請 (在寫代碼時) 至少考慮一下這裏
-的代碼風格。
+這是一個簡短的文件，描述了 linux 核心的首選程式碼風格。程式碼風格是因人而
+異的，而且我不願意把自己的觀點強加給任何人，但這就像我去做任何事情都必須遵
+循的原則那樣，我也希望在絕大多數事上保持這種的態度。請 (在寫程式碼時) 至少
+考慮一下這裡的程式碼風格。
-首先，我建議你打印一份 GNU 代碼規範，然後不要讀。燒了它，這是一個具有重大象徵
-性意義的動作。
+首先，我建議你列印一份 GNU 程式碼規範，然後不要讀。燒了它，這是一個具有重
+大象徵性意義的動作。
不管怎樣，現在我們開始：
-1) 縮進
+1) 縮排
-------
-製表符是 8 個字符，所以縮進也是 8 個字符。有些異端運動試圖將縮進變爲 4 (甚至
-2！) 字符深，這幾乎相當於嘗試將圓周率的值定義爲 3。
+製表符是 8 個字元，所以縮排也是 8 個字元。有些異端運動試圖將縮排變為 4 (甚至
+2！) 字元深，這幾乎相當於嘗試將圓周率的值定義為 3。
-理由：縮進的全部意義就在於清楚的定義一個控制塊起止於何處。尤其是當你盯着你的
-屏幕連續看了 20 小時之後，你將會發現大一點的縮進會使你更容易分辨縮進。
+理由：縮排的全部意義就在於清楚的定義一個控制塊起止於何處。尤其是當你盯著你的
+屏幕連續看了 20 小時之後，你將會發現大一點的縮排會使你更容易分辨縮排。
-現在，有些人會抱怨 8 個字符的縮進會使代碼向右邊移動的太遠，在 80 個字符的終端
-屏幕上就很難讀這樣的代碼。這個問題的答案是，如果你需要 3 級以上的縮進，不管用
-何種方式你的代碼已經有問題了，應該修正你的程序。
+現在，有些人會抱怨 8 個字元的縮排會使程式碼向右邊移動的太遠，在 80 個字元
+的終端屏幕上就很難讀這樣的程式碼。這個問題的答案是，如果你需要 3 級以上的
+縮排，不管用何種方式你的程式碼已經有問題了，應該修正你的程式。
-簡而言之，8 個字符的縮進可以讓代碼更容易閱讀，還有一個好處是當你的函數嵌套太
+簡而言之，8 個字元的縮排可以讓程式碼更容易閱讀，還有一個好處是當你的函式嵌套太
深的時候可以給你警告。留心這個警告。
-在 switch 語句中消除多級縮進的首選的方式是讓 ``switch`` 和從屬於它的 ``case``
-標籤對齊於同一列，而不要 ``兩次縮進`` ``case`` 標籤。比如：
+在 switch 語句中消除多級縮排的首選的方式是讓 ``switch`` 和從屬於它的 ``case``
+標籤對齊於同一列，而不要 ``兩次縮排`` ``case`` 標籤。比如：
.. code-block:: c
@@ -71,7 +72,7 @@ Linux 內核代碼風格
break;
}
-不要把多個語句放在一行裏，除非你有什麼東西要隱藏：
+不要把多個語句放在一行裡，除非你有什麼東西要隱藏：
.. code-block:: c
@@ -94,37 +95,38 @@ Linux 內核代碼風格
do_that();
}
-也不要在一行裏放多個賦值語句。內核代碼風格超級簡單。就是避免可能導致別人誤讀
+也不要在一行裡放多個賦值語句。核心程式碼風格超級簡單。就是避免可能導致別人誤讀
的表達式。
-除了註釋、文檔和 Kconfig 之外，不要使用空格來縮進，前面的例子是例外，是有意爲
+除了註解、文件和 Kconfig 之外，不要使用空格來縮排，前面的例子是例外，是有意為
之。
選用一個好的編輯器，不要在行尾留空格。
-2) 把長的行和字符串打散
+2) 把長的行和字串打散
-----------------------
-代碼風格的意義就在於使用平常使用的工具來維持代碼的可讀性和可維護性。
+程式碼風格的意義就在於使用平常使用的工具來維持程式碼的可讀性和可維護性。
每一行的長度的限制是 80 列，我們強烈建議您遵守這個慣例。
長於 80 列的語句要打散成有意義的片段。除非超過 80 列能顯著增加可讀性，並且不
-會隱藏信息。
+會隱藏資訊。
-子片段要明顯短於母片段，並明顯靠右。一種非常常用的樣式是將子體與函數左括號對齊。
+子片段要明顯短於母片段，並明顯靠右。一種非常常用的樣式是將子體與函式左括號
+對齊。
-這同樣適用於有着很長參數列表的函數頭。
+這同樣適用於有著很長參數列表的函式頭。
-然而，絕對不要打散對用戶可見的字符串，例如 printk 信息，因爲這樣就
+然而，絕對不要打散對使用者可見的字串，例如 printk 資訊，因為這樣就
很難對它們 grep。
3) 大括號和空格的放置
---------------------
-C 語言風格中另外一個常見問題是大括號的放置。和縮進大小不同，選擇或棄用某種放
+C 語言風格中另外一個常見問題是大括號的放置。和縮排大小不同，選擇或棄用某種放
置策略並沒有多少技術上的原因，不過首選的方式，就像 Kernighan 和 Ritchie 展示
給我們的，是把起始大括號放在行尾，而把結束大括號放在行首，所以：
@@ -134,7 +136,7 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
we do y
}
-這適用於所有的非函數語句塊 (if, switch, for, while, do)。比如：
+這適用於所有的非函式語句塊 (if, switch, for, while, do)。比如：
.. code-block:: c
@@ -149,7 +151,7 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
return NULL;
}
-不過，有一個例外，那就是函數：函數的起始大括號放置於下一行的開頭，所以：
+不過，有一個例外，那就是函式：函式的起始大括號放置於下一行的開頭，所以：
.. code-block:: c
@@ -159,10 +161,10 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
}
全世界的異端可能會抱怨這個不一致性是……呃……不一致，不過所有思維健全的人
-都知道 (a) K&R 是 **正確的** 並且 (b) K&R 是正確的。此外，不管怎樣函數都是特
-殊的 (C 函數是不能嵌套的)。
+都知道 (a) K&R 是 **正確的** 並且 (b) K&R 是正確的。此外，不管怎樣函式都是特
+殊的 (C 函式是不能嵌套的)。
-注意結束大括號獨自佔據一行，除非它後面跟着同一個語句的剩餘部分，也就是 do 語
+注意結束大括號獨自佔據一行，除非它後面跟著同一個語句的剩餘部分，也就是 do 語
句中的 ``while`` 或者 if 語句中的 ``else`` ，像這樣：
.. code-block:: c
@@ -187,7 +189,7 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
也請注意這種大括號的放置方式也能使空 (或者差不多空的) 行的數量最小化，同時不
失可讀性。因此，由於你的屏幕上的新行是不可再生資源 (想想 25 行的終端屏幕)，你
-將會有更多的空行來放置註釋。
+將會有更多的空行來放置註解。
當只有一個單獨的語句的時候，不用加不必要的大括號。
@@ -219,10 +221,10 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
3.1) 空格
*********
-Linux 內核的空格使用方式 (主要) 取決於它是用於函數還是關鍵字。(大多數) 關鍵字
+Linux 核心的空格使用方式 (主要) 取決於它是用於函式還是關鍵字。(大多數) 關鍵字
後要加一個空格。值得注意的例外是 sizeof, typeof, alignof 和 __attribute__，這
-些關鍵字某些程度上看起來更像函數 (它們在 Linux 裏也常常伴隨小括號而使用，儘管
-在 C 裏這樣的小括號不是必需的，就像 ``struct fileinfo info;`` 聲明過後的
+些關鍵字某些程度上看起來更像函式 (它們在 Linux 裡也常常伴隨小括號而使用，儘管
+在 C 裡這樣的小括號不是必需的，就像 ``struct fileinfo info;`` 宣告過後的
``sizeof info``)。
所以在這些關鍵字之後放一個空格::
@@ -236,14 +238,14 @@ Linux 內核的空格使用方式 (主要) 取決於它是用於函數還是關
s = sizeof(struct file);
-不要在小括號裏的表達式兩側加空格。這是一個 **反例** ：
+不要在小括號裡的表達式兩側加空格。這是一個 **反例** ：
.. code-block:: c
s = sizeof( struct file );
-當聲明指針類型或者返回指針類型的函數時， ``*`` 的首選使用方式是使之靠近變量名
-或者函數名，而不是靠近類型名。例子：
+當宣告指標類型或者返回指標類型的函式時， ``*`` 的首選使用方式是使之靠近變數名
+或者函式名，而不是靠近類型名。例子：
.. code-block:: c
@@ -269,67 +271,67 @@ Linux 內核的空格使用方式 (主要) 取決於它是用於函數還是關
``.`` 和 ``->`` 結構體成員操作符前後不加空格。
-不要在行尾留空白。有些可以自動縮進的編輯器會在新行的行首加入適量的空白，然後
-你就可以直接在那一行輸入代碼。不過假如你最後沒有在那一行輸入代碼，有些編輯器
-就不會移除已經加入的空白，就像你故意留下一個只有空白的行。包含行尾空白的行就
-這樣產生了。
+不要在行尾留空白。有些可以自動縮排的編輯器會在新行的行首加入適量的空白，然
+後你就可以直接在那一行輸入程式碼。不過假如你最後沒有在那一行輸入程式碼，有
+些編輯器就不會移除已經加入的空白，就像你故意留下一個只有空白的行。包含行尾
+空白的行就這樣產生了。
當 git 發現補丁包含了行尾空白的時候會警告你，並且可以應你的要求去掉行尾空白；
-不過如果你是正在打一系列補丁，這樣做會導致後面的補丁失敗，因爲你改變了補丁的
+不過如果你是正在打一系列補丁，這樣做會導致後面的補丁失敗，因為你改變了補丁的
上下文。
4) 命名
-------
-C 是一個簡樸的語言，你的命名也應該這樣。和 Modula-2 和 Pascal 程序員不同，
-C 程序員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字。C 程序員會
-稱那個變量爲 ``tmp`` ，這樣寫起來會更容易，而且至少不會令其難於理解。
+C 是一個簡樸的語言，你的命名也應該這樣。和 Modula-2 和 Pascal 程式員不同，
+C 程式員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字。C 程式員會
+稱那個變數為 ``tmp`` ，這樣寫起來會更容易，而且至少不會令其難於理解。
-不過，雖然混用大小寫的名字是不提倡使用的，但是全局變量還是需要一個具描述性的
-名字。稱一個全局函數爲 ``foo`` 是一個難以饒恕的錯誤。
+不過，雖然混用大小寫的名字是不提倡使用的，但是全域變數還是需要一個具描述性的
+名字。稱一個全域函式為 ``foo`` 是一個難以饒恕的錯誤。
-全局變量 (只有當你 **真正** 需要它們的時候再用它) 需要有一個具描述性的名字，就
-像全局函數。如果你有一個可以計算活動用戶數量的函數，你應該叫它
+全域變數 (只有當你 **真正** 需要它們的時候再用它) 需要有一個具描述性的名字，就
+像全域函式。如果你有一個可以計算活動使用者數量的函式，你應該叫它
``count_active_users()`` 或者類似的名字，你不應該叫它 ``cntuser()`` 。
-在函數名中包含函數類型 (所謂的匈牙利命名法) 是腦子出了問題——編譯器知道那些類
-型而且能夠檢查那些類型，這樣做只能把程序員弄糊塗了。
+在函式名中包含函式類型 (所謂的匈牙利命名法) 是腦子出了問題——編譯器知道那些類
+型而且能夠檢查那些類型，這樣做只能把程式員弄糊塗了。
-本地變量名應該簡短，而且能夠表達相關的含義。如果你有一些隨機的整數型的循環計
-數器，它應該被稱爲 ``i`` 。叫它 ``loop_counter`` 並無益處，如果它沒有被誤解的
-可能的話。類似的， ``tmp`` 可以用來稱呼任意類型的臨時變量。
+本地變數名應該簡短，而且能夠表達相關的含義。如果你有一些隨機的整數型的迴圈計
+數器，它應該被稱為 ``i`` 。叫它 ``loop_counter`` 並無益處，如果它沒有被誤解的
+可能的話。類似的， ``tmp`` 可以用來稱呼任意類型的臨時變數。
-如果你怕混淆了你的本地變量名，你就遇到另一個問題了，叫做函數增長荷爾蒙失衡綜
-合徵。請看第六章 (函數)。
+如果你怕混淆了你的本地變數名，你就遇到另一個問題了，叫做函式增長荷爾蒙失衡綜
+合徵。請看第六章 (函式)。
-對於符號名稱和文檔，避免引入新的“master/slave”（或獨立於“master”的“slave”）
+對於符號名稱和文件，避免引入新的“master/slave”（或獨立於“master”的“slave”）
和“blacklist/whitelist”。
-“master/slave”推薦替換爲：
+“master/slave”推薦替換為：
'{primary,main} / {secondary,replica,subordinate}'
'{initiator,requester} / {target,responder}'
'{controller,host} / {device,worker,proxy}'
'leader/follower'
'director/performer'
-“blacklist/whitelist”推薦替換爲：
+“blacklist/whitelist”推薦替換為：
'denylist/allowlist'
'blocklist/passlist'
-引入新用法的例外情況是：維護用戶空間ABI/API，或更新現有（截至2020年）硬件或
-協議規範的代碼時要求這些術語。對於新規範，儘可能將術語的規範用法轉換爲內核
+引入新用法的例外情況是：維護使用者空間ABI/API，或更新現有（截至2020年）硬體或
+協議規範的程式碼時要求這些術語。對於新規範，儘可能將術語的規範用法轉換為核心
編碼標準。
.. warning::
- 以上主從、黑白名單規則不適用於中文文檔，請勿更改中文術語！
+ 以上主從、黑白名單規則不適用於中文文件，請勿更改中文術語！
5) Typedef
----------
不要使用類似 ``vps_t`` 之類的東西。
-對結構體和指針使用 typedef 是一個 **錯誤** 。當你在代碼裏看到：
+對結構體和指標使用 typedef 是一個 **錯誤** 。當你在程式碼裡看到：
.. code-block:: c
@@ -345,34 +347,34 @@ C 程序員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
你就知道 ``a`` 是什麼了。
-很多人認爲 typedef ``能提高可讀性`` 。實際不是這樣的。它們只在下列情況下有用：
+很多人認為 typedef ``能提高可讀性`` 。實際不是這樣的。它們只在下列情況下有用：
- (a) 完全不透明的對象 (這種情況下要主動使用 typedef 來 **隱藏** 這個對象實際上
+ (a) 完全不透明的物件 (這種情況下要主動使用 typedef 來 **隱藏** 這個物件實際上
是什麼)。
- 例如： ``pte_t`` 等不透明對象，你只能用合適的訪問函數來訪問它們。
+ 例如： ``pte_t`` 等不透明物件，你只能用合適的存取函式來存取它們。
.. note::
- 不透明性和“訪問函數”本身是不好的。我們使用 pte_t 等類型的原因在於真
- 的是完全沒有任何共用的可訪問信息。
+ 不透明性和“存取函式”本身是不好的。我們使用 pte_t 等類型的原因在於真
+ 的是完全沒有任何共用的可存取資訊。
(b) 清楚的整數類型，如此，這層抽象就可以 **幫助** 消除到底是 ``int`` 還是
``long`` 的混淆。
- u8/u16/u32 是完全沒有問題的 typedef，不過它們更符合類別 (d) 而不是這裏。
+ u8/u16/u32 是完全沒有問題的 typedef，不過它們更符合類別 (d) 而不是這裡。
.. note::
- 要這樣做，必須事出有因。如果某個變量是 ``unsigned long`` ，那麼沒有必要
+ 要這樣做，必須事出有因。如果某個變數是 ``unsigned long`` ，那麼沒有必要
typedef unsigned long myflags_t;
不過如果有一個明確的原因，比如它在某種情況下可能會是一個 ``unsigned int``
- 而在其他情況下可能爲 ``unsigned long`` ，那麼就不要猶豫，請務必使用
+ 而在其他情況下可能為 ``unsigned long`` ，那麼就不要猶豫，請務必使用
typedef。
- (c) 當你使用 sparse 按字面的創建一個 **新** 類型來做類型檢查的時候。
+ (c) 當你使用 sparse 按字面的建立一個 **新** 類型來做類型檢查的時候。
(d) 和標準 C99 類型相同的類型，在某些例外的情況下。
@@ -380,45 +382,45 @@ C 程序員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
是有些人仍然拒絕使用它們。
因此，Linux 特有的等同於標準類型的 ``u8/u16/u32/u64`` 類型和它們的有符號
- 類型是被允許的——儘管在你自己的新代碼中，它們不是強制要求要使用的。
+ 類型是被允許的——儘管在你自己的新程式碼中，它們不是強制要求要使用的。
- 當編輯已經使用了某個類型集的已有代碼時，你應該遵循那些代碼中已經做出的選
+ 當編輯已經使用了某個類型集的已有程式碼時，你應該遵循那些程式碼中已經做出的選
擇。
- (e) 可以在用戶空間安全使用的類型。
+ (e) 可以在使用者空間安全使用的類型。
- 在某些用戶空間可見的結構體裏，我們不能要求 C99 類型而且不能用上面提到的
- ``u32`` 類型。因此，我們在與用戶空間共享的所有結構體中使用 __u32 和類似
+ 在某些使用者空間可見的結構體裡，我們不能要求 C99 類型而且不能用上面提到的
+ ``u32`` 類型。因此，我們在與使用者空間共享的所有結構體中使用 __u32 和類似
的類型。
可能還有其他的情況，不過基本的規則是 **永遠不要** 使用 typedef，除非你可以明
確的應用上述某個規則中的一個。
-總的來說，如果一個指針或者一個結構體裏的元素可以合理的被直接訪問到，那麼它們
+總的來說，如果一個指標或者一個結構體裡的元素可以合理的被直接存取到，那麼它們
就不應該是一個 typedef。
-6) 函數
+6) 函式
-------
-函數應該簡短而漂亮，並且只完成一件事情。函數應該可以一屏或者兩屏顯示完 (我們
+函式應該簡短而漂亮，並且只完成一件事情。函式應該可以一屏或者兩屏顯示完 (我們
都知道 ISO/ANSI 屏幕大小是 80x24)，只做一件事情，而且把它做好。
-一個函數的最大長度是和該函數的複雜度和縮進級數成反比的。所以，如果你有一個理
-論上很簡單的只有一個很長 (但是簡單) 的 case 語句的函數，而且你需要在每個 case
-裏做很多很小的事情，這樣的函數儘管很長，但也是可以的。
+一個函式的最大長度是和該函式的複雜度和縮排級數成反比的。所以，如果你有一個理
+論上很簡單的只有一個很長 (但是簡單) 的 case 語句的函式，而且你需要在每個 case
+裡做很多很小的事情，這樣的函式儘管很長，但也是可以的。
-不過，如果你有一個複雜的函數，而且你懷疑一個天分不是很高的高中一年級學生可能
-甚至搞不清楚這個函數的目的，你應該嚴格遵守前面提到的長度限制。使用輔助函數，
-併爲之取個具描述性的名字 (如果你覺得它們的性能很重要的話，可以讓編譯器內聯它
-們，這樣的效果往往會比你寫一個複雜函數的效果要好。)
+不過，如果你有一個複雜的函式，而且你懷疑一個天分不是很高的高中一年級學生可能
+甚至搞不清楚這個函式的目的，你應該嚴格遵守前面提到的長度限制。使用輔助函式，
+併為之取個具描述性的名字 (如果你覺得它們的效能很重要的話，可以讓編譯器行內它
+們，這樣的效果往往會比你寫一個複雜函式的效果要好。)
-函數的另外一個衡量標準是本地變量的數量。此數量不應超過 5－10 個，否則你的函數
-就有問題了。重新考慮一下你的函數，把它分拆成更小的函數。人的大腦一般可以輕鬆
-的同時跟蹤 7 個不同的事物，如果再增多的話，就會糊塗了。即便你聰穎過人，你也可
+函式的另外一個衡量標準是本地變數的數量。此數量不應超過 5－10 個，否則你的函式
+就有問題了。重新考慮一下你的函式，把它分拆成更小的函式。人的大腦一般可以輕鬆
+的同時追蹤 7 個不同的事物，如果再增多的話，就會糊塗了。即便你聰穎過人，你也可
能會記不清你 2 個星期前做過的事情。
-在源文件裏，使用空行隔開不同的函數。如果該函數需要被導出，它的 **EXPORT** 宏
+在原始檔裡，使用空行隔開不同的函式。如果該函式需要被匯出，它的 **EXPORT** 巨集
應該緊貼在它的結束大括號之下。比如：
.. code-block:: c
@@ -429,37 +431,38 @@ C 程序員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
}
EXPORT_SYMBOL(system_is_up);
-6.1) 函數原型
+6.1) 函式原型
*************
-在函數原型中包含參數名和它們的數據類型。雖然 C 語言裏沒有這樣的要求，但在
-Linux 裏這是提倡的做法，因爲這樣可以很簡單的給讀者提供更多的有價值的信息。
+在函式原型中包含參數名和它們的資料類型。雖然 C 語言裡沒有這樣的要求，但在
+Linux 裡這是提倡的做法，因為這樣可以很簡單的給讀者提供更多的有價值的資訊。
-不要在函數聲明裏使用 ``extern`` 關鍵字，因爲這會導致代碼行變長，並且不是嚴格
+不要在函式宣告裡使用 ``extern`` 關鍵字，因為這會導致程式碼行變長，並且不是嚴格
必需的。
-寫函數原型時，請保持 `元素順序規則 <https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_ 。
-例如下列函數聲明::
+寫函式原型時，請保持 `元素順序規則 <https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_ 。
+例如下列函式宣告::
__init void * __must_check action(enum magic value, size_t size, u8 count,
char *fmt, ...) __printf(4, 5) __malloc;
-推薦的函數原型元素順序是：
+推薦的函式原型元素順序是：
- 儲存類型（下方的 ``static __always_inline`` ，注意 ``__always_inline``
技術上來講是個屬性但被當做 ``inline`` ）
-- 儲存類型屬性（上方的 ``__init`` ——即節聲明，但也像 ``__cold`` ）
+- 儲存類型屬性（上方的 ``__init`` ——即節宣告，但也像 ``__cold`` ）
- 返回類型（上方的 ``void *`` ）
- 返回類型屬性（上方的 ``__must_check`` ）
-- 函數名（上方的 ``action`` ）
-- 函數參數（上方的 ``(enum magic value, size_t size, u8 count, char *fmt, ...)`` ，
- 注意必須寫上參數名）
-- 函數參數屬性（上方的 ``__printf(4, 5)`` ）
-- 函數行爲屬性（上方的 ``__malloc`` ）
+- 函式名（上方的 ``action`` ）
+- 函式參數（上方的
+ ``(enum magic value, size_t size, u8 count, char *fmt, ...)`` ，注意必須
+ 寫上參數名）
+- 函式參數屬性（上方的 ``__printf(4, 5)`` ）
+- 函式行為屬性（上方的 ``__malloc`` ）
-請注意，對於函數 **定義** （即實際函數體），編譯器不允許在函數參數之後添加函
-數參數屬性。在這種情況下，它們應該跟隨存儲類型屬性（例如，與上面的 **聲明**
-示例相比，請注意下面的 ``__printf(4, 5)`` 的位置發生了變化）::
+請注意，對於函式 **定義** （即實際函式體），編譯器不允許在函式參數之後添加函
+數參數屬性。在這種情況下，它們應該跟隨儲存類型屬性（例如，與上面的 **宣告**
+範例相比，請注意下面的 ``__printf(4, 5)`` 的位置發生了變化）::
static __always_inline __init __printf(4, 5) void * __must_check action(enum magic value,
size_t size, u8 count, char *fmt, ...) __malloc
@@ -467,26 +470,26 @@ Linux 裏這是提倡的做法，因爲這樣可以很簡單的給讀者提供
...
}
-7) 集中的函數退出途徑
+7) 集中的函式退出途徑
---------------------
雖然被某些人聲稱已經過時，但是 goto 語句的等價物還是經常被編譯器所使用，具體
形式是無條件跳轉指令。
-當一個函數從多個位置退出，並且需要做一些類似清理的常見操作時，goto 語句就很方
+當一個函式從多個位置退出，並且需要做一些類似清理的常見操作時，goto 語句就很方
便了。如果並不需要清理操作，那麼直接 return 即可。
-選擇一個能夠說明 goto 行爲或它爲何存在的標籤名。如果 goto 要釋放 ``buffer``,
+選擇一個能夠說明 goto 行為或它為何存在的標籤名。如果 goto 要釋放 ``buffer``,
一個不錯的名字可以是 ``out_free_buffer:`` 。別去使用像 ``err1:`` 和 ``err2:``
-這樣的GW_BASIC 名稱，因爲一旦你添加或刪除了 (函數的) 退出路徑，你就必須對它們
+這樣的GW_BASIC 名稱，因為一旦你添加或刪除了 (函式的) 退出路徑，你就必須對它們
重新編號，這樣會難以去檢驗正確性。
使用 goto 的理由是：
-- 無條件語句容易理解和跟蹤
+- 無條件語句容易理解和追蹤
- 嵌套程度減小
- 可以避免由於修改時忘記更新個別的退出點而導致錯誤
-- 讓編譯器省去刪除冗餘代碼的工作 ;)
+- 讓編譯器省去刪除冗餘程式碼的工作 ;)
.. code-block:: c
@@ -521,7 +524,7 @@ Linux 裏這是提倡的做法，因爲這樣可以很簡單的給讀者提供
kfree(foo);
return ret;
-這段代碼的錯誤是，在某些退出路徑上 ``foo`` 是 NULL。通常情況下，通過把它分離
+這段程式碼的錯誤是，在某些退出路徑上 ``foo`` 是 NULL。通常情況下，透過把它分離
成兩個錯誤標籤 ``err_free_bar:`` 和 ``err_free_foo:`` 來修復這個錯誤：
.. code-block:: c
@@ -535,22 +538,23 @@ Linux 裏這是提倡的做法，因爲這樣可以很簡單的給讀者提供
理想情況下，你應該模擬錯誤來測試所有退出路徑。
-8) 註釋
+8) 註解
-------
-註釋是好的，不過有過度註釋的危險。永遠不要在註釋裏解釋你的代碼是如何運作的：
-更好的做法是讓別人一看你的代碼就可以明白，解釋寫的很差的代碼是浪費時間。
+註解是好的，不過有過度註解的危險。永遠不要在註解裡解釋你的程式碼是如何運作的：
+更好的做法是讓別人一看你的程式碼就可以明白，解釋寫的很差的程式碼是浪費時間。
-一般來說你用註釋告訴別人你的代碼做了什麼，而不是怎麼做的。也請你不要把
-註釋放在一個函數體內部：如果函數複雜到你需要獨立的註釋其中的一部分，你很可能
-需要回到第六章看一看。你可以做一些小注釋來註明或警告某些很聰明 (或者槽糕) 的
-做法，但不要加太多。你應該做的，是把註釋放在函數的頭部，告訴人們它做了什麼，
+一般來說你用註解告訴別人你的程式碼做了什麼，而不是怎麼做的。也請你不要把
+註解放在一個函式體內部：如果函式複雜到你需要獨立的註解其中的一部分，你很可能
+需要回到第六章看一看。你可以做一些小註解來註明或警告某些很聰明 (或者槽糕) 的
+做法，但不要加太多。你應該做的，是把註解放在函式的頭部，告訴人們它做了什麼，
也可以加上它做這些事情的原因。
-當註釋內核 API 函數時，請使用 kernel-doc 格式。詳見
-Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc 。
+當註解核心 API 函式時，請使用 kernel-doc 格式。詳見
+Documentation/translations/zh_CN/doc-guide/index.rst 和
+tools/docs/kernel-doc 。
-長 (多行) 註釋的首選風格是：
+長 (多行) 註解的首選風格是：
.. code-block:: c
@@ -563,7 +567,7 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc
* with beginning and ending almost-blank lines.
*/
-對於在 net/ 和 drivers/net/ 的文件，首選的長 (多行) 註釋風格有些不同。
+對於在 net/ 和 drivers/net/ 的檔案，首選的長 (多行) 註解風格有些不同。
.. code-block:: c
@@ -574,22 +578,22 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc
* but there is no initial almost-blank line.
*/
-註釋數據也是很重要的，不管是基本類型還是衍生類型。爲了方便實現這一點，每一行
-應只聲明一個數據 (不要使用逗號來一次聲明多個數據)。這樣你就有空間來爲每個數據
-寫一段小注釋來解釋它們的用途了。
+註解資料也是很重要的，不管是基本類型還是衍生類型。為了方便實作這一點，每一行
+應只宣告一個資料 (不要使用逗號來一次宣告多個資料)。這樣你就有空間來為每個資料
+寫一段小註解來解釋它們的用途了。
9) 你已經把事情弄糟了
---------------------
-這沒什麼，我們都是這樣。可能你長期使用 Unix 的朋友已經告訴你
-``GNU emacs`` 能自動幫你格式化 C 源代碼，而且你也注意到了，確實是這樣，不過它
-所使用的默認值和我們想要的相去甚遠 (實際上，甚至比隨機打的還要差——無數個猴子
-在 GNU emacs 裏打字永遠不會創造出一個好程序)
+這沒什麼，我們都是這樣。可能你長期使用 Unix 的朋友已經告訴你``GNU emacs``
+能自動幫你格式化 C 原始程式碼，而且你也注意到了，確實是這樣，不過它所使用
+的預設值和我們想要的相去甚遠 (實際上，甚至比隨機打的還要差——無數個猴子在
+GNU emacs 裡打字永遠不會創造出一個好程式)
*(譯註：Infinite Monkey Theorem)*
所以你要麼放棄 GNU emacs，要麼改變它讓它使用更合理的設定。要採用後一個方案，
-你可以把下面這段粘貼到你的 .emacs 文件裏。
+你可以把下面這段貼上到你的 .emacs 檔案裡。
.. code-block:: elisp
@@ -640,31 +644,31 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc
(expand-file-name "~/src/linux-trees")
'linux-kernel)
-這會讓 emacs 在 ``~/src/linux-trees`` 下的 C 源文件獲得更好的內核代碼風格。
+這會讓 emacs 在 ``~/src/linux-trees`` 下的 C 原始檔獲得更好的核心程式碼風格。
-不過就算你嘗試讓 emacs 正確的格式化代碼失敗了，也並不意味着你失去了一切：還可
-以用 ``indent`` 。
+不過就算你嘗試讓 emacs 正確的格式化程式碼失敗了，也並不意味著你失去了一切：
+還可以用 ``indent`` 。
不過，GNU indent 也有和 GNU emacs 一樣有問題的設定，所以你需要給它一些命令選
-項。不過，這還不算太糟糕，因爲就算是 GNU indent 的作者也認同 K&R 的權威性
+項。不過，這還不算太糟糕，因為就算是 GNU indent 的作者也認同 K&R 的權威性
(GNU 的人並不是壞人，他們只是在這個問題上被嚴重的誤導了)，所以你只要給 indent
-指定選項 ``-kr -i8`` (代表 ``K&R，8 字符縮進``)，或使用 ``scripts/Lindent``
-這樣就可以以最時髦的方式縮進源代碼。
+指定選項 ``-kr -i8`` (代表 ``K&R，8 字元縮排``)，或使用 ``scripts/Lindent``
+這樣就可以以最時髦的方式縮排原始程式碼。
-``indent`` 有很多選項，特別是重新格式化註釋的時候，你可能需要看一下它的手冊。
-不過記住： ``indent`` 不能修正壞的編程習慣。
+``indent`` 有很多選項，特別是重新格式化註解的時候，你可能需要看一下它的手冊。
+不過記住： ``indent`` 不能修正壞的程式設計習慣。
-請注意，您還可以使用 ``clang-format`` 工具幫助您處理這些規則，快速自動重新格
-式化部分代碼，並審閱整個文件以發現代碼風格錯誤、打字錯誤和可能的改進。它還可
-以方便地排序 ``#include`` ，對齊變量/宏，重排文本和其他類似任務。
+請注意，您還可以使用 ``clang-format`` 工具幫助您處理這些規則，快速自動重新
+格式化部分程式碼，並審閱整個檔案以發現程式碼風格錯誤、打字錯誤和可能的改進。
+它還可以方便地排序 ``#include`` ，對齊變數/巨集，重排文字和其他類似任務。
詳見 Documentation/dev-tools/clang-format.rst 。
-10) Kconfig 配置文件
+10) Kconfig 設定檔
--------------------
-對於遍佈源碼樹的所有 Kconfig* 配置文件來說，它們縮進方式有所不同。緊挨着
-``config`` 定義的行，用一個製表符縮進，然而 help 信息的縮進則額外增加 2 個空
+對於遍佈源碼樹的所有 Kconfig* 設定文件來說，它們縮排方式有所不同。緊挨著
+``config`` 定義的行，用一個製表符縮排，然而 help 資訊的縮排則額外增加 2 個空
格。舉個例子::
config AUDIT
@@ -676,7 +680,7 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc
logging of avc messages output). Does not do system-call
auditing without CONFIG_AUDITSYSCALL.
-而那些危險的功能 (比如某些文件系統的寫支持) 應該在它們的提示字符串裏顯著的聲
+而那些危險的功能 (比如某些檔案系統的寫支援) 應該在它們的提示字串裡顯著的聲
明這一點::
config ADFS_FS_RW
@@ -684,49 +688,50 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc
depends on ADFS_FS
...
-要查看配置文件的完整文檔，請看 Documentation/kbuild/kconfig-language.rst 。
+要查看設定文件的完整文件，請看 Documentation/kbuild/kconfig-language.rst 。
-11) 數據結構
+11) 資料結構
------------
-如果一個數據結構，在創建和銷燬它的單線執行環境之外可見，那麼它必須要有一個引
-用計數器。內核裏沒有垃圾收集 (並且內核之外的垃圾收集慢且效率低下)，這意味着你
-絕對需要記錄你對這種數據結構的使用情況。
+如果一個資料結構，在建立和銷燬它的單線執行環境之外可見，那麼它必須要有一個引
+用計數器。核心裡沒有垃圾收集 (並且核心之外的垃圾收集慢且效率低下)，這意味著你
+絕對需要記錄你對這種資料結構的使用情況。
-引用計數意味着你能夠避免上鎖，並且允許多個用戶並行訪問這個數據結構——而不需要
-擔心這個數據結構僅僅因爲暫時不被使用就消失了，那些用戶可能不過是沉睡了一陣或
+引用計數意味著你能夠避免上鎖，並且允許多個使用者並行存取這個資料結構——而不需要
+擔心這個資料結構僅僅因為暫時不被使用就消失了，那些使用者可能不過是沉睡了一陣或
者做了一些其他事情而已。
-注意上鎖 **不能** 取代引用計數。上鎖是爲了保持數據結構的一致性，而引用計數是一
-個內存管理技巧。通常二者都需要，不要把兩個搞混了。
+注意上鎖 **不能** 取代引用計數。上鎖是為了保持資料結構的一致性，而引用計數是一
+個記憶體管理技巧。通常二者都需要，不要把兩個搞混了。
-很多數據結構實際上有 2 級引用計數，它們通常有不同 ``類`` 的用戶。子類計數器統
-計子類用戶的數量，每當子類計數器減至零時，全局計數器減一。
+很多資料結構實際上有 2 級引用計數，它們通常有不同 ``類`` 的使用者。子類計
+數器統計子類使用者的數量，每當子類計數器減至零時，全域計數器減一。
-這種 ``多級引用計數`` 的例子可以在內存管理 (``struct mm_struct``: mm_users 和
-mm_count)，和文件系統 (``struct super_block``: s_count 和 s_active) 中找到。
+這種 ``多級引用計數`` 的例子可以在記憶體管理 (``struct mm_struct``:
+mm_users 和mm_count)，和檔案系統 (``struct super_block``: s_count 和
+s_active) 中找到。
-記住：如果另一個執行線索可以找到你的數據結構，但這個數據結構沒有引用計數器，
-這裏幾乎肯定是一個 bug。
+記住：如果另一個執行線索可以找到你的資料結構，但這個資料結構沒有引用計數器，
+這裡幾乎肯定是一個 bug。
-12) 宏，枚舉和RTL
------------------
+12) 巨集，列舉和RTL
+-------------------
-用於定義常量的宏的名字及枚舉裏的標籤需要大寫。
+用於定義常數的巨集的名字及列舉裡的標籤需要大寫。
.. code-block:: c
#define CONSTANT 0x12345
-在定義幾個相關的常量時，最好用枚舉。
+在定義幾個相關的常數時，最好用列舉。
-宏的名字請用大寫字母，不過形如函數的宏的名字可以用小寫字母。
+巨集的名字請用大寫字母，不過形如函式的巨集的名字可以用小寫字母。
-通常如果能寫成內聯函數就不要寫成像函數的宏。
+通常如果能寫成行內函式就不要寫成像函式的巨集。
-含有多個語句的宏應該被包含在一個 do-while 代碼塊裏：
+含有多個語句的巨集應該被包含在一個 do-while 程式碼塊裡：
.. code-block:: c
@@ -736,9 +741,9 @@ mm_count)，和文件系統 (``struct super_block``: s_count 和 s_active) 中
do_this(b, c); \
} while (0)
-使用宏的時候應避免的事情：
+使用巨集的時候應避免的事情：
-1) 影響控制流程的宏：
+1) 影響控制流程的巨集：
.. code-block:: c
@@ -748,30 +753,30 @@ mm_count)，和文件系統 (``struct super_block``: s_count 和 s_active) 中
return -EBUGGERED; \
} while (0)
-**非常** 不好。它看起來像一個函數，不過卻能導致 ``調用`` 它的函數退出；不要打
-亂讀者大腦裏的語法分析器。
+**非常** 不好。它看起來像一個函式，不過卻能導致 ``呼叫`` 它的函式退出；不要打
+亂讀者大腦裡的語法分析器。
-2) 依賴於一個固定名字的本地變量的宏：
+2) 依賴於一個固定名字的本地變數的巨集：
.. code-block:: c
#define FOO(val) bar(index, val)
-可能看起來像是個不錯的東西，不過它非常容易把讀代碼的人搞糊塗，而且容易導致看起
-來不相關的改動帶來錯誤。
+可能看起來像是個不錯的東西，不過它非常容易把讀程式碼的人搞糊塗，而且容易導
+致看起來不相關的改動帶來錯誤。
-3) 作爲左值的帶參數的宏： FOO(x) = y；如果有人把 FOO 變成一個內聯函數的話，這
+3) 作為左值的帶參數的巨集： FOO(x) = y；如果有人把 FOO 變成一個行內函式的話，這
種用法就會出錯了。
-4) 忘記了優先級：使用表達式定義常量的宏必須將表達式置於一對小括號之內。帶參數
- 的宏也要注意此類問題。
+4) 忘記了優先級：使用表達式定義常數的巨集必須將表達式置於一對小括號之內。帶參數
+ 的巨集也要注意此類問題。
.. code-block:: c
#define CONSTANT 0x4000
#define CONSTEXP (CONSTANT | 3)
-5) 在宏裏定義類似函數的本地變量時命名衝突：
+5) 在巨集裡定義類似函式的本地變數時命名衝突：
.. code-block:: c
@@ -782,45 +787,45 @@ mm_count)，和文件系統 (``struct super_block``: s_count 和 s_active) 中
(ret); \
})
-ret 是本地變量的通用名字—— __foo_ret 更不容易與一個已存在的變量衝突。
+ret 是本地變數的通用名字—— __foo_ret 更不容易與一個已存在的變數衝突。
-cpp 手冊對宏的講解很詳細。gcc internals 手冊也詳細講解了 RTL，內核裏的彙編語
+cpp 手冊對巨集的講解很詳細。gcc internals 手冊也詳細講解了 RTL，核心裡的組譯語
言經常用到它。
-13) 打印內核消息
+13) 列印核心訊息
----------------
-內核開發者應該看起來有文化。請一定注意內核信息的拼寫，以給人良好的印象。
+核心開發者應該看起來有文化。請一定注意核心資訊的拼寫，以給人良好的印象。
不要用不規範的單詞比如 ``dont``，而要用 ``do not`` 或者 ``don't`` 。保證這些信
息簡單明瞭、無歧義。
-內核信息不必以英文句號結束。
+核心資訊不必以英文句號結束。
-在小括號裏打印數字 (%d) 沒有任何價值，應該避免這樣做。
+在小括號裡列印數字 (%d) 沒有任何價值，應該避免這樣做。
-<linux/device.h> 裏有一些驅動模型診斷宏，你應該使用它們，以確保信息對應於正確
-的設備和驅動，並且被標記了正確的消息級別。這些宏有：dev_err(), dev_warn(),
-dev_info() 等等。對於那些不和某個特定設備相關連的信息，<linux/printk.h> 定義
-了 pr_notice(), pr_info(), pr_warn(), pr_err() 和其他。
+<linux/device.h> 裡有一些驅動模型診斷巨集，你應該使用它們，以確保資訊對應
+於正確的設備和驅動，並且被標記了正確的訊息級別。這些巨集有：dev_err(),
+dev_warn(),dev_info() 等等。對於那些不和某個特定設備相關連的資訊，
+<linux/printk.h> 定義了 pr_notice(), pr_info(), pr_warn(), pr_err() 和其他。
-寫出好的調試信息可以是一個很大的挑戰；一旦你寫出後，這些信息在遠程除錯時能提
-供極大的幫助。然而打印調試信息的處理方式同打印非調試信息不同。其他 pr_XXX()
-函數能無條件地打印，pr_debug() 卻不；默認情況下它不會被編譯，除非定義了 DEBUG
-或設定了 CONFIG_DYNAMIC_DEBUG。實際這同樣是爲了 dev_dbg()，一個相關約定是在一
-個已經開啓了 DEBUG 時，使用 VERBOSE_DEBUG 來添加 dev_vdbg()。
+寫出好的除錯資訊可以是一個很大的挑戰；一旦你寫出後，這些資訊在遠端除錯時能提
+供極大的幫助。然而列印除錯資訊的處理方式同列印非除錯資訊不同。其他 pr_XXX()
+函式能無條件地列印，pr_debug() 卻不；預設情況下它不會被編譯，除非定義了 DEBUG
+或設定了 CONFIG_DYNAMIC_DEBUG。實際這同樣是為了 dev_dbg()，一個相關約定是在一
+個已經開啟了 DEBUG 時，使用 VERBOSE_DEBUG 來添加 dev_vdbg()。
-許多子系統擁有 Kconfig 調試選項來開啓對應 Makefile 裏面的 -DDEBUG；在其他
-情況下，特殊文件使用 #define DEBUG。當一條調試信息需要被無條件打印時，例如，
-如果已經包含一個調試相關的 #ifdef 條件，printk(KERN_DEBUG ...) 就可被使用。
+許多子系統擁有 Kconfig 除錯選項來開啟對應 Makefile 裡面的 -DDEBUG；在其他
+情況下，特定檔案使用 #define DEBUG。當一條除錯資訊需要被無條件列印時，例如，
+如果已經包含一個除錯相關的 #ifdef 條件，printk(KERN_DEBUG ...) 就可被使用。
-14) 分配內存
-------------
+14) 分配記憶體
+--------------
-內核提供了下面的一般用途的內存分配函數：
-kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc() 和 vzalloc()。
-請參考 API 文檔以獲取有關它們的詳細信息：
+核心提供了下面的一般用途的記憶體分配函式：
+kmalloc(), kzalloc(), kmalloc_objs(), kzalloc_objs(), vmalloc() 和 vzalloc()。
+請參考 API 文件以獲取有關它們的詳細資訊：
Documentation/translations/zh_CN/core-api/memory-allocation.rst 。
傳遞結構體大小的首選形式是這樣的：
@@ -830,103 +835,106 @@ Documentation/translations/zh_CN/core-api/memory-allocation.rst 。
p = kmalloc_obj(*p, ...);
另外一種傳遞方式中，sizeof 的操作數是結構體的名字，這樣會降低可讀性，並且可能
-會引入 bug。有可能指針變量類型被改變時，而對應的傳遞給內存分配函數的 sizeof
+會引入 bug。有可能指標變數類型被改變時，而對應的傳遞給記憶體分配函式的 sizeof
的結果不變。
-強制轉換一個 void 指針返回值是多餘的。C 語言本身保證了從 void 指針到其他任何
-指針類型的轉換是沒有問題的。
+強制轉換一個 void 指標回傳值是多餘的。C 語言本身保證了從 void 指標到其他任何
+指標類型的轉換是沒有問題的。
-分配一個數組的首選形式是這樣的：
+分配一個陣列的首選形式是這樣的：
.. code-block:: c
- p = kmalloc_array(n, sizeof(...), ...);
+ p = kmalloc_objs(*p, n, ...);
-分配一個零長數組的首選形式是這樣的：
+分配一個零長陣列的首選形式是這樣的：
.. code-block:: c
- p = kcalloc(n, sizeof(...), ...);
+ p = kzalloc_objs(*p, n, ...);
+
+這兩種形式都會檢查分配大小 n * sizeof(...) 是否溢位，如果發生溢位則回傳
+NULL。
-兩種形式都會檢查分配 n * sizeof(...) 大小時內存的溢出，如果溢出返回 NULL。
+兩種形式都會檢查分配 n * sizeof(...) 大小時記憶體的溢出，如果溢出返回 NULL。
-在沒有 __GFP_NOWARN 的情況下使用時，這些通用分配函數都會在失敗時發起堆棧轉儲，
-因此當返回NULL時，沒有必要發出額外的失敗消息。
+在沒有 __GFP_NOWARN 的情況下使用時，這些通用分配函式都會在失敗時發起堆疊轉儲，
+因此當返回NULL時，沒有必要發出額外的失敗訊息。
-15) 內聯弊病
+15) 行內弊病
------------
-有一個常見的誤解是 ``內聯`` 是 gcc 提供的可以讓代碼運行更快的一個選項。雖然使
-用內聯函數有時候是恰當的 (比如作爲一種替代宏的方式，請看第十二章)，不過很多情
-況下不是這樣。inline 的過度使用會使內核變大，從而使整個系統運行速度變慢。
-因爲體積大內核會佔用更多的指令高速緩存，而且會導致 pagecache 的可用內存減少。
-想象一下，一次 pagecache 未命中就會導致一次磁盤尋址，將耗時 5 毫秒。5 毫秒的
-時間內 CPU 能執行很多很多指令。
-
-一個基本的原則是如果一個函數有 3 行以上，就不要把它變成內聯函數。這個原則的一
-個例外是，如果你知道某個參數是一個編譯時常量，而且因爲這個常量你確定編譯器在
-編譯時能優化掉你的函數的大部分代碼，那仍然可以給它加上 inline 關鍵字。
-kmalloc() 內聯函數就是一個很好的例子。
-
-人們經常主張給 static 的而且只用了一次的函數加上 inline，如此不會有任何損失，
-因爲沒有什麼好權衡的。雖然從技術上說這是正確的，但是實際上這種情況下即使不加
-inline gcc 也可以自動使其內聯。而且其他用戶可能會要求移除 inline，由此而來的
+有一個常見的誤解是 ``行內`` 是 gcc 提供的可以讓程式碼執行更快的一個選項。
+雖然使用行內函式有時候是恰當的 (比如作為一種替代巨集的方式，請看第十二章)，
+不過很多情況下不是這樣。inline 的過度使用會使核心變大，從而使整個系統執行
+速度變慢。因為體積大核心會佔用更多的指令高速快取，而且會導致 pagecache 的
+可用記憶體減少。想象一下，一次 pagecache 未命中就會導致一次磁碟尋址，將耗
+時 5 毫秒。5 毫秒的時間內 CPU 能執行很多很多指令。
+
+一個基本的原則是如果一個函式有 3 行以上，就不要把它變成行內函式。這個原則的一
+個例外是，如果你知道某個參數是一個編譯時常數，而且因為這個常數你確定編譯器在
+編譯時能最佳化掉你的函式的大部分程式碼，那仍然可以給它加上 inline 關鍵字。
+kmalloc() 行內函式就是一個很好的例子。
+
+人們經常主張給 static 的而且只用了一次的函式加上 inline，如此不會有任何損失，
+因為沒有什麼好權衡的。雖然從技術上說這是正確的，但是實際上這種情況下即使不加
+inline gcc 也可以自動使其行內。而且其他使用者可能會要求移除 inline，由此而來的
爭論會抵消 inline 自身的潛在價值，得不償失。
-16) 函數返回值及命名
+16) 函式回傳值及命名
--------------------
-函數可以返回多種不同類型的值，最常見的一種是表明函數執行成功或者失敗的值。這樣
-的一個值可以表示爲一個錯誤代碼整數 (-Exxx＝失敗，0＝成功) 或者一個 ``成功``
-布爾值 (0＝失敗，非0＝成功)。
+函式可以返回多種不同類型的值，最常見的一種是表明函式執行成功或者失敗的值。這樣
+的一個值可以表示為一個錯誤程式碼整數 (-Exxx＝失敗，0＝成功) 或者一個 ``成功``
+布林值 (0＝失敗，非0＝成功)。
混合使用這兩種表達方式是難於發現的 bug 的來源。如果 C 語言本身嚴格區分整形和
-布爾型變量，那麼編譯器就能夠幫我們發現這些錯誤... 不過 C 語言不區分。爲了避免
+布林型變數，那麼編譯器就能夠幫我們發現這些錯誤... 不過 C 語言不區分。為了避免
產生這種 bug，請遵循下面的慣例::
- 如果函數的名字是一個動作或者強制性的命令，那麼這個函數應該返回錯誤代
- 碼整數。如果是一個判斷，那麼函數應該返回一個“成功”布爾值。
+ 如果函式的名字是一個動作或者強制性的命令，那麼這個函式應該返回錯誤代
+ 碼整數。如果是一個判斷，那麼函式應該返回一個“成功”布林值。
比如， ``add work`` 是一個命令，所以 add_work() 在成功時返回 0，在失敗時返回
--EBUSY。類似的，因爲 ``PCI device present`` 是一個判斷，所以 pci_dev_present()
+-EBUSY。類似的，因為 ``PCI device present`` 是一個判斷，所以 pci_dev_present()
在成功找到一個匹配的設備時應該返回 1，如果找不到時應該返回 0。
-所有 EXPORTed 函數都必須遵守這個慣例，所有的公共函數也都應該如此。私有
-(static) 函數不需要如此，但是我們也推薦這樣做。
+所有 EXPORTed 函式都必須遵守這個慣例，所有的公共函式也都應該如此。私有
+(static) 函式不需要如此，但是我們也推薦這樣做。
-返回值是實際計算結果而不是計算是否成功的標誌的函數不受此慣例的限制。通常
-他們通過返回一些正常值範圍之外的結果來表示出錯。典型的例子是返回指針的函數，
+回傳值是實際計算結果而不是計算是否成功的標誌的函式不受此慣例的限制。通常
+他們透過返回一些正常值範圍之外的結果來表示出錯。典型的例子是返回指標的函式，
他們使用 NULL 或者 ERR_PTR 機制來報告錯誤。
-17) 使用布爾類型
+17) 使用布林類型
----------------
-Linux內核布爾（bool）類型是C99 _Bool類型的別名。布爾值只能爲0或1，而對布爾的
-隱式或顯式轉換將自動將值轉換爲true或false。在使用布爾類型時 **不需要** 構造，
+Linux核心布林（bool）類型是C99 _Bool類型的別名。布林值只能為0或1，而對布林的
+隱式或顯式轉換將自動將值轉換為true或false。在使用布林類型時 **不需要** 構造，
它會消除一類錯誤。
-使用布爾值時，應使用true和false定義，而不是1和0。
+使用布林值時，應使用true和false定義，而不是1和0。
-布爾函數返回類型和堆棧變量總是可以在適當的時候使用。鼓勵使用布爾來提高可讀性，
-並且布爾值在存儲時通常比“int”更好。
+布林函式返回類型和堆疊變數總是可以在適當的時候使用。鼓勵使用布林來提高可讀性，
+並且布林值在儲存時通常比“int”更好。
-如果緩存行佈局或值的大小很重要，請不要使用布爾，因爲其大小和對齊方式根據編譯
-的體系結構而不同。針對對齊和大小進行優化的結構體不應使用布爾。
+如果快取行佈局或值的大小很重要，請不要使用布林，因為其大小和對齊方式根據編譯
+的體系結構而不同。針對對齊和大小進行最佳化的結構體不應使用布林。
-如果一個結構體有多個true/false值，請考慮將它們合併爲具有1比特成員的位域，或使
+如果一個結構體有多個true/false值，請考慮將它們合併為具有1比特成員的位域，或使
用適當的固定寬度類型，如u8。
-類似地，對於函數參數，多個true/false值可以合併爲單個按位的“標誌”參數，如果調
-用點具有裸true/false常量，“標誌”參數通常是更具可讀性的替代方法。
+類似地，對於函式參數，多個true/false值可以合併為單個按位的“標誌”參數，如果調
+用點具有裸true/false常數，“標誌”參數通常是更具可讀性的替代方法。
-總之，在結構體和參數中有限地使用布爾可以提高可讀性。
+總之，在結構體和參數中有限地使用布林可以提高可讀性。
-18) 不要重新發明內核宏
-----------------------
+18) 不要重新發明核心巨集
+------------------------
-頭文件 include/linux/kernel.h 包含了一些宏，你應該使用它們，而不要自己寫一些
-它們的變種。比如，如果你需要計算一個數組的長度，使用這個宏
+標頭檔 include/linux/kernel.h 包含了一些巨集，你應該使用它們，而不要自己寫一些
+它們的變種。比如，如果你需要計算一個陣列的長度，使用這個巨集
.. code-block:: c
@@ -938,15 +946,15 @@ Linux內核布爾（bool）類型是C99 _Bool類型的別名。布爾值只能
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
-還有可以做嚴格的類型檢查的 min() 和 max() 宏，如果你需要可以使用它們。你可以
-自己看看那個頭文件裏還定義了什麼你可以拿來用的東西，如果有定義的話，你就不應
-在你的代碼裏自己重新定義。
+還有可以做嚴格的類型檢查的 min() 和 max() 巨集，如果你需要可以使用它們。你可以
+自己看看那個標頭檔裡還定義了什麼你可以拿來用的東西，如果有定義的話，你就不應
+在你的程式碼裡自己重新定義。
19) 編輯器模式行和其他需要羅嗦的事情
------------------------------------
-有一些編輯器可以解釋嵌入在源文件裏的由一些特殊標記標明的配置信息。比如，emacs
+有一些編輯器可以解釋嵌入在原始檔裡的由一些特殊標記標明的設定資訊。比如，emacs
能夠解析被標記成這樣的行：
.. code-block:: c
@@ -969,29 +977,29 @@ Vim 能夠解析這樣的標記：
/* vim:set sw=8 noet */
-不要在源代碼中包含任何這樣的內容。每個人都有他自己的編輯器配置，你的源文件不
-應該覆蓋別人的配置。這包括有關縮進和模式配置的標記。人們可以使用他們自己定製
-的模式，或者使用其他可以產生正確的縮進的巧妙方法。
+不要在原始程式碼中包含任何這樣的內容。每個人都有他自己的編輯器設定，你的原
+始檔不應該覆蓋別人的設定。這包括有關縮排和模式設定的標記。人們可以使用他們
+自己定製的模式，或者使用其他可以產生正確的縮排的巧妙方法。
-20) 內聯彙編
+20) 行內組譯
------------
-在特定架構的代碼中，你可能需要內聯彙編與 CPU 和平臺相關功能連接。需要這麼做時
-就不要猶豫。然而，當 C 可以完成工作時，不要平白無故地使用內聯彙編。在可能的情
-況下，你可以並且應該用 C 和硬件溝通。
+在特定架構的程式碼中，你可能需要行內組譯與 CPU 和平臺相關功能連接。需要這
+麼做時就不要猶豫。然而，當 C 可以完成工作時，不要平白無故地使用行內組譯。
+在可能的情況下，你可以並且應該用 C 和硬體溝通。
-請考慮去寫捆綁通用位元 (wrap common bits) 的內聯彙編的簡單輔助函數，別去重複
-地寫下只有細微差異內聯彙編。記住內聯彙編可以使用 C 參數。
+請考慮去寫捆綁通用位元 (wrap common bits) 的行內組譯的簡單輔助函式，別去重複
+地寫下只有細微差異行內組譯。記住行內組譯可以使用 C 參數。
-大型，有一定複雜度的彙編函數應該放在 .S 文件內，用相應的 C 原型定義在 C 頭文
-件中。彙編函數的 C 原型應該使用 ``asmlinkage`` 。
+大型，有一定複雜度的組譯函式應該放在 .S 檔案內，用相應的 C 原型定義在 C 標頭
+檔中。組譯函式的 C 原型應該使用 ``asmlinkage`` 。
-你可能需要把彙編語句標記爲 volatile，用來阻止 GCC 在沒發現任何副作用後就把它
-移除了。你不必總是這樣做，儘管，這不必要的舉動會限制優化。
+你可能需要把組譯語句標記為 volatile，用來阻止 GCC 在沒發現任何副作用後就把它
+移除了。你不必總是這樣做，儘管，這不必要的舉動會限制最佳化。
-在寫一個包含多條指令的單個內聯彙編語句時，把每條指令用引號分割而且各佔一行，
-除了最後一條指令外，在每個指令結尾加上 ``\n\t`` ，讓彙編輸出時可以正確地縮進
+在寫一個包含多條指令的單個行內組譯語句時，把每條指令用引號分割而且各佔一行，
+除了最後一條指令外，在每個指令結尾加上 ``\n\t`` ，讓組譯輸出時可以正確地縮排
下一條指令：
.. code-block:: c
@@ -1004,21 +1012,21 @@ Vim 能夠解析這樣的標記：
21) 條件編譯
------------
-只要可能，就不要在 .c 文件裏面使用預處理條件 (#if, #ifdef)；這樣做會讓代碼更難
-閱讀並且更難去跟蹤邏輯。替代方案是，在頭文件中用預處理條件提供給那些 .c 文件
-使用，再給 #else 提供一個空樁 (no-op stub) 版本，然後在 .c 文件內無條件地調用
-那些 (定義在頭文件內的) 函數。這樣做，編譯器會避免爲樁函數 (stub) 的調用生成
-任何代碼，產生的結果是相同的，但邏輯將更加清晰。
+只要可能，就不要在 .c 檔案裡面使用預處理條件 (#if, #ifdef)；這樣做會讓程式
+碼更難閱讀並且更難去追蹤邏輯。替代方案是，在標頭檔中用預處理條件提供給那些
+.c 檔案使用，再給 #else 提供一個空樁 (no-op stub) 版本，然後在 .c 檔案內無
+條件地呼叫那些 (定義在標頭檔內的) 函式。這樣做，編譯器會避免為樁函式 (stub
+) 的呼叫產生任何程式碼，產生的結果是相同的，但邏輯將更加清晰。
-最好傾向於編譯整個函數，而不是函數的一部分或表達式的一部分。與其放一個 ifdef
-在表達式內，不如分解出部分或全部表達式，放進一個單獨的輔助函數，並應用預處理
-條件到這個輔助函數內。
+最好傾向於編譯整個函式，而不是函式的一部分或表達式的一部分。與其放一個 ifdef
+在表達式內，不如分解出部分或全部表達式，放進一個單獨的輔助函式，並應用預處理
+條件到這個輔助函式內。
-如果你有一個在特定配置中，可能變成未使用的函數或變量，編譯器會警告它定義了但
-未使用，請把它標記爲 __maybe_unused 而不是將它包含在一個預處理條件中。(然而，
-如果一個函數或變量總是未使用，就直接刪除它。)
+如果你有一個在特定設定中，可能變成未使用的函式或變數，編譯器會警告它定義了但
+未使用，請把它標記為 __maybe_unused 而不是將它包含在一個預處理條件中。(然而，
+如果一個函式或變數總是未使用，就直接刪除它。)
-在代碼中，儘可能地使用 IS_ENABLED 宏來轉化某個 Kconfig 標記爲 C 的布爾
+在程式碼中，儘可能地使用 IS_ENABLED 巨集來轉化某個 Kconfig 標記為 C 的布林
表達式，並在一般的 C 條件中使用它：
.. code-block:: c
@@ -1027,13 +1035,13 @@ Vim 能夠解析這樣的標記：
...
}
-編譯器會做常量摺疊，然後就像使用 #ifdef 那樣去包含或排除代碼塊，所以這不會帶
-來任何運行時開銷。然而，這種方法依舊允許 C 編譯器查看塊內的代碼，並檢查它的正
-確性 (語法，類型，符號引用，等等)。因此，如果條件不滿足，代碼塊內的引用符號就
-不存在時，你還是必須去用 #ifdef。
+編譯器會做常數摺疊，然後就像使用 #ifdef 那樣去包含或排除程式碼塊，所以這不
+會帶來任何執行時開銷。然而，這種方法依舊允許 C 編譯器查看塊內的程式碼，並
+檢查它的正確性 (語法，類型，符號引用，等等)。因此，如果條件不滿足，程式碼
+塊內的引用符號就不存在時，你還是必須去用 #ifdef。
在任何有意義的 #if 或 #ifdef 塊的末尾 (超過幾行的)，在 #endif 同一行的後面寫下
-註解，註釋這個條件表達式。例如：
+註解，註解這個條件表達式。例如：
.. code-block:: c
@@ -1052,7 +1060,7 @@ ISBN 0-13-110362-8 (平裝), 0-13-110370-9 (精裝).
.. note::
- 《C程序設計語言（第2版）》
+ 《C程式設計語言（第2版）》
作者：[美] Brian W. Kernighan / [美] Dennis M. Ritchie
譯者：徐寶文 / 李志 / 尤晉元（審校）
出版社：機械工業出版社，2019
@@ -1065,23 +1073,23 @@ ISBN 0-201-61586-X.
.. note::
- 《程序設計實踐》
+ 《程式設計實踐》
作者：[美] Brian W. Kernighan / [美] Rob Pike
出版社：機械工業出版社，2005
ISBN：9787111091578
- 《程序設計實踐》
+ 《程式設計實踐》
作者：[美] Brian W. Kernighan / Rob Pike
譯者：裘宗燕
出版社：機械工業出版社，2000
ISBN：9787111075738
-GNU 手冊 - 遵循 K&R 標準和此文本 - cpp, gcc, gcc internals and indent,
+GNU 手冊 - 遵循 K&R 標準和此文字 - cpp, gcc, gcc internals and indent,
都可以從 https://www.gnu.org/manual/ 找到
WG14 是 C 語言的國際標準化工作組，URL: http://www.open-std.org/JTC1/SC22/WG14/
-內核文檔 Documentation/process/coding-style.rst，
+核心文件 Documentation/process/coding-style.rst，
作者 greg@kroah.com 發表於 OLS 2002：
http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 08/16] docs/zh_TW: process: localize terminology in stable-kernel-rules.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (6 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 07/16] docs/zh_TW: process: localize terminology in coding-style.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 09/16] docs/zh_TW: process: localize terminology in 5.Posting.rst Chen-Yu Yeh
` (8 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Retranslate from the current English text, which was heavily
restructured upstream (three submission options, stable tag variants,
tree list), and localize mainland terms to Taiwanese Mandarin
(內核→核心, 隊列→佇列, 數據→資料, ...).
update to commit 10466b17af65 ("docs: stable-kernel-rules: fix typo
sent->send")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../zh_TW/process/stable-kernel-rules.rst | 256 ++++++++++++++----
1 file changed, 208 insertions(+), 48 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
index 2f8f064f8629..7d286ad54f2e 100644
--- a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
+++ b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
@@ -6,7 +6,7 @@
:Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
-如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
+如果想評論或更新本文的內容，請直接聯繫原文件的維護者。如果你使用英文
交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
譯存在問題，請聯繫中文版維護者::
@@ -16,53 +16,213 @@
- 李陽 Li Yang <leoyang.li@nxp.com>
- Kangkai Yin <e12051@motorola.com>
- 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ - 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
-所有你想知道的事情 - 關於linux穩定版發佈
-========================================
-
-關於Linux 2.6穩定版發佈，所有你想知道的事情。
-
-關於哪些類型的補丁可以被接收進入穩定版代碼樹，哪些不可以的規則：
-----------------------------------------------------------------
-
- - 必須是顯而易見的正確，並且經過測試的。
- - 連同上下文，不能大於100行。
- - 必須只修正一件事情。
- - 必須修正了一個給大家帶來麻煩的真正的bug（不是“這也許是一個問題...”
- 那樣的東西）。
- - 必須修正帶來如下後果的問題：編譯錯誤（對被標記爲CONFIG_BROKEN的例外），
- 內核崩潰，掛起，數據損壞，真正的安全問題，或者一些類似“哦，這不
- 好”的問題。簡短的說，就是一些致命的問題。
- - 沒有“理論上的競爭條件”，除非能給出競爭條件如何被利用的解釋。
- - 不能存在任何的“瑣碎的”修正（拼寫修正，去掉多餘空格之類的）。
- - 必須被相關子系統的維護者接受。
- - 必須遵循Documentation/translations/zh_CN/process/submitting-patches.rst裏的規則。
-
-向穩定版代碼樹提交補丁的過程：
-------------------------------
-
- - 在確認了補丁符合以上的規則後，將補丁發送到stable@vger.kernel.org。
- - 如果補丁被接受到隊列裏，發送者會收到一個ACK回覆，如果沒有被接受，收
- 到的是NAK回覆。回覆需要幾天的時間，這取決於開發者的時間安排。
- - 被接受的補丁會被加到穩定版本隊列裏，等待其他開發者的審查。
- - 安全方面的補丁不要發到這個列表，應該發送到security@kernel.org。
-
-審查週期：
-----------
+所有你想知道的事情 - 關於Linux -stable 版本發布
+===============================================
+
+關於哪些類型的補丁會被接收進入 "-stable" 樹、哪些不會被接收的規則：
+
+- 該補丁或一個等效的修復必須已經存在於Linux主線（上游）。
+- 它必須是顯而易見正確的，並且經過測試的。
+- 連同上下文，它不能大於100行。
+- 它必須遵循
+ :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+ 裡的規則。
+- 它必須要麼修復一個困擾人們的真實的缺陷，要麼只是添加一個裝置ID。
+ 對於前者，詳細來說：
+
+ - 它修復的問題，像是oops、當機、資料損壞、真實的安全問題、硬體怪癖
+ （hardware quirk）、建置錯誤（但不包括標記為CONFIG_BROKEN的東西），
+ 或者一些“喔，這可不好”之類的問題。
+ - 發行版核心的使用者所報告的嚴重問題，如果修復的是顯著的效能或互動性
+ 問題，也可以被考慮。由於這些修復不那麼顯而易見，並且有較高的風險引入
+ 不易察覺的迴歸，它們應該只由發行版核心的維護者提交，並附上補充說明，
+ 給出指向bugzilla條目（如果存在）的連結，以及關於使用者可見影響的額外
+ 資訊。
+ - 不接受“這可能是一個問題...”之類的東西，比如“理論上的競爭條件”，除非
+ 同時提供了缺陷如何被利用的解釋。
+ - 不接受對使用者沒有好處的“瑣碎”修復（拼寫更改、空白清理等）。
+
+
+向 -stable 樹提交補丁的流程
+---------------------------
+
+.. note::
+
+ 安全補丁不應（只）由 -stable 審查流程處理，而應遵循
+ :ref:`Documentation/process/security-bugs.rst <securitybugs>`
+ 的流程。
+
+要向 -stable 樹提交更改，有三個選項：
+
+1. 在你隨後提交到主線的補丁的描述中，加上一個“stable標籤”。
+2. 請求穩定版團隊撿取一個已經合併到主線的補丁。
+3. 向穩定版團隊提交一個與已合併到主線的更改等效的補丁。
+
+以下小節更詳細地描述每個選項。
+
+:ref:`tw_option_1` 是 **強烈** 推薦的做法，它最簡單也最常見。
+:ref:`tw_option_2` 主要用於提交時沒有考慮向後移植的更改。 :ref:`tw_option_3`
+是前兩個選項之外的替代方案，用於已合併到主線的補丁需要調整才能套用到較舊系列
+的情況（例如由於API變化）。
+
+使用選項2或3時，可以要求將你的更改包含到特定的穩定版系列中。這麼做時，要確保
+該修復或等效修復適用於、已提交到、或已經存在於所有仍在維護的較新穩定版樹中。
+這是為了防止使用者日後更新時可能遇到的迴歸，例如一個合併於5.19-rc1的修復被
+向後移植到5.10.y，卻沒有移植到5.15.y。
+
+.. _tw_option_1:
+
+選項1
+*****
+
+要讓你提交到主線的補丁之後被自動撿取到穩定版樹，請在簽署（sign-off）區加上
+這個標籤::
+
+ Cc: stable@vger.kernel.org
+
+當修復未公開的漏洞時，請改用 ``Cc: stable@kernel.org``：它可以降低透過
+'git send-email' 意外將修復公開的機會，因為發送到該地址的郵件不會被投遞到
+任何地方。
+
+補丁合併到主線後，它將被套用到穩定版樹，而無需作者或子系統維護者再做任何
+事情。
+
+要向穩定版團隊發送額外的指示，可使用shell風格的行內註解來傳遞任意的或預定義
+的備註：
+
+* 指明揀選（cherry pick）所需的額外補丁前置條件::
+
+ Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
+ Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
+ Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
+ Cc: <stable@vger.kernel.org> # 3.3.x
+ Signed-off-by: Ingo Molnar <mingo@elte.hu>
+
+ 上面標籤序列的含義為::
+
+ git cherry-pick a1f84a3
+ git cherry-pick 1b9508f
+ git cherry-pick fd21073
+ git cherry-pick <this commit>
+
+ 注意，對於一個補丁系列，你不必把系列中已有的補丁列為前置條件。例如，如果
+ 你有如下補丁系列::
+
+ patch1
+ patch2
+
+ 其中patch2依賴patch1，如果你已經把patch1標記為穩定版收錄，就不必再把它列
+ 為patch2的前置條件。
+
+* 指出核心版本的前置條件::
+
+ Cc: <stable@vger.kernel.org> # 3.3.x
+
+ 該標籤的含義為::
+
+ git cherry-pick <this commit>
+
+ 對每個從指定版本開始的“-stable”樹執行。
+
+ 注意，如果穩定版團隊可以從Fixes:標籤推導出適當的版本，則無需這樣標記。
+
+* 延遲補丁的撿取::
- - 當穩定版的維護者決定開始一個審查週期，補丁將被髮送到審查委員會，以
- 及被補丁影響的領域的維護者（除非提交者就是該領域的維護者）並且抄送
- 到linux-kernel郵件列表。
- - 審查委員會有48小時的時間，用來決定給該補丁回覆ACK還是NAK。
- - 如果委員會中有成員拒絕這個補丁，或者linux-kernel列表上有人反對這個
- 補丁，並提出維護者和審查委員會之前沒有意識到的問題，補丁會從隊列中
- 丟棄。
- - 在審查週期結束的時候，那些得到ACK回應的補丁將會被加入到最新的穩定版
- 發佈中，一個新的穩定版發佈就此產生。
- - 安全性補丁將從內核安全小組那裏直接接收到穩定版代碼樹中，而不是通過
- 通常的審查週期。請聯繫內核安全小組以獲得關於這個過程的更多細節。
-
-審查委員會：
-------------
- - 由一些自願承擔這項任務的內核開發者，和幾個非志願的組成。
+ Cc: <stable@vger.kernel.org> # after -rc3
+
+* 指出已知的問題::
+
+ Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
+
+此外，stable標籤還有一種變體，可以讓穩定版團隊的向後移植工具（例如AUTOSEL
+或尋找含有'Fixes:'標籤的提交的腳本）忽略一個更改::
+
+ Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present
+
+.. _tw_option_2:
+
+選項2
+*****
+
+如果補丁已經合併到主線，請發送一封電子郵件到stable@vger.kernel.org，內容
+包含補丁的標題、提交ID、你認為它應該被套用的原因，以及你希望它被套用到哪些
+核心版本。
+
+.. _tw_option_3:
+
+選項3
+*****
+
+在確認補丁符合上述規則後，將補丁發送到stable@vger.kernel.org，並註明你希望
+它被套用到的核心版本。這麼做時，你必須在你所提交補丁的更改日誌中註明上游的
+提交ID，並在提交說明文字上方以單獨一行標註，像這樣::
+
+ commit <sha1> upstream.
+
+或者::
+
+ [ Upstream commit <sha1> ]
+
+如果提交的補丁與原始的上游補丁有出入（例如因為需要為較舊的API調整），則必須
+在補丁描述中非常清楚地記錄並說明理由。
+
+
+提交之後
+--------
+
+當補丁被接受進入佇列後，發送者會收到一個ACK；如果補丁被拒絕，則會收到NAK。
+這個回覆可能需要幾天時間，取決於穩定版團隊成員的日程安排。
+
+如果被接受，補丁將被加入 -stable 佇列，供其他開發人員和相關子系統維護者
+審查。
+
+
+審查週期
+--------
+
+- 當 -stable 維護者決定進行審查週期時，補丁將被發送到審查委員會，以及補丁
+ 影響領域的維護者（除非提交者就是該領域的維護者），並抄送到linux-kernel
+ 郵件列表。
+- 審查委員會有48小時的時間對補丁作出ACK或NAK。
+- 如果補丁被委員會成員拒絕，或者linux-kernel列表上的成員反對這個補丁並提出
+ 了維護者和委員會成員沒有意識到的問題，補丁將從佇列中移除。
+- 通過ACK的補丁將作為釋出候選（-rc）版本的一部分再次發布，以供開發人員和
+ 測試人員測試。
+- 通常只會產生一個 -rc 版本，然而如果存在未解決的問題，某些補丁可能會被修改
+ 或移除，或者有額外的補丁進入佇列。此後會發布更多的 -rc 版本並加以測試，
+ 直到不再發現問題為止。
+- 可以在郵件列表上發送帶有任何所需測試資訊的“Tested-by:”郵件來回覆 -rc
+ 版本。“Tested-by:”標籤將被收集並加入到發布提交中。
+- 在審查週期結束時，新的 -stable 版本將被發布，其中包含所有排隊的、經過測試
+ 的補丁。
+- 安全補丁將由核心安全團隊直接接受進入 -stable 樹，而不經過正常的審查週期。
+ 關於這一流程的更多細節，請聯繫核心安全團隊。
+
+
+樹
+--
+
+- 已完成版本和進行中版本的補丁佇列可以在以下位置找到：
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
+
+- 所有穩定版核心的最終定版並打上標籤的版本，可以在以下位置的每個版本各自的
+ 分支中找到：
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+
+- 所有穩定版核心版本的釋出候選版本可以在以下位置找到：
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
+
+ .. warning::
+ -stable-rc 樹是stable-queue樹在某個時間點的快照，會頻繁變動，因此會經常
+ 被rebase。它只應被用於測試目的（例如供CI系統使用）。
+
+
+審查委員會
+----------
+- 審查委員會由一些自願承擔這項任務的核心開發人員組成，還有幾位不是自願的。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 09/16] docs/zh_TW: process: localize terminology in 5.Posting.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (7 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 08/16] docs/zh_TW: process: localize terminology in stable-kernel-rules.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 10/16] docs/zh_TW: process: localize terminology in 2.Process.rst Chen-Yu Yeh
` (7 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 代碼→程式碼,
通過→透過, ...) and sync with the English original: add the testing/
KUnit advice, the Fixes:/Link:/Closes: tag paragraphs, the Suggested-by:
tag, and the updated rules about tagging other people.
Also point cross-references at the zh_TW translations instead of
zh_CN.
update to commit 0a83293322fd ("doc: development-process: add notice on
testing")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../translations/zh_TW/process/5.Posting.rst | 235 ++++++++++--------
1 file changed, 136 insertions(+), 99 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/5.Posting.rst b/Documentation/translations/zh_TW/process/5.Posting.rst
index 38f3a6d618eb..698cde5cd06d 100644
--- a/Documentation/translations/zh_TW/process/5.Posting.rst
+++ b/Documentation/translations/zh_TW/process/5.Posting.rst
@@ -12,73 +12,78 @@
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
.. _tw_development_posting:
-發佈補丁
+發布補丁
========
-您的工作遲早會準備好提交給社區進行審查，並最終包含到主線內核中。毫不稀奇，
-內核開發社區已經發展出一套用於發佈補丁的約定和過程；遵循這些約定和過程將使
-參與其中的每個人的生活更加輕鬆。本文檔試圖描述這些約定的部分細節；更多信息
-也可在以下文檔中找到
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
-和 :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <tw_submitchecklist>`。
+您的工作遲早會準備好提交給社群進行審查，並最終包含到主線核心中。毫不稀奇，
+核心開發社群已經發展出一套用於發布補丁的約定和過程；遵循這些約定和過程將使
+參與其中的每個人的生活更加輕鬆。本文件試圖描述這些約定的部分細節；更多資訊
+也可在以下文件中找到
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+和
+:ref:`Documentation/translations/zh_TW/process/submit-checklist.rst <tw_submitchecklist>`。
何時寄送
--------
-在補丁完全“準備好”之前，避免發佈補丁是一種持續的誘惑。對於簡單的補丁，這
-不是問題。但是如果正在完成的工作很複雜，那麼在工作完成之前從社區獲得反饋就
-可以獲得很多好處。因此，您應該考慮發佈正在進行的工作，甚至維護一個可用的Git
+在補丁完全“準備好”之前，避免發布補丁是一種持續的誘惑。對於簡單的補丁，這
+不是問題。但是如果正在完成的工作很複雜，那麼在工作完成之前從社群獲得反饋就
+可以獲得很多好處。因此，您應該考慮發布正在進行的工作，甚至維護一個可用的Git
樹，以便感興趣的開發人員可以隨時趕上您的工作。
-當發佈中有尚未準備好被包含的代碼，最好在發佈中說明。還應提及任何有待完成的
-主要工作和任何已知問題。很少有人會願意看那些被認爲是半生不熟的補丁，但是
-那些願意的人會帶着他們的點子來一起幫助你把工作推向正確的方向。
+當發布中有尚未準備好被包含的程式碼，最好在發布中說明。還應提及任何有待完成的
+主要工作和任何已知問題。很少有人會願意看那些被認為是半生不熟的補丁，但是
+那些願意的人會帶著他們的點子來一起幫助你把工作推向正確的方向。
-創建補丁之前
+建立補丁之前
------------
-在考慮將補丁發送到開發社區之前，有許多事情應該做。包括：
+在考慮將補丁發送到開發社群之前，有許多事情應該做。包括：
- - 儘可能地測試代碼。利用內核的調試工具，確保內核使用了所有可能的配置選項組合
- 進行構建，使用交叉編譯器爲不同的體系結構進行構建等。
+ - 儘可能地測試程式碼。利用核心的除錯工具，確保核心使用了所有可能的設定選
+ 項組合進行建置，使用交叉編譯器為不同的架構進行建置等。添加測試，最好使
+ 用現有的測試框架（如KUnit），並將其作為補丁系列中單獨的一員（關於補丁系
+ 列，見下一節）。注意，對某些子系統而言這可能是強制性的。例如，函式庫函
+ 式（位於lib/下）幾乎在所有地方被廣泛使用，應當有適當的測試。
- - 確保您的代碼符合內核代碼風格指南。
+ - 確保您的程式碼符合核心程式碼風格指南。
- - 您的更改是否具有性能影響？如果是這樣，您應該運行基準測試來顯示您的變更的
+ - 您的更改是否具有效能影響？如果是這樣，您應該執行基準測試來顯示您的變更的
影響（或好處）；結果的摘要應該包含在補丁中。
- - 確保您有權發佈代碼。如果這項工作是爲僱主完成的，僱主對這項工作具有所有權，
- 並且必須同意根據GPL對其進行發佈。
+ - 確保您有權發布程式碼。如果這項工作是為僱主完成的，僱主對這項工作具有所
+ 有權，並且必須同意根據GPL對其進行發布。
-一般來說，在發佈代碼之前進行一些額外的思考，幾乎總是能在短時間內得到回報。
+一般來說，在發布程式碼之前進行一些額外的思考，幾乎總是能在短時間內得到回報。
補丁準備
--------
-準備補丁發佈的工作量可能很驚人，但在此嘗試節省時間通常是不明智的，即使在短期
+準備補丁發布的工作量可能很驚人，但在此嘗試節省時間通常是不明智的，即使在短期
內亦然。
-必須針對內核的特定版本準備補丁。一般來說，補丁應該基於Linus的Git樹中的當前
-主線。當以主線爲基礎時，請從一個衆所周知的發佈點開始——如穩定版本或 -rc
-版本發佈點——而不是在一個任意的主線分支點。
+必須針對核心的特定版本準備補丁。一般來說，補丁應該基於Linus的Git樹中的當前
+主線。當以主線為基礎時，請從一個衆所周知的發布點開始——如穩定版本或 -rc
+版本發布點——而不是在一個任意的主線分支點。
-也可能需要針對-mm、linux-next或子系統樹生成版本，以便於更廣泛的測試和審查。
+也可能需要針對-mm、linux-next或子系統樹產生版本，以便於更廣泛的測試和審查。
根據補丁的區域以及其他地方的情況，針對其他樹建立的補丁可能需要大量的工作來
解決衝突和處理API更改。
-只有最簡單的更改才應格式化爲單個補丁；其他所有更改都應作爲一系列邏輯更改進行。
-分割補丁是一門藝術；一些開發人員花了很長時間來弄清楚如何按照社區期望的方式來
+只有最簡單的更改才應格式化為單個補丁；其他所有更改都應作為一系列邏輯更改進行。
+分割補丁是一門藝術；一些開發人員花了很長時間來弄清楚如何按照社群期望的方式來
分割。不過，這些經驗法則也許有幫助：
- - 您發佈的補丁系列幾乎肯定不會是開發過程中版本控制系統中的一系列更改。相反，
+ - 您發布的補丁系列幾乎肯定不會是開發過程中版本控制系統中的一系列更改。相反，
需要對您所做更改的最終形式加以考慮，然後以有意義的方式進行拆分。開發人員對
離散的、自包含的更改感興趣，而不是您創造這些更改的原始路徑。
- - 每個邏輯上獨立的變更都應該格式化爲單獨的補丁。這些更改可以是小的（如“向
- 此結構體添加字段”）或大的（如添加一個重要的新驅動程序），但它們在概念上
+ - 每個邏輯上獨立的變更都應該格式化為單獨的補丁。這些更改可以是小的（如“向
+ 此結構體添加欄位”）或大的（如添加一個重要的新驅動程式），但它們在概念上
應該是小的，並且可以在一行內簡述。每個補丁都應該做一個特定的、可以單獨
檢查並驗證它所做的事情的更改。
@@ -86,132 +91,164 @@
一個補丁修復了一個關鍵的安全漏洞，又重新排列了一些結構，還重新格式化了代
碼，那麼它很有可能會被忽略，從而導致重要的修復丟失。
- - 每個補丁都應該能創建一個可以正確地構建和運行的內核；如果補丁系列在中間被
- 斷開，那麼結果仍應是一個正常工作的內核。部分應用一系列補丁是使用
- “git bisct”工具查找回歸的一個常見場景；如果結果是一個損壞的內核，那麼將使
- 那些從事追蹤問題的高尚工作的開發人員和用戶的生活更加艱難。
+ - 每個補丁都應該能建立一個可以正確地建置和執行的核心；如果補丁系列在中間被
+ 斷開，那麼結果仍應是一個正常工作的核心。部分應用一系列補丁是使用
+ “git bisct”工具查找回歸的一個常見場景；如果結果是一個損壞的核心，那麼將使
+ 那些從事追蹤問題的高尚工作的開發人員和使用者的生活更加艱難。
- - 不要過分分割。一位開發人員曾經將一組針對單個文件的編輯分成500個單獨的補丁
- 發佈，這並沒有使他成爲內核郵件列表中最受歡迎的人。一個補丁可以相當大，
+ - 不要過分分割。一位開發人員曾經將一組針對單一檔案的編輯分成500個單獨的補丁
+ 發布，這並沒有使他成為核心郵件列表中最受歡迎的人。一個補丁可以相當大，
只要它仍然包含一個單一的 *邏輯* 變更。
- - 用一系列補丁添加一個全新的基礎設施，但是該設施在系列中的最後一個補丁啓用
+ - 用一系列補丁添加一個全新的基礎設施，但是該設施在系列中的最後一個補丁啟用
整個變更之前不能使用，這看起來很誘人。如果可能的話，應該避免這種誘惑；
如果這個系列增加了迴歸，那麼二分法將指出最後一個補丁是導致問題的補丁，
- 即使真正的bug在其他地方。只要有可能，添加新代碼的補丁程序應該立即激活該
- 代碼。
+ 即使真正的bug在其他地方。只要有可能，添加新程式碼的補丁程式應該立即激活該
+ 程式碼。
-創建完美補丁系列的工作可能是一個令人沮喪的過程，在完成“真正的工作”之後需要
+建立完美補丁系列的工作可能是一個令人沮喪的過程，在完成“真正的工作”之後需要
花費大量的時間和思考。但是如果做得好，花費的時間就是值得的。
補丁格式和更改日誌
------------------
-所以現在你有了一系列完美的補丁可以發佈，但是這項工作還沒有完成。每個補丁都
-需要被格式化成一條消息，以快速而清晰地將其目的傳達到世界其他地方。爲此，
+所以現在你有了一系列完美的補丁可以發布，但是這項工作還沒有完成。每個補丁都
+需要被格式化成一條訊息，以快速而清晰地將其目的傳達到世界其他地方。為此，
每個補丁將由以下部分組成：
- - 可選的“From”行，表明補丁作者。只有當你通過電子郵件發送別人的補丁時，這一行
- 纔是必須的，但是爲防止疑問加上它也不會有什麼壞處。
+ - 可選的“From”行，表明補丁作者。只有當你透過電子郵件發送別人的補丁時，這一行
+ 才是必須的，但是為防止疑問加上它也不會有什麼壞處。
- - 一行描述，說明補丁的作用。對於在沒有其他上下文的情況下看到該消息的讀者來說，
- 該消息應足以確定修補程序的範圍；此行將顯示在“short form（簡短格式）”變更
- 日誌中。此消息通常需要先加上子系統名稱前綴，然後是補丁的目的。例如：
+ - 一行描述，說明補丁的作用。對於在沒有其他上下文的情況下看到該訊息的讀者
+ 來說，該訊息應足以確定修補程式的範圍；此行將顯示在“short form（簡短格式）”
+ 變更日誌中。此訊息通常需要先加上子系統名稱前綴，然後是補丁的目的。例如：
::
gpio: fix build on CONFIG_GPIO_SYSFS=n
- - 一行空白，後接補丁內容的詳細描述。此描述可以是任意需要的長度；它應該說明補丁
- 的作用以及爲什麼它應該應用於內核。
+ - 一行空白，後接補丁內容的詳細描述。此描述可以是任意需要的長度；它應該說
+ 明補丁的作用以及為什麼它應該應用於核心。
- 一個或多個標記行，至少有一個由補丁作者的 Signed-off-by 簽名。標記將在下面
詳細描述。
-上面的項目一起構成補丁的變更日誌。寫一則好的變更日誌是一門至關重要但常常被
+上面的專案一起構成補丁的變更日誌。寫一則好的變更日誌是一門至關重要但常常被
忽視的藝術；值得花一點時間來討論這個問題。當你編寫變更日誌時，你應該記住有
很多不同的人會讀你的話。其中包括子系統維護人員和審查人員，他們需要決定是否
-應該合併補丁，分銷商和其他維護人員試圖決定是否應該將補丁反向移植到其他內核，
-缺陷搜尋人員想知道補丁是否導致他們正在追查的問題，以及想知道內核如何變化的
-用戶等等。一個好的變更日誌以最直接和最簡潔的方式向所有這些人傳達所需的信息。
+應該合併補丁，分銷商和其他維護人員試圖決定是否應該將補丁反向移植到其他核心，
+缺陷搜尋人員想知道補丁是否導致他們正在追查的問題，以及想知道核心如何變化的
+使用者等等。一個好的變更日誌以最直接和最簡潔的方式向所有這些人傳達所需的資訊。
在結尾，總結行應該描述變更的影響和動機，以及在一行約束條件下可能發生的變化。
-然後，詳細的描述可以詳述這些主題，並提供任何需要的附加信息。如果補丁修復了
+然後，詳細的描述可以詳述這些主題，並提供任何需要的附加資訊。如果補丁修復了
一個缺陷，請引用引入該缺陷的提交（如果可能，請在引用提交時同時提供其 id 和
標題）。如果某個問題與特定的日誌或編譯器輸出相關聯，請包含該輸出以幫助其他
-人搜索同一問題的解決方案。如果更改是爲了支持以後補丁中的其他更改，那麼應當
+人搜索同一問題的解決方案。如果更改是為了支援以後補丁中的其他更改，那麼應當
說明。如果更改了內部API，請詳細說明這些更改以及其他開發人員應該如何響應。
-一般來說，你越把自己放在每個閱讀你變更日誌的人的位置上，變更日誌（和內核
-作爲一個整體）就越好。
+一般來說，你越把自己放在每個閱讀你變更日誌的人的位置上，變更日誌（和核心
+作為一個整體）就越好。
-不需要說，變更日誌是將變更提交到版本控制系統時使用的文本。接下來將是：
+不需要說，變更日誌是將變更提交到版本控制系統時使用的文字。接下來將是：
- - 補丁本身，採用統一的（“-u”）補丁格式。使用“-p”選項來diff將使函數名與
+ - 補丁本身，採用統一的（“-u”）補丁格式。使用“-p”選項來diff將使函式名與
更改相關聯，從而使結果補丁更容易被其他人讀取。
-上面提到的標籤（tag）用於描述各種開發人員如何與這個補丁的開發相關聯。
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
-文檔中對它們進行了詳細描述；下面是一個簡短的總結。每一行的格式如下：
+前面已簡要提到的標籤（tag）用於提供補丁如何產生的線索。
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+文件中對它們進行了詳細描述；下面是一個簡短的總結。
-::
+有一種標籤用於引用引入了本補丁所修復問題的較早提交::
+
+ Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
+
+另一種標籤用於連結帶有額外背景或細節的網頁，例如導致此補丁的較早討論，或
+一份由此補丁實作的規格文件::
+
+ Link: https://example.com/somewhere.html optional-other-stuff
+
+依照企鵝老大（Chief Penguin）的指導，只有當Link:標籤指向的有用資訊無法在
+提交本身中找到時，才應該把它加到提交中。
+
+如果URL指向此補丁所修復的公開缺陷報告，請改用“Closes:”標籤::
+
+ Closes: https://example.com/issues/1234 optional-other-stuff
+
+一些缺陷追蹤系統能夠在帶有此類標籤的提交被套用時自動關閉問題。一些監控
+郵件列表的機器人也會追蹤這類標籤並採取相應動作。私有缺陷追蹤系統和無效
+的URL是被禁止的。
+
+另一種標籤用於記錄誰參與了補丁的開發。它們每個都使用如下格式::
tag: Full Name <email address> optional-other-stuff
常用的標籤有：
- - Signed-off-by: 這是一個開發人員的證明，證明他或她有權提交補丁以包含到內核
- 中。這表明同意開發者來源認證協議，其全文見
- :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
+ - Signed-off-by: 這是一個開發人員的證明，證明他或她有權提交補丁以包含到核
+ 心中。這表明同意開發者來源認證協議，其全文見
+ :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
如果沒有合適的簽字，則不能合併到主線中。
- - Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上
- 工作時，它用於給出共同作者（除了 From: 所給出的作者之外）。由於
- Co-developed-by: 表示作者身份，所以每個共同開發人，必須緊跟在相關合作作者
- 的Signed-off-by之後。具體內容和示例見以下文件
- :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
+ - Co-developed-by: 聲明補丁是由多個開發人員共同建立的；當幾個人在一個補丁
+ 上工作時，它用於給出共同作者（除了 From: 所給出的作者之外）。由於
+ Co-developed-by: 表示作者身份，所以每個共同開發人，必須緊跟在相關合作作
+ 者的Signed-off-by之後。具體內容和範例見以下文件
+ :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
- - Acked-by: 表示另一個開發人員（通常是相關代碼的維護人員）同意補丁適合包含
- 在內核中。
+ - Acked-by: 表示另一個開發人員（通常是相關程式碼的維護人員）同意補丁適合包含
+ 在核心中。
- Tested-by: 聲明某人已經測試了補丁並確認它可以工作。
- - Reviewed-by: 表示某開發人員已經審查了補丁的正確性；有關詳細信息，請參閱
- :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
+ - Reviewed-by: 表示某開發人員已經審查了補丁的正確性；有關詳細資訊，請參閱
+ :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+
+ - Reported-by: 指定報告此補丁修復的問題的使用者；此標籤用於向測試我們的
+ 程式碼並在發現問題時告知我們的人們（他們常常沒有得到應有的重視）表示
+ 感謝。注意，此標籤後面應跟隨指向該報告的Closes:標籤，除非該報告無法在
+ 網路上取得。如果補丁只修復了所報告問題的一部分，可以用Link:標籤代替
+ Closes:。
- - Reported-by: 指定報告此補丁修復的問題的用戶；此標記用於表示感謝。
+ - Suggested-by: 標籤表明補丁的想法是由被指名者建議的，確保其想法獲得
+ 讚譽。希望這能激勵他們在未來繼續幫助我們。
- Cc：指定某人收到了補丁的副本，並有機會對此發表評論。
-在補丁中添加標籤時要小心：只有Cc:才適合在沒有指定人員明確許可的情況下添加。
+在補丁中添加上述標籤時要小心：除了Cc:、Reported-by:和Suggested-by:之外，
+所有標籤都需要被指名者的明確許可。對於這三個標籤，如果根據lore存檔或提交
+歷史，該人曾以該名字和電子郵件地址對Linux核心做出過貢獻，那麼隱含的許可
+就足夠了——並且對於Reported-by:和Suggested-by:，報告或建議必須是公開作出
+的。注意，就此而言bugzilla.kernel.org是公開場所，但其中使用的電子郵件地址
+是私密的；因此不要在標籤中暴露它們，除非該人在先前的貢獻中使用過。
寄送補丁
--------
在寄送補丁之前，您還需要注意以下幾點：
- - 您確定您的郵件發送程序不會損壞補丁嗎？被郵件客戶端更改空白或修飾了行的補丁
+ - 您確定您的郵件發送程式不會損壞補丁嗎？被郵件客戶端更改空白或修飾了行的補丁
無法被另一端接受，並且通常不會進行任何詳細檢查。如果有任何疑問，先把補丁寄
給你自己，讓你自己確定它是完好無損的。
- :ref:`Documentation/translations/zh_CN/process/email-clients.rst <tw_email_clients>`
+ :ref:`Documentation/translations/zh_TW/process/email-clients.rst <tw_email_clients>`
提供了一些有用的提示，可以讓特定的郵件客戶端正常發送補丁。
- - 你確定你的補丁沒有荒唐的錯誤嗎？您應該始終通過scripts/checkpatch.pl檢查
- 補丁程序，並解決它提出的問題。請記住，checkpatch.pl，雖然體現了對內核補丁
+ - 你確定你的補丁沒有荒唐的錯誤嗎？您應該始終透過scripts/checkpatch.pl檢查
+ 補丁程式，並解決它提出的問題。請記住，checkpatch.pl，雖然體現了對核心補丁
應該是什麼樣的大量思考，但它並不比您聰明。如果修復checkpatch.pl給的問題會
- 使代碼變得更糟，請不要這樣做。
+ 使程式碼變得更糟，請不要這樣做。
-補丁應始終以純文本形式發送。請不要將它們作爲附件發送；這使得審閱者在答覆中更難
-引用補丁的部分。相反，只需將補丁直接放到您的消息中。
+補丁應始終以純文字形式發送。請不要將它們作為附件發送；這使得審閱者在答覆中更難
+引用補丁的部分。相反，只需將補丁直接放到您的訊息中。
-寄出補丁時，重要的是將副本發送給任何可能感興趣的人。與其他一些項目不同，內核
-鼓勵人們甚至錯誤地發送過多的副本；不要假定相關人員會看到您在郵件列表中的發佈。
+寄出補丁時，重要的是將副本發送給任何可能感興趣的人。與其他一些專案不同，核心
+鼓勵人們甚至錯誤地發送過多的副本；不要假定相關人員會看到您在郵件列表中的發布。
尤其是，副本應發送至：
- - 受影響子系統的維護人員。如前所述，維護人員文件是查找這些人員的首選地方。
+ - 受影響子系統的維護人員。如前所述，MAINTAINERS檔案是查找這些人員的首選地方。
- - 其他在同一領域工作的開發人員，尤其是那些現在可能在那裏工作的開發人員。使用
- git查看還有誰修改了您正在處理的文件，這很有幫助。
+ - 其他在同一領域工作的開發人員，尤其是那些現在可能在那裡工作的開發人員。使用
+ git查看還有誰修改了您正在處理的檔案，這很有幫助。
- 如果您對某錯誤報告或功能請求做出響應，也可以抄送原始發送人。
@@ -221,9 +258,9 @@
補丁副本也應發到stable@vger.kernel.org 。另外，在補丁本身的標籤中添加一個
“Cc: stable@vger.kernel.org”；這將使穩定版團隊在修復進入主線時收到通知。
-當爲一個補丁選擇接收者時，最好清楚你認爲誰最終會接受這個補丁並將其合併。雖然
+當為一個補丁選擇接收者時，最好清楚你認為誰最終會接受這個補丁並將其合併。雖然
可以將補丁直接發給Linus Torvalds並讓他合併，但通常情況下不會這樣做。Linus很
-忙，並且有子系統維護人員負責監視內核的特定部分。通常您會希望維護人員合併您的
+忙，並且有子系統維護人員負責監視核心的特定部分。通常您會希望維護人員合併您的
補丁。如果沒有明顯的維護人員，Andrew Morton通常是最後的補丁接收者。
補丁需要好的主題行。補丁主題行的規範格式如下：
@@ -235,12 +272,12 @@
其中“nn”是補丁的序號，“mm”是系列中補丁的總數，“subsys”是受影響子系統的
名稱。當然，一個單獨的補丁可以省略nn/mm。
-如果您有一系列重要的補丁，那麼通常發送一個簡介作爲第〇部分。不過，這個約定
-並沒有得到普遍遵循；如果您使用它，請記住簡介中的信息不會進入內核變更日誌。
-因此，請確保補丁本身具有完整的變更日誌信息。
+如果您有一系列重要的補丁，那麼通常發送一個簡介作為第〇部分。不過，這個約定
+並沒有得到普遍遵循；如果您使用它，請記住簡介中的資訊不會進入核心變更日誌。
+因此，請確保補丁本身具有完整的變更日誌資訊。
-一般來說，多部分補丁的第二部分和後續部分應作爲對第一部分的回覆發送，以便它們
-在接收端都連接在一起。像git和coilt這樣的工具有命令，可以通過適當的線程發送
+一般來說，多部分補丁的第二部分和後續部分應作為對第一部分的回覆發送，以便它們
+在接收端都連接在一起。像git和coilt這樣的工具有命令，可以透過適當的執行緒發送
一組補丁。但是，如果您有一長串補丁，並正使用git，請不要使用–-chain-reply-to
-選項，以避免創建過深的嵌套。
+選項，以避免建立過深的嵌套。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 10/16] docs/zh_TW: process: localize terminology in 2.Process.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (8 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 09/16] docs/zh_TW: process: localize terminology in 5.Posting.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-07 13:15 ` Weijie Yuan
2026-08-06 18:19 ` [PATCH v3 11/16] docs/zh_TW: process: localize terminology in howto.rst Chen-Yu Yeh
` (6 subsequent siblings)
16 siblings, 1 reply; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 社區→社群,
郵箱→信箱, ...) and sync with the English original: rolling-release
wording with the 9.x example and Wikipedia link, 9.x-rc1 examples,
stable team now Greg Kroah-Hartman and Sasha Levin, LTS list moved to
kernel.org, linux-next maintained by Mark Brown, and mailing lists
hosted at subspace.kernel.org.
update to commit 46298375477b ("linux-next: update maintainer info.")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../translations/zh_TW/process/2.Process.rst | 325 +++++++++---------
1 file changed, 158 insertions(+), 167 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/2.Process.rst b/Documentation/translations/zh_TW/process/2.Process.rst
index f45ddba6238f..36b109622ea6 100644
--- a/Documentation/translations/zh_TW/process/2.Process.rst
+++ b/Documentation/translations/zh_TW/process/2.Process.rst
@@ -12,64 +12,60 @@
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
.. _tw_development_process:
開發流程如何進行
================
-90年代早期的Linux內核開發是一件相當鬆散的事情，涉及的用戶和開發人員相對較少。
-由於擁有數以百萬計的用戶羣，且每年有大約2000名開發人員參與進來，內核因此必須
-發展出許多既定流程來保證開發的順利進行。要參與到流程中來，需要對此流程的進行
-方式有一個紮實的理解。
+90年代早期的Linux核心開發是一件相當鬆散的事情，涉及的使用者和開發人員相對
+較少。由於擁有數以百萬計的使用者羣，且每年有大約2000名開發人員參與進來，核
+心因此必須發展出許多既定流程來保證開發的順利進行。要參與到流程中來，需要對
+此流程的進行方式有一個紮實的理解。
總覽
----
-內核開發人員使用一個鬆散的基於時間的發佈過程，每兩到三個月發佈一次新的主要
-內核版本。最近的發佈歷史記錄如下：
+Linux核心使用一種鬆散的、基於時間的滾動發布開發模式。每兩到三個月就會有
+一個新的主要核心版本發布（作為範例，我們稱之為9.x） [1]_ ，它帶來新特性、
+內部API更改等等。一個典型的版本可以包含大約13000個變更集，變更了幾十萬行
+程式碼。最近的版本及其日期可以在
+`維基百科 <https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_
+找到。
- ====== =================
- 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日
- ====== =================
-
-每個5.x版本都是一個主要的內核版本，具有新特性、內部API更改等等。一個典型的5.x
-版本包含大約13000個變更集，變更了幾十萬行代碼。因此，5.x是Linux內核開發的前
-沿；內核使用滾動開發模型，不斷集成重大變化。
+.. [1] 嚴格來說，Linux核心並不使用語意化版本編號方案，而是以9.x這一對
+ 數字作為一個整體來標識主要發布版本。每次發布時x會遞增，只有當x被
+ 認為足夠大時才會遞增9（例如，Linux 5.0是繼Linux 4.20之後發布的）。
對於每個版本的補丁合併，遵循一個相對簡單的規則。在每個開發週期的開頭，“合併
-窗口”被打開。這時，被認爲足夠穩定（並且被開發社區接受）的代碼被合併到主線內
+視窗”被開啟。這時，被認為足夠穩定（並且被開發社群接受）的程式碼被合併到主線內
核中。在這段時間內，新開發週期的大部分變更（以及所有主要變更）將以接近每天
1000次變更（“補丁”或“變更集”）的速度合併。
-（順便說一句，值得注意的是，合併窗口期間集成的更改並不是憑空產生的；它們是經
+（順便說一句，值得注意的是，合併視窗期間整合的更改並不是憑空產生的；它們是經
提前收集、測試和分級的。稍後將詳細描述該過程的工作方式。）
-合併窗口持續大約兩週。在這段時間結束時，Linus Torvalds將聲明窗口已關閉，並
-釋放第一個“rc”內核。例如，對於目標爲5.6的內核，在合併窗口結束時發生的釋放
-將被稱爲5.6-rc1。-rc1 版本是一個信號，表示合併新特性的時間已經過去，穩定下一
-個內核的時間已經到來。
+合併視窗持續大約兩週。在這段時間結束時，Linus Torvalds將聲明視窗已關閉，並
+釋放第一個“rc”核心。例如，對於目標為9.x的核心，在合併視窗結束時發生的釋放
+將被稱為9.x-rc1。-rc1 版本是一個信號，表示合併新特性的時間已經過去，穩定下一
+個核心的時間已經到來。
在接下來的6到10周內，只有修復問題的補丁才應該提交給主線。有時會允許更大的
-更改，但這種情況很少發生；試圖在合併窗口外合併新功能的開發人員往往受不到
-友好的接待。一般來說，如果您錯過了給定特性的合併窗口，最好的做法是等待下一
-個開發週期。（偶爾會對未支持硬件的驅動程序進行例外；如果它們不改變已有代碼，
+更改，但這種情況很少發生；試圖在合併視窗外合併新功能的開發人員往往受不到
+友好的接待。一般來說，如果您錯過了給定特性的合併視窗，最好的做法是等待下一
+個開發週期。（偶爾會對未支援硬體的驅動程式進行例外；如果它們不改變已有程式碼，
則不會導致迴歸，應該可以隨時被安全地加入）。
-隨着修復程序進入主線，補丁速度將隨着時間的推移而變慢。Linus大約每週發佈一次
-新的-rc內核；在內核被認爲足夠穩定並最終發佈前，一般會達到-rc6到-rc9之間。
+隨著修復程式進入主線，補丁速度將隨著時間的推移而變慢。Linus大約每週發布一次
+新的-rc核心；在核心被認為足夠穩定並最終發布前，一般會達到-rc6到-rc9之間。
然後，整個過程又重新開始了。
-例如，這裏是5.4的開發週期進行情況（2019年）:
+例如，這裡是5.4的開發週期進行情況（2019年）:
============== ==============================
- 九月 15 5.3 穩定版發佈
- 九月 30 5.4-rc1 合併窗口關閉
+ 九月 15 5.3 穩定版發布
+ 九月 30 5.4-rc1 合併視窗關閉
十月 6 5.4-rc2
十月 13 5.4-rc3
十月 20 5.4-rc4
@@ -77,26 +73,26 @@
十一月 3 5.4-rc6
十一月 10 5.4-rc7
十一月 17 5.4-rc8
- 十一月 24 5.4 穩定版發佈
+ 十一月 24 5.4 穩定版發布
============== ==============================
-開發人員如何決定何時結束開發週期並創建穩定版本？最重要的指標是以前版本的
-迴歸列表。不歡迎出現任何錯誤，但是那些破壞了以前能工作的系統的錯誤被認爲是
+開發人員如何決定何時結束開發週期並建立穩定版本？最重要的指標是以前版本的
+迴歸列表。不歡迎出現任何錯誤，但是那些破壞了以前能工作的系統的錯誤被認為是
特別嚴重的。因此，導致迴歸的補丁是不受歡迎的，很可能在穩定期內刪除。
-開發人員的目標是在穩定發佈之前修復所有已知的迴歸。在現實世界中，這種完美是
-很難實現的；在這種規模的項目中，變數太多了。需要說明的是，延遲最終版本只會
-使問題變得更糟；等待下一個合併窗口的更改將變多，導致下次出現更多的迴歸錯誤。
-因此，大多數5.x內核都有一些已知的迴歸錯誤，不過，希望沒有一個是嚴重的。
+開發人員的目標是在穩定發布之前修復所有已知的迴歸。在現實世界中，這種完美是
+很難實作的；在這種規模的專案中，變數太多了。需要說明的是，延遲最終版本只會
+使問題變得更糟；等待下一個合併視窗的更改將變多，導致下次出現更多的迴歸錯誤。
+因此，大多數核心版本都有一些已知的迴歸錯誤，不過，希望沒有一個是嚴重的。
-一旦一個穩定的版本發佈，它的持續維護工作就被移交給“穩定團隊”，目前由
-Greg Kroah-Hartman領導。穩定團隊將使用5.x.y編號方案不定期地發佈穩定版本的
-更新。要合入更新版本，補丁必須（1）修復一個重要的缺陷，且（2）已經合併到
-下一個開發版本主線中。內核通常會在其初始版本後的一個以上的開發週期內收到
-穩定版更新。例如，5.2內核的歷史如下（2019年）：
+一旦一個穩定的版本發布，它的持續維護工作就被移交給“穩定團隊”，目前由Greg
+Kroah-Hartman和Sasha Levin組成。穩定團隊將使用9.x.y編號方案不定期地發布穩
+定版本的更新。要合入更新版本，補丁必須（1）修復一個重要的缺陷，且（2）已經
+合併到下一個開發版本主線中。核心通常會在其初始版本後的一個以上的開發週期內
+收到穩定版更新。例如，5.2核心的歷史如下（2019年）：
============== ===============================
- 七月 7 5.2 穩定版發佈
+ 七月 7 5.2 穩定版發布
七月 13 5.2.1
七月 21 5.2.2
七月 26 5.2.3
@@ -108,36 +104,29 @@ Greg Kroah-Hartman領導。穩定團隊將使用5.x.y編號方案不定期地發
5.2.21是5.2版本的最終穩定更新。
-有些內核被指定爲“長期”內核；它們將得到更長時間的支持。在本文中，當前的長期
-內核及其維護者是：
+有些核心被指定為“長期”核心；它們將得到更長時間的支援。當前的長期核心
+版本及其維護者的列表，請參考以下連結：
- ====== ================================ ================
- 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
- ====== ================================ ================
+ https://www.kernel.org/category/releases.html
-長期支持內核的選擇純粹是維護人員是否有需求和時間來維護該版本的問題。
-目前還沒有爲即將發佈的任何特定版本提供長期支持的已知計劃。
+長期支援核心的選擇純粹是維護人員是否有需求和時間來維護該版本的問題。
補丁的生命週期
--------------
-補丁不會直接從開發人員的鍵盤進入主線內核。相反，有一個稍微複雜（如果有些非
-正式）的過程，旨在確保對每個補丁進行質量審查，並確保每個補丁實現了一個在主線
-中需要的更改。對於小的修復，這個過程可能會很快完成，，而對於較大或有爭議的
-變更，可能會持續數年。許多開發人員的沮喪來自於對這個過程缺乏理解或者試圖繞過它。
+補丁不會直接從開發人員的鍵盤進入主線核心。相反，有一個稍微複雜（如果有些非
+正式）的過程，旨在確保對每個補丁進行品質審查，並確保每個補丁實作了一個在主
+線中需要的更改。對於小的修復，這個過程可能會很快完成，，而對於較大或有爭議
+的變更，可能會持續數年。許多開發人員的沮喪來自於對這個過程缺乏理解或者試圖
+繞過它。
-爲了減少這種挫敗，本文將描述補丁如何進入內核。下面的介紹以一種較爲理想化的
+為了減少這種挫敗，本文將描述補丁如何進入核心。下面的介紹以一種較為理想化的
方式描述了這個過程。更詳細的過程將在後面的章節中介紹。
補丁通常要經歷以下階段：
- 設計。這就是補丁的真正需求——以及滿足這些需求的方式——所在。設計工作通常
- 是在不涉及社區的情況下完成的，但是如果可能的話，最好是在公開的情況下完成
+ 是在不涉及社群的情況下完成的，但是如果可能的話，最好是在公開的情況下完成
這項工作；這樣可以節省很多稍後再重新設計的時間。
- 早期評審。補丁被髮布到相關的郵件列表中，列表中的開發人員會回覆他們可能有
@@ -150,74 +139,75 @@ Greg Kroah-Hartman領導。穩定團隊將使用5.x.y編號方案不定期地發
問題。
- 請注意，大多數維護人員也有日常工作，因此合併補丁可能不是他們的最優先工作。
- 如果您的補丁得到了需要更改的反饋，那麼您應該進行這些更改，或者解釋爲何
+ 如果您的補丁得到了需要更改的反饋，那麼您應該進行這些更改，或者解釋為何
不應該進行這些更改。如果您的補丁沒有評審意見，也沒有被其相應的子系統或
- 驅動程序維護者接受，那麼您應該堅持不懈地將補丁更新到當前內核使其可被正常
- 應用，並不斷地發送它以供審查和合並。
+ 驅動程式維護者接受，那麼您應該堅持不懈地將補丁更新到當前核心使其可被正常
+ 應用，並不斷地發送它以供審查和合併。
-- 合併到主線。最終，一個成功的補丁將被合併到由LinusTorvalds管理的主線存儲庫
+- 合併到主線。最終，一個成功的補丁將被合併到由Linus Torvalds管理的主線儲存庫
中。此時可能會出現更多的評論和/或問題；對開發人員來說應對這些問題並解決
出現的任何問題仍很重要。
-- 穩定版發佈。大量用戶可能受此補丁影響，因此可能再次出現新的問題。
+- 穩定版發布。大量使用者可能受此補丁影響，因此可能再次出現新的問題。
-- 長期維護。雖然開發人員在合併代碼後可能會忘記代碼，但這種行爲往往會給開發
- 社區留下不良印象。合併代碼消除了一些維護負擔，因爲其他人將修復由API更改
- 引起的問題。但是，如果代碼要長期保持可用，原始開發人員應該繼續爲代碼負責。
+- 長期維護。雖然開發人員在合併程式碼後可能會忘記程式碼，但這種行為往往會給
+ 開發社群留下不良印象。合併程式碼消除了一些維護負擔，因為其他人將修復由
+ API更改引起的問題。但是，如果程式碼要長期保持可用，原始開發人員應該繼續
+ 為程式碼負責。
-內核開發人員（或他們的僱主）犯的最大錯誤之一是試圖將流程簡化爲一個“合併到
+核心開發人員（或他們的僱主）犯的最大錯誤之一是試圖將流程簡化為一個“合併到
主線”步驟。這種方法總是會讓所有相關人員感到沮喪。
-補丁如何進入內核
+補丁如何進入核心
----------------
-只有一個人可以將補丁合併到主線內核存儲庫中：Linus Torvalds。但是，在進入
-2.6.38內核的9500多個補丁中，只有112個（大約1.3%）是由Linus自己直接選擇的。
-內核項目已經發展到一個沒有一個開發人員可以在沒有支持的情況下檢查和選擇每個
-補丁的規模。內核開發人員處理這種增長的方式是使用圍繞信任鏈構建的助理系統。
+只有一個人可以將補丁合併到主線核心儲存庫中：Linus Torvalds。但是，在進入
+2.6.38核心的9500多個補丁中，只有112個（大約1.3%）是由Linus自己直接選擇的。
+核心專案已經發展到一個沒有一個開發人員可以在沒有支援的情況下檢查和選擇每個
+補丁的規模。核心開發人員處理這種增長的方式是使用圍繞信任鏈建置的助理系統。
-內核代碼庫在邏輯上被分解爲一組子系統：網絡、特定體系結構支持、內存管理、視
-頻設備等。大多數子系統都有一個指定的維護人員，其總體負責該子系統中的代碼。
-這些子系統維護者（鬆散地）是他們所管理的內核部分的“守門員”；他們（通常）
-會接受一個補丁以包含到主線內核中。
+核心程式碼庫在邏輯上被分解為一組子系統：網路、特定體系結構支援、記憶體管理、視
+頻設備等。大多數子系統都有一個指定的維護人員，其總體負責該子系統中的程式碼。
+這些子系統維護者（鬆散地）是他們所管理的核心部分的“守門員”；他們（通常）
+會接受一個補丁以包含到主線核心中。
-子系統維護人員每個人都管理着自己版本的內核源代碼樹，通常（並非總是）使用Git。
-Git等工具（以及Quilt或Mercurial等相關工具）允許維護人員跟蹤補丁列表，包括作者
-信息和其他元數據。在任何給定的時間，維護人員都可以確定他或她的存儲庫中的哪
-些補丁在主線中找不到。
+子系統維護人員每個人都管理著自己版本的核心原始程式碼樹，通常（並非總是）使
+用Git。Git等工具（以及Quilt或Mercurial等相關工具）允許維護人員追蹤補丁列表，
+包括作者資訊和其他元資料。在任何給定的時間，維護人員都可以確定他或她的儲存
+庫中的哪些補丁在主線中找不到。
-當合並窗口打開時，頂級維護人員將要求Linus從存儲庫中“拉出”他們爲合併選擇
-的補丁。如果Linus同意，補丁流將流向他的存儲庫，成爲主線內核的一部分。
+當合併視窗開啟時，頂級維護人員將要求Linus從儲存庫中“拉出”他們為合併選擇
+的補丁。如果Linus同意，補丁流將流向他的儲存庫，成為主線核心的一部分。
Linus對拉取中接收到的特定補丁的關注程度各不相同。很明顯，有時他看起來很
關注。但是一般來說，Linus相信子系統維護人員不會向上遊發送壞補丁。
-子系統維護人員反過來也可以從其他維護人員那裏獲取補丁。例如，網絡樹是由首先
-在專用於網絡設備驅動程序、無線網絡等的樹中積累的補丁構建的。此存儲鏈可以
-任意長，但很少超過兩個或三個鏈接。由於鏈中的每個維護者都信任那些管理較低
-級別樹的維護者，所以這個過程稱爲“信任鏈”。
+子系統維護人員反過來也可以從其他維護人員那裡獲取補丁。例如，網路樹是由首先
+在專用於網路設備驅動程式、無線網路等的樹中積累的補丁建置的。此儲存鏈可以
+任意長，但很少超過兩個或三個連結。由於鏈中的每個維護者都信任那些管理較低
+級別樹的維護者，所以這個過程稱為“信任鏈”。
-顯然，在這樣的系統中，獲取內核補丁取決於找到正確的維護者。直接向Linus發送
+顯然，在這樣的系統中，獲取核心補丁取決於找到正確的維護者。直接向Linus發送
補丁通常不是正確的方法。
Next 樹
-------
-子系統樹鏈引導補丁流到內核，但它也提出了一個有趣的問題：如果有人想查看爲
-下一個合併窗口準備的所有補丁怎麼辦？開發人員將感興趣的是，還有什麼其他的
-更改有待解決，以瞭解是否存在需要擔心的衝突；例如，更改核心內核函數原型的
-修補程序將與使用該函數舊形式的任何其他修補程序衝突。審查人員和測試人員希望
-在所有這些變更到達主線內核之前，能夠訪問它們的集成形式的變更。您可以從所有
+子系統樹鏈引導補丁流到核心，但它也提出了一個有趣的問題：如果有人想查看為
+下一個合併視窗準備的所有補丁怎麼辦？開發人員將感興趣的是，還有什麼其他的
+更改有待解決，以瞭解是否存在需要擔心的衝突；例如，更改核心核心函式原型的
+修補程式將與使用該函式舊形式的任何其他修補程式衝突。審查人員和測試人員希望
+在所有這些變更到達主線核心之前，能夠存取它們的整合形式的變更。您可以從所有
相關的子系統樹中提取更改，但這將是一項複雜且容易出錯的工作。
-解決方案以-next樹的形式出現，在這裏子系統樹被收集以供測試和審查。這些樹中
-由Andrew Morton維護的較老的一個，被稱爲“-mm”（用於內存管理，創建時爲此）。
--mm 樹集成了一長串子系統樹中的補丁；它還包含一些旨在幫助調試的補丁。
+解決方案以-next樹的形式出現，在這裡子系統樹被收集以供測試和審查。這些樹中
+由Andrew Morton維護的較老的一個，被稱為“-mm”（用於記憶體管理，建立時為此）。
+-mm 樹整合了一長串子系統樹中的補丁；它還包含一些旨在幫助除錯的補丁。
除此之外，-mm 還包含大量由Andrew直接選擇的補丁。這些補丁可能已經發布在郵件
-列表上，或者它們可能應用於內核中未指定子系統樹的部分。同時，-mm 作爲最後
+列表上，或者它們可能應用於核心中未指定子系統樹的部分。同時，-mm 作為最後
手段的子系統樹；如果沒有其他明顯的路徑可以讓補丁進入主線，那麼它很可能最
終選擇-mm 樹。累積在-mm 中的各種補丁最終將被轉發到適當的子系統樹，或者直接
-發送到Linus。在典型的開發週期中，大約5-10%的補丁通過-mm 進入主線。
+發送到Linus。在典型的開發週期中，大約5-10%的補丁透過-mm 進入主線。
當前-mm 補丁可在“mmotm”（-mm of the moment）目錄中找到：
@@ -225,102 +215,103 @@ Next 樹
然而，使用MMOTM樹可能會十分令人頭疼；它甚至可能無法編譯。
-下一個週期補丁合併的主要樹是linux-next，由Stephen Rothwell 維護。根據設計
-linux-next 是下一個合併窗口關閉後主線的快照。linux-next樹在Linux-kernel 和
-Linux-next 郵件列表中發佈，可從以下位置下載：
+下一個週期補丁合併的主要樹是linux-next，由Mark Brown維護。根據設計
+linux-next 是下一個合併視窗關閉後主線的快照。linux-next樹在Linux-kernel 和
+Linux-next 郵件列表中發布，可從以下位置下載：
https://www.kernel.org/pub/linux/kernel/next/
-Linux-next 已經成爲內核開發過程中不可或缺的一部分；在一個給定的合併窗口中合併
-的所有補丁都應該在合併窗口打開之前的一段時間內找到進入Linux-next 的方法。
+Linux-next 已經成為核心開發過程中不可或缺的一部分；在一個給定的合併視窗中合併
+的所有補丁都應該在合併視窗開啟之前的一段時間內找到進入Linux-next 的方法。
Staging 樹
----------
-內核源代碼樹包含drivers/staging/目錄，其中有許多驅動程序或文件系統的子目錄
-正在被添加到內核樹中。它們在仍然需要更多的修正的時候可以保留在driver/staging/
-目錄中；一旦完成，就可以將它們移到內核中。這是一種跟蹤不符合Linux內核編碼或
-質量標準的驅動程序的方法，人們可能希望使用它們並跟蹤開發。
+核心原始程式碼樹包含drivers/staging/目錄，其中有許多驅動程式或檔案系統的子目錄
+正在被添加到核心樹中。它們在仍然需要更多的修正的時候可以保留在driver/staging/
+目錄中；一旦完成，就可以將它們移到核心中。這是一種追蹤不符合Linux核心編碼或
+品質標準的驅動程式的方法，人們可能希望使用它們並追蹤開發。
-Greg Kroah Hartman 目前負責維護staging 樹。仍需要修正的驅動程序將發送給他，
-每個驅動程序在drivers/staging/中都有自己的子目錄。除了驅動程序源文件之外，
-目錄中還應該有一個TODO文件。TODO文件列出了驅動程序需要接受的暫停的工作，
-以及驅動程序的任何補丁都應該抄送的人員列表。當前的規則要求，staging的驅動
-程序必須至少正確編譯。
+Greg Kroah-Hartman 目前負責維護staging樹。仍需要修正的驅動程式將發送給他，
+每個驅動程式在drivers/staging/中都有自己的子目錄。除了驅動程式原始檔之外，
+目錄中還應該有一個TODO檔案。TODO檔案列出了驅動程式需要接受的暫停的工作，
+以及驅動程式的任何補丁都應該抄送的人員列表。當前的規則要求，staging的驅動
+程式必須至少正確編譯。
-Staging 是一種讓新的驅動程序進入主線的相對容易的方法，它們會幸運地引起其他
+Staging 是一種讓新的驅動程式進入主線的相對容易的方法，它們會幸運地引起其他
開發人員的注意，並迅速改進。然而，進入staging並不是故事的結尾；staging中
-沒有看到常規進展的代碼最終將被刪除。經銷商也傾向於相對不願意使用staging驅動
-程序。因此，在成爲一個合適的主線驅動的路上，staging 僅是一箇中轉站。
+沒有看到常規進展的程式碼最終將被刪除。經銷商也傾向於相對不願意使用staging驅動
+程式。因此，在成為一個合適的主線驅動的路上，staging 僅是一箇中轉站。
工具
----
-從上面的文本可以看出，內核開發過程在很大程度上依賴於在不同方向上聚集補丁的
+從上面的文字可以看出，核心開發過程在很大程度上依賴於在不同方向上聚集補丁的
能力。如果沒有適當強大的工具，整個系統將無法在任何地方正常工作。關於如何使用
-這些工具的教程遠遠超出了本文檔的範圍，但還是用一點篇幅介紹一些關鍵點。
+這些工具的教程遠遠超出了本文件的範圍，但還是用一點篇幅介紹一些關鍵點。
-到目前爲止，內核社區使用的主要源代碼管理系統是git。Git是在自由軟件社區中開發
-的許多分佈式版本控制系統之一。它非常適合內核開發，因爲它在處理大型存儲庫和
-大量補丁時性能非常好。它也以難以學習和使用而著稱，儘管隨着時間的推移它變得
-更好了。對於內核開發人員來說，對Git的某種熟悉幾乎是一種要求；即使他們不將它
-用於自己的工作，他們也需要Git來跟上其他開發人員（以及主線）正在做的事情。
+到目前為止，核心社群使用的主要原始程式碼管理系統是git。Git是在自由軟體社群
+中開發的許多分散式版本控制系統之一。它非常適合核心開發，因為它在處理大型儲
+存庫和大量補丁時效能非常好。它也以難以學習和使用而著稱，儘管隨著時間的推移
+它變得更好了。對於核心開發人員來說，對Git的某種熟悉幾乎是一種要求；即使他
+們不將它用於自己的工作，他們也需要Git來跟上其他開發人員（以及主線）正在做
+的事情。
現在幾乎所有的Linux發行版都打包了Git。Git主頁位於：
https://git-scm.com/
-此頁面包含了文檔和教程的鏈接。
+此頁面包含了文件和教程的連結。
-在不使用git的內核開發人員中，最流行的選擇幾乎肯定是Mercurial：
+在不使用git的核心開發人員中，最流行的選擇幾乎肯定是Mercurial：
http://www.seleric.com/mercurial/
-Mercurial與Git共享許多特性，但它提供了一個界面，許多人覺得它更易於使用。
+Mercurial與Git共享許多特性，但它提供了一個介面，許多人覺得它更易於使用。
另一個值得了解的工具是Quilt:
https://savannah.nongnu.org/projects/quilt
-Quilt 是一個補丁管理系統，而不是源代碼管理系統。它不會隨着時間的推移跟蹤歷史；
-相反，它面向根據不斷發展的代碼庫跟蹤一組特定的更改。一些主要的子系統維護人員
-使用Quilt來管理打算向上遊移動的補丁。對於某些樹的管理（例如-mm），quilt 是
-最好的工具。
+Quilt 是一個補丁管理系統，而不是原始程式碼管理系統。它不會隨著時間的推移追
+蹤歷史；相反，它面向根據不斷發展的程式碼庫追蹤一組特定的更改。一些主要的子
+系統維護人員使用Quilt來管理打算向上遊移動的補丁。對於某些樹的管理（例如-mm），
+quilt 是最好的工具。
郵件列表
--------
-大量的Linux內核開發工作是通過郵件列表完成的。如果不加入至少一個某個列表，
-就很難成爲社區中的一個“全功能”成員。但是，Linux郵件列表對開發人員來說也是
+大量的Linux核心開發工作是透過郵件列表完成的。如果不加入至少一個某個列表，
+就很難成為社群中的一個“全功能”成員。但是，Linux郵件列表對開發人員來說也是
一個潛在的危險，他們可能會被一堆電子郵件淹沒、違反Linux列表上使用的約定，
或者兩者兼而有之。
-大多數內核郵件列表都在vger.kernel.org上運行；主列表位於：
+大多數核心郵件列表都託管在kernel.org上；主列表位於：
- http://vger.kernel.org/vger-lists.html
+ https://subspace.kernel.org
-不過，也有一些列表託管在別處；其中一些列表位於
-redhat.com/mailman/listinfo。
+也有一些列表託管在別處；請查閱MAINTAINERS檔案以找到與特定子系統相關的
+列表。
-當然，內核開發的核心郵件列表是linux-kernel。這個列表是一個令人生畏的地方：
-每天的信息量可以達到500條，噪音很高，談話技術性很強，且參與者並不總是表現出
-高度的禮貌。但是，沒有其他地方可以讓內核開發社區作爲一個整體聚集在一起；
-不使用此列表的開發人員將錯過重要信息。
+當然，核心開發的核心郵件列表是linux-kernel。這個列表是一個令人生畏的地方：
+每天的資訊量可以達到500條，噪音很高，談話技術性很強，且參與者並不總是表現出
+高度的禮貌。但是，沒有其他地方可以讓核心開發社群作為一個整體聚集在一起；
+不使用此列表的開發人員將錯過重要資訊。
以下一些提示可以幫助在linux-kernel生存：
-- 將郵件轉移到單獨的文件夾，而不是主郵箱文件夾。我們必須能夠持續地忽略洪流。
+- 將郵件轉移到單獨的資料夾，而不是主信箱資料夾。我們必須能夠持續地忽略洪流。
- 不要試圖跟上每一次談話——沒人會這樣。重要的是要篩選感興趣的主題（但請注意
長時間的對話可能會偏離原來的主題，儘管未改變電子郵件的主題）和參與的人。
- 不要回復挑事的人。如果有人試圖激起憤怒，請忽略他們。
-- 當回覆Linux內核電子郵件（或其他列表上的電子郵件）時，請爲所有相關人員保留
+- 當回覆Linux核心電子郵件（或其他列表上的電子郵件）時，請為所有相關人員保留
Cc: 抄送頭。如果沒有確實的理由（如明確的請求），則不應刪除收件人。一定要
確保你要回復的人在抄送列表中。這個慣例也使你不必在回覆郵件時明確要求被抄送。
-- 在提出問題之前，搜索列表存檔（和整個網絡）。有些開發人員可能會對那些顯然
+- 在提出問題之前，搜索列表存檔（和整個網路）。有些開發人員可能會對那些顯然
沒有完成家庭作業的人感到不耐煩。
- 避免頂部回覆（把你的答案放在你要回復的引文上面的做法）。這會讓你的回答更難
@@ -329,41 +320,41 @@ redhat.com/mailman/listinfo。
- 在正確的郵件列表發問。linux-kernel 可能是通用的討論場所，但它不是尋找所有
子系統開發人員的最佳場所。
-最後一點——找到正確的郵件列表——是開發人員常出錯的地方。在linux-kernel上
-提出與網絡相關的問題的人幾乎肯定會收到一個禮貌的建議，轉到netdev列表上提出，
-因爲這是大多數網絡開發人員經常出現的列表。還有其他列表可用於scsi、video4linux、
-ide、filesystem等子系統。查找郵件列表的最佳位置是與內核源代碼一起打包的
-MAINTAINERS文件。
+最後一點——找到正確的郵件列表——是開發人員常出錯的地方。在linux-kernel上提出
+與網路相關的問題的人幾乎肯定會收到一個禮貌的建議，轉到netdev列表上提出，因
+為這是大多數網路開發人員經常出現的列表。還有其他列表可用於scsi、
+video4linux、ide、filesystem等子系統。查找郵件列表的最佳位置是與核心原始程
+式碼一起打包的MAINTAINERS檔案。
-開始內核開發
+開始核心開發
------------
-關於如何開始內核開發過程的問題很常見——個人和公司皆然。同樣常見的是失誤，這
+關於如何開始核心開發過程的問題很常見——個人和公司皆然。同樣常見的是失誤，這
使得關係的開始比本應的更困難。
-公司通常希望聘請知名的開發人員來啓動開發團隊。實際上，這是一種有效的技術。
-但它也往往是昂貴的，而且對增加有經驗的內核開發人員的數量沒有多大幫助。考
-慮到時間投入，可以讓內部開發人員加快Linux內核的開發速度。利用這段時間可以
-讓僱主擁有一批既瞭解內核又瞭解公司的開發人員，還可以幫助培訓其他人。從中期
+公司通常希望聘請知名的開發人員來啟動開發團隊。實際上，這是一種有效的技術。
+但它也往往是昂貴的，而且對增加有經驗的核心開發人員的數量沒有多大幫助。考
+慮到時間投入，可以讓內部開發人員加快Linux核心的開發速度。利用這段時間可以
+讓僱主擁有一批既瞭解核心又瞭解公司的開發人員，還可以幫助培訓其他人。從中期
來看，這通常是更有利可圖的方法。
-可以理解的是，單個開發人員往往對起步感到茫然。從一個大型項目開始可能會很
-嚇人；人們往往想先用一些較小的東西來試試水。由此，一些開發人員開始創建修補
+可以理解的是，單個開發人員往往對起步感到茫然。從一個大型專案開始可能會很
+嚇人；人們往往想先用一些較小的東西來試試水。由此，一些開發人員開始建立修補
拼寫錯誤或輕微編碼風格問題的補丁。不幸的是，這樣的補丁會產生一定程度的噪音，
-這會分散整個開發社區的注意力，因此，它們越來越被人不看重。希望向社區介紹
-自己的新開發人員將無法通過這些方式獲得他們期待的反響。
+這會分散整個開發社群的注意力，因此，它們越來越被人不看重。希望向社群介紹
+自己的新開發人員將無法透過這些方式獲得他們期待的反響。
-Andrew Morton 爲有抱負的內核開發人員提供瞭如下建議
+Andrew Morton 為有抱負的核心開發人員提供了如下建議
::
- 所有內核開發者的第一個項目肯定應該是“確保內核在您可以操作的所有
- 機器上始終完美運行”。通常的方法是和其他人一起解決問題（這可能需
- 要堅持！），但就是如此——這是內核開發的一部分。
+ 所有核心開發者的第一個專案肯定應該是“確保核心在您可以操作的所有
+ 機器上始終完美執行”。通常的方法是和其他人一起解決問題（這可能需
+ 要堅持！），但就是如此——這是核心開發的一部分。
(http://lwn.net/Articles/283982/)
在沒有明顯問題需要解決的情況下，通常建議開發人員查看當前的迴歸和開放缺陷
-列表。從來都不缺少需要解決的問題；通過解決這些問題，開發人員將從該過程獲得
-經驗，同時與開發社區的其他成員建立相互尊重。
+列表。從來都不缺少需要解決的問題；透過解決這些問題，開發人員將從該過程獲得
+經驗，同時與開發社群的其他成員建立相互尊重。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v3 10/16] docs/zh_TW: process: localize terminology in 2.Process.rst
2026-08-06 18:19 ` [PATCH v3 10/16] docs/zh_TW: process: localize terminology in 2.Process.rst Chen-Yu Yeh
@ 2026-08-07 13:15 ` Weijie Yuan
0 siblings, 0 replies; 20+ messages in thread
From: Weijie Yuan @ 2026-08-07 13:15 UTC (permalink / raw)
To: Chen-Yu Yeh
Cc: Jonathan Corbet, Alex Shi, Dongliang Mu, Yanteng Si, Hu Haowen,
linux-doc, linux-kernel
On Fri, Aug 07, 2026 at 02:19:43AM +0800, Chen-Yu Yeh wrote:
> Localize mainland terms to Taiwanese Mandarin (內核→核心, 社區→社群,
> 郵箱→信箱, ...) and sync with the English original: rolling-release
> wording with the 9.x example and Wikipedia link, 9.x-rc1 examples,
> stable team now Greg Kroah-Hartman and Sasha Levin, LTS list moved to
> kernel.org, linux-next maintained by Mark Brown, and mailing lists
> hosted at subspace.kernel.org.
>
> update to commit 46298375477b ("linux-next: update maintainer info.")
>
> Assisted-by: Claude:claude-opus-5
Reviewed-by: Weijie Yuan <wy@wyuan.org>
> Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
> ---
> .../translations/zh_TW/process/2.Process.rst | 325 +++++++++---------
> 1 file changed, 158 insertions(+), 167 deletions(-)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v3 11/16] docs/zh_TW: process: localize terminology in howto.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (9 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 10/16] docs/zh_TW: process: localize terminology in 2.Process.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 12/16] docs/zh_TW: process: localize terminology in embargoed-hardware-issues.rst Chen-Yu Yeh
` (5 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 軟件→軟體,
社區→社群, ...) and sync with the English original: update the
man-pages maintainer address, the linux-next git URL (also dropping a
stray full-width question mark), and the mailing list links now
pointing at subspace.kernel.org and lore.kernel.org.
update to commit 413e775efaec ("Documentation: fix links to mailing list
services")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../translations/zh_TW/process/howto.rst | 344 +++++++++---------
1 file changed, 173 insertions(+), 171 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
index 80c416483e73..8466f6af96cc 100644
--- a/Documentation/translations/zh_TW/process/howto.rst
+++ b/Documentation/translations/zh_TW/process/howto.rst
@@ -17,13 +17,14 @@
陳琦 Maggie Chen <chenqi@beyondsoft.com>
王聰 Wang Cong <xiyou.wangcong@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
-如何參與Linux內核開發
+如何參與Linux核心開發
=====================
-這是一篇將如何參與Linux內核開發的相關問題一網打盡的終極祕笈。它將指導你
-成爲一名Linux內核開發者，並且學會如何同Linux內核開發社區合作。它儘可能不
-包括任何關於內核編程的技術細節，但會給你指引一條獲得這些知識的正確途徑。
+這是一篇將如何參與Linux核心開發的相關問題一網打盡的終極祕笈。它將指導你
+成為一名Linux核心開發者，並且學會如何同Linux核心開發社群合作。它儘可能不
+包括任何關於核心程式設計的技術細節，但會給你指引一條獲得這些知識的正確途徑。
如果這篇文章中的任何內容不再適用，請給文末列出的文件維護者發送補丁。
@@ -31,15 +32,15 @@
入門
----
-你想了解如何成爲一名Linux內核開發者？或者老闆吩咐你「給這個設備寫個Linux
-驅動程序」？這篇文章的目的就是教會你達成這些目標的全部訣竅，它將描述你需
-要經過的流程以及給出如何同內核社區合作的一些提示。它還將試圖解釋內核社區
-爲何這樣運作。
+你想了解如何成為一名Linux核心開發者？或者老闆吩咐你「給這個設備寫個Linux
+驅動程式」？這篇文章的目的就是教會你達成這些目標的全部訣竅，它將描述你需
+要經過的流程以及給出如何同核心社群合作的一些提示。它還將試圖解釋核心社群
+為何這樣運作。
-Linux內核大部分是由C語言寫成的，一些體系結構相關的代碼用到了彙編語言。要
-參與內核開發，你必須精通C語言。除非你想爲某個架構開發底層代碼，否則你並
-不需要了解（任何體系結構的）彙編語言。下面列舉的書籍雖然不能替代紮實的C
-語言教育和多年的開發經驗，但如果需要的話，做爲參考還是不錯的：
+Linux核心大部分是由C語言寫成的，一些體系結構相關的程式碼用到了組譯語言。要
+參與核心開發，你必須精通C語言。除非你想為某個架構開發底層程式碼，否則你並
+不需要了解（任何體系結構的）組譯語言。下面列舉的書籍雖然不能替代紮實的C
+語言教育和多年的開發經驗，但如果需要的話，做為參考還是不錯的：
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
《C程序設計語言（第2版·新版）》（徐寶文 李志 譯）[機械工業出版社]
@@ -48,67 +49,67 @@ Linux內核大部分是由C語言寫成的，一些體系結構相關的代碼
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社]
-Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準，但也用到了一些
-標準中沒有定義的擴展。內核是自給自足的C環境，不依賴於標準C庫的支持，所以
-並不支持C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許
-使用。有時候確實很難弄清楚內核對工具鏈的要求和它所使用的擴展，不幸的是目
-前還沒有明確的參考資料可以解釋它們。請查閱gcc信息頁（使用「info gcc」命令
-顯示）獲得一些這方面信息。
+Linux核心使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準，但也用到了一些
+標準中沒有定義的擴展。核心是自給自足的C環境，不依賴於標準C庫的支援，所以
+並不支援C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許
+使用。有時候確實很難弄清楚核心對工具鏈的要求和它所使用的擴展，不幸的是目
+前還沒有明確的參考資料可以解釋它們。請查閱gcc資訊頁（使用「info gcc」命令
+顯示）獲得一些這方面資訊。
-請記住你是在學習怎麼和已經存在的開發社區打交道。它由一羣形形色色的人組成，
-他們對代碼、風格和過程有著很高的標準。這些標準是在長期實踐中總結出來的，
+請記住你是在學習怎麼和已經存在的開發社群打交道。它由一羣形形色色的人組成，
+他們對程式碼、風格和過程有著很高的標準。這些標準是在長期實踐中總結出來的，
適應於地理上分散的大型開發團隊。它們已經被很好得整理成檔，建議你在開發
-之前儘可能多的學習這些標準，而不要期望別人來適應你或者你公司的行爲方式。
+之前儘可能多的學習這些標準，而不要期望別人來適應你或者你公司的行為方式。
法律問題
--------
-Linux內核原始碼都是在GPL（通用公共許可證）的保護下發布的。要了解這種許可
-的細節請查看原始碼主目錄下的COPYING文件。Linux內核許可準則和如何使用
+Linux核心原始碼都是在GPL（通用公共許可證）的保護下發布的。要了解這種許可
+的細節請查看原始碼主目錄下的COPYING檔案。Linux核心許可準則和如何使用
`SPDX <https://spdx.org/>` 標誌符說明在這個文件中
:ref:`Documentation/translations/zh_TW/process/license-rules.rst <tw_kernel_licensing>`
-如果你對它還有更深入問題請聯繫律師，而不要在Linux內核郵件組上提問。因爲
+如果你對它還有更深入問題請聯繫律師，而不要在Linux核心郵件組上提問。因為
郵件組裡的人並不是律師，不要期望他們的話有法律效力。
-對於GPL的常見問題和解答，請訪問以下連結：
+對於GPL的常見問題和解答，請造訪以下連結：
https://www.gnu.org/licenses/gpl-faq.html
-文檔
+文件
----
-Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與內核社區互動有著
-不可估量的價值。當一個新的功能被加入內核，最好把解釋如何使用這個功能的文
-檔也放進內核。當內核的改動導致面向用戶空間的接口發生變化時，最好將相關信
-息或手冊頁(manpages)的補丁發到mtk.manpages@gmail.com，以向手冊頁(manpages)
+Linux核心程式碼中包含有大量的文件。這些文件對於學習如何與核心社群互動有著
+不可估量的價值。當一個新的功能被加入核心，最好把解釋如何使用這個功能的文
+檔也放進核心。當核心的改動導致面向使用者空間的介面發生變化時，最好將相關信
+息或手冊頁(manpages)的補丁發到alx@kernel.org，以向手冊頁(manpages)
的維護者解釋這些變化。
-以下是內核代碼中需要閱讀的文檔：
+以下是核心程式碼中需要閱讀的文件：
:ref:`Documentation/admin-guide/README.rst <readme>`
- 文件簡要介紹了Linux內核的背景，並且描述了如何配置和編譯內核。內核的
- 新用戶應該從這裡開始。
+ 文件簡要介紹了Linux核心的背景，並且描述了如何設定和編譯核心。核心的
+ 新使用者應該從這裡開始。
:ref:`Documentation/process/changes.rst <changes>`
- 文件給出了用來編譯和使用內核所需要的最小軟體包列表。
+ 文件給出了用來編譯和使用核心所需要的最小軟體套件列表。
:ref:`Documentation/translations/zh_TW/process/coding-style.rst <tw_codingstyle>`
- 描述Linux內核的代碼風格和理由。所有新代碼需要遵守這篇文檔中定義的規
+ 描述Linux核心的程式碼風格和理由。所有新程式碼需要遵守這篇文件中定義的規
范。大多數維護者只會接收符合規定的補丁，很多人也只會幫忙檢查符合風格
- 的代碼。
+ 的程式碼。
:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
- 這兩份文檔明確描述如何創建和發送補丁，其中包括（但不僅限於)：
+ 這兩份文件明確描述如何建立和發送補丁，其中包括（但不僅限於)：
- 郵件內容
- 郵件格式
- 選擇收件人
- 遵守這些規定並不能保證提交成功（因爲所有補丁需要通過嚴格的內容和風格
+ 遵守這些規定並不能保證提交成功（因為所有補丁需要透過嚴格的內容和風格
審查），但是忽視他們幾乎就意味著失敗。
- 其他關於如何正確地生成補丁的優秀文檔包括：
+ 其他關於如何正確地產生補丁的優秀文件包括：
"The Perfect Patch"
https://www.ozlabs.org/~akpm/stuff/tpp.txt
@@ -118,78 +119,78 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
:ref:`Documentation/translations/zh_TW/process/stable-api-nonsense.rst <tw_stable_api_nonsense>`
- 論證內核爲什麼特意不包括穩定的內核內部API，也就是說不包括像這樣的特
+ 論證核心為什麼特意不包括穩定的核心內部API，也就是說不包括像這樣的特
性：
- - 子系統中間層（爲了兼容性？）
- - 在不同作業系統間易於移植的驅動程序
- - 減緩（甚至阻止）內核代碼的快速變化
+ - 子系統中間層（為了相容性？）
+ - 在不同作業系統間易於移植的驅動程式
+ - 減緩（甚至阻止）核心程式碼的快速變化
- 這篇文檔對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系
+ 這篇文件對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系
統轉移到Linux的人來說也很重要。
:ref:`Documentation/process/security-bugs.rst <securitybugs>`
- 如果你認爲自己發現了Linux內核的安全性問題，請根據這篇文檔中的步驟來
- 提醒其他內核開發者並幫助解決這個問題。
+ 如果你認為自己發現了Linux核心的安全性問題，請根據這篇文件中的步驟來
+ 提醒其他核心開發者並幫助解決這個問題。
:ref:`Documentation/translations/zh_TW/process/management-style.rst <tw_managementstyle>`
- 描述內核維護者的工作方法及其共有特點。這對於剛剛接觸內核開發（或者對
- 它感到好奇）的人來說很重要，因爲它解釋了很多對於內核維護者獨特行爲的
+ 描述核心維護者的工作方法及其共有特點。這對於剛剛接觸核心開發（或者對
+ 它感到好奇）的人來說很重要，因為它解釋了很多對於核心維護者獨特行為的
普遍誤解與迷惑。
:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
- 解釋了穩定版內核發布的規則，以及如何將改動放入這些版本的步驟。
+ 解釋了穩定版核心發布的規則，以及如何將改動放入這些版本的步驟。
:ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
- 有助於內核開發的外部文檔列表。如果你在內核自帶的文檔中沒有找到你想找
- 的內容，可以查看這些文檔。
+ 有助於核心開發的外部文件列表。如果你在核心自帶的文件中沒有找到你想找
+ 的內容，可以查看這些文件。
:ref:`Documentation/process/applying-patches.rst <applying_patches>`
- 關於補丁是什麼以及如何將它打在不同內核開發分支上的好介紹
+ 關於補丁是什麼以及如何將它打在不同核心開發分支上的好介紹
-內核還擁有大量從代碼自動生成或者從 ReStructuredText(ReST) 標記生成的文檔，
-比如這個文檔，它包含內核內部API的全面介紹以及如何妥善處理加鎖的規則。所有
-這些文檔都可以通過運行以下命令從內核代碼中生成爲PDF或HTML文檔::
+核心還擁有大量從程式碼自動產生或者從 ReStructuredText(ReST) 標記產生的文件，
+比如這個文件，它包含核心內部API的全面介紹以及如何妥善處理加鎖的規則。所有
+這些文件都可以透過執行以下命令從核心程式碼中產生為PDF或HTML文件::
make pdfdocs
make htmldocs
-ReST格式的文檔會生成在 Documentation/output. 目錄中。
-它們也可以用下列命令生成 LaTeX 和 ePub 格式文檔::
+ReST格式的文件會產生在 Documentation/output. 目錄中。
+它們也可以用下列命令產生 LaTeX 和 ePub 格式文件::
make latexdocs
make epubdocs
-如何成爲內核開發者
+如何成為核心開發者
------------------
-如果你對Linux內核開發一無所知，你應該訪問「Linux內核新手」計劃：
+如果你對Linux核心開發一無所知，你應該造訪「Linux核心新手」計劃：
https://kernelnewbies.org
-它擁有一個可以問各種最基本的內核開發問題的郵件列表（在提問之前一定要記得
+它擁有一個可以問各種最基本的核心開發問題的郵件列表（在提問之前一定要記得
查找已往的郵件，確認是否有人已經回答過相同的問題）。它還擁有一個可以獲得
-實時反饋的IRC聊天頻道，以及大量對於學習Linux內核開發相當有幫助的文檔。
+實時反饋的IRC聊天頻道，以及大量對於學習Linux核心開發相當有幫助的文件。
-網站簡要介紹了原始碼組織結構、子系統劃分以及目前正在進行的項目（包括內核
-中的和單獨維護的）。它還提供了一些基本的幫助信息，比如如何編譯內核和打補
-丁。
+網站簡要介紹了原始碼組織結構、子系統劃分以及目前正在進行的專案（包括核心
+中的和單獨維護的）。它還提供了一些基本的幫助資訊，比如如何編譯核心和打補丁
+。
-如果你想加入內核開發社區並協助完成一些任務，卻找不到從哪裡開始，可以訪問
-「Linux內核房管員」計劃：
+如果你想加入核心開發社群並協助完成一些任務，卻找不到從哪裡開始，可以造訪
+「Linux核心房管員」計劃：
https://kernelnewbies.org/KernelJanitors
-這是極佳的起點。它提供一個相對簡單的任務列表，列出內核代碼中需要被重新
-整理或者改正的地方。通過和負責這個計劃的開發者們一同工作，你會學到將補丁
-集成進內核的基本原理。如果還沒有決定下一步要做什麼的話，你還可能會得到方
+這是極佳的起點。它提供一個相對簡單的任務列表，列出核心程式碼中需要被重新
+整理或者改正的地方。透過和負責這個計劃的開發者們一同工作，你會學到將補丁
+整合進核心的基本原理。如果還沒有決定下一步要做什麼的話，你還可能會得到方
向性的指點。
-在真正動手修改內核代碼之前，理解要修改的代碼如何運作是必需的。要達到這個
-目的，沒什麼辦法比直接讀代碼更有效了（大多數花招都會有相應的注釋），而且
-一些特製的工具還可以提供幫助。例如，「Linux代碼交叉引用」項目就是一個值得
+在真正動手修改核心程式碼之前，理解要修改的程式碼如何運作是必需的。要達到這個
+目的，沒什麼辦法比直接讀程式碼更有效了（大多數花招都會有相應的註解），而且
+一些特製的工具還可以提供幫助。例如，「Linux程式碼交叉引用」專案就是一個值得
特別推薦的幫助工具，它將原始碼顯示在有編目和索引的網頁上。其中一個更新及
-時的內核源碼庫，可以通過以下地址訪問：
+時的核心源碼庫，可以透過以下地址造訪：
https://elixir.bootlin.com/
@@ -197,158 +198,159 @@ ReST格式的文檔會生成在 Documentation/output. 目錄中。
開發流程
--------
-目前Linux內核開發流程包括幾個「主內核分支」和很多子系統相關的內核分支。這
+目前Linux核心開發流程包括幾個「主核心分支」和很多子系統相關的核心分支。這
些分支包括：
- - Linus 的內核源碼樹
- - 多個主要版本的穩定版內核樹
- - 子系統相關的內核樹
- - linux-next 集成測試樹
+ - Linus 的核心源碼樹
+ - 多個主要版本的穩定版核心樹
+ - 子系統相關的核心樹
+ - linux-next 整合測試樹
主線樹
------
-主線樹是由Linus Torvalds 維護的。你可以在https://kernel.org 網站或者代碼
+主線樹是由Linus Torvalds 維護的。你可以在https://kernel.org 網站或者程式碼
庫中下找到它。它的開發遵循以下步驟：
- - 每當一個新版本的內核被發布，爲期兩周的集成窗口將被打開。在這段時間裡
- 維護者可以向Linus提交大段的修改，通常這些修改已經被放到-mm內核中幾個
- 星期了。提交大量修改的首選方式是使用git工具（內核的代碼版本管理工具
- ，更多的信息可以在 https://git-scm.com/ 獲取），不過使用普通補丁也是
+ - 每當一個新版本的核心被發布，為期兩周的整合視窗將被開啟。在這段時間裡
+ 維護者可以向Linus提交大段的修改，通常這些修改已經被放到-mm核心中幾個
+ 星期了。提交大量修改的首選方式是使用git工具（核心的程式碼版本管理工具
+ ，更多的資訊可以在 https://git-scm.com/ 獲取），不過使用普通補丁也是
可以的。
- - 兩個星期以後-rc1版本內核發布。之後只有不包含可能影響整個內核穩定性的
- 新功能的補丁才可能被接受。請注意一個全新的驅動程序（或者文件系統）有
- 可能在-rc1後被接受是因爲這樣的修改完全獨立，不會影響其他的代碼，所以
- 沒有造成內核退步的風險。在-rc1以後也可以用git向Linus提交補丁，不過所
+ - 兩個星期以後-rc1版本核心發布。之後只有不包含可能影響整個核心穩定性的
+ 新功能的補丁才可能被接受。請注意一個全新的驅動程式（或者檔案系統）有
+ 可能在-rc1後被接受是因為這樣的修改完全獨立，不會影響其他的程式碼，所以
+ 沒有造成核心退步的風險。在-rc1以後也可以用git向Linus提交補丁，不過所
有的補丁需要同時被發送到相應的公衆郵件列表以徵詢意見。
- - 當Linus認爲當前的git源碼樹已經達到一個合理健全的狀態足以發布供人測試
+ - 當Linus認為當前的git源碼樹已經達到一個合理健全的狀態足以發布供人測試
時，一個新的-rc版本就會被發布。計劃是每周都發布新的-rc版本。
- - 這個過程一直持續下去直到內核被認爲達到足夠穩定的狀態，持續時間大概是
+ - 這個過程一直持續下去直到核心被認為達到足夠穩定的狀態，持續時間大概是
6個星期。
-關於內核發布，值得一提的是Andrew Morton在linux-kernel郵件列表中如是說：
- 「沒有人知道新內核何時會被發布，因爲發布是根據已知bug的情況來決定
+關於核心發布，值得一提的是Andrew Morton在linux-kernel郵件列表中如是說：
+ 「沒有人知道新核心何時會被發布，因為發布是根據已知bug的情況來決定
的，而不是根據一個事先制定好的時間表。」
子系統特定樹
------------
-各種內核子系統的維護者——以及許多內核子系統開發人員——在原始碼庫中公開了他們
-當前的開發狀態。這樣，其他人就可以看到內核的不同區域發生了什麼。在開發速度
-很快的領域，可能會要求開發人員將提交的內容建立在這樣的子系統內核樹上，這樣
+各種核心子系統的維護者——以及許多核心子系統開發人員——在原始碼庫中公開了他們
+當前的開發狀態。這樣，其他人就可以看到核心的不同區域發生了什麼。在開發速度
+很快的領域，可能會要求開發人員將提交的內容建立在這樣的子系統核心樹上，這樣
就避免了提交與其他已經進行的工作之間的衝突。
-這些存儲庫中的大多數都是Git樹，但是也有其他的scm在使用，或者補丁隊列被發布
-爲Quilt系列。這些子系統存儲庫的地址列在MAINTAINERS文件中。其中許多可以在
+這些儲存庫中的大多數都是Git樹，但是也有其他的scm在使用，或者補丁佇列被發布
+為Quilt系列。這些子系統儲存庫的地址列在MAINTAINERS檔案中。其中許多可以在
https://git.kernel.org/上瀏覽。
在將一個建議的補丁提交到這樣的子系統樹之前，需要對它進行審查，審查主要發生
-在郵件列表上（請參見下面相應的部分）。對於幾個內核子系統，這個審查過程是通
-過工具補丁跟蹤的。Patchwork提供了一個Web界面，顯示補丁發布、對補丁的任何評
-論或修訂，維護人員可以將補丁標記爲正在審查、接受或拒絕。大多數補丁網站都列
+在郵件列表上（請參見下面相應的部分）。對於幾個核心子系統，這個審查過程是通
+過工具補丁追蹤的。Patchwork提供了一個Web介面，顯示補丁發布、對補丁的任何評
+論或修訂，維護人員可以將補丁標記為正在審查、接受或拒絕。大多數補丁網站都列
在 https://patchwork.kernel.org/
-Linux-next 集成測試樹
+Linux-next 整合測試樹
---------------------
-在將子系統樹的更新合併到主線樹之前，需要對它們進行集成測試。爲此，存在一個
-特殊的測試存儲庫，其中幾乎每天都會提取所有子系統樹：
+在將子系統樹的更新合併到主線樹之前，需要對它們進行整合測試。為此，存在一個
+特殊的測試儲存庫，其中幾乎每天都會提取所有子系統樹：
- https://git.kernel.org/？p=linux/kernel/git/next/linux-next.git
+ https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
-通過這種方式，Linux-next 對下一個合併階段將進入主線內核的內容給出了一個概要
-展望。非常歡冒險的測試者運行測試Linux-next。
+透過這種方式，Linux-next 對下一個合併階段將進入主線核心的內容給出了一個概要
+展望。非常歡迎冒險的測試者對linux-next進行執行時測試。
-多個主要版本的穩定版內核樹
+多個主要版本的穩定版核心樹
-----------------------------------
-由3個數字組成的內核版本號說明此內核是-stable版本。它們包含內核的相對較小且
-至關重要的修補，這些修補針對安全性問題或者嚴重的內核退步。
+由3個數字組成的核心版本號說明此核心是-stable版本。它們包含核心的相對較小且
+至關重要的修補，這些修補針對安全性問題或者嚴重的核心退步。
-這種版本的內核適用於那些期望獲得最新的穩定版內核並且不想參與測試開發版或
-者實驗版的用戶。
+這種版本的核心適用於那些期望獲得最新的穩定版核心並且不想參與測試開發版或
+者實驗版的使用者。
-穩定版內核樹版本由「穩定版」小組（郵件地址<stable@vger.kernel.org>）維護，一般
+穩定版核心樹版本由「穩定版」小組（郵件地址<stable@vger.kernel.org>）維護，一般
隔周發布新版本。
-內核源碼中的 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
-文件具體描述了可被穩定版內核接受的修改類型以及發布的流程。
+核心源碼中的
+:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+文件具體描述了可被穩定版核心接受的修改類型以及發布的流程。
報告bug
-------
-bugzilla.kernel.org是Linux內核開發者們用來跟蹤內核Bug的網站。我們鼓勵用
-戶在這個工具中報告找到的所有bug。如何使用內核bugzilla的細節請訪問：
+bugzilla.kernel.org是Linux核心開發者們用來追蹤核心Bug的網站。我們鼓勵用
+戶在這個工具中報告找到的所有bug。如何使用核心bugzilla的細節請造訪：
http://test.kernel.org/bugzilla/faq.html
-內核源碼主目錄中的:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
-文件里有一個很好的模板。它指導用戶如何報告可能的內核bug以及需要提供哪些信息
-來幫助內核開發者們找到問題的根源。
+核心源碼主目錄中的:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
+文件裡有一個很好的模板。它指導使用者如何報告可能的核心bug以及需要提供哪些資訊
+來幫助核心開發者們找到問題的根源。
利用bug報告
-----------
-練習內核開發技能的最好辦法就是修改其他人報告的bug。你不光可以幫助內核變
+練習核心開發技能的最好辦法就是修改其他人報告的bug。你不光可以幫助核心變
得更加穩定，還可以學會如何解決實際問題從而提高自己的技能，並且讓其他開發
-者感受到你的存在。修改bug是贏得其他開發者讚譽的最好辦法，因爲並不是很多
+者感受到你的存在。修改bug是贏得其他開發者讚譽的最好辦法，因為並不是很多
人都喜歡浪費時間去修改別人報告的bug。
-要嘗試修改已知的bug，請訪問 http://bugzilla.kernel.org 網址。
+要嘗試修改已知的bug，請造訪 http://bugzilla.kernel.org 網址。
郵件列表
--------
-正如上面的文檔所描述，大多數的骨幹內核開發者都加入了Linux Kernel郵件列
+正如上面的文件所描述，大多數的骨幹核心開發者都加入了Linux Kernel郵件列
表。如何訂閱和退訂列表的細節可以在這裡找到：
- http://vger.kernel.org/vger-lists.html#linux-kernel
+ https://subspace.kernel.org/subscribing.html
網上很多地方都有這個郵件列表的存檔(archive)。可以使用搜尋引擎來找到這些
存檔。比如：
- https://lore.kernel.org/lkml/
+ https://lore.kernel.org/linux-kernel/
在發信之前，我們強烈建議你先在存檔中搜索你想要討論的問題。很多已經被詳細
討論過的問題只在郵件列表的存檔中可以找到。
-大多數內核子系統也有自己獨立的郵件列表來協調各自的開發工作。從
-MAINTAINERS文件中可以找到不同話題對應的郵件列表。
+大多數核心子系統也有自己獨立的郵件列表來協調各自的開發工作。從
+MAINTAINERS檔案中可以找到不同話題對應的郵件列表。
-很多郵件列表架設在kernel.org伺服器上。這些列表的信息可以在這裡找到：
+很多郵件列表架設在kernel.org伺服器上。這些列表的資訊可以在這裡找到：
- http://vger.kernel.org/vger-lists.html
+ https://subspace.kernel.org
-在使用這些郵件列表時，請記住保持良好的行爲習慣。下面的連結提供了與這些列
+在使用這些郵件列表時，請記住保持良好的行為習慣。下面的連結提供了與這些列
表（或任何其它郵件列表）交流的一些簡單規則，雖然內容有點濫竽充數。
- http://www.albion.com/netiquette/
+ https://subspace.kernel.org/etiquette.html
當有很多人回覆你的郵件時，郵件的抄送列表會變得很長。請不要將任何人從抄送
列表中刪除，除非你有足夠的理由這麼做。也不要只回復到郵件列表。請習慣於同
-一封郵件接收兩次（一封來自發送者一封來自郵件列表），而不要試圖通過添加一
+一封郵件接收兩次（一封來自發送者一封來自郵件列表），而不要試圖透過添加一
些奇特的郵件頭來解決這個問題，人們不會喜歡的。
記住保留你所回復內容的上下文和源頭。在你回覆郵件的頂部保留「某某某說到……」
這幾行。將你的評論加在被引用的段落之間而不要放在郵件的頂部。
-如果你在郵件中附帶補丁，請確認它們是可以直接閱讀的純文本（如
+如果你在郵件中附帶補丁，請確認它們是可以直接閱讀的純文字（如
:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
-文檔中所述）。內核開發者們不希望遇到附件或者被壓縮了的補丁。只有這樣才能
-保證他們可以直接評論你的每行代碼。請確保你使用的郵件發送程序不會修改空格
+文件中所述）。核心開發者們不希望遇到附件或者被壓縮了的補丁。只有這樣才能
+保證他們可以直接評論你的每行程式碼。請確保你使用的郵件發送程式不會修改空格
和制表符。一個防範性的測試方法是先將郵件發送給自己，然後自己嘗試是否可以
-順利地打上收到的補丁。如果測試不成功，請調整或者更換你的郵件發送程序直到
-它正確工作爲止。
+順利地打上收到的補丁。如果測試不成功，請調整或者更換你的郵件發送程式直到
+它正確工作為止。
總而言之，請尊重其他的郵件列表訂閱者。
-同內核社區合作
+同核心社群合作
----------------
-內核社區的目標就是提供盡善盡美的內核。所以當你提交補丁期望被接受進內核的
+核心社群的目標就是提供盡善盡美的核心。所以當你提交補丁期望被接受進核心的
時候，它的技術價值以及其他方面都將被評審。那麼你可能會得到什麼呢？
- 批評
@@ -357,9 +359,9 @@ MAINTAINERS文件中可以找到不同話題對應的郵件列表。
- 要求證明修改的必要性
- 沉默
-要記住，這些是把補丁放進內核的正常情況。你必須學會聽取對補丁的批評和評論，
+要記住，這些是把補丁放進核心的正常情況。你必須學會聽取對補丁的批評和評論，
從技術層面評估它們，然後要麼重寫你的補丁要麼簡明扼要地論證修改是不必要
-的。如果你發的郵件沒有得到任何回應，請過幾天後再試一次，因爲有時信件會湮
+的。如果你發的郵件沒有得到任何回應，請過幾天後再試一次，因為有時信件會湮
沒在茫茫信海中。
你不應該做的事情：
@@ -369,8 +371,8 @@ MAINTAINERS文件中可以找到不同話題對應的郵件列表。
- 忽略別人的評論
- 沒有按照別人的要求做任何修改就重新提交
-在一個努力追尋最好技術方案的社區里，對於一個補丁有多少好處總會有不同的見
-解。你必須要抱著合作的態度，願意改變自己的觀點來適應內核的風格。或者至少
+在一個努力追尋最好技術方案的社群裡，對於一個補丁有多少好處總會有不同的見
+解。你必須要抱著合作的態度，願意改變自己的觀點來適應核心的風格。或者至少
願意去證明你的想法是有價值的。記住，犯錯誤是允許的，只要你願意朝著正確的
方案去努力。
@@ -378,36 +380,36 @@ MAINTAINERS文件中可以找到不同話題對應的郵件列表。
不會被接受，也不意味著有人和你作對。你只需要改正所有提出的問題然後重新發
送你的補丁。
-內核社區和公司文化的差異
+核心社群和公司文化的差異
------------------------
-內核社區的工作模式同大多數傳統公司開發隊伍的工作模式並不相同。下面這些例
+核心社群的工作模式同大多數傳統公司開發隊伍的工作模式並不相同。下面這些例
子，可以幫助你避免某些可能發生問題：
用這些話介紹你的修改提案會有好處：
- 它同時解決了多個問題
- - 它刪除了2000行代碼
+ - 它刪除了2000行程式碼
- 這是補丁，它已經解釋了我想要說明的
- 我在5種不同的體系結構上測試過它……
- 這是一系列小補丁用來……
- - 這個修改提高了普通機器的性能……
+ - 這個修改提高了普通機器的效能……
應該避免如下的說法：
- 我們在AIX/ptx/Solaris就是這麼做的，所以這麼做肯定是好的……
- 我做這行已經20年了，所以……
- - 爲了我們公司賺錢考慮必須這麼做
+ - 為了我們公司賺錢考慮必須這麼做
- 這是我們的企業產品線所需要的
- - 這裡是描述我觀點的1000頁設計文檔
+ - 這裡是描述我觀點的1000頁設計文件
- 這是一個5000行的補丁用來……
- - 我重寫了現在亂七八糟的代碼，這就是……
+ - 我重寫了現在亂七八糟的程式碼，這就是……
- 我被規定了最後期限，所以這個補丁需要立刻被接受
-另外一個內核社區與大部分傳統公司的軟體開發隊伍不同的地方是無法面對面地交
-流。使用電子郵件和IRC聊天工具做爲主要溝通工具的一個好處是性別和種族歧視
-將會更少。Linux內核的工作環境更能接受婦女和少數族羣，因爲每個人在別人眼
-里只是一個郵件地址。國際化也幫助了公平的實現，因爲你無法通過姓名來判斷人
-的性別。男人有可能叫李麗，女人也有可能叫王剛。大多數在Linux內核上工作過
+另外一個核心社群與大部分傳統公司的軟體開發隊伍不同的地方是無法面對面地交
+流。使用電子郵件和IRC聊天工具做為主要溝通工具的一個好處是性別和種族歧視
+將會更少。Linux核心的工作環境更能接受婦女和少數族羣，因為每個人在別人眼
+里只是一個郵件地址。國際化也幫助了公平的實作，因為你無法透過姓名來判斷人
+的性別。男人有可能叫李麗，女人也有可能叫王剛。大多數在Linux核心上工作過
並表達過看法的女性對在linux上工作的經歷都給出了正面的評價。
對於一些不習慣使用英語的人來說，語言可能是一個引起問題的障礙。在郵件列表
@@ -418,61 +420,61 @@ MAINTAINERS文件中可以找到不同話題對應的郵件列表。
拆分修改
--------
-Linux內核社區並不喜歡一下接收大段的代碼。修改需要被恰當地介紹、討論並且
+Linux核心社群並不喜歡一下接收大段的程式碼。修改需要被恰當地介紹、討論並且
拆分成獨立的小段。這幾乎完全和公司中的習慣背道而馳。你的想法應該在開發最
開始的階段就讓大家知道，這樣你就可以及時獲得對你正在進行的開發的反饋。這
-樣也會讓社區覺得你是在和他們協作，而不是僅僅把他們當作傾銷新功能的對象。
+樣也會讓社群覺得你是在和他們協作，而不是僅僅把他們當作傾銷新功能的物件。
無論如何，你不要一次性地向郵件列表發送50封信，你的補丁序列應該永遠用不到
這麼多。
將補丁拆開的原因如下：
-1) 小的補丁更有可能被接受，因爲它們不需要太多的時間和精力去驗證其正確性。
+1) 小的補丁更有可能被接受，因為它們不需要太多的時間和精力去驗證其正確性。
一個5行的補丁，可能在維護者看了一眼以後就會被接受。而500行的補丁則
需要數個小時來審查其正確性（所需時間隨補丁大小增加大約呈指數級增長）。
- 當出了問題的時候，小的補丁也會讓調試變得非常容易。一個一個補丁地回溯
+ 當出了問題的時候，小的補丁也會讓除錯變得非常容易。一個一個補丁地回溯
將會比仔細剖析一個被打上的大補丁（這個補丁破壞了其他東西）容易得多。
2）不光發送小的補丁很重要，在提交之前重新編排、化簡（或者僅僅重新排列）
補丁也是很重要的。
-這裡有內核開發者Al Viro打的一個比方：
- 「想像一個老師正在給學生批改數學作業。老師並不希望看到學生爲了得
+這裡有核心開發者Al Viro打的一個比方：
+ 「想像一個老師正在給學生批改數學作業。老師並不希望看到學生為了得
到正確解法所進行的嘗試和產生的錯誤。他希望看到的是最乾淨最優雅的
解答。好學生了解這點，絕不會把最終解決之前的中間方案提交上去。」
- 內核開發也是這樣。維護者和評審者不希望看到一個人在解決問題時的思
+ 核心開發也是這樣。維護者和評審者不希望看到一個人在解決問題時的思
考過程。他們只希望看到簡單和優雅的解決方案。
-直接給出一流的解決方案，和社區一起協作討論尚未完成的工作，這兩者之間似乎
+直接給出一流的解決方案，和社群一起協作討論尚未完成的工作，這兩者之間似乎
很難找到一個平衡點。所以最好儘早開始收集有利於你進行改進的反饋；同時也要
-保證修改分成很多小塊，這樣在整個項目都準備好被包含進內核之前，其中的一部
+保證修改分成很多小塊，這樣在整個專案都準備好被包含進核心之前，其中的一部
分可能會先被接收。
-必須了解這樣做是不可接受的：試圖將未完成的工作提交進內核，然後再找時間修
+必須了解這樣做是不可接受的：試圖將未完成的工作提交進核心，然後再找時間修
復。
證明修改的必要性
----------------
-除了將補丁拆成小塊，很重要的一點是讓Linux社區了解他們爲什麼需要這樣修改。
+除了將補丁拆成小塊，很重要的一點是讓Linux社群了解他們為什麼需要這樣修改。
你必須證明新功能是有人需要的並且是有用的。
記錄修改
--------
-當你發送補丁的時候，需要特別留意郵件正文的內容。因爲這裡的信息將會做爲補
-丁的修改記錄(ChangeLog)，會被一直保留以備大家查閱。它需要完全地描述補丁，
+當你發送補丁的時候，需要特別留意郵件正文的內容。因為這裡的資訊將會做為補丁
+的修改記錄(ChangeLog)，會被一直保留以備大家查閱。它需要完全地描述補丁，
包括：
- - 爲什麼需要這個修改
+ - 為什麼需要這個修改
- 補丁的總體設計
- - 實現細節
+ - 實作細節
- 測試結果
-想了解它具體應該看起來像什麼，請查閱以下文檔中的「ChangeLog」章節：
+想了解它具體應該看起來像什麼，請查閱以下文件中的「ChangeLog」章節：
「The Perfect Patch」
https://www.ozlabs.org/~akpm/stuff/tpp.txt
@@ -490,7 +492,7 @@ Dunlap和Gerrit Huizenga完善了應該說和不該說的列表。感謝Pat Moch
Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer,
Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian
Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael
-Kerrisk和Alex Shepard的評審、建議和貢獻。沒有他們的幫助，這篇文檔是不可
+Kerrisk和Alex Shepard的評審、建議和貢獻。沒有他們的幫助，這篇文件是不可
能完成的。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 12/16] docs/zh_TW: process: localize terminology in embargoed-hardware-issues.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (10 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 11/16] docs/zh_TW: process: localize terminology in howto.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 13/16] docs/zh_TW: process: localize terminology in submitting-patches.rst Chen-Yu Yeh
` (4 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 硬件→硬體,
信息→資訊, ...) and sync with the English original: silicon-vendor
wording, real PGP/S/MIME key URLs, updated Linux Foundation IT
paragraph, disclosing-party responsibilities, shared-resources rule,
the new "Early access" section, and the current process ambassadors
list. Also fix the broken zh_Contact cross reference.
update to commit cead34ac1ce1 ("MAINTAINERS: update ndesaulniers")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../process/embargoed-hardware-issues.rst | 209 ++++++++++--------
1 file changed, 122 insertions(+), 87 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
index 93d21fd88910..611247c816f4 100644
--- a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
+++ b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
@@ -5,115 +5,119 @@
:Original: :ref:`Documentation/process/embargoed-hardware-issues.rst <embargoed_hardware_issues>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
+ Chen-Yu Yeh <chenyou910331@gmail.com>
-被限制的硬件問題
+被限制的硬體問題
================
範圍
----
-導致安全問題的硬件問題與隻影響Linux內核的純軟件錯誤是不同的安全錯誤類別。
+導致安全問題的硬體問題與只影響Linux核心的純軟體錯誤是不同的安全錯誤類別。
-必須區別對待諸如熔燬(Meltdown)、Spectre、L1TF等硬件問題，因爲它們通常會影響
-所有操作系統（“OS”），因此需要在不同的OS供應商、發行版、硬件供應商和其他各方
-之間進行協調。對於某些問題，軟件緩解可能依賴於微碼或固件更新，這需要進一步的
-協調。
+必須區別對待諸如熔毀(Meltdown)、Spectre、L1TF等硬體問題，因為它們通常會影
+響所有作業系統（“OS”），因此需要在不同的OS供應商、發行版、晶片供應商、硬體
+整合商和其他各方之間進行協調。對於某些問題，軟體緩解可能依賴於微碼或韌體更
+新，這需要進一步的協調。
.. _tw_Contact:
接觸
----
-Linux內核硬件安全小組獨立於普通的Linux內核安全小組。
+Linux核心硬體安全小組獨立於普通的Linux核心安全小組。
-該小組只負責協調被限制的硬件安全問題。Linux內核中純軟件安全漏洞的報告不由該
-小組處理，報告者將被引導至常規Linux內核安全小組(:ref:`Documentation/admin-guide/
-<securitybugs>`)聯繫。
+該小組只負責協調被限制的硬體安全問題。Linux核心中純軟體安全漏洞的報告不由
+該小組處理，報告者將被引導至常規Linux核心安全小組(
+:ref:`Documentation/admin-guide/<securitybugs>`)聯繫。
-可以通過電子郵件 <hardware-security@kernel.org> 與小組聯繫。這是一份私密的安全
-官名單，他們將幫助您根據我們的文檔化流程協調問題。
+可以透過電子郵件 <hardware-security@kernel.org> 與小組聯繫。這是一份私密的安全
+官名單，他們將幫助您根據我們的文件化流程協調問題。
-郵件列表是加密的，發送到列表的電子郵件可以通過PGP或S/MIME加密，並且必須使用報告
-者的PGP密鑰或S/MIME證書籤名。該列表的PGP密鑰和S/MIME證書可從
-https://www.kernel.org/.... 獲得。
+郵件列表是加密的，發送到列表的電子郵件可以透過PGP或S/MIME加密，並且必須使
+用報告者的PGP密鑰或S/MIME證書籤名。該列表的PGP密鑰和S/MIME證書可從以下URL
+獲得：
-雖然硬件安全問題通常由受影響的硬件供應商處理，但我們歡迎發現潛在硬件缺陷的研究
+ - PGP: https://www.kernel.org/static/files/hardware-security.asc
+ - S/MIME: https://www.kernel.org/static/files/hardware-security.crt
+
+雖然硬體安全問題通常由受影響的晶片供應商處理，但我們歡迎發現潛在硬體缺陷的研究
人員或個人與我們聯繫。
-硬件安全官
+硬體安全官
^^^^^^^^^^
-目前的硬件安全官小組:
+目前的硬體安全官小組:
- Linus Torvalds（Linux基金會院士）
- - Greg Kroah Hartman（Linux基金會院士）
+ - Greg Kroah-Hartman（Linux基金會院士）
- Thomas Gleixner（Linux基金會院士）
郵件列表的操作
^^^^^^^^^^^^^^
-處理流程中使用的加密郵件列表託管在Linux Foundation的IT基礎設施上。通過提供這項
-服務，Linux基金會的IT基礎設施安全總監在技術上有能力訪問被限制的信息，但根據他
-的僱傭合同，他必須保密。Linux基金會的IT基礎設施安全總監還負責 kernel.org 基礎
-設施。
+處理流程中使用的加密郵件列表託管在Linux基金會的IT基礎設施上。透過提供這項
+服務，Linux基金會IT營運人員在技術上有能力存取被限制的資訊，但根據其僱傭
+合約必須保密。Linux基金會的IT人員還負責營運和管理kernel.org的其餘基礎設施。
-Linux基金會目前的IT基礎設施安全總監是 Konstantin Ryabitsev。
+Linux基金會目前的IT專案基礎設施總監是 Konstantin Ryabitsev。
保密協議
--------
-Linux內核硬件安全小組不是正式的機構，因此無法簽訂任何保密協議。核心社區意識到
+Linux核心硬體安全小組不是正式的機構，因此無法簽訂任何保密協議。核心社群意識到
這些問題的敏感性，並提供了一份諒解備忘錄。
諒解備忘錄
----------
-Linux內核社區深刻理解在不同操作系統供應商、發行商、硬件供應商和其他各方之間
-進行協調時，保持硬件安全問題處於限制狀態的要求。
+Linux核心社群深刻理解在不同作業系統供應商、發行商、晶片供應商和其他各方之間
+進行協調時，保持硬體安全問題處於限制狀態的要求。
-Linux內核社區在過去已經成功地處理了硬件安全問題，並且有必要的機制允許在限制
-限制下進行符合社區的開發。
+Linux核心社群在過去已經成功地處理了硬體安全問題，並且有必要的機制允許在限制
+限制下進行符合社群的開發。
-Linux內核社區有一個專門的硬件安全小組負責初始聯繫，並監督在限制規則下處理
+Linux核心社群有一個專門的硬體安全小組負責初始聯繫，並監督在限制規則下處理
此類問題的過程。
-硬件安全小組確定開發人員（領域專家），他們將組成特定問題的初始響應小組。最初
+硬體安全小組確定開發人員（領域專家），他們將組成特定問題的初始響應小組。最初
的響應小組可以引入更多的開發人員（領域專家）以最佳的技術方式解決這個問題。
-所有相關開發商承諾遵守限制規定，並對收到的信息保密。違反承諾將導致立即從當前
-問題中排除，並從所有相關郵件列表中刪除。此外，硬件安全小組還將把違反者排除在
-未來的問題之外。這一後果的影響在我們社區是一種非常有效的威懾。如果發生違規
-情況，硬件安全小組將立即通知相關方。如果您或任何人發現潛在的違規行爲，請立即
-向硬件安全人員報告。
+所有相關開發商承諾遵守限制規定，並對收到的資訊保密。違反承諾將導致立即從當前
+問題中排除，並從所有相關郵件列表中刪除。此外，硬體安全小組還將把違反者排除在
+未來的問題之外。這一後果的影響在我們社群是一種非常有效的威懾。如果發生違規
+情況，硬體安全小組將立即通知相關方。如果您或任何人發現潛在的違規行為，請立即
+向硬體安全人員報告。
流程
^^^^
-由於Linux內核開發的全球分佈式特性，面對面的會議幾乎不可能解決硬件安全問題。
+由於Linux核心開發的全球分散式特性，面對面的會議幾乎不可能解決硬體安全問題。
由於時區和其他因素，電話會議很難協調，只能在絕對必要時使用。加密電子郵件已被
證明是解決此類問題的最有效和最安全的通信方法。
開始披露
""""""""
-披露內容首先通過電子郵件聯繫Linux內核硬件安全小組。此初始聯繫人應包含問題的
-描述和任何已知受影響硬件的列表。如果您的組織製造或分發受影響的硬件，我們建議
-您也考慮哪些其他硬件可能會受到影響。
+披露首先按照上述聯繫方式一節，透過電子郵件聯繫Linux核心硬體安全小組。此
+初始聯繫應包含問題的描述和任何已知受影響晶片的列表。如果您的組織製造或分發
+受影響的硬體，我們建議您也考慮哪些其他硬體可能會受到影響。披露方有責任及時
+聯繫受影響的晶片供應商。
-硬件安全小組將提供一個特定於事件的加密郵件列表，用於與報告者進行初步討論、
+硬體安全小組將提供一個特定於事件的加密郵件列表，用於與報告者進行初步討論、
進一步披露和協調。
-硬件安全小組將向披露方提供一份開發人員（領域專家）名單，在與開發人員確認他們
-將遵守本諒解備忘錄和文件化流程後，應首先告知開發人員有關該問題的信息。這些開發
-人員組成初始響應小組，並在初始接觸後負責處理問題。硬件安全小組支持響應小組，
+硬體安全小組將向披露方提供一份開發人員（領域專家）名單，在與開發人員確認他們
+將遵守本諒解備忘錄和文件化流程後，應首先告知開發人員有關該問題的資訊。這些開發
+人員組成初始響應小組，並在初始接觸後負責處理問題。硬體安全小組支援響應小組，
但不一定參與緩解開發過程。
-雖然個別開發人員可能通過其僱主受到保密協議的保護，但他們不能以Linux內核開發
-人員的身份簽訂個別保密協議。但是，他們將同意遵守這一書面程序和諒解備忘錄。
+雖然個別開發人員可能透過其僱主受到保密協議的保護，但他們不能以Linux核心開發
+人員的身份簽訂個別保密協議。但是，他們將同意遵守這一書面程式和諒解備忘錄。
披露方應提供已經或應該被告知該問題的所有其他實體的聯繫人名單。這有幾個目的:
- - 披露的實體列表允許跨行業通信，例如其他操作系統供應商、硬件供應商等。
+ - 披露的實體列表允許跨行業通信，例如其他作業系統供應商、硬體供應商等。
- 可聯繫已披露的實體，指定應參與緩解措施開發的專家。
@@ -123,67 +127,97 @@ Linux內核社區有一個專門的硬件安全小組負責初始聯繫，並監
披露
""""
-披露方通過特定的加密郵件列表向初始響應小組提供詳細信息。
+披露方透過特定的加密郵件列表向初始響應小組提供詳細資訊。
-根據我們的經驗，這些問題的技術文檔通常是一個足夠的起點，最好通過電子郵件進行
+根據我們的經驗，這些問題的技術文件通常是一個足夠的起點，最好透過電子郵件進行
進一步的技術澄清。
緩解開發
""""""""
-初始響應小組設置加密郵件列表，或在適當的情況下重新修改現有郵件列表。
+初始響應小組設定加密郵件列表，或在適當的情況下重新修改現有郵件列表。
-使用郵件列表接近於正常的Linux開發過程，並且在過去已經成功地用於爲各種硬件安全
+使用郵件列表接近於正常的Linux開發過程，並且在過去已經成功地用於為各種硬體安全
問題開發緩解措施。
-郵件列表的操作方式與正常的Linux開發相同。發佈、討論和審查修補程序，如果同意，
-則應用於非公共git存儲庫，參與開發人員只能通過安全連接訪問該存儲庫。存儲庫包含
-針對主線內核的主開發分支，並根據需要爲穩定的內核版本提供向後移植分支。
+郵件列表的操作方式與正常的Linux開發相同。發布、討論和審查修補程式，如果同意，
+則應用於非公共git儲存庫，參與開發人員只能透過安全連接存取該儲存庫。儲存庫包含
+針對主線核心的主開發分支，並根據需要為穩定的核心版本提供向後移植分支。
+
+最初的響應小組將根據需要從Linux核心開發人員社群中確定更多的專家。任何相關
+方都可以建議增補專家，每位專家都須符合上述相同的要求。
-最初的響應小組將根據需要從Linux內核開發人員社區中確定更多的專家。引進專家可以
-在開發過程中的任何時候發生，需要及時處理。
+引進專家可以在開發過程中的任何時候發生，需要及時處理。
如果專家受僱於披露方提供的披露清單上的實體或其成員，則相關實體將要求其參與。
否則，披露方將被告知專家參與的情況。諒解備忘錄涵蓋了專家，要求披露方確認參與。
如果披露方有令人信服的理由提出異議，則必須在五個工作日內提出異議，並立即與事件
-小組解決。如果披露方在五個工作日內未作出回應，則視爲默許。
+小組解決。如果披露方在五個工作日內未作出回應，則視為默許。
在確認或解決異議後，專家由事件小組披露，並進入開發過程。
+列表參與者不得在私有郵件列表之外交流該問題。列表參與者在處理補丁時不得使用
+任何共享資源（例如僱主的建置農場、CI系統等）。
+
+提前取得
+""""""""
+
+在列表上討論和開發的補丁，既不能分發給任何非響應小組成員的個人，也不能分發
+給任何其他組織。
+
+為了讓受影響的晶片供應商能夠與其內部團隊和產業夥伴合作進行測試、驗證和
+後勤工作，提供了以下例外：
+
+ 受影響晶片供應商的指定代表可以在任何時候將補丁移交給該晶片供應商
+ 的響應小組。該代表必須將移交一事通知核心響應小組。受影響的晶片
+ 供應商必須為與其響應小組共享的任何補丁，制定並維護自己的、與本
+ 政策一致的文件化安全流程。
+
+ 晶片供應商的響應小組可以依照該晶片供應商的文件化安全流程，將這些
+ 補丁分發給其產業夥伴及其內部團隊。來自產業夥伴的反饋會回到晶片
+ 供應商，並由晶片供應商轉達給核心響應小組。
+
+ 移交給晶片供應商的響應小組後，因晶片供應商的內部團隊或產業夥伴的
+ 參與而發生的過早披露，核心響應小組不再承擔任何責任或義務。晶片
+ 供應商透過同意本流程來保證這一責任免除。
+
協調發布
""""""""
-有關各方將協商限制結束的日期和時間。此時，準備好的緩解措施集成到相關的內核樹中
+有關各方將協商限制結束的日期和時間。此時，準備好的緩解措施整合到相關的核心樹中
併發布。
-雖然我們理解硬件安全問題需要協調限制時間，但限制時間應限制在所有有關各方制定、
-測試和準備緩解措施所需的最短時間內。人爲地延長限制時間以滿足會議討論日期或其他
-非技術原因，會給相關的開發人員和響應小組帶來了更多的工作和負擔，因爲補丁需要
-保持最新，以便跟蹤正在進行的上游內核開發，這可能會造成衝突的更改。
+雖然我們理解硬體安全問題需要協調限制時間，但限制時間應限制在所有有關各方制定、
+測試和準備緩解措施所需的最短時間內。人為地延長限制時間以滿足會議討論日期或其他
+非技術原因，會給相關的開發人員和響應小組帶來了更多的工作和負擔，因為補丁需要
+保持最新，以便追蹤正在進行的上游核心開發，這可能會造成衝突的更改。
CVE分配
"""""""
-硬件安全小組和初始響應小組都不分配CVE，開發過程也不需要CVE。如果CVE是由披露方
-提供的，則可用於文檔中。
+硬體安全小組和初始響應小組都不分配CVE，開發過程也不需要CVE。如果CVE是由披露方
+提供的，則可用於文件記錄目的。
流程專使
--------
-爲了協助這一進程，我們在各組織設立了專使，他們可以回答有關報告流程和進一步處理
+為了協助這一流程，我們在各組織設立了專使，他們可以回答有關報告流程和進一步處理
的問題或提供指導。專使不參與特定問題的披露，除非響應小組或相關披露方提出要求。
現任專使名單:
============= ========================================================
- ARM
AMD Tom Lendacky <thomas.lendacky@amd.com>
- IBM
+ Ampere Darren Hart <darren@os.amperecomputing.com>
+ ARM Catalin Marinas <catalin.marinas@arm.com>
+ IBM Power Madhavan Srinivasan <maddy@linux.ibm.com>
+ IBM Z Christian Borntraeger <borntraeger@de.ibm.com>
Intel Tony Luck <tony.luck@intel.com>
Qualcomm Trilok Soni <quic_tsoni@quicinc.com>
+ RISC-V Palmer Dabbelt <palmer@dabbelt.com>
+ Samsung Javier González <javier.gonz@samsung.com>
- Microsoft Sasha Levin <sashal@kernel.org>
- VMware
+ Microsoft James Morris <jamorris@linux.microsoft.com>
Xen Andrew Cooper <andrew.cooper3@citrix.com>
Canonical John Johansen <john.johansen@canonical.com>
@@ -192,27 +226,28 @@ CVE分配
Red Hat Josh Poimboeuf <jpoimboe@redhat.com>
SUSE Jiri Kosina <jkosina@suse.cz>
- Amazon
Google Kees Cook <keescook@chromium.org>
+
+ LLVM Nick Desaulniers <ndesaulniers@google.com>
============= ========================================================
-如果要將您的組織添加到專使名單中，請與硬件安全小組聯繫。被提名的專使必須完全
-理解和支持我們的過程，並且在Linux內核社區中很容易聯繫。
+如果要將您的組織添加到專使名單中，請與硬體安全小組聯繫。被提名的專使必須完全
+理解和支援我們的過程，並且在Linux核心社群中很容易聯繫。
加密郵件列表
------------
我們使用加密郵件列表進行通信。這些列表的工作原理是，發送到列表的電子郵件使用
-列表的PGP密鑰或列表的/MIME證書進行加密。郵件列表軟件對電子郵件進行解密，並
-使用訂閱者的PGP密鑰或S/MIME證書爲每個訂閱者分別對其進行重新加密。有關郵件列表
-軟件和用於確保列表安全和數據保護的設置的詳細信息，請訪問:
-https://www.kernel.org/....
+列表的PGP密鑰或列表的S/MIME證書進行加密。郵件列表軟體對電子郵件進行解密，並
+使用訂閱者的PGP密鑰或S/MIME證書為每個訂閱者分別對其進行重新加密。有關郵件列表
+軟體和用於確保列表安全和資料保護的設定的詳細資訊，請見：
+https://korg.wiki.kernel.org/userdoc/remail.
-關鍵點
-^^^^^^
+列表密鑰
+^^^^^^^^
-初次接觸見 :ref:`zh_Contact`. 對於特定於事件的郵件列表，密鑰和S/MIME證書通過
-特定列表發送的電子郵件傳遞給訂閱者。
+初次接觸見上面的 :ref:`tw_Contact` 一節。 對於特定於事件的郵件列表，密鑰和
+S/MIME證書透過特定列表發送的電子郵件傳遞給訂閱者。
訂閱事件特定列表
^^^^^^^^^^^^^^^^
@@ -220,13 +255,13 @@ https://www.kernel.org/....
訂閱由響應小組處理。希望參與通信的披露方將潛在訂戶的列表發送給響應組，以便
響應組可以驗證訂閱請求。
-每個訂戶都需要通過電子郵件向響應小組發送訂閱請求。電子郵件必須使用訂閱服務器
-的PGP密鑰或S/MIME證書籤名。如果使用PGP密鑰，則必須從公鑰服務器獲得該密鑰，
-並且理想情況下該密鑰連接到Linux內核的PGP信任網。另請參見:
+每個訂戶都需要透過電子郵件向響應小組發送訂閱請求。電子郵件必須使用訂閱者
+的PGP密鑰或S/MIME證書籤名。如果使用PGP密鑰，則必須從公鑰伺服器獲得該密鑰，
+並且理想情況下該密鑰連接到Linux核心的PGP信任網。另請參見:
https://www.kernel.org/signature.html.
-響應小組驗證訂閱者，並將訂閱者添加到列表中。訂閱後，訂閱者將收到來自郵件列表
-的電子郵件，該郵件列表使用列表的PGP密鑰或列表的/MIME證書籤名。訂閱者的電子郵件
-客戶端可以從簽名中提取PGP密鑰或S/MIME證書，以便訂閱者可以向列表發送加密電子
-郵件。
+響應小組驗證訂閱者，並將訂閱者添加到列表中。訂閱後，訂閱者將收到來自郵件列
+表的電子郵件，該郵件列表使用列表的PGP密鑰或列表的S/MIME證書籤名。訂閱者的
+電子郵件客戶端可以從簽名中提取PGP密鑰或S/MIME證書，以便訂閱者可以向列表發
+送加密電子郵件。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 13/16] docs/zh_TW: process: localize terminology in submitting-patches.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (11 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 12/16] docs/zh_TW: process: localize terminology in embargoed-hardware-issues.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-07 2:35 ` Dongliang Mu
2026-08-06 18:19 ` [PATCH v3 14/16] docs/zh_TW: process: localize terminology in 8.Conclusion.rst Chen-Yu Yeh
` (3 subsequent siblings)
16 siblings, 1 reply; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 文件→檔案,
代碼→程式碼, ...) and sync with the English original: subspace.kernel.org
list info, interleaved-reply etiquette section, reworked Acked-by
semantics with "# Suffix", tagging-people permission rules, the
Assisted-by tag, canonical patch format subsections with
affiliation format and previous-version links, and the b4 tooling
section. Cross references now point at zh_TW translations and broken
zh_-prefixed ref targets are fixed to tw_.
update to commit 48c3876a6a6f ("docs: submitting-patches: Clarify that
"reviewer" is a person")
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../zh_TW/process/submitting-patches.rst | 556 ++++++++++--------
1 file changed, 325 insertions(+), 231 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst
index 64de92c07906..b780f1539b46 100644
--- a/Documentation/translations/zh_TW/process/submitting-patches.rst
+++ b/Documentation/translations/zh_TW/process/submitting-patches.rst
@@ -15,37 +15,38 @@
- 李陽 Li Yang <leoyang.li@nxp.com>
- 王聰 Wang Cong <xiyou.wangcong@gmail.com>
- 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ - 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
-提交補丁：如何讓你的改動進入內核
+提交補丁：如何讓你的改動進入核心
================================
-對於想要將改動提交到 Linux 內核的個人或者公司來說，如果不熟悉“規矩”，
-提交的流程會讓人畏懼。本文檔包含了一系列建議，可以大大提高你
+對於想要將改動提交到 Linux 核心的個人或者公司來說，如果不熟悉“規矩”，
+提交的流程會讓人畏懼。本文件包含了一系列建議，可以大大提高你
的改動被接受的機會.
-本文檔以較爲簡潔的行文給出了大量建議。關於內核開發流程如何進行的詳細信息，
-參見： Documentation/translations/zh_CN/process/development-process.rst 。
-Documentation/translations/zh_CN/process/submit-checklist.rst 給出了一系列
+本文件以較為簡潔的行文給出了大量建議。關於核心開發流程如何進行的詳細資訊，
+參見： Documentation/translations/zh_TW/process/development-process.rst 。
+Documentation/translations/zh_TW/process/submit-checklist.rst 給出了一系列
提交補丁之前要檢查的事項。設備樹相關的補丁，請參閱
Documentation/devicetree/bindings/submitting-patches.rst 。
-本文檔假設您正在使用 ``git`` 準備你的補丁。如果您不熟悉 ``git`` ，最好學習
-如何使用它，這將使您作爲內核開發人員的生活變得更加輕鬆。
+本文件假設您正在使用 ``git`` 準備你的補丁。如果您不熟悉 ``git`` ，最好學習
+如何使用它，這將使您作為核心開發人員的生活變得更加輕鬆。
-部分子系統和維護人員的樹有一些關於其工作流程和要求的額外信息，請參閱
+部分子系統和維護人員的樹有一些關於其工作流程和要求的額外資訊，請參閱
Documentation/process/maintainer-handbooks.rst 。
獲取當前源碼樹
--------------
-如果您手頭沒有當前內核源代碼的存儲庫，請使用 ``git`` 獲取一份。您需要先獲取
-主線存儲庫，它可以通過以下命令拉取::
+如果您手頭沒有當前核心原始程式碼的儲存庫，請使用 ``git`` 獲取一份。您需要先獲取
+主線儲存庫，它可以透過以下命令拉取::
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
但是，請注意，您可能不想直接針對主線樹進行開發。大多數子系統維護人員運
-行自己的樹，並希望看到針對這些樹準備的補丁。請參見MAINTAINERS文件中子系
+行自己的樹，並希望看到針對這些樹準備的補丁。請參見MAINTAINERS檔案中子系
統的 **T:** 項以查找該樹，或者直接詢問維護者該樹是否未在其中列出。
.. _tw_describe_changes:
@@ -57,35 +58,37 @@ Documentation/process/maintainer-handbooks.rst 。
的問題激勵您完成這項工作。說服審閱者相信有一個問題值得解決，讓他們讀完第一段
後就能明白這一點。
-描述用戶可見的影響。直接崩潰和鎖定是相當有說服力的，但並不是所有的錯誤都那麼
-明目張膽。即使在代碼審閱期間發現了這個問題，也要描述一下您認爲它可能對用戶產
-生的影響。請記住，大多數Linux安裝運行的內核來自二級穩定樹或特定於供應商/產品
-的樹，只從上游精選特定的補丁，因此請包含任何可以幫助您將更改定位到下游的內容：
-觸發的場景、DMESG的摘錄、崩潰描述、性能迴歸、延遲尖峯、鎖定等。
+描述使用者可見的影響。直接崩潰和鎖定是相當有說服力的，但並不是所有的錯誤都
+那麼明目張膽。即使在程式碼審閱期間發現了這個問題，也要描述一下您認為它可能
+對使用者產生的影響。請記住，大多數Linux安裝執行的核心來自二級穩定樹或特定
+於供應商/產品的樹，只從上游精選特定的補丁，因此請包含任何可以幫助您將更改
+定位到下游的內容：觸發的場景、DMESG的摘錄、崩潰描述、效能迴歸、延遲尖峯、
+鎖定等。
-質量優化和權衡。如果您聲稱在性能、內存消耗、堆棧佔用空間或二進制大小方面有所
-改進，請包括支持它們的數據。但也要描述不明顯的成本。優化通常不是零成本的，而是
-在CPU、內存和可讀性之間進行權衡；或者，做探索性的工作，在不同的工作負載之間進
-行權衡。請描述優化的預期缺點，以便審閱者可以權衡成本和收益。
+品質最佳化和權衡。如果您聲稱在效能、記憶體消耗、堆疊佔用空間或二進位大小方
+面有所改進，請包括支援它們的資料。但也要描述不明顯的成本。最佳化通常不是零
+成本的，而是在CPU、記憶體和可讀性之間進行權衡；或者，做探索性的工作，在不
+同的工作負載之間進行權衡。請描述最佳化的預期缺點，以便審閱者可以權衡成本和
+收益。
提出問題之後，就要詳細地描述一下您實際在做的技術細節。對於審閱者來說，用簡練的
-英語描述代碼的變化是很重要的，以驗證代碼的行爲是否符合您的意圖。
+英語描述程式碼的變化是很重要的，以驗證程式碼的行為是否符合您的意圖。
-如果您將補丁描述寫成“標準格式”，可以很容易地作爲“提交日誌”放入Linux的源代
+如果您將補丁描述寫成“標準格式”，可以很容易地作為“提交日誌”放入Linux的源代
碼管理系統 ``git`` 中，那麼維護人員將非常感謝您。
-參見 :ref:`zh_the_canonical_patch_format` 。
+參見 :ref:`tw_the_canonical_patch_format` 。
每個補丁只解決一個問題。如果你的描述開始變長，這就表明你可能需要拆分你的補丁。
-請見 :ref:`zh_split_changes` 。
+請見 :ref:`tw_split_changes` 。
-提交或重新提交補丁或補丁系列時，請包括完整的補丁說明和理由。不要
-只說這是補丁（系列）的第幾版。不要期望子系統維護人員引用更早的補丁版本或引用
-URL來查找補丁描述並將其放入補丁中。也就是說，補丁（系列）及其描述應該是獨立的。
-這對維護人員和審閱者都有好處。一些審閱者可能甚至沒有收到補丁的早期版本。
+提交或重新提交補丁或補丁系列時，請包括完整的補丁說明和理由。不要只說這是補丁
+（系列）的第幾版。不要期望子系統維護人員引用更早的補丁版本或引用URL來查
+找補丁描述並將其放入補丁中。也就是說，補丁（系列）及其描述應該是獨立的。這
+對維護人員和審閱者都有好處。一些審閱者可能甚至沒有收到補丁的早期版本。
用祈使句描述你的變更，例如“make xyzzy do frotz”而不是“[This patch]make
-xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令代碼庫改變
-它的行爲一樣。
+xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令程式碼庫改變
+它的行為一樣。
如果您想要引用一個特定的提交，不要只引用提交的SHA-1 ID。還請包括提交的一行
摘要，以便於審閱者瞭解它是關於什麼的。例如::
@@ -95,38 +98,38 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令
platform_set_drvdata(), but left the variable "dev" unused,
delete it.
-您還應該確保至少使用前12位SHA-1 ID。內核存儲庫包含 *許多* 對象，使較短的ID
-發生衝突的可能性很大。記住，即使現在不會與您的六個字符ID發生衝突，這種情況
+您還應該確保至少使用前12位SHA-1 ID。核心儲存庫包含 *許多* 物件，使較短的ID
+發生衝突的可能性很大。記住，即使現在不會與您的六個字元ID發生衝突，這種情況
也可能在五年後改變。
-如果該變更的相關討論或背景信息可以在網上查閱，請加上“Link:”標籤指向它。例如
-你的補丁修復了一個缺陷，需要添加一個帶有URL的標籤指向郵件列表存檔或缺陷跟蹤器
-的相關報告；如果該補丁是由一些早先郵件列表討論或網絡上的記錄引起的，請指向它。
+如果該變更的相關討論或背景資訊可以在網上查閱，請加上“Link:”標籤指向它。例如
+你的補丁修復了一個缺陷，需要添加一個帶有URL的標籤指向郵件列表存檔或缺陷追蹤器
+的相關報告；如果該補丁是由一些早先郵件列表討論或網路上的記錄引起的，請指向它。
-當鏈接到郵件列表存檔時，請首選lore.kernel.org郵件存檔服務。用郵件中的
-``Message-ID`` 頭（去掉尖括號）可以創建鏈接URL。例如::
+當連結到郵件列表存檔時，請首選lore.kernel.org郵件存檔服務。用郵件中的
+``Message-ID`` 頭（去掉尖括號）可以建立連結URL。例如::
- Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI
-請檢查該鏈接以確保可用且指向正確的郵件。
+請檢查該連結以確保可用且指向正確的郵件。
不過，在沒有外部資源的情況下，也要儘量讓你的解釋可理解。除了提供郵件列表存檔或
缺陷的URL之外，還要需要總結該補丁的相關討論要點。
-如果補丁修復了特定提交中的錯誤，例如使用 ``git bisct`` 發現了一個問題，請使用
-帶有前12個字符SHA-1 ID的“Fixes:”標籤和單行摘要。爲了簡化解析腳本，不要將該
-標籤拆分爲多行，標籤不受“75列換行”規則的限制。例如::
+如果補丁修復了特定提交中的錯誤，例如使用 ``git bisect`` 發現了一個問題，請使用
+帶有至少前12個字元SHA-1 ID的“Fixes:”標籤和單行摘要。為了簡化解析腳本，不要將該
+標籤拆分為多行，標籤不受“75列換行”規則的限制。例如::
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
-下列 ``git config`` 設置可以讓 ``git log``, ``git show`` 增加上述風格的顯示格式::
+下列 ``git config`` 設定可以讓 ``git log``, ``git show`` 增加上述風格的顯示格式::
[core]
abbrev = 12
[pretty]
fixes = Fixes: %h (\"%s\")
-使用示例::
+使用範例::
$ git log -1 --pretty=fixes 54a4f0239f2e
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
@@ -138,41 +141,42 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令
將每個 **邏輯更改** 拆分成一個單獨的補丁。
-例如，如果你的改動裏同時有bug修正和性能優化，那麼把這些改動拆分到兩個或
-者更多的補丁文件中。如果你的改動包含對API的修改，並且增加了一個使用該新API
+例如，如果你的改動裡同時有bug修正和效能最佳化，那麼把這些改動拆分到兩個或
+者更多的補丁檔案中。如果你的改動包含對API的修改，並且增加了一個使用該新API
的驅動，那麼把這些修改分成兩個補丁。
-另一方面，如果你將一個單獨的改動做成多個補丁文件，那麼將它們合併成一個
-單獨的補丁文件。這樣一個邏輯上單獨的改動只被包含在一個補丁文件裏。
+另一方面，如果你將一個單獨的改動做成多個補丁檔案，那麼將它們合併成一個
+單獨的補丁檔案。這樣一個邏輯上單獨的改動只被包含在一個補丁檔案裡。
需要記住的一點是，每個補丁的更改都應易於理解，以便審閱者驗證。每個補丁都應該
對其價值進行闡述。
-如果有一個補丁依賴另外一個補丁來完成它的改動，那沒問題。直接在你的補
-丁描述裏指出 **“這個補丁依賴某補丁”** 就好了。
+如果有一個補丁依賴另外一個補丁來完成它的改動，那沒問題。直接在你的補丁
+描述裡指出 **“這個補丁依賴某補丁”** 就好了。
-在將您的更改劃分爲一系列補丁時，要特別注意確保內核在應用系列中的每個補丁之後
-都能正常構建和運行。使用 ``git bisect`` 來追蹤問題的開發者可能會在任何地方分
+在將您的更改劃分為一系列補丁時，要特別注意確保核心在應用系列中的每個補丁之後
+都能正常建置和執行。使用 ``git bisect`` 來追蹤問題的開發者可能會在任何地方分
割你的補丁系列；如果你在中間引入錯誤，他們不會感謝你。
如果你不能將補丁系列濃縮得更小，那麼每次大約發送出15個補丁，然後等待審閱
-和集成。
+和整合。
檢查你的更改風格
----------------
-檢查您的補丁是否違反了基本樣式規定，詳細信息參見
-Documentation/translations/zh_CN/process/coding-style.rst
+檢查您的補丁是否違反了基本樣式規定，詳細資訊參見
+Documentation/translations/zh_TW/process/coding-style.rst
中找到。如果不這樣做，只會浪費審閱者的時間，並且會導致你的補丁被拒絕，甚至
可能沒有被閱讀。
-一個重要的例外是在將代碼從一個文件移動到另一個文件時——在這種情況下，您不應
-該在移動代碼的同一個補丁中修改移動的代碼。這清楚地描述了移動代碼和您的更改
-的行爲。這大大有助於審閱實際差異，並允許工具更好地跟蹤代碼本身的歷史。
+一個重要的例外是在將程式碼從一個檔案移動到另一個檔案時——在這種情況下，您不
+應該在移動程式碼的同一個補丁中修改移動的程式碼。這清楚地描述了移動程式碼和
+您的更改的行為。這大大有助於審閱實際差異，並允許工具更好地追蹤程式碼本身的
+歷史。
-在提交之前，使用補丁樣式檢查程序檢查補丁（scripts/check patch.pl）。不過，
-請注意，樣式檢查程序應該被視爲一個指南，而不是作爲人類判斷的替代品。如果您
-的代碼看起來更好，但有違規行爲，那麼最好別管它。
+在提交之前，使用補丁樣式檢查程式檢查補丁（scripts/checkpatch.pl）。不過，
+請注意，樣式檢查程式應該被視為一個指南，而不是作為人類判斷的替代品。如果您
+的程式碼看起來更好，但有違規行為，那麼最好別管它。
檢查者報告三個級別：
@@ -180,58 +184,56 @@ Documentation/translations/zh_CN/process/coding-style.rst
- WARNING：需要仔細審閱的事項
- CHECK：需要思考的事情
-您應該能夠判斷您的補丁中存在的所有違規行爲。
+您應該能夠判斷您的補丁中存在的所有違規行為。
選擇補丁收件人
--------------
-您應該總是知會任何補丁相應代碼的子系統維護人員；查看
-維護人員文件和源代碼修訂歷史記錄，以瞭解這些維護人員是誰。腳本
+您應該總是知會任何補丁相應程式碼的子系統維護人員；查看
+MAINTAINERS檔案和原始程式碼修訂歷史記錄，以瞭解這些維護人員是誰。腳本
scripts/get_maintainer.pl在這個步驟中非常有用。如果您找不到正在工作的子系統
的維護人員，那麼Andrew Morton（akpm@linux-foundation.org）將充當最後的維護
人員。
-您通常還應該選擇至少一個郵件列表來接收補丁集的副本。linux-kernel@vger.kernel.org
-是所有補丁的默認列表，但是這個列表的流量已經導致了許多開發人員不再看它。
-在MAINTAINERS文件中查找子系統特定的列表；您的補丁可能會在那裏得到更多的關注。
-不過，請不要發送垃圾郵件到無關的列表。
+您通常還應該選擇至少一個郵件列表來接收補丁集的副本。linux-kernel@
+vger.kernel.org是所有補丁的預設列表，但是這個列表的流量已經導致了許多開發
+人員不再看它。在MAINTAINERS檔案中查找子系統特定的列表；您的補丁可能會在那
+裡得到更多的關注。不過，請不要發送垃圾郵件到無關的列表。
-許多與內核相關的列表託管在vger.kernel.org上；您可以在
-http://vger.kernel.org/vger-lists.html 上找到它們的列表。不過，也有與內核相關
+許多與核心相關的列表託管在kernel.org上；您可以在
+https://subspace.kernel.org 上找到它們的列表。不過，也有與核心相關
的列表託管在其他地方。
-不要一次發送超過15個補丁到vger郵件列表！！！！
-
-Linus Torvalds是決定改動能否進入 Linux 內核的最終裁決者。他的郵件地址是
+Linus Torvalds是決定改動能否進入 Linux 核心的最終裁決者。他的郵件地址是
torvalds@linux-foundation.org 。他收到的郵件很多，所以一般來說最好 **別**
給他發郵件。
-如果您有修復可利用安全漏洞的補丁，請將該補丁發送到 security@kernel.org 。對於
-嚴重的bug，可以考慮短期禁令以允許分銷商（有時間）向用戶發佈補丁；在這種情況下，
-顯然不應將補丁發送到任何公共列表。
-參見 Documentation/translations/zh_CN/process/security-bugs.rst 。
+如果您有修復可利用安全漏洞的補丁，請將該補丁發送到 security@kernel.org 。
+對於嚴重的bug，可以考慮短期禁令以允許分銷商（有時間）向使用者發布補丁；在
+這種情況下，顯然不應將補丁發送到任何公共列表。參見
+Documentation/process/security-bugs.rst 。
-修復已發佈內核中嚴重錯誤的補丁程序應該抄送給穩定版維護人員，方法是把以下列行
-放進補丁的籤準區（注意，不是電子郵件收件人）::
+修復已發布核心中嚴重錯誤的補丁程式應該抄送給穩定版維護人員，方法是把以下列行
+放進補丁的簽署區（注意，不是電子郵件收件人）::
Cc: stable@vger.kernel.org
除了本文件之外，您還應該閱讀
-Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
+Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
-如果更改影響到用戶側內核接口，請向手冊頁維護人員（如維護人員文件中所列）發送
-手冊頁補丁，或至少發送更改通知，以便一些信息進入手冊頁。還應將用戶空間API
-更改抄送到 linux-api@vger.kernel.org 。
+如果更改影響到使用者側核心介面，請向手冊頁維護人員（如MAINTAINERS檔案中所
+列）發送手冊頁補丁，或至少發送更改通知，以便一些資訊進入手冊頁。還應將使用
+者空間API更改抄送到 linux-api@vger.kernel.org 。
-不要MIME編碼，不要鏈接，不要壓縮，不要附件，只要純文本
+不要MIME編碼，不要連結，不要壓縮，不要附件，只要純文字
------------------------------------------------------
-Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對於內核開發者來說
+Linus 和其他的核心開發者需要閱讀和評論你提交的改動。對於核心開發者來說
，可以“引用”你的改動很重要，使用一般的郵件工具，他們就可以在你的
-代碼的任何位置添加評論。
+程式碼的任何位置添加評論。
-因爲這個原因，所有的提交的補丁都是郵件中“內嵌”的。最簡單（和推薦）的方法就
+因為這個原因，所有的提交的補丁都是郵件中“內嵌”的。最簡單（和推薦）的方法就
是使用 ``git send-email`` 。https://git-send-email.io 有 ``git send-email``
的交互式教程。
@@ -239,30 +241,54 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對
.. warning::
- 如果你使用剪切-粘貼你的補丁，小心你的編輯器的自動換行功能破壞你的補丁
+ 如果你使用剪切-貼上你的補丁，小心你的編輯器的自動換行功能破壞你的補丁
-不要將補丁作爲MIME編碼的附件，不管是否壓縮。很多流行的郵件軟件不
-是任何時候都將MIME編碼的附件當作純文本發送的，這會使得別人無法在你的
-代碼中加評論。另外，MIME編碼的附件會讓Linus多花一點時間來處理，這就
+不要將補丁作為MIME編碼的附件，不管是否壓縮。很多流行的郵件軟體不
+是任何時候都將MIME編碼的附件當作純文字發送的，這會使得別人無法在你的
+程式碼中加評論。另外，MIME編碼的附件會讓Linus多花一點時間來處理，這就
降低了你的改動被接受的可能性。
例外：如果你的郵路損壞了補丁，那麼有人可能會要求你使用MIME重新發送補丁。
-請參閱 Documentation/translations/zh_CN/process/email-clients.rst
-以獲取有關配置電子郵件客戶端以使其不受影響地發送補丁的提示。
+請參閱 Documentation/translations/zh_TW/process/email-clients.rst
+以獲取有關設定電子郵件客戶端以使其不受影響地發送補丁的提示。
回覆審閱意見
------------
你的補丁幾乎肯定會得到審閱者對補丁改進方法的評論（以回覆郵件的形式）。您必須
對這些評論作出回應；讓補丁被忽略的一個好辦法就是忽略審閱者的意見。直接回復郵
-件來回應意見即可。不會導致代碼更改的意見或問題幾乎肯定會帶來註釋或變更日誌的
+件來回應意見即可。不會導致程式碼更改的意見或問題幾乎肯定會帶來註解或變更日誌的
改變，以便下一個審閱者更好地瞭解正在發生的事情。
-一定要告訴審閱者你在做什麼改變，並感謝他們的時間。代碼審閱是一個累人且耗時的
+一定要告訴審閱者你在做什麼改變，並感謝他們的時間。程式碼審閱是一個累人且耗時的
過程，審閱者有時會變得暴躁。即使在這種情況下，也要禮貌地回應並解決他們指出的
問題。當發送下一版時，在封面郵件或獨立補丁里加上 ``patch changelog`` 說明與
-前一版本的不同之處（參見 :ref:`zh_the_canonical_patch_format` ）。
+前一版本的不同之處（參見 :ref:`tw_the_canonical_patch_format` ）。
+
+.. _tw_interleaved_replies:
+
+在郵件討論中使用裁剪過的交錯式回覆
+----------------------------------
+
+在Linux核心開發的討論中，強烈不建議置頂回覆（top-posting）。交錯式（或
+“行內”）回覆使對話更容易理解。更多細節參見：
+https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
+
+正如郵件列表中經常被引用的那樣::
+
+ A: http://en.wikipedia.org/wiki/Top_post
+ Q: Where do I find info about this thing called top-posting?
+ A: Because it messes up the order in which people normally read text.
+ Q: Why is top-posting such a bad thing?
+ A: Top-posting.
+ Q: What is the most annoying thing in e-mail?
+
+同樣，請裁剪掉所有與你的回覆無關的引文。這使回覆更容易查找，並節省時間和
+空間。更多細節參見： http://daringfireball.net/2007/07/on_top ::
+
+ A: No.
+ Q: Should I include quotations after my reply?
.. _tw_resend_reminders:
@@ -271,54 +297,54 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對
提交更改後，請耐心等待。審閱者是大忙人，可能無法立即審閱您的補丁。
-曾幾何時，補丁曾在沒收到評論的情況下消失在虛空中，但現在開發過程應該更加順利了。
-您應該在一週左右的時間內收到評論；如果沒有收到評論，請確保您已將補丁發送
-到正確的位置。在重新提交或聯繫審閱者之前至少等待一週——在諸如合併窗口之類的
-繁忙時間可能更長。
+曾幾何時，補丁曾在沒收到評論的情況下消失在虛空中，但現在開發過程應該更加順
+利了。您應該在一週左右的時間內收到評論；如果沒有收到評論，請確保您已將補丁
+發送到正確的位置。在重新提交或聯繫審閱者之前至少等待一週——在諸如合併視窗之
+類的繁忙時間可能更長。
在等了幾個星期後，用帶RESEND的主題重發補丁也是可以的::
[PATCH Vx RESEND] sub/sys: Condensed patch summary
-當你發佈補丁（系列）修改版的時候，不要加上“RESEND”——“RESEND”只適用於重
+當你發布補丁（系列）修改版的時候，不要加上“RESEND”——“RESEND”只適用於重
新提交之前未經修改的補丁（系列）。
主題中包含 PATCH
----------------
由於到Linus和linux-kernel的電子郵件流量很高，通常會在主題行前面加上[PATCH]
-前綴。這使Linus和其他內核開發人員更容易將補丁與其他電子郵件討論區分開。
+前綴。這使Linus和其他核心開發人員更容易將補丁與其他電子郵件討論區分開。
-``git send-email`` 會自動爲你加上。
+``git send-email`` 會自動為你加上。
簽署你的作品——開發者來源認證
------------------------------
-爲了加強對誰做了何事的追蹤，尤其是對那些透過好幾層維護者才最終到達的補丁，我
-們在通過郵件發送的補丁上引入了“簽署（sign-off）”流程。
+為了加強對誰做了何事的追蹤，尤其是對那些透過好幾層維護者才最終到達的補丁，我
+們在透過郵件發送的補丁上引入了“簽署（sign-off）”流程。
-“簽署”是在補丁註釋最後的一行簡單文字，認證你編寫了它或者其他
-人有權力將它作爲開放源代碼的補丁傳遞。規則很簡單：如果你能認證如下信息:
+“簽署”是在補丁註解最後的一行簡單文字，認證你編寫了它或者其他
+人有權力將它作為開放原始程式碼的補丁傳遞。規則很簡單：如果你能認證如下資訊:
開發者來源認證 1.1
^^^^^^^^^^^^^^^^^^
-對於本項目的貢獻，我認證如下信息：
+對於本專案的貢獻，我認證如下資訊：
- (a) 這些貢獻是完全或者部分的由我創建，我有權利以文件中指出
- 的開放源代碼許可證提交它；或者
+ (a) 這些貢獻是完全或者部分的由我建立，我有權利以文件中指出
+ 的開放原始程式碼許可證提交它；或者
(b) 這些貢獻基於以前的工作，據我所知，這些以前的工作受恰當的開放
- 源代碼許可證保護，而且，根據文件中指出的許可證，我有權提交修改後的貢獻，
- 無論是完全還是部分由我創造，這些貢獻都使用同一個開放源代碼許可證
+ 原始程式碼許可證保護，而且，根據文件中指出的許可證，我有權提交修改後的貢獻，
+ 無論是完全還是部分由我創造，這些貢獻都使用同一個開放原始程式碼許可證
（除非我被允許用其它的許可證）；或者
(c) 這些貢獻由認證（a），（b）或者（c）的人直接提供給我，而
且我沒有修改它。
- (d) 我理解並同意這個項目和貢獻是公開的，貢獻的記錄（包括我
- 一起提交的個人記錄，包括sign-off）被永久維護並且可以和這個項目
- 或者開放源代碼的許可證同步地再發行。
+ (d) 我理解並同意這個專案和貢獻是公開的，貢獻的記錄（包括我
+ 一起提交的個人記錄，包括sign-off）被永久維護並且可以和這個專案
+ 或者開放原始程式碼的許可證同步地再發行。
那麼加入這樣一行::
@@ -339,33 +365,47 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對
Signed-off-by: 標籤表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。
-如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准/贊成，
-那麼他們可以要求在補丁的變更日誌中添加一個Acked-by:。
+如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准/
+贊成，那麼他們可以要求在補丁的變更日誌中添加一個Acked-by:。
+
+Acked-by: 供以某種方式對受影響程式碼負責或與之相關的人使用。最常見的情況是，
+當維護者既沒有貢獻也沒有轉發補丁時，由該維護者使用。
-Acked-by: 通常由受影響代碼的維護者使用，當該維護者既沒有貢獻也沒有轉發補丁時。
+Acked-by: 也可以由其他利益相關者使用，例如具有領域知識的人（例如被修改程式
+碼的原作者）、核心uAPI補丁的使用者空間側審閱者，或某項功能的關鍵使用者。在
+這些情況下，可以視需要加上一個“# 後綴”以澄清其含義::
+
+ Acked-by: The Stakeholder <stakeholder@example.org> # As primary user
Acked-by: 不像簽署那樣正式。這是一個記錄，確認人至少審閱了補丁，並表示接受。
-因此，補丁合併有時會手動將Acker的“Yep，looks good to me”轉換爲 Acked-By:（但
+因此，補丁合併有時會手動將Acker的“Yep，looks good to me”轉換為 Acked-By:（但
請注意，通常最好要求一個明確的Ack）。
-Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁影響多個子系統，並且
-有一個來自某個子系統維護者的Acked-By:，那麼這通常表示只確認影響維護者代碼的部
-分。這裏應該仔細判斷。如有疑問，應參考郵件列表存檔中的原始討論。
+Acked-by: 也不如 Reviewed-by: 正式。例如，維護者可以用它表示他們同意補丁
+合入，但可能沒有像提供Reviewed-by:那樣徹底地審閱過補丁。同樣，關鍵使用者
+可能沒有對補丁進行技術審閱，但他們可能對整體方法、功能或面向使用者的介面
+感到滿意。
+
+Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁影響多個子系統，並
+且有一個來自某個子系統維護者的Acked-By:，那麼這通常表示只確認影響維護者程
+式碼的部分。這裡應該仔細判斷。如有疑問，應參考郵件列表存檔中的原始討論。在
+這種情況下也可以使用“# 後綴”來澄清。
如果某人本應有機會對補丁進行評論，但沒有提供此類評論，您可以選擇在補丁中添加
-``Cc:`` 這是唯一可以在沒有被該人明確同意的情況下添加的標籤——但它應該表明
-這個人是在補丁上抄送的。此標籤記錄了討論中包含的潛在利益相關方。
+``Cc:`` 標籤。此標籤記錄了討論中包含的潛在利益相關方。注意，這是僅有的三個
+可以在未經被指名者明確許可的情況下使用的標籤之一（詳見下面的“標記他人需要
+許可”）。
-Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上工
-作時，它用於給出共同作者（除了From:所給出的作者之外）。因爲Co-developed-by:
+Co-developed-by: 聲明補丁是由多個開發人員共同建立的；當幾個人在一個補丁上工
+作時，它用於給出共同作者（除了From:所給出的作者之外）。因為Co-developed-by:
表示作者身份，所以每個Co-developed-by:必須緊跟在相關合作作者的簽署之後。標準
-簽署程序要求Signed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通
+簽署程式要求Signed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通
過From:還是Co-developed-by:表明。值得注意的是，最後一個Signed-off-by:必須是
提交補丁的開發人員。
注意，如果From:作者也是電子郵件標題的From:行中列出的人，則From:標籤是可選的。
-被From:作者提交的補丁示例::
+被From:作者提交的補丁範例::
<changelog>
@@ -375,7 +415,7 @@ Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個
Signed-off-by: Second Co-Author <second@coauthor.example.org>
Signed-off-by: From Author <from@author.example.org>
-被合作開發者提交的補丁示例::
+被合作開發者提交的補丁範例::
From: From Author <from@author.example.org>
@@ -392,67 +432,95 @@ Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個
-----------------------------------------------------------------
Reported-by: 給那些發現錯誤並報告錯誤的人致謝，它希望激勵他們在將來再次幫助
-我們。請注意，如果bug是以私有方式報告的，那麼在使用Reported-by標籤之前，請
-先請求許可。此標籤是爲Bug設計的；請不要將其用於感謝功能請求。
+我們。注意，Reported-by標籤是僅有的三個可以在未經被指名者明確許可的情況下
+使用的標籤之一（詳見下面的“標記他人需要許可”）。此標籤是為Bug設計的；請不要
+將其用於感謝功能請求。
Tested-by: 標籤表示補丁已由指定的人（在某些環境中）成功測試。這個標籤通知
-維護人員已經執行了一些測試，爲將來的補丁提供了一種定位測試人員的方法，並彰顯測試人員的功勞。
+維護人員已經執行了一些測試，為將來的補丁提供了一種定位測試人員的方法，並彰
+顯測試人員的功勞。
-Reviewed-by：根據審閱者的監督聲明，表明該補丁已被審閱並被認爲是可接受的：
+Reviewed-by：根據審閱者的監督聲明，表明該補丁已被審閱並被認為是可接受的：
審閱者的監督聲明
^^^^^^^^^^^^^^^^
-通過提供我的Reviewed-by:標籤，我聲明：
+透過提供我的Reviewed-by:標籤，我聲明：
(a) 我已經對這個補丁進行了一次技術審閱，以評估它是否適合被包含到
- 主線內核中。
+ 主線核心中。
(b) 與補丁相關的任何問題、顧慮或問題都已反饋給提交者。我對提交者對
我的評論的回應感到滿意。
- (c) 雖然這一提交可能仍可被改進，但我相信，此時，（1）對內核
+ (c) 雖然這一提交可能仍可被改進，但我相信，此時，（1）對核心
進行了有價值的修改，（2）沒有包含爭論中涉及的已知問題。
- (d) 雖然我已經審閱了補丁並認爲它是健全的，但我不會（除非另有明確
- 說明）作出任何保證或擔保它會在任何給定情況下實現其規定的目的
- 或正常運行。
+ (d) 雖然我已經審閱了補丁並認為它是健全的，但我不會（除非另有明確
+ 說明）作出任何保證或擔保它會在任何給定情況下實作其規定的目的
+ 或正常執行。
-Reviewed-by是一種觀點聲明，即補丁是對內核的適當修改，沒有任何遺留的嚴重技術
-問題。任何感興趣的審閱者（完成工作的人）都可以爲一個補丁提供一個Reviewed-by
-標籤。此標籤用於向審閱者提供致謝，並通知維護者補丁的審閱進度。
-當Reviewed-by:標籤由已知了解主題區域並執行徹底檢查的審閱者提供時，通常會增加
-補丁進入內核的可能性。
+Reviewed-by是一種觀點聲明，即補丁是對核心的適當修改，沒有任何遺留的嚴重技
+術問題。任何感興趣的審閱者（完成了審閱工作且具有已知身分的人）都可以為一個
+補丁提供一個Reviewed-by標籤。此標籤用於向審閱者提供致謝，並通知維護者補丁
+的審閱進度。當Reviewed-by:標籤由已知了解主題區域並執行徹底檢查的審閱者提供
+時，通常會增加補丁進入核心的可能性。
-一旦從測試人員或審閱者的“Tested-by”和“Reviewed-by”標籤出現在郵件列表中，
-作者應在發送下一個版本時將其添加到適用的補丁中。但是，如果補丁在以下版本中發
-生了實質性更改，這些標籤可能不再適用，因此應該刪除。通常，在補丁更改日誌中
-（在 ``---`` 分隔符之後）應該提到刪除某人的測試者或審閱者標籤。
+一旦從測試人員或審閱者的“Tested-by”和“Reviewed-by”標籤出現在郵件列表中，作
+者應在發送下一個版本時將其添加到適用的補丁中。但是，如果補丁在以下版本中發
+生了實質性更改，這些標籤可能不再適用，因此應該刪除。通常，刪除某人的
+Acked-by、Tested-by或Reviewed-by標籤時，應在補丁更改日誌中（在 ``---`` 分
+隔符之後）提及並附上解釋。
Suggested-by: 表示補丁的想法是由指定的人提出的，並確保將此想法歸功於指定的
-人。請注意，未經許可，不得添加此標籤，特別是如果該想法未在公共論壇上發佈。
-也就是說，如果我們勤快地致謝創意提供者，他們將受到鼓舞，很有希望在未來再次
-幫助我們。
+人：如果我們勤快地致謝創意提供者，他們將受到鼓舞，很有希望在未來再次幫助
+我們。注意，這是僅有的三個可以在未經被指名者明確許可的情況下使用的標籤之一
+（詳見下面的“標記他人需要許可”）。
-Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定錯誤的來源，這有助於
-檢查錯誤修復。這個標籤還幫助穩定內核團隊確定應該接收修復的穩定內核版本。這是
-指示補丁修復的錯誤的首選方法。請參閱 :ref:`zh_describe_changes` 瞭解更多信息。
+Fixes: 指示補丁修復了之前提交中的一個缺陷。它可以便於確定問題的來源，這有助於
+檢查錯誤修復。這個標籤還幫助穩定核心團隊確定應該接收修復的穩定核心版本。這是
+指示補丁修復的錯誤的首選方法。請參閱 :ref:`tw_describe_changes` 瞭解更多資訊。
.. note::
- 附加Fixes:標籤不會改變穩定內核規則流程，也不改變所有穩定版補丁抄送
- stable@vger.kernel.org的要求。有關更多信息，請閱讀
- Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
+ 附加Fixes:標籤不會改變穩定核心規則流程，也不改變所有穩定版補丁抄送
+ stable@vger.kernel.org的要求。有關更多資訊，請閱讀
+ Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
+
+最後，雖然提供標籤是受歡迎的且通常非常受讚賞，但請注意，簽署者（即提交者和
+維護者）可以自行斟酌是否採用所提供的標籤。
+
+.. _tw_tagging_people:
+
+標記他人需要許可
+----------------
+
+在補丁中添加上述標籤時要小心：除了Cc:、Reported-by:和Suggested-by:之外，
+所有標籤都需要被指名者的明確許可。對於這三個標籤，如果根據lore存檔或提交
+歷史，該人曾以該名字和電子郵件地址對Linux核心做出過貢獻，那麼隱含的許可
+就足夠了——並且對於Reported-by:和Suggested-by:，報告或建議必須是公開作出
+的。注意，就此而言bugzilla.kernel.org是公開場所，但其中使用的電子郵件地址
+是私密的；因此不要在標籤中暴露它們，除非該人在先前的貢獻中使用過。
+
+使用Assisted-by:
+----------------
+
+如果您在建立補丁的過程中使用了任何進階編碼工具，您需要透過添加Assisted-by
+標籤來聲明這一使用。不這樣做可能會妨礙您的工作被接受。關於聲明編碼助手的
+細節，請參見 Documentation/process/coding-assistants.rst 。
.. _tw_the_canonical_patch_format:
標準補丁格式
------------
-本節描述如何格式化補丁本身。請注意，如果您的補丁存儲在 ``Git`` 存儲庫中，則
-可以使用 ``git format-patch`` 進行正確的補丁格式化。但是，這些工具無法創建
-必要的文本，因此請務必閱讀下面的說明。
+本節描述如何格式化補丁本身。請注意，如果您的補丁儲存在 ``Git`` 儲存庫中，則
+可以使用 ``git format-patch`` 進行正確的補丁格式化。但是，這些工具無法建立
+必要的文字，因此請務必閱讀下面的說明。
+
+主題行
+^^^^^^
標準的補丁標題行是::
@@ -460,7 +528,8 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
標準補丁的信體包含如下部分：
- - 一個 ``from`` 行指出補丁作者。後跟空行（僅當發送補丁的人不是作者時才需要）。
+ - 一個 ``from`` 行指出補丁作者。後跟空行（僅當發送補丁的人不是作者時才需
+ 要）。
- 說明文字，每行最長75列，這將被複制到永久變更日誌來描述這個補丁。
@@ -470,30 +539,30 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
- 只包含 ``---`` 的標記線。
- - 任何其他不適合放在變更日誌的註釋。
+ - 任何其他不適合放在變更日誌的註解。
- 實際補丁（ ``diff`` 輸出）。
標題行的格式，使得對標題行按字母序排序非常的容易——很多郵件客戶端都
-可以支持——因爲序列號是用零填充的，所以按數字排序和按字母排序是一樣的。
+可以支援——因為序列號是用零填充的，所以按數字排序和按字母排序是一樣的。
-郵件標題中的“子系統”標識哪個內核子系統將被打補丁。
+郵件標題中的“子系統”標識哪個核心子系統將被打補丁。
郵件標題中的“一句話概述”扼要的描述郵件中的補丁。“一句話概述”
-不應該是一個文件名。對於一個補丁系列（“補丁系列”指一系列的多個相關補
-丁），不要對每個補丁都使用同樣的“一句話概述”。
+不應該是一個檔名。對於一個補丁系列（“補丁系列”指一系列的多個相關補丁
+），不要對每個補丁都使用同樣的“一句話概述”。
-記住郵件的“一句話概述”會成爲該補丁的全局唯一標識。它會進入 ``git``
-的改動記錄裏。然後“一句話概述”會被用在開發者的討論裏，用來指代這個補
-丁。用戶將希望通過搜索引擎搜索“一句話概述”來找到那些討論這個補丁的文
+記住郵件的“一句話概述”會成為該補丁的全域唯一標識。它會進入 ``git``
+的改動記錄裡。然後“一句話概述”會被用在開發者的討論裡，用來指代這個補丁
+。使用者將希望透過搜索引擎搜索“一句話概述”來找到那些討論這個補丁的文
章。當人們在兩三個月後使用諸如 ``gitk`` 或 ``git log --oneline`` 之類
的工具查看數千個補丁時，也會很快看到它。
-出於這些原因，概述必須不超過70-75個字符，並且必須描述補丁的更改以及爲
+出於這些原因，概述必須不超過70-75個字元，並且必須描述補丁的更改以及為
什麼需要補丁。既要簡潔又要描述性很有挑戰性，但寫得好的概述應該這樣。
概述的前綴可以用方括號括起來：“Subject: [PATCH <tag>...] <概述>”。標記
-不被視爲概述的一部分，而是描述應該如何處理補丁。如果補丁的多個版本已發
+不被視為概述的一部分，而是描述應該如何處理補丁。如果補丁的多個版本已發
送出來以響應評審（即“v1，v2，v3”）則必須包含版本號，或包含“RFC”以指示
評審請求。如果一個補丁系列中有四個補丁，那麼各個補丁可以這樣編號：1/4、2/4、
3/4、4/4。這可以確保開發人員瞭解補丁應用的順序，且
@@ -501,42 +570,78 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
一些標題的例子::
- Subject: [patch 2/5] ext2: improve scalability of bitmap searching
- Subject: [PATCHv2 001/207] x86: fix eflags tracking
+ Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
+ Subject: [PATCH v2 01/27] x86: fix eflags tracking
+ Subject: [PATCH v2] sub/sys: Condensed patch summary
+ Subject: [PATCH v2 M/N] sub/sys: Condensed patch summary
+
+From行
+^^^^^^
-``From`` 行是信體裏的最上面一行，具有如下格式::
+``From`` 行必須是信體裡的最上面一行，具有如下格式::
From: Patch Author <author@example.com>
-``From`` 行指明在永久改動日誌裏，誰會被確認爲作者。如果沒有 ``From`` 行，那
-麼郵件頭裏的 ``From:`` 行會被用來決定改動日誌中的作者。
+``From`` 行指明在永久改動日誌裡，誰會被確認為作者。如果沒有 ``From`` 行，那
+麼郵件頭裡的 ``From:`` 行會被用來決定改動日誌中的作者。
-說明文字將會被提交到永久的源代碼改動日誌裏，因此應針對那些早已經不記得和這
-個補丁相關的討論細節的讀者。包括補丁處理的故障症狀（內核日誌消息、oops消息
-等），這對於可能正在搜索提交日誌以查找適用補丁的人特別有用。文本應該寫得如
-此詳細，以便在數週、數月甚至數年後閱讀時，能夠爲讀者提供所需的細節信息，以
-掌握創建補丁的 **原因** 。
+作者可以透過在 ``from`` 行和 ``SoB`` 行中加上組織名稱，來表明其所屬單位
+或工作的贊助者，例如：
+
+ From: Patch Author (Company) <author@example.com>
+
+說明主體
+^^^^^^^^
+
+說明文字將會被提交到永久的原始程式碼改動日誌裡，因此應針對那些早已經不記得和這
+個補丁相關的討論細節的讀者。包括補丁處理的故障症狀（核心日誌訊息、oops訊息
+等），這對於可能正在搜索提交日誌以查找適用補丁的人特別有用。文字應該寫得如
+此詳細，以便在數週、數月甚至數年後閱讀時，能夠為讀者提供所需的細節資訊，以
+掌握建立補丁的 **原因** 。
如果一個補丁修復了一個編譯失敗，那麼可能不需要包含 *所有* 編譯失敗；
只要足夠讓搜索補丁的人能夠找到它就行了。與概述一樣，既要簡潔又要描述性。
-``---`` 標記行對於補丁處理工具要找到哪裏是改動日誌信息的結束，是不可缺少
+
+.. _tw_backtraces:
+
+提交訊息中的回溯（Backtraces）
+""""""""""""""""""""""""""""""
+
+回溯有助於記錄導致問題的呼叫鏈。然而，並非所有回溯都有幫助。例如，早期引導呼
+叫鏈是獨特而明顯的。而逐字複製完整的dmesg輸出則會增加時間戳、模組列表、暫存
+器和堆疊轉儲等分散注意力的資訊。
+
+因此，最有用的回溯應該從轉儲中提取相關資訊，以更容易集中在真實問題上。下面是
+一個剪裁良好的回溯範例::
+
+ unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064)
+ at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
+ Call Trace:
+ mba_wrmsr
+ update_domains
+ rdtgroup_mkdir
+
+附加註解（Commentary）
+^^^^^^^^^^^^^^^^^^^^^^
+
+``---`` 標記行對於補丁處理工具要找到哪裡是改動日誌資訊的結束，是不可缺少
的。
-對於 ``---`` 標記之後的額外註解，一個好的用途就是用來寫 ``diffstat`` ，用來顯
-示修改了什麼文件和每個文件都增加和刪除了多少行。 ``diffstat`` 對於比較大的補
-丁特別有用。
-使用 ``diffstat`` 的選項 ``-p 1 -w 70`` 這樣文件名就會從內核源代碼樹的目錄開始
-，不會佔用太寬的空間（很容易適合80列的寬度，也許會有一些縮進。）
-（ ``git`` 默認會生成合適的diffstat。）
+對於 ``---`` 標記之後的額外註解，一個好的用途就是用來寫 ``diffstat`` ，用
+來顯示修改了什麼檔案和每個檔案都增加和刪除了多少行。 ``diffstat`` 對於比較
+大的補丁特別有用。使用 ``diffstat`` 的選項 ``-p 1 -w 70`` 這樣檔名就會從核
+心原始程式碼樹的目錄開始，不會佔用太寬的空間（很容易適合80列的寬度，也許會
+有一些縮排。）（ ``git`` 預設會產生合適的diffstat。）
-其餘那些只適用於當時或者與維護者相關的註解，不合適放到永久的改動日誌裏的，也
-應該放這裏。較好的例子就是 ``補丁更改記錄`` ，記錄了v1和v2版本補丁之間的差異。
+其餘那些只適用於當時或者與維護者相關的註解，不合適放到永久的改動日誌裡的，也
+應該放這裡。較好的例子就是 ``補丁更改記錄`` ，記錄了v1和v2版本補丁之間的差異。
-請將此信息放在將變更日誌與補丁的其餘部分分隔開的 ``---`` 行 **之後** 。版本
-信息不是提交到git樹的變更日誌的一部分。只是供審閱人員使用的附加信息。如果將
+請將此資訊放在將變更日誌與補丁的其餘部分分隔開的 ``---`` 行 **之後** 。版本
+資訊不是提交到git樹的變更日誌的一部分。只是供審閱人員使用的附加資訊。如果將
其放置在提交標記上方，則需要手動交互才能將其刪除。如果它位於分隔線以下，則在
-應用補丁時會自動剝離::
+應用補丁時會自動剝離。如果可以，建議附上指向該補丁先前版本的連結（例如
+lore.kernel.org存檔連結），以幫助審閱者::
<commit message>
...
@@ -545,29 +650,14 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
V2 -> V3: Removed redundant helper function
V1 -> V2: Cleaned up coding style and addressed review comments
+ v2: https://lore.kernel.org/bar
+ v1: https://lore.kernel.org/foo
+
path/to/file | 5+++--
...
在後面的參考資料中能看到正確補丁格式的更多細節。
-.. _tw_backtraces:
-
-提交消息中的回溯（Backtraces）
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-回溯有助於記錄導致問題的調用鏈。然而，並非所有回溯都有幫助。例如，早期引導調
-用鏈是獨特而明顯的。而逐字複製完整的dmesg輸出則會增加時間戳、模塊列表、寄存
-器和堆棧轉儲等分散注意力的信息。
-
-因此，最有用的回溯應該從轉儲中提取相關信息，以更容易集中在真實問題上。下面是
-一個剪裁良好的回溯示例::
-
- unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064)
- at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
- Call Trace:
- mba_wrmsr
- update_domains
- rdtgroup_mkdir
.. _tw_explicit_in_reply_to:
@@ -575,21 +665,21 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
-----------------------------
手動添加回復補丁的的郵件頭（In-Reply_To:）是有用的（例如，使用 ``git send-email`` ），
-可以將補丁與以前的相關討論關聯起來，例如，將bug補丁鏈接到電子郵件和bug報告。
-但是，對於多補丁系列，最好避免在回覆時使用鏈接到該系列的舊版本。這樣，
-補丁的多個版本就不會成爲電子郵件客戶端中無法管理的引用樹。如果鏈接有用，
-可以使用 https://lore.kernel.org/ 重定向器（例如，在封面電子郵件文本中）
-鏈接到補丁系列的早期版本。
+可以將補丁與以前的相關討論關聯起來，例如，將bug補丁連結到電子郵件和bug報告。
+但是，對於多補丁系列，最好避免在回覆時使用連結到該系列的舊版本。這樣，
+補丁的多個版本就不會成為電子郵件客戶端中無法管理的引用樹。如果連結有用，
+可以使用 https://lore.kernel.org/ 重定向器（例如，在封面電子郵件文字中）
+連結到補丁系列的早期版本。
-給出基礎樹信息
+給出基礎樹資訊
--------------
-當其他開發人員收到您的補丁並開始審閱時，知道應該將您的工作放到代碼樹歷史記錄
-中的什麼位置通常很有用。這對於自動化持續集成流水（CI）特別有用，這些流水線試
-圖運行一系列測試，以便在維護人員開始審閱之前確定提交的質量。
+當其他開發人員收到您的補丁並開始審閱時，知道應該將您的工作放到程式碼樹歷史記錄
+中的什麼位置通常很有用。這對於自動化持續整合流水（CI）特別有用，這些流水線試
+圖執行一系列測試，以便在維護人員開始審閱之前確定提交的品質。
-如果您使用 ``git format-patch`` 生成補丁，則可以通過 ``--base`` 標誌在提交中
-自動包含基礎樹信息。使用此選項最簡單、最方便的方法是配合主題分支::
+如果您使用 ``git format-patch`` 產生補丁，則可以透過 ``--base`` 標誌在提交中
+自動包含基礎樹資訊。使用此選項最簡單、最方便的方法是配合主題分支::
$ git checkout -t -b my-topical-branch master
Branch 'my-topical-branch' set up to track local branch 'master'.
@@ -603,7 +693,7 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
outgoing/...
當你編輯 ``outgoing/0000-cover-letter.patch`` 時，您會注意到在它的最底部有一
-行 ``base-commit:`` 尾註，它爲審閱者和CI工具提供了足夠的信息以正確執行
+行 ``base-commit:`` 尾註，它為審閱者和CI工具提供了足夠的資訊以正確執行
``git am`` 而不必擔心衝突::
$ git checkout -b patch-review [base-commit-id]
@@ -612,7 +702,7 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
Applying: First Commit
Applying: ...
-有關此選項的更多信息，請參閱 ``man git-format-patch`` 。
+有關此選項的更多資訊，請參閱 ``man git-format-patch`` 。
.. note::
@@ -622,16 +712,23 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
的工作所基於的樹的提交哈希。你應該在封面郵件或系列的第一個補丁中添加它，它應
該放在 ``---`` 行的下面或所有其他內容之後，即只在你的電子郵件簽名之前。
+工具
+----
+
+此流程的許多技術層面都可以使用b4自動化，其說明文件見
+<https://b4.docs.kernel.org/en/latest/>。它可以幫助追蹤依賴關係、執行
+checkpatch，以及格式化和發送郵件。
+
參考文獻
--------
Andrew Morton，“完美的補丁”（tpp）
<https://www.ozlabs.org/~akpm/stuff/tpp.txt>
-Jeff Garzik，“Linux內核補丁提交格式”
+Jeff Garzik，“Linux核心補丁提交格式”
<https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
-Greg Kroah-Hartman，“如何惹惱內核子系統維護人員”
+Greg Kroah-Hartman，“如何惹惱核心子系統維護人員”
<http://www.kroah.com/log/linux/maintainer.html>
<http://www.kroah.com/log/linux/maintainer-02.html>
@@ -644,10 +741,7 @@ Greg Kroah-Hartman，“如何惹惱內核子系統維護人員”
<http://www.kroah.com/log/linux/maintainer-06.html>
-不！！！別再發巨型補丁炸彈給linux-kernel@vger.kernel.org的人們了！
- <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net>
-
-內核 Documentation/translations/zh_CN/process/coding-style.rst
+核心 Documentation/translations/zh_TW/process/coding-style.rst
Linus Torvalds關於標準補丁格式的郵件
<https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org>
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v3 13/16] docs/zh_TW: process: localize terminology in submitting-patches.rst
2026-08-06 18:19 ` [PATCH v3 13/16] docs/zh_TW: process: localize terminology in submitting-patches.rst Chen-Yu Yeh
@ 2026-08-07 2:35 ` Dongliang Mu
0 siblings, 0 replies; 20+ messages in thread
From: Dongliang Mu @ 2026-08-07 2:35 UTC (permalink / raw)
To: Chen-Yu Yeh, Jonathan Corbet, Alex Shi
Cc: Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc, linux-kernel
On 8/7/26 2:19 AM, Chen-Yu Yeh wrote:
> Localize mainland terms to Taiwanese Mandarin (內核→核心, 文件→檔案,
> 代碼→程式碼, ...) and sync with the English original: subspace.kernel.org
> list info, interleaved-reply etiquette section, reworked Acked-by
> semantics with "# Suffix", tagging-people permission rules, the
> Assisted-by tag, canonical patch format subsections with
> affiliation format and previous-version links, and the b4 tooling
> section. Cross references now point at zh_TW translations and broken
> zh_-prefixed ref targets are fixed to tw_.
>
> update to commit 48c3876a6a6f ("docs: submitting-patches: Clarify that
> "reviewer" is a person")
>
> Reviewed-by: Weijie Yuan <wy@wyuan.org>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
> ---
> .../zh_TW/process/submitting-patches.rst | 556 ++++++++++--------
> 1 file changed, 325 insertions(+), 231 deletions(-)
>
> diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst
> index 64de92c07906..b780f1539b46 100644
> --- a/Documentation/translations/zh_TW/process/submitting-patches.rst
> +++ b/Documentation/translations/zh_TW/process/submitting-patches.rst
> @@ -15,37 +15,38 @@
> - 李陽 Li Yang <leoyang.li@nxp.com>
> - 王聰 Wang Cong <xiyou.wangcong@gmail.com>
> - 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
> + - 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
>
>
> -提交補丁：如何讓你的改動進入內核
> +提交補丁：如何讓你的改動進入核心
> ================================
>
> -對於想要將改動提交到 Linux 內核的個人或者公司來說，如果不熟悉“規矩”，
> -提交的流程會讓人畏懼。本文檔包含了一系列建議，可以大大提高你
> +對於想要將改動提交到 Linux 核心的個人或者公司來說，如果不熟悉“規矩”，
> +提交的流程會讓人畏懼。本文件包含了一系列建議，可以大大提高你
> 的改動被接受的機會.
>
> -本文檔以較爲簡潔的行文給出了大量建議。關於內核開發流程如何進行的詳細信息，
> -參見： Documentation/translations/zh_CN/process/development-process.rst 。
> -Documentation/translations/zh_CN/process/submit-checklist.rst 給出了一系列
> +本文件以較為簡潔的行文給出了大量建議。關於核心開發流程如何進行的詳細資訊，
> +參見： Documentation/translations/zh_TW/process/development-process.rst 。
> +Documentation/translations/zh_TW/process/submit-checklist.rst 給出了一系列
> 提交補丁之前要檢查的事項。設備樹相關的補丁，請參閱
> Documentation/devicetree/bindings/submitting-patches.rst 。
>
> -本文檔假設您正在使用 ``git`` 準備你的補丁。如果您不熟悉 ``git`` ，最好學習
> -如何使用它，這將使您作爲內核開發人員的生活變得更加輕鬆。
> +本文件假設您正在使用 ``git`` 準備你的補丁。如果您不熟悉 ``git`` ，最好學習
> +如何使用它，這將使您作為核心開發人員的生活變得更加輕鬆。
>
> -部分子系統和維護人員的樹有一些關於其工作流程和要求的額外信息，請參閱
> +部分子系統和維護人員的樹有一些關於其工作流程和要求的額外資訊，請參閱
> Documentation/process/maintainer-handbooks.rst 。
>
> 獲取當前源碼樹
> --------------
>
> -如果您手頭沒有當前內核源代碼的存儲庫，請使用 ``git`` 獲取一份。您需要先獲取
> -主線存儲庫，它可以通過以下命令拉取::
> +如果您手頭沒有當前核心原始程式碼的儲存庫，請使用 ``git`` 獲取一份。您需要先獲取
> +主線儲存庫，它可以透過以下命令拉取::
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> 但是，請注意，您可能不想直接針對主線樹進行開發。大多數子系統維護人員運
> -行自己的樹，並希望看到針對這些樹準備的補丁。請參見MAINTAINERS文件中子系
> +行自己的樹，並希望看到針對這些樹準備的補丁。請參見MAINTAINERS檔案中子系
> 統的 **T:** 項以查找該樹，或者直接詢問維護者該樹是否未在其中列出。
>
> .. _tw_describe_changes:
> @@ -57,35 +58,37 @@ Documentation/process/maintainer-handbooks.rst 。
> 的問題激勵您完成這項工作。說服審閱者相信有一個問題值得解決，讓他們讀完第一段
> 後就能明白這一點。
>
> -描述用戶可見的影響。直接崩潰和鎖定是相當有說服力的，但並不是所有的錯誤都那麼
> -明目張膽。即使在代碼審閱期間發現了這個問題，也要描述一下您認爲它可能對用戶產
> -生的影響。請記住，大多數Linux安裝運行的內核來自二級穩定樹或特定於供應商/產品
> -的樹，只從上游精選特定的補丁，因此請包含任何可以幫助您將更改定位到下游的內容：
> -觸發的場景、DMESG的摘錄、崩潰描述、性能迴歸、延遲尖峯、鎖定等。
> +描述使用者可見的影響。直接崩潰和鎖定是相當有說服力的，但並不是所有的錯誤都
> +那麼明目張膽。即使在程式碼審閱期間發現了這個問題，也要描述一下您認為它可能
> +對使用者產生的影響。請記住，大多數Linux安裝執行的核心來自二級穩定樹或特定
> +於供應商/產品的樹，只從上游精選特定的補丁，因此請包含任何可以幫助您將更改
> +定位到下游的內容：觸發的場景、DMESG的摘錄、崩潰描述、效能迴歸、延遲尖峯、
> +鎖定等。
>
> -質量優化和權衡。如果您聲稱在性能、內存消耗、堆棧佔用空間或二進制大小方面有所
> -改進，請包括支持它們的數據。但也要描述不明顯的成本。優化通常不是零成本的，而是
> -在CPU、內存和可讀性之間進行權衡；或者，做探索性的工作，在不同的工作負載之間進
> -行權衡。請描述優化的預期缺點，以便審閱者可以權衡成本和收益。
> +品質最佳化和權衡。如果您聲稱在效能、記憶體消耗、堆疊佔用空間或二進位大小方
> +面有所改進，請包括支援它們的資料。但也要描述不明顯的成本。最佳化通常不是零
> +成本的，而是在CPU、記憶體和可讀性之間進行權衡；或者，做探索性的工作，在不
> +同的工作負載之間進行權衡。請描述最佳化的預期缺點，以便審閱者可以權衡成本和
> +收益。
Quantify optimizations and trade-offs.
Quantify means "量化", not “质量”, but this issue already exists in the original translation.
"when it comes to heuristics" means "若采用启发式策略". It also exists in
the original translation.
We can then submit a patch to fix these issues in both zh_CN and zh_TW.
Dongliang Mu
>
> 提出問題之後，就要詳細地描述一下您實際在做的技術細節。對於審閱者來說，用簡練的
> -英語描述代碼的變化是很重要的，以驗證代碼的行爲是否符合您的意圖。
> +英語描述程式碼的變化是很重要的，以驗證程式碼的行為是否符合您的意圖。
>
> -如果您將補丁描述寫成“標準格式”，可以很容易地作爲“提交日誌”放入Linux的源代
> +如果您將補丁描述寫成“標準格式”，可以很容易地作為“提交日誌”放入Linux的源代
> 碼管理系統 ``git`` 中，那麼維護人員將非常感謝您。
> -參見 :ref:`zh_the_canonical_patch_format` 。
> +參見 :ref:`tw_the_canonical_patch_format` 。
>
> 每個補丁只解決一個問題。如果你的描述開始變長，這就表明你可能需要拆分你的補丁。
> -請見 :ref:`zh_split_changes` 。
> +請見 :ref:`tw_split_changes` 。
>
> -提交或重新提交補丁或補丁系列時，請包括完整的補丁說明和理由。不要
> -只說這是補丁（系列）的第幾版。不要期望子系統維護人員引用更早的補丁版本或引用
> -URL來查找補丁描述並將其放入補丁中。也就是說，補丁（系列）及其描述應該是獨立的。
> -這對維護人員和審閱者都有好處。一些審閱者可能甚至沒有收到補丁的早期版本。
> +提交或重新提交補丁或補丁系列時，請包括完整的補丁說明和理由。不要只說這是補丁
> +（系列）的第幾版。不要期望子系統維護人員引用更早的補丁版本或引用URL來查
> +找補丁描述並將其放入補丁中。也就是說，補丁（系列）及其描述應該是獨立的。這
> +對維護人員和審閱者都有好處。一些審閱者可能甚至沒有收到補丁的早期版本。
>
> 用祈使句描述你的變更，例如“make xyzzy do frotz”而不是“[This patch]make
> -xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令代碼庫改變
> -它的行爲一樣。
> +xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令程式碼庫改變
> +它的行為一樣。
>
> 如果您想要引用一個特定的提交，不要只引用提交的SHA-1 ID。還請包括提交的一行
> 摘要，以便於審閱者瞭解它是關於什麼的。例如::
> @@ -95,38 +98,38 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令
> platform_set_drvdata(), but left the variable "dev" unused,
> delete it.
>
> -您還應該確保至少使用前12位SHA-1 ID。內核存儲庫包含 *許多* 對象，使較短的ID
> -發生衝突的可能性很大。記住，即使現在不會與您的六個字符ID發生衝突，這種情況
> +您還應該確保至少使用前12位SHA-1 ID。核心儲存庫包含 *許多* 物件，使較短的ID
> +發生衝突的可能性很大。記住，即使現在不會與您的六個字元ID發生衝突，這種情況
> 也可能在五年後改變。
>
> -如果該變更的相關討論或背景信息可以在網上查閱，請加上“Link:”標籤指向它。例如
> -你的補丁修復了一個缺陷，需要添加一個帶有URL的標籤指向郵件列表存檔或缺陷跟蹤器
> -的相關報告；如果該補丁是由一些早先郵件列表討論或網絡上的記錄引起的，請指向它。
> +如果該變更的相關討論或背景資訊可以在網上查閱，請加上“Link:”標籤指向它。例如
> +你的補丁修復了一個缺陷，需要添加一個帶有URL的標籤指向郵件列表存檔或缺陷追蹤器
> +的相關報告；如果該補丁是由一些早先郵件列表討論或網路上的記錄引起的，請指向它。
>
> -當鏈接到郵件列表存檔時，請首選lore.kernel.org郵件存檔服務。用郵件中的
> -``Message-ID`` 頭（去掉尖括號）可以創建鏈接URL。例如::
> +當連結到郵件列表存檔時，請首選lore.kernel.org郵件存檔服務。用郵件中的
> +``Message-ID`` 頭（去掉尖括號）可以建立連結URL。例如::
>
> - Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
> + Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI
>
> -請檢查該鏈接以確保可用且指向正確的郵件。
> +請檢查該連結以確保可用且指向正確的郵件。
>
> 不過，在沒有外部資源的情況下，也要儘量讓你的解釋可理解。除了提供郵件列表存檔或
> 缺陷的URL之外，還要需要總結該補丁的相關討論要點。
>
> -如果補丁修復了特定提交中的錯誤，例如使用 ``git bisct`` 發現了一個問題，請使用
> -帶有前12個字符SHA-1 ID的“Fixes:”標籤和單行摘要。爲了簡化解析腳本，不要將該
> -標籤拆分爲多行，標籤不受“75列換行”規則的限制。例如::
> +如果補丁修復了特定提交中的錯誤，例如使用 ``git bisect`` 發現了一個問題，請使用
> +帶有至少前12個字元SHA-1 ID的“Fixes:”標籤和單行摘要。為了簡化解析腳本，不要將該
> +標籤拆分為多行，標籤不受“75列換行”規則的限制。例如::
>
> Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
>
> -下列 ``git config`` 設置可以讓 ``git log``, ``git show`` 增加上述風格的顯示格式::
> +下列 ``git config`` 設定可以讓 ``git log``, ``git show`` 增加上述風格的顯示格式::
>
> [core]
> abbrev = 12
> [pretty]
> fixes = Fixes: %h (\"%s\")
>
> -使用示例::
> +使用範例::
>
> $ git log -1 --pretty=fixes 54a4f0239f2e
> Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
> @@ -138,41 +141,42 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令
>
> 將每個 **邏輯更改** 拆分成一個單獨的補丁。
>
> -例如，如果你的改動裏同時有bug修正和性能優化，那麼把這些改動拆分到兩個或
> -者更多的補丁文件中。如果你的改動包含對API的修改，並且增加了一個使用該新API
> +例如，如果你的改動裡同時有bug修正和效能最佳化，那麼把這些改動拆分到兩個或
> +者更多的補丁檔案中。如果你的改動包含對API的修改，並且增加了一個使用該新API
> 的驅動，那麼把這些修改分成兩個補丁。
>
> -另一方面，如果你將一個單獨的改動做成多個補丁文件，那麼將它們合併成一個
> -單獨的補丁文件。這樣一個邏輯上單獨的改動只被包含在一個補丁文件裏。
> +另一方面，如果你將一個單獨的改動做成多個補丁檔案，那麼將它們合併成一個
> +單獨的補丁檔案。這樣一個邏輯上單獨的改動只被包含在一個補丁檔案裡。
>
> 需要記住的一點是，每個補丁的更改都應易於理解，以便審閱者驗證。每個補丁都應該
> 對其價值進行闡述。
>
> -如果有一個補丁依賴另外一個補丁來完成它的改動，那沒問題。直接在你的補
> -丁描述裏指出 **“這個補丁依賴某補丁”** 就好了。
> +如果有一個補丁依賴另外一個補丁來完成它的改動，那沒問題。直接在你的補丁
> +描述裡指出 **“這個補丁依賴某補丁”** 就好了。
>
> -在將您的更改劃分爲一系列補丁時，要特別注意確保內核在應用系列中的每個補丁之後
> -都能正常構建和運行。使用 ``git bisect`` 來追蹤問題的開發者可能會在任何地方分
> +在將您的更改劃分為一系列補丁時，要特別注意確保核心在應用系列中的每個補丁之後
> +都能正常建置和執行。使用 ``git bisect`` 來追蹤問題的開發者可能會在任何地方分
> 割你的補丁系列；如果你在中間引入錯誤，他們不會感謝你。
>
> 如果你不能將補丁系列濃縮得更小，那麼每次大約發送出15個補丁，然後等待審閱
> -和集成。
> +和整合。
>
> 檢查你的更改風格
> ----------------
>
> -檢查您的補丁是否違反了基本樣式規定，詳細信息參見
> -Documentation/translations/zh_CN/process/coding-style.rst
> +檢查您的補丁是否違反了基本樣式規定，詳細資訊參見
> +Documentation/translations/zh_TW/process/coding-style.rst
> 中找到。如果不這樣做，只會浪費審閱者的時間，並且會導致你的補丁被拒絕，甚至
> 可能沒有被閱讀。
>
> -一個重要的例外是在將代碼從一個文件移動到另一個文件時——在這種情況下，您不應
> -該在移動代碼的同一個補丁中修改移動的代碼。這清楚地描述了移動代碼和您的更改
> -的行爲。這大大有助於審閱實際差異，並允許工具更好地跟蹤代碼本身的歷史。
> +一個重要的例外是在將程式碼從一個檔案移動到另一個檔案時——在這種情況下，您不
> +應該在移動程式碼的同一個補丁中修改移動的程式碼。這清楚地描述了移動程式碼和
> +您的更改的行為。這大大有助於審閱實際差異，並允許工具更好地追蹤程式碼本身的
> +歷史。
>
> -在提交之前，使用補丁樣式檢查程序檢查補丁（scripts/check patch.pl）。不過，
> -請注意，樣式檢查程序應該被視爲一個指南，而不是作爲人類判斷的替代品。如果您
> -的代碼看起來更好，但有違規行爲，那麼最好別管它。
> +在提交之前，使用補丁樣式檢查程式檢查補丁（scripts/checkpatch.pl）。不過，
> +請注意，樣式檢查程式應該被視為一個指南，而不是作為人類判斷的替代品。如果您
> +的程式碼看起來更好，但有違規行為，那麼最好別管它。
>
> 檢查者報告三個級別：
>
> @@ -180,58 +184,56 @@ Documentation/translations/zh_CN/process/coding-style.rst
> - WARNING：需要仔細審閱的事項
> - CHECK：需要思考的事情
>
> -您應該能夠判斷您的補丁中存在的所有違規行爲。
> +您應該能夠判斷您的補丁中存在的所有違規行為。
>
> 選擇補丁收件人
> --------------
>
> -您應該總是知會任何補丁相應代碼的子系統維護人員；查看
> -維護人員文件和源代碼修訂歷史記錄，以瞭解這些維護人員是誰。腳本
> +您應該總是知會任何補丁相應程式碼的子系統維護人員；查看
> +MAINTAINERS檔案和原始程式碼修訂歷史記錄，以瞭解這些維護人員是誰。腳本
> scripts/get_maintainer.pl在這個步驟中非常有用。如果您找不到正在工作的子系統
> 的維護人員，那麼Andrew Morton（akpm@linux-foundation.org）將充當最後的維護
> 人員。
>
> -您通常還應該選擇至少一個郵件列表來接收補丁集的副本。linux-kernel@vger.kernel.org
> -是所有補丁的默認列表，但是這個列表的流量已經導致了許多開發人員不再看它。
> -在MAINTAINERS文件中查找子系統特定的列表；您的補丁可能會在那裏得到更多的關注。
> -不過，請不要發送垃圾郵件到無關的列表。
> +您通常還應該選擇至少一個郵件列表來接收補丁集的副本。linux-kernel@
> +vger.kernel.org是所有補丁的預設列表，但是這個列表的流量已經導致了許多開發
> +人員不再看它。在MAINTAINERS檔案中查找子系統特定的列表；您的補丁可能會在那
> +裡得到更多的關注。不過，請不要發送垃圾郵件到無關的列表。
>
> -許多與內核相關的列表託管在vger.kernel.org上；您可以在
> -http://vger.kernel.org/vger-lists.html 上找到它們的列表。不過，也有與內核相關
> +許多與核心相關的列表託管在kernel.org上；您可以在
> +https://subspace.kernel.org 上找到它們的列表。不過，也有與核心相關
> 的列表託管在其他地方。
>
> -不要一次發送超過15個補丁到vger郵件列表！！！！
> -
> -Linus Torvalds是決定改動能否進入 Linux 內核的最終裁決者。他的郵件地址是
> +Linus Torvalds是決定改動能否進入 Linux 核心的最終裁決者。他的郵件地址是
> torvalds@linux-foundation.org 。他收到的郵件很多，所以一般來說最好 **別**
> 給他發郵件。
>
> -如果您有修復可利用安全漏洞的補丁，請將該補丁發送到 security@kernel.org 。對於
> -嚴重的bug，可以考慮短期禁令以允許分銷商（有時間）向用戶發佈補丁；在這種情況下，
> -顯然不應將補丁發送到任何公共列表。
> -參見 Documentation/translations/zh_CN/process/security-bugs.rst 。
> +如果您有修復可利用安全漏洞的補丁，請將該補丁發送到 security@kernel.org 。
> +對於嚴重的bug，可以考慮短期禁令以允許分銷商（有時間）向使用者發布補丁；在
> +這種情況下，顯然不應將補丁發送到任何公共列表。參見
> +Documentation/process/security-bugs.rst 。
>
> -修復已發佈內核中嚴重錯誤的補丁程序應該抄送給穩定版維護人員，方法是把以下列行
> -放進補丁的籤準區（注意，不是電子郵件收件人）::
> +修復已發布核心中嚴重錯誤的補丁程式應該抄送給穩定版維護人員，方法是把以下列行
> +放進補丁的簽署區（注意，不是電子郵件收件人）::
>
> Cc: stable@vger.kernel.org
>
> 除了本文件之外，您還應該閱讀
> -Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
> +Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
>
> -如果更改影響到用戶側內核接口，請向手冊頁維護人員（如維護人員文件中所列）發送
> -手冊頁補丁，或至少發送更改通知，以便一些信息進入手冊頁。還應將用戶空間API
> -更改抄送到 linux-api@vger.kernel.org 。
> +如果更改影響到使用者側核心介面，請向手冊頁維護人員（如MAINTAINERS檔案中所
> +列）發送手冊頁補丁，或至少發送更改通知，以便一些資訊進入手冊頁。還應將使用
> +者空間API更改抄送到 linux-api@vger.kernel.org 。
>
>
> -不要MIME編碼，不要鏈接，不要壓縮，不要附件，只要純文本
> +不要MIME編碼，不要連結，不要壓縮，不要附件，只要純文字
> ------------------------------------------------------
>
> -Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對於內核開發者來說
> +Linus 和其他的核心開發者需要閱讀和評論你提交的改動。對於核心開發者來說
> ，可以“引用”你的改動很重要，使用一般的郵件工具，他們就可以在你的
> -代碼的任何位置添加評論。
> +程式碼的任何位置添加評論。
>
> -因爲這個原因，所有的提交的補丁都是郵件中“內嵌”的。最簡單（和推薦）的方法就
> +因為這個原因，所有的提交的補丁都是郵件中“內嵌”的。最簡單（和推薦）的方法就
> 是使用 ``git send-email`` 。https://git-send-email.io 有 ``git send-email``
> 的交互式教程。
>
> @@ -239,30 +241,54 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對
>
> .. warning::
>
> - 如果你使用剪切-粘貼你的補丁，小心你的編輯器的自動換行功能破壞你的補丁
> + 如果你使用剪切-貼上你的補丁，小心你的編輯器的自動換行功能破壞你的補丁
>
> -不要將補丁作爲MIME編碼的附件，不管是否壓縮。很多流行的郵件軟件不
> -是任何時候都將MIME編碼的附件當作純文本發送的，這會使得別人無法在你的
> -代碼中加評論。另外，MIME編碼的附件會讓Linus多花一點時間來處理，這就
> +不要將補丁作為MIME編碼的附件，不管是否壓縮。很多流行的郵件軟體不
> +是任何時候都將MIME編碼的附件當作純文字發送的，這會使得別人無法在你的
> +程式碼中加評論。另外，MIME編碼的附件會讓Linus多花一點時間來處理，這就
> 降低了你的改動被接受的可能性。
>
> 例外：如果你的郵路損壞了補丁，那麼有人可能會要求你使用MIME重新發送補丁。
>
> -請參閱 Documentation/translations/zh_CN/process/email-clients.rst
> -以獲取有關配置電子郵件客戶端以使其不受影響地發送補丁的提示。
> +請參閱 Documentation/translations/zh_TW/process/email-clients.rst
> +以獲取有關設定電子郵件客戶端以使其不受影響地發送補丁的提示。
>
> 回覆審閱意見
> ------------
>
> 你的補丁幾乎肯定會得到審閱者對補丁改進方法的評論（以回覆郵件的形式）。您必須
> 對這些評論作出回應；讓補丁被忽略的一個好辦法就是忽略審閱者的意見。直接回復郵
> -件來回應意見即可。不會導致代碼更改的意見或問題幾乎肯定會帶來註釋或變更日誌的
> +件來回應意見即可。不會導致程式碼更改的意見或問題幾乎肯定會帶來註解或變更日誌的
> 改變，以便下一個審閱者更好地瞭解正在發生的事情。
>
> -一定要告訴審閱者你在做什麼改變，並感謝他們的時間。代碼審閱是一個累人且耗時的
> +一定要告訴審閱者你在做什麼改變，並感謝他們的時間。程式碼審閱是一個累人且耗時的
> 過程，審閱者有時會變得暴躁。即使在這種情況下，也要禮貌地回應並解決他們指出的
> 問題。當發送下一版時，在封面郵件或獨立補丁里加上 ``patch changelog`` 說明與
> -前一版本的不同之處（參見 :ref:`zh_the_canonical_patch_format` ）。
> +前一版本的不同之處（參見 :ref:`tw_the_canonical_patch_format` ）。
> +
> +.. _tw_interleaved_replies:
> +
> +在郵件討論中使用裁剪過的交錯式回覆
> +----------------------------------
> +
> +在Linux核心開發的討論中，強烈不建議置頂回覆（top-posting）。交錯式（或
> +“行內”）回覆使對話更容易理解。更多細節參見：
> +https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
> +
> +正如郵件列表中經常被引用的那樣::
> +
> + A: http://en.wikipedia.org/wiki/Top_post
> + Q: Where do I find info about this thing called top-posting?
> + A: Because it messes up the order in which people normally read text.
> + Q: Why is top-posting such a bad thing?
> + A: Top-posting.
> + Q: What is the most annoying thing in e-mail?
> +
> +同樣，請裁剪掉所有與你的回覆無關的引文。這使回覆更容易查找，並節省時間和
> +空間。更多細節參見： http://daringfireball.net/2007/07/on_top ::
> +
> + A: No.
> + Q: Should I include quotations after my reply?
>
> .. _tw_resend_reminders:
>
> @@ -271,54 +297,54 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對
>
> 提交更改後，請耐心等待。審閱者是大忙人，可能無法立即審閱您的補丁。
>
> -曾幾何時，補丁曾在沒收到評論的情況下消失在虛空中，但現在開發過程應該更加順利了。
> -您應該在一週左右的時間內收到評論；如果沒有收到評論，請確保您已將補丁發送
> -到正確的位置。在重新提交或聯繫審閱者之前至少等待一週——在諸如合併窗口之類的
> -繁忙時間可能更長。
> +曾幾何時，補丁曾在沒收到評論的情況下消失在虛空中，但現在開發過程應該更加順
> +利了。您應該在一週左右的時間內收到評論；如果沒有收到評論，請確保您已將補丁
> +發送到正確的位置。在重新提交或聯繫審閱者之前至少等待一週——在諸如合併視窗之
> +類的繁忙時間可能更長。
>
> 在等了幾個星期後，用帶RESEND的主題重發補丁也是可以的::
>
> [PATCH Vx RESEND] sub/sys: Condensed patch summary
>
> -當你發佈補丁（系列）修改版的時候，不要加上“RESEND”——“RESEND”只適用於重
> +當你發布補丁（系列）修改版的時候，不要加上“RESEND”——“RESEND”只適用於重
> 新提交之前未經修改的補丁（系列）。
>
> 主題中包含 PATCH
> ----------------
>
> 由於到Linus和linux-kernel的電子郵件流量很高，通常會在主題行前面加上[PATCH]
> -前綴。這使Linus和其他內核開發人員更容易將補丁與其他電子郵件討論區分開。
> +前綴。這使Linus和其他核心開發人員更容易將補丁與其他電子郵件討論區分開。
>
> -``git send-email`` 會自動爲你加上。
> +``git send-email`` 會自動為你加上。
>
> 簽署你的作品——開發者來源認證
> ------------------------------
>
> -爲了加強對誰做了何事的追蹤，尤其是對那些透過好幾層維護者才最終到達的補丁，我
> -們在通過郵件發送的補丁上引入了“簽署（sign-off）”流程。
> +為了加強對誰做了何事的追蹤，尤其是對那些透過好幾層維護者才最終到達的補丁，我
> +們在透過郵件發送的補丁上引入了“簽署（sign-off）”流程。
>
> -“簽署”是在補丁註釋最後的一行簡單文字，認證你編寫了它或者其他
> -人有權力將它作爲開放源代碼的補丁傳遞。規則很簡單：如果你能認證如下信息:
> +“簽署”是在補丁註解最後的一行簡單文字，認證你編寫了它或者其他
> +人有權力將它作為開放原始程式碼的補丁傳遞。規則很簡單：如果你能認證如下資訊:
>
> 開發者來源認證 1.1
> ^^^^^^^^^^^^^^^^^^
>
> -對於本項目的貢獻，我認證如下信息：
> +對於本專案的貢獻，我認證如下資訊：
>
> - (a) 這些貢獻是完全或者部分的由我創建，我有權利以文件中指出
> - 的開放源代碼許可證提交它；或者
> + (a) 這些貢獻是完全或者部分的由我建立，我有權利以文件中指出
> + 的開放原始程式碼許可證提交它；或者
>
> (b) 這些貢獻基於以前的工作，據我所知，這些以前的工作受恰當的開放
> - 源代碼許可證保護，而且，根據文件中指出的許可證，我有權提交修改後的貢獻，
> - 無論是完全還是部分由我創造，這些貢獻都使用同一個開放源代碼許可證
> + 原始程式碼許可證保護，而且，根據文件中指出的許可證，我有權提交修改後的貢獻，
> + 無論是完全還是部分由我創造，這些貢獻都使用同一個開放原始程式碼許可證
> （除非我被允許用其它的許可證）；或者
>
> (c) 這些貢獻由認證（a），（b）或者（c）的人直接提供給我，而
> 且我沒有修改它。
>
> - (d) 我理解並同意這個項目和貢獻是公開的，貢獻的記錄（包括我
> - 一起提交的個人記錄，包括sign-off）被永久維護並且可以和這個項目
> - 或者開放源代碼的許可證同步地再發行。
> + (d) 我理解並同意這個專案和貢獻是公開的，貢獻的記錄（包括我
> + 一起提交的個人記錄，包括sign-off）被永久維護並且可以和這個專案
> + 或者開放原始程式碼的許可證同步地再發行。
>
> 那麼加入這樣一行::
>
> @@ -339,33 +365,47 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對
>
> Signed-off-by: 標籤表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。
>
> -如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准/贊成，
> -那麼他們可以要求在補丁的變更日誌中添加一個Acked-by:。
> +如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准/
> +贊成，那麼他們可以要求在補丁的變更日誌中添加一個Acked-by:。
> +
> +Acked-by: 供以某種方式對受影響程式碼負責或與之相關的人使用。最常見的情況是，
> +當維護者既沒有貢獻也沒有轉發補丁時，由該維護者使用。
>
> -Acked-by: 通常由受影響代碼的維護者使用，當該維護者既沒有貢獻也沒有轉發補丁時。
> +Acked-by: 也可以由其他利益相關者使用，例如具有領域知識的人（例如被修改程式
> +碼的原作者）、核心uAPI補丁的使用者空間側審閱者，或某項功能的關鍵使用者。在
> +這些情況下，可以視需要加上一個“# 後綴”以澄清其含義::
> +
> + Acked-by: The Stakeholder <stakeholder@example.org> # As primary user
>
> Acked-by: 不像簽署那樣正式。這是一個記錄，確認人至少審閱了補丁，並表示接受。
> -因此，補丁合併有時會手動將Acker的“Yep，looks good to me”轉換爲 Acked-By:（但
> +因此，補丁合併有時會手動將Acker的“Yep，looks good to me”轉換為 Acked-By:（但
> 請注意，通常最好要求一個明確的Ack）。
>
> -Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁影響多個子系統，並且
> -有一個來自某個子系統維護者的Acked-By:，那麼這通常表示只確認影響維護者代碼的部
> -分。這裏應該仔細判斷。如有疑問，應參考郵件列表存檔中的原始討論。
> +Acked-by: 也不如 Reviewed-by: 正式。例如，維護者可以用它表示他們同意補丁
> +合入，但可能沒有像提供Reviewed-by:那樣徹底地審閱過補丁。同樣，關鍵使用者
> +可能沒有對補丁進行技術審閱，但他們可能對整體方法、功能或面向使用者的介面
> +感到滿意。
> +
> +Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁影響多個子系統，並
> +且有一個來自某個子系統維護者的Acked-By:，那麼這通常表示只確認影響維護者程
> +式碼的部分。這裡應該仔細判斷。如有疑問，應參考郵件列表存檔中的原始討論。在
> +這種情況下也可以使用“# 後綴”來澄清。
>
> 如果某人本應有機會對補丁進行評論，但沒有提供此類評論，您可以選擇在補丁中添加
> -``Cc:`` 這是唯一可以在沒有被該人明確同意的情況下添加的標籤——但它應該表明
> -這個人是在補丁上抄送的。此標籤記錄了討論中包含的潛在利益相關方。
> +``Cc:`` 標籤。此標籤記錄了討論中包含的潛在利益相關方。注意，這是僅有的三個
> +可以在未經被指名者明確許可的情況下使用的標��之一（詳見下面的“標記他人需要
> +許可”）。
>
> -Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上工
> -作時，它用於給出共同作者（除了From:所給出的作者之外）。因爲Co-developed-by:
> +Co-developed-by: 聲明補丁是由多個開發人員共同建立的；當幾個人在一個補丁上工
> +作時，它用於給出共同作者（除了From:所給出的作者之外）。因為Co-developed-by:
> 表示作者身份，所以每個Co-developed-by:必須緊跟在相關合作作者的簽署之後。標準
> -簽署程序要求Signed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通
> +簽署程式要求Signed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通
> 過From:還是Co-developed-by:表明。值得注意的是，最後一個Signed-off-by:必須是
> 提交補丁的開發人員。
>
> 注意，如果From:作者也是電子郵件標題的From:行中列出的人，則From:標籤是可選的。
>
> -被From:作者提交的補丁示例::
> +被From:作者提交的補丁範例::
>
> <changelog>
>
> @@ -375,7 +415,7 @@ Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個
> Signed-off-by: Second Co-Author <second@coauthor.example.org>
> Signed-off-by: From Author <from@author.example.org>
>
> -被合作開發者提交的補丁示例::
> +被合作開發者提交的補丁範例::
>
> From: From Author <from@author.example.org>
>
> @@ -392,67 +432,95 @@ Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個
> -----------------------------------------------------------------
>
> Reported-by: 給那些發現錯誤並報告錯誤的人致謝，它希望激勵他們在將來再次幫助
> -我們。請注意，如果bug是以私有方式報告的，那麼在使用Reported-by標籤之前，請
> -先請求許可。此標籤是爲Bug設計的；請不要將其用於感謝功能請求。
> +我們。注意，Reported-by標籤是僅有的三個可以在未經被指名者明確許可的情況下
> +使用的標籤之一（詳見下面的“標記他人需要許可”）。此標籤是為Bug設計的；請不要
> +將其用於感謝功能請求。
>
> Tested-by: 標籤表示補丁已由指定的人（在某些環境中）成功測試。這個標籤通知
> -維護人員已經執行了一些測試，爲將來的補丁提供了一種定位測試人員的方法，並彰顯測試人員的功勞。
> +維護人員已經執行了一些測試，為將來的補丁提供了一種定位測試人員的方法，並彰
> +顯測試人員的功勞。
>
> -Reviewed-by：根據審閱者的監督聲明，表明該補丁已被審閱並被認爲是可接受的：
> +Reviewed-by：根據審閱者的監督聲明，表明該補丁已被審閱並被認為是可接受的：
>
>
> 審閱者的監督聲明
> ^^^^^^^^^^^^^^^^
>
> -通過提供我的Reviewed-by:標籤，我聲明：
> +透過提供我的Reviewed-by:標籤，我聲明：
>
> (a) 我已經對這個補丁進行了一次技術審閱，以評估它是否適合被包含到
> - 主線內核中。
> + 主線核心中。
>
> (b) 與補丁相關的任何問題、顧慮或問題都已反饋給提交者。我對提交者對
> 我的評論的回應感到滿意。
>
> - (c) 雖然這一提交可能仍可被改進，但我相信，此時，（1）對內核
> + (c) 雖然這一提交可能仍可被改進，但我相信，此時，（1）對核心
> 進行了有價值的修改，（2）沒有包含爭論中涉及的已知問題。
>
> - (d) 雖然我已經審閱了補丁並認爲它是健全的，但我不會（除非另有明確
> - 說明）作出任何保證或擔保它會在任何給定情況下實現其規定的目的
> - 或正常運行。
> + (d) 雖然我已經審閱了補丁並認為它是健全的，但我不會（除非另有明確
> + 說明）作出任何保證或擔保它會在任何給定情況下實作其規定的目的
> + 或正常執行。
>
> -Reviewed-by是一種觀點聲明，即補丁是對內核的適當修改，沒有任何遺留的嚴重技術
> -問題。任何感興趣的審閱者（完成工作的人）都可以爲一個補丁提供一個Reviewed-by
> -標籤。此標籤用於向審閱者提供致謝，並通知維護者補丁的審閱進度。
> -當Reviewed-by:標籤由已知了解主題區域並執行徹底檢查的審閱者提供時，通常會增加
> -補丁進入內核的可能性。
> +Reviewed-by是一種觀點聲明，即補丁是對核心的適當修改，沒有任何遺留的嚴重技
> +術問題。任何感興趣的審閱者（完成了審閱工作且具有已知身分的人）都可以為一個
> +補丁提供一個Reviewed-by標籤。此標籤用於向審閱者提供致謝，並通知維護者補丁
> +的審閱進度。當Reviewed-by:標籤由已知了解主題區域並執行徹底檢查的審閱者提供
> +時，通常會增加補丁進入核心的可能性。
>
> -一旦從測試人員或審閱者的“Tested-by”和“Reviewed-by”標籤出現在郵件列表中，
> -作者應在發送下一個版本時將其添加到適用的補丁中。但是，如果補丁在以下版本中發
> -生了實質性更改，這些標籤可能不再適用，因此應該刪除。通常，在補丁更改日誌中
> -（在 ``---`` 分隔符之後）應該提到刪除某人的測試者或審閱者標籤。
> +一旦從測試人員或審閱者的“Tested-by”和“Reviewed-by”標籤出現在郵件列表中，作
> +者應在發送下一個版本時將其添加到適用的補丁中。但是，如果補丁在以下版本中發
> +生了實質性更改，這些標籤可能不再適用，因此應該刪除。通常，刪除某人的
> +Acked-by、Tested-by或Reviewed-by標籤時，應在補丁更改日誌中（在 ``---`` 分
> +隔符之後）提及並附上解釋。
>
> Suggested-by: 表示補丁的想法是由指定的人提出的，並確保將此想法歸功於指定的
> -人。請注意，未經許可，不得添加此標籤，特別是如果該想法未在公共論壇上發佈。
> -也就是說，如果我們勤快地致謝創意提供者，他們將受到鼓舞，很有希望在未來再次
> -幫助我們。
> +人：如果我們勤快地致謝創意提供者，他們將受到鼓舞，很有希望在未來再次幫助
> +我們。注意，這是僅有的三個可以在未經被指名者明確許可的情況下使用的標籤之一
> +（詳見下面的“標記他人需要許可”）。
>
> -Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定錯誤的來源，這有助於
> -檢查錯誤修復。這個標籤還幫助穩定內核團隊確定應該接收修復的穩定內核版本。這是
> -指示補丁修復的錯誤的首選方法。請參閱 :ref:`zh_describe_changes` 瞭解更多信息。
> +Fixes: 指示補丁修復了之前提交中的一個缺陷。它可以便於確定問題的來源，這有助於
> +檢查錯誤修復。這個標籤還幫助穩定核心團隊確定應該接收修復的穩定核心版本。這是
> +指示補丁修復的錯誤的首選方法。請參閱 :ref:`tw_describe_changes` 瞭解更多資訊。
>
> .. note::
>
> - 附加Fixes:標籤不會改變穩定內核規則流程，也不改變所有穩定版補丁抄送
> - stable@vger.kernel.org的要求。有關更多信息，請閱讀
> - Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
> + 附加Fixes:標籤不會改變穩定核心規則流程，也不改變所有穩定版補丁抄送
> + stable@vger.kernel.org的要求。有關更多資訊，請閱讀
> + Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
> +
> +最後，雖然提供標籤是受歡迎的且通常非常受讚賞，但請注意，簽署者（即提交者和
> +維護者）可以自行斟酌是否採用所提供的標籤。
> +
> +.. _tw_tagging_people:
> +
> +標記他人需要許可
> +----------------
> +
> +在補丁中添加上述標籤時要小心：除了Cc:、Reported-by:和Suggested-by:之外，
> +所有標籤都需要被指名者的明確許可。對於這三個標籤，如果根據lore存檔或提交
> +歷史，該人曾以該名字和電子郵件地址對Linux核心做出過貢獻，那麼隱含的許可
> +就足夠了——並且對於Reported-by:和Suggested-by:，報告或建議必須是公開作出
> +的。注意，就此而言bugzilla.kernel.org是公開場所，但其中使用的電子郵件地址
> +是私密的；因此不要在標籤中暴露它們，除非該人在先前的貢獻中使用過。
> +
> +使用Assisted-by:
> +----------------
> +
> +如果您在建立補丁的過程中使用了任何進階編碼工具，您需要透過添加Assisted-by
> +標籤來聲明這一使用。不這樣做可能會妨礙您的工作被接受。關於聲明編碼助手的
> +細節，請參見 Documentation/process/coding-assistants.rst 。
>
> .. _tw_the_canonical_patch_format:
>
> 標準補丁格式
> ------------
>
> -本節描述如何格式化補丁本身。請注意，如果您的補丁存儲在 ``Git`` 存儲庫中，則
> -可以使用 ``git format-patch`` 進行正確的補丁格式化。但是，這些工具無法創建
> -必要的文本，因此請務必閱讀下面的說明。
> +本節描述如何格式化補丁本身。請注意，如果您的補丁儲存在 ``Git`` 儲存庫中，則
> +可以使用 ``git format-patch`` 進行正確的補丁格式化。但是，這些工具無法建立
> +必要的文字，因此請務必閱讀下面的說明。
> +
> +主題行
> +^^^^^^
>
> 標準的補丁標題行是::
>
> @@ -460,7 +528,8 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
>
> 標準補丁的信體包含如下部分：
>
> - - 一個 ``from`` 行指出補丁作者。後跟空行（僅當發送補丁的人不是作者時才需要）。
> + - 一個 ``from`` 行指出補丁作者。後跟空行（僅當發送補丁的人不是作者時才需
> + 要）。
>
> - 說明文字，每行最長75列，這將被複制到永久變更日誌來描述這個補丁。
>
> @@ -470,30 +539,30 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
>
> - 只包含 ``---`` 的標記線。
>
> - - 任何其他不適合放在變更日誌的註釋。
> + - 任何其他不適合放在變更日誌的註解。
>
> - 實際補丁（ ``diff`` 輸出）。
>
> 標題行的格式，使得對標題行按字母序排序非常的容易——很多郵件客戶端都
> -可以支持——因爲序列號是用零填充的，所以按數字排序和按字母排序是一樣的。
> +可以支援——因為序列號是用零填充的，所以按數字排序和按字母排序是一樣的。
>
> -郵件標題中的“子系統”標識哪個內核子系統將被打補丁。
> +郵件標題中的“子系統”標識哪個核心子系統將被打補丁。
>
> 郵件標題中的“一句話概述”扼要的描述郵件中的補丁。“一句話概述”
> -不應該是一個文件名。對於一個補丁系列（“補丁系列”指一系列的多個相關補
> -丁），不要對每個補丁都使用同樣的“一句話概述”。
> +不應該是一個檔名。對於一個補丁系列（“補丁系列”指一系列的多個相關補丁
> +），不要對每個補丁都使用同樣的“一句話概述”。
>
> -記住郵件的“一句話概述”會成爲該補丁的全局唯一標識。它會進入 ``git``
> -的改動記錄裏。然後“一句話概述”會被用在開發者的討論裏，用來指代這個補
> -丁。用戶將希望通過搜索引擎搜索“一句話概述”來找到那些討論這個補丁的文
> +記住郵件的“一句話概述”會成為該補丁的全域唯一標識。它會進入 ``git``
> +的改動記錄裡。然後“一句話概述”會被用在開發者的討論裡，用來指代這個補丁
> +。使用者將希望透過搜索引擎搜索“一句話概述”來找到那些討論這個補丁的文
> 章。當人們在兩三個月後使用諸如 ``gitk`` 或 ``git log --oneline`` 之類
> 的工具查看數千個補丁時，也會很快看到它。
>
> -出於這些原因，概述必須不超過70-75個字符，並且必須描述補丁的更改以及爲
> +出於這些原因，概述必須不超過70-75個字元，並且必須描述補丁的更改以及為
> 什麼需要補丁。既要簡潔又要描述性很有挑戰性，但寫得好的概述應該這樣。
>
> 概述的前綴可以用方括號括起來：“Subject: [PATCH <tag>...] <概述>”。標記
> -不被視爲概述的一部分，而是描述應該如何處理補丁。如果補丁的多個版本已發
> +不被視為概述的一部分，而是描述應該如何處理補丁。如果補丁的多個版本已發
> 送出來以響應評審（即“v1，v2，v3”）則必須包含版本號，或包含“RFC”以指示
> 評審請求。如果一個補丁系列中有四個補丁，那麼各個補丁可以這樣編號：1/4、2/4、
> 3/4、4/4。這可以確保開發人員瞭解補丁應用的順序，且
> @@ -501,42 +570,78 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
>
> 一些標題的例子::
>
> - Subject: [patch 2/5] ext2: improve scalability of bitmap searching
> - Subject: [PATCHv2 001/207] x86: fix eflags tracking
> + Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
> + Subject: [PATCH v2 01/27] x86: fix eflags tracking
> + Subject: [PATCH v2] sub/sys: Condensed patch summary
> + Subject: [PATCH v2 M/N] sub/sys: Condensed patch summary
> +
> +From行
> +^^^^^^
>
> -``From`` 行是信體裏的最上面一行，具有如下格式::
> +``From`` 行必須是信體裡的最上面一行，具有如下格式::
>
> From: Patch Author <author@example.com>
>
> -``From`` 行指明在永久改動日誌裏，誰會被確認爲作者。如果沒有 ``From`` 行，那
> -麼郵件頭裏的 ``From:`` 行會被用來決定改動日誌中的作者。
> +``From`` 行指明在永久改動日誌裡，誰會被確認為作者。如果沒有 ``From`` 行，那
> +麼郵件頭裡的 ``From:`` 行會被用來決定改動日誌中的作者。
>
> -說明文字將會被提交到永久的源代碼改動日誌裏，因此應針對那些早已經不記得和這
> -個補丁相關的討論細節的讀者。包括補丁處理的故障症狀（內核日誌消息、oops消息
> -等），這對於可能正在搜索提交日誌以查找適用補丁的人特別有用。文本應該寫得如
> -此詳細，以便在數週、數月甚至數年後閱讀時，能夠爲讀者提供所需的細節信息，以
> -掌握創建補丁的 **原因** 。
> +作者可以透過在 ``from`` 行和 ``SoB`` 行中加上組織名稱，來表明其所屬單位
> +或工作的贊助者，例如：
> +
> + From: Patch Author (Company) <author@example.com>
> +
> +說明主體
> +^^^^^^^^
> +
> +說明文字將會被提交到永久的原始程式碼改動日誌裡，因此應針對那些早已經不記得和這
> +個補丁相關的討論細節的讀者。包括補丁處理的故障症狀（核心日誌訊息、oops訊息
> +等），這對於可能正在搜索提交日誌以查找適用補丁的人特別有用。文字應該寫得如
> +此詳細，以便在數週、數月甚至數年後閱讀時，能夠為讀者提供所需的細節資訊，以
> +掌握建立補丁的 **原因** 。
>
> 如果一個補丁修復了一個編譯失敗，那麼可能不需要包含 *所有* 編譯失敗；
> 只要足夠讓搜索補丁的人能夠找到它就行了。與概述一樣，既要簡潔又要描述性。
>
> -``---`` 標記行對於補丁處理工具要找到哪裏是改動日誌信息的結束，是不可缺少
> +
> +.. _tw_backtraces:
> +
> +提交訊息中的回溯（Backtraces）
> +""""""""""""""""""""""""""""""
> +
> +回溯有助於記錄導致問題的呼叫鏈。然而，並非所有回溯都有幫助。例如，早期引導呼
> +叫鏈是獨特而明顯的。而逐字複製完整的dmesg輸出則會增加時間戳、模組列表、暫存
> +器和堆疊轉儲等分散注意力的資訊。
> +
> +因此，最有用的回溯應該從轉儲中提取相關資訊，以更容易集中在真實問題上。下面是
> +一個剪裁良好的回溯範例::
> +
> + unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064)
> + at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
> + Call Trace:
> + mba_wrmsr
> + update_domains
> + rdtgroup_mkdir
> +
> +附加註解（Commentary）
> +^^^^^^^^^^^^^^^^^^^^^^
> +
> +``---`` 標記行對於補丁處理工具要找到哪裡是改動日誌資訊的結束，是不可缺少
> 的。
>
> -對於 ``---`` 標記之後的額外註解，一個好的用途就是用來寫 ``diffstat`` ，用來顯
> -示修改了什麼文件和每個文件都增加和刪除了多少行。 ``diffstat`` 對於比較大的補
> -丁特別有用。
> -使用 ``diffstat`` 的選項 ``-p 1 -w 70`` 這樣文件名就會從內核源代碼樹的目錄開始
> -，不會佔用太寬的空間（很容易適合80列的寬度，也許會有一些縮進。）
> -（ ``git`` 默認會生成合適的diffstat。）
> +對於 ``---`` 標記之後的額外註解，一個好的用途就是用來寫 ``diffstat`` ，用
> +來顯示修改了什麼檔案和每個檔案都增加和刪除了多少行。 ``diffstat`` 對於比較
> +大的補丁特別有用。使用 ``diffstat`` 的選項 ``-p 1 -w 70`` 這樣檔名就會從核
> +心原始程式碼樹的目錄開始，不會佔用太寬的空間（很容易適合80列的寬度，也許會
> +有一些縮排。）（ ``git`` 預設會產生合適的diffstat。）
>
> -其餘那些只適用於當時或者與維護者相關的註解，不合適放到永久的改動日誌裏的，也
> -應該放這裏。較好的例子就是 ``補丁更改記錄`` ，記錄了v1和v2版本補丁之間的差異。
> +其餘那些只適用於當時或者與維護者相關的註解，不合適放到永久的改動日誌裡的，也
> +應該放這裡。較好的例子就是 ``補丁更改記錄`` ，記錄了v1和v2版本補丁之間的差異。
>
> -請將此信息放在將變更日誌與補丁的其餘部分分隔開的 ``---`` 行 **之後** 。版本
> -信息不是提交到git樹的變更日誌的一部分。只是供審閱人員使用的附加信息。如果將
> +請將此資訊放在將變更日誌與補丁的其餘部分分隔開的 ``---`` 行 **之後** 。版本
> +資訊不是提交到git樹的變更日誌的一部分。只是供審閱人員使用的附加資訊。如果將
> 其放置在提交標記上方，則需要手動交互才能將其刪除。如果它位於分隔線以下，則在
> -應用補丁時會自動剝離::
> +應用補丁時會自動剝離。如果可以，建議附上指向該補丁先前版本的連結（例如
> +lore.kernel.org存檔連結），以幫助審閱者::
>
> <commit message>
> ...
> @@ -545,29 +650,14 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
> V2 -> V3: Removed redundant helper function
> V1 -> V2: Cleaned up coding style and addressed review comments
>
> + v2: https://lore.kernel.org/bar
> + v1: https://lore.kernel.org/foo
> +
> path/to/file | 5+++--
> ...
>
> 在後面的參考資料中能看到正確補丁格式的更多細節。
>
> -.. _tw_backtraces:
> -
> -提交消息中的回溯（Backtraces）
> -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> -
> -回溯有助於記錄導致問題的調用鏈。然而，並非所有回溯都有幫助。例如，早期引導調
> -用鏈是獨特而明顯的。而逐字複製完整的dmesg輸出則會增加時間戳、模塊列表、寄存
> -器和堆棧轉儲等分散注意力的信息。
> -
> -因此，最有用的回溯應該從轉儲中提取相關信息，以更容易集中在真實問題上。下面是
> -一個剪裁良好的回溯示例::
> -
> - unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064)
> - at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
> - Call Trace:
> - mba_wrmsr
> - update_domains
> - rdtgroup_mkdir
>
> .. _tw_explicit_in_reply_to:
>
> @@ -575,21 +665,21 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
> -----------------------------
>
> 手動添加回復補丁的的郵件頭（In-Reply_To:）是有用的（例如，使用 ``git send-email`` ），
> -可以將補丁與以前的相關討論關聯起來，例如，將bug補丁鏈接到電子郵件和bug報告。
> -但是，對於多補丁系列，最好避免在回覆時使用鏈接到該系列的舊版本。這樣，
> -補丁的多個版本就不會成爲電子郵件客戶端中無法管理的引用樹。如果鏈接有用，
> -可以使用 https://lore.kernel.org/ 重定向器（例如，在封面電子郵件文本中）
> -鏈接到補丁系列的早期版本。
> +可以將補丁與以前的相關討論關聯起來，例如，將bug補丁連結到電子郵件和bug報告。
> +但是，對於多補丁系列，最好避免在回覆時使用連結到該系列的舊版本。這樣，
> +補丁的多個版本就不會成為電子郵件客戶端中無法管理的引用樹。如果連結有用，
> +可以使用 https://lore.kernel.org/ 重定向器（例如，在封面電子郵件文字中）
> +連結到補丁系列的早期版本。
>
> -給出基礎樹信息
> +給出基礎樹資訊
> --------------
>
> -當其他開發人員收到您的補丁並開始審閱時，知道應該將您的工作放到代碼樹歷史記錄
> -中的什麼位置通常很有用。這對於自動化持續集成流水（CI）特別有用，這些流水線試
> -圖運行一系列測試，以便在維護人員開始審閱之前確定提交的質量。
> +當其他開發人員收到您的補丁並開始審閱時，知道應該將您的工作放到程式碼樹歷史記錄
> +中的什麼位置通常很有用。這對於自動化持續整合流水（CI）特別有用，這些流水線試
> +圖執行一系列測試，以便在維護人員開始審閱之前確定提交的品質。
>
> -如果您使用 ``git format-patch`` 生成補丁，則可以通過 ``--base`` 標誌在提交中
> -自動包含基礎樹信息。使用此選項最簡單、最方便的方法是配合主題分支::
> +如果您使用 ``git format-patch`` 產生補丁，則可以透過 ``--base`` 標誌在提交中
> +自動包含基礎樹資訊。使用此選項最簡單、最方便的方法是配合主題分支::
>
> $ git checkout -t -b my-topical-branch master
> Branch 'my-topical-branch' set up to track local branch 'master'.
> @@ -603,7 +693,7 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
> outgoing/...
>
> 當你編輯 ``outgoing/0000-cover-letter.patch`` 時，您會注意到在它的最底部有一
> -行 ``base-commit:`` 尾註，它爲審閱者和CI工具提供了足夠的信息以正確執行
> +行 ``base-commit:`` 尾註，它為審閱者和CI工具提供了足夠的資訊以正確執行
> ``git am`` 而不必擔心衝突::
>
> $ git checkout -b patch-review [base-commit-id]
> @@ -612,7 +702,7 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
> Applying: First Commit
> Applying: ...
>
> -有關此選項的更多信息，請參閱 ``man git-format-patch`` 。
> +有關此選項的更多資訊，請參閱 ``man git-format-patch`` 。
>
> .. note::
>
> @@ -622,16 +712,23 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
> 的工作所基於的樹的提交哈希。你應該在封面郵件或系列的第一個補丁中添加它，它應
> 該放在 ``---`` 行的下面或所有其他內容之後，即只在你的電子郵件簽名之前。
>
> +工具
> +----
> +
> +此流程的許多技術層面都可以使用b4自動化，其說明文件見
> +<https://b4.docs.kernel.org/en/latest/>。它可以幫助追蹤依賴關係、執行
> +checkpatch，以及格式化和發送郵件。
> +
> 參考文獻
> --------
>
> Andrew Morton，“完美的補丁”（tpp）
> <https://www.ozlabs.org/~akpm/stuff/tpp.txt>
>
> -Jeff Garzik，“Linux內核補丁提交格式”
> +Jeff Garzik，“Linux核心補丁提交格式”
> <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
>
> -Greg Kroah-Hartman，“如何惹惱內核子系統維護人員”
> +Greg Kroah-Hartman，“如何惹惱核心子系統維護人員”
> <http://www.kroah.com/log/linux/maintainer.html>
>
> <http://www.kroah.com/log/linux/maintainer-02.html>
> @@ -644,10 +741,7 @@ Greg Kroah-Hartman，“如何惹惱內核子系統維護人員”
>
> <http://www.kroah.com/log/linux/maintainer-06.html>
>
> -不！！！別再發巨型補丁炸彈給linux-kernel@vger.kernel.org的人們了！
> - <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net>
> -
> -內核 Documentation/translations/zh_CN/process/coding-style.rst
> +核心 Documentation/translations/zh_TW/process/coding-style.rst
>
> Linus Torvalds關於標準補丁格式的郵件
> <https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v3 14/16] docs/zh_TW: process: localize terminology in 8.Conclusion.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (12 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 13/16] docs/zh_TW: process: localize terminology in submitting-patches.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-06 18:19 ` [PATCH v3 15/16] docs/zh_TW: process: localize terminology in index.rst Chen-Yu Yeh
` (2 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 代碼→程式碼,
軟件→軟體, ...), normalize character conventions (爲→為, 裏→裡, 啓→啟,
發佈→發布) to match the zh_TW glossary, fix the zh_CN cross-references
to zh_TW, and rephrase a few sentences for fluency.
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Reviewed-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../zh_TW/process/8.Conclusion.rst | 58 ++++++++++---------
1 file changed, 30 insertions(+), 28 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst
index d1634421b62c..8f9b4ec6845f 100644
--- a/Documentation/translations/zh_TW/process/8.Conclusion.rst
+++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst
@@ -11,45 +11,46 @@
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
.. _tw_development_conclusion:
-更多信息
+更多資訊
========
-關於Linux內核開發和相關主題的信息來源很多。首先是在內核源代碼分發中找到的
-文檔目錄。頂級
-:ref:`Documentation/translations/zh_CN/process/howto.rst <tw_process_howto>`
+關於Linux核心開發和相關主題的資訊來源很多。首先是在核心原始碼分發中找到的
+文件目錄。頂級
+:ref:`Documentation/translations/zh_TW/process/howto.rst <tw_process_howto>`
文件是一個重要的起點；
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
-也是所有內核開發人員都應該閱讀的內容。許多內部內核API都是使用kerneldoc機制
-記錄的；“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式生成這些文檔
-（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文檔）。
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+也是所有核心開發人員都應該閱讀的內容。許多內部核心API都是使用kerneldoc機制
+記錄的；“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式產生這些文件
+（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文件）。
-不同的網站在各個細節層次上討論內核開發。本文作者想謙虛地建議用 https://lwn.net/
-作爲來源；有關許多特定內核主題的信息可以通過以下網址的 LWN 內核索引找到：
+不同的網站在各個細節層次上討論核心開發。本文作者想謙虛地建議用 https://lwn.net/
+作為來源；有關許多特定核心主題的資訊可以透過以下網址的 LWN 核心索引找到：
- http://lwn.net/kernel/index/
+ https://lwn.net/Kernel/Index/
-除此之外，內核開發人員的一個寶貴資源是：
+除此之外，核心開發人員的一個寶貴資源是：
https://kernelnewbies.org/
-當然，也不應該忘記 https://kernel.org/ ，這是內核發佈信息的最終位置。
+當然，也不應該忘記 https://kernel.org/ ，這是核心發布資訊的最終位置。
-關於內核開發有很多書：
+關於核心開發有很多書：
- 《Linux設備驅動程序》第三版（Jonathan Corbet、Alessandro Rubini和Greg Kroah Hartman）
- 線上版本在 http://lwn.net/kernel/ldd3/
+ 《Linux設備驅動程序》第三版（Jonathan Corbet、Alessandro Rubini和Greg Kroah-Hartman）
+ 線上版本在 https://lwn.net/Kernel/LDD3/
- 《Linux內核設計與實現》（Robert Love）
+ 《Linux核心設計與實現》（Robert Love）
- 《深入理解Linux內核》(Daniel Bovet和Marco Cesati）
+ 《深入理解Linux核心》(Daniel Bovet和Marco Cesati）
然而，所有這些書都有一個共同的缺點：它們上架時就往往有些過時，而且已經上架
-一段時間了。不過，在那裏還是可以找到相當多的好信息。
+一段時間了。不過，在那裡還是可以找到相當多的好資訊。
-有關git的文檔，請訪問：
+有關git的文件，請造訪：
https://www.kernel.org/pub/software/scm/git/docs/
@@ -58,16 +59,17 @@
結論
====
-祝賀所有通過這篇冗長的文檔的人。希望它能夠幫助您理解Linux內核是如何開發的，
+祝賀所有通過這篇冗長的文件的人。希望它能夠幫助您理解Linux核心是如何開發的，
以及您如何參與這個過程。
-最後，重要的是參與。任何開源軟件項目都不會超過其貢獻者投入其中的總和。Linux
-內核的發展速度和以前一樣快，因爲它得到了大量開發人員的幫助，他們都在努力使它
-變得更好。內核是一個最成功的例子，說明了當成千上萬的人爲了一個共同的目標一起
+最後，重要的是參與。任何開源軟體專案都不會超過其貢獻者投入其中的總和。Linux
+核心的發展速度和以前一樣快，因為它得到了大量開發人員的幫助，他們都在努力使它
+變得更好。核心是一個最成功的例子，說明了當成千上萬的人為了一個共同的目標一起
工作時，可以做出什麼。
-不過，內核總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣
-重要的是，Linux生態系統中的大多數其他參與者可以通過爲內核做出貢獻而受益。使
-代碼進入主線是提高代碼質量、降低維護和分發成本、提高對內核開發方向的影響程度
-等的關鍵。這是一種共贏的局面。啓動你的編輯器，來加入我們吧；你會非常受歡迎的。
+不過，核心總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣
+重要的是，Linux生態系統中的大多數其他參與者可以透過為核心做出貢獻而受益。
+使程式碼進入主線是提高程式碼品質、降低維護和分發成本、提高對核心開發方向的
+影響程度等的關鍵。這是一種共贏的局面。啟動你的編輯器，來加入我們吧；你會非
+常受歡迎的。
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 15/16] docs/zh_TW: process: localize terminology in index.rst
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (13 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 14/16] docs/zh_TW: process: localize terminology in 8.Conclusion.rst Chen-Yu Yeh
@ 2026-08-06 18:19 ` Chen-Yu Yeh
2026-08-07 5:53 ` [PATCH v3 16/16] docs/zh_TW: Add a glossary for Traditional Chinese translations Chen-Yu Yeh
[not found] ` <de2ddee4-7907-42bc-bc2f-af9f6d5bb613@hust.edu.cn>
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-06 18:19 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Localize mainland terms to Taiwanese Mandarin (內核→核心, 社區→社群,
文檔→文件, ...) and sync with the reworked English process index:
mirror the new section layout (introduction, tools and technical
guides, policy guides, dealing with bugs, maintainer information,
other material), keep only existing zh_TW translations in the
toctrees, and track the still-untranslated documents in TODO lists
following the zh_CN convention.
update to commit a03ef333fbd6 ("Documentation: security-bugs: explain
what is and is not a security bug")
Acked-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
.../translations/zh_TW/process/index.rst | 99 ++++++++++++++++---
1 file changed, 83 insertions(+), 16 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/index.rst b/Documentation/translations/zh_TW/process/index.rst
index 65922d9faa20..3f84437a2ca9 100644
--- a/Documentation/translations/zh_TW/process/index.rst
+++ b/Documentation/translations/zh_TW/process/index.rst
@@ -10,53 +10,121 @@
:Original: :ref:`Documentation/process/index.rst <process_index>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
+ Chen-Yu Yeh <chenyou910331@gmail.com>
.. _tw_process_index:
========================
-與Linux 內核社區一起工作
+與Linux核心社群一起工作
========================
-你想成爲Linux內核開發人員嗎？歡迎之至！在學習許多關於內核的技術知識的同時，
-瞭解我們社區的工作方式也很重要。閱讀這些文檔可以讓您以更輕鬆的、麻煩更少的
-方式將更改合併到內核。
+你想成為Linux核心開發人員嗎？歡迎之至！在學習許多關於核心的技術知識的同時，
+瞭解我們社群的工作方式也很重要。閱讀這些文件可以讓您以更輕鬆的、麻煩更少的
+方式將更改合併到核心。
-以下是每位開發人員都應閱讀的基本指南：
+核心開發如何運作的介紹
+----------------------
+
+請先閱讀這些文件：理解這裡的內容將使你更順利地進入核心社群。
.. toctree::
:maxdepth: 1
howto
- code-of-conduct
- code-of-conduct-interpretation
+ development-process
submitting-patches
+ submit-checklist
+
+核心開發者的工具與技術指南
+--------------------------
+
+這是核心開發者應該熟悉的材料集合。
+
+.. toctree::
+ :maxdepth: 1
+
programming-language
coding-style
- development-process
email-clients
- license-rules
- kernel-enforcement-statement
- kernel-driver-statement
+ volatile-considered-harmful
+
+TODOList:
-其它大多數開發人員感興趣的社區指南：
+* changes
+* maintainer-pgp-guide
+* applying-patches
+* backporting
+* adding-syscalls
+* botching-up-ioctls
+政策指南與開發者聲明
+--------------------
+
+這些是我們在核心社群（以及更廣範圍）中努力遵循的規則。
.. toctree::
:maxdepth: 1
- submit-checklist
+ license-rules
+ code-of-conduct
+ code-of-conduct-interpretation
+ kernel-enforcement-statement
+ kernel-driver-statement
stable-api-nonsense
stable-kernel-rules
management-style
+
+TODOList:
+
+* contribution-maturity-model
+* researcher-guidelines
+* generated-content
+* coding-assistants
+* conclave
+
+處理缺陷
+--------
+
+缺陷是無法避免的；正確地處理它們非常重要。下面的文件提供了關於除錯的一般
+建議，並描述了我們處理幾類特殊缺陷——迴歸和安全問題——的政策。
+
+.. toctree::
+ :maxdepth: 1
+
embargoed-hardware-issues
-這些是一些總體性技術指南，由於不大好分類而放在這裏：
+TODOList:
+
+* debugging/index
+* handling-regressions
+* security-bugs
+* threat-model
+* cve
+
+維護者資訊
+----------
+
+如何找到會接受你補丁的人。
+
+TODOList:
+
+* maintainer-handbooks
+* maintainers
+
+其他材料
+--------
+
+這裡是一些大多數開發者會感興趣的其他社群指南：
.. toctree::
:maxdepth: 1
magic-number
- volatile-considered-harmful
+
+TODOList:
+
+* kernel-docs
+* deprecated
.. only:: subproject and html
@@ -64,4 +132,3 @@
====
* :ref:`genindex`
-
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v3 16/16] docs/zh_TW: Add a glossary for Traditional Chinese translations
2026-08-06 18:19 [PATCH v3 00/16] docs/zh_TW: localize terminology and sync process/ documents Chen-Yu Yeh
` (14 preceding siblings ...)
2026-08-06 18:19 ` [PATCH v3 15/16] docs/zh_TW: process: localize terminology in index.rst Chen-Yu Yeh
@ 2026-08-07 5:53 ` Chen-Yu Yeh
[not found] ` <de2ddee4-7907-42bc-bc2f-af9f6d5bb613@hust.edu.cn>
16 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Yeh @ 2026-08-07 5:53 UTC (permalink / raw)
To: Jonathan Corbet, Alex Shi
Cc: Dongliang Mu, Yanteng Si, Weijie Yuan, Hu Haowen, linux-doc,
linux-kernel, Chen-Yu Yeh
Add Documentation/translations/zh_TW/glossary.rst documenting the
Taiwanese Mandarin terminology used by the zh_TW translations, with the
corresponding zh_CN terms for cross reference, the character conventions
(為/裡/著/才/啟/只/發布), and the convention of not putting a space
between CJK and ASCII, which is what the existing zh_TW tree
predominantly does. Hook it into the zh_TW index, replacing the
existing TODO entry.
The zh_CN column is a cross-reference only; every term in it was checked
against the actual usage in Documentation/translations/zh_CN/ rather
than taken from an external glossary.
This is the reference used by the terminology localization of the zh_TW
process/ documents in this series.
Acked-by: Weijie Yuan <wy@wyuan.org>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
Documentation/translations/zh_TW/glossary.rst | 168 ++++++++++++++++++
Documentation/translations/zh_TW/index.rst | 5 +-
2 files changed, 171 insertions(+), 2 deletions(-)
create mode 100644 Documentation/translations/zh_TW/glossary.rst
diff --git a/Documentation/translations/zh_TW/glossary.rst b/Documentation/translations/zh_TW/glossary.rst
new file mode 100644
index 000000000000..15ed1be54416
--- /dev/null
+++ b/Documentation/translations/zh_TW/glossary.rst
@@ -0,0 +1,168 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _tw_glossary:
+
+術語表
+======
+
+:作者: 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
+
+本術語表列出Linux核心繁體中文（zh_TW）翻譯所使用的術語。zh_TW翻譯以臺灣
+慣用的資訊術語為準。新增或更新翻譯時，請依照本表選擇用詞，以維持整個
+zh_TW文件樹的一致性；若遇到本表未收錄的術語，歡迎提交補丁補充。
+
+下表同時列出常見的簡體中文（zh_CN）譯法，方便從zh_CN翻譯轉換或對照時
+使用。本表的zh_CN欄位為對照參考，其用詞經核對核心文件樹zh_CN譯文中的
+實際用法，非引用外部術語表。
+
+一般術語
+--------
+
+======================== ========================== ====================
+英文 zh_TW zh_CN（對照）
+======================== ========================== ====================
+kernel 核心 内核
+user / user space 使用者／使用者空間 用户／用户空间
+software / hardware 軟體／硬體 软件／硬件
+firmware 韌體 固件
+operating system 作業系統 操作系统
+distribution 發行版 发行版
+community 社群 社区
+project 專案 项目
+documentation 文件 文档
+file 檔案 文件
+folder / directory 資料夾／目錄 文件夹／目录
+default 預設 默认／缺省
+support 支援 支持
+information 資訊 信息
+message 訊息 消息
+data 資料 数据
+quality 品質 质量
+performance 效能 性能
+network 網路 网络
+the Internet 網際網路 因特网
+server 伺服器 服务器
+digital 數位 数字
+computer 電腦 计算机
+integrate 整合 集成
+create 建立 创建
+access 存取 访问
+via / through 透過 通过
+======================== ========================== ====================
+
+程式設計術語
+------------
+
+======================== ========================== ====================
+英文 zh_TW zh_CN（對照）
+======================== ========================== ====================
+source code 原始程式碼／原始碼 源代码
+code 程式碼 代码
+program 程式 程序
+process 行程 进程
+thread 執行緒 线程
+scheduler / schedule 排程器／排程 调度器／调度
+queue 佇列 队列
+memory 記憶體 内存
+cache 快取 缓存
+interface 介面 接口
+port 埠 端口
+register 暫存器 寄存器
+stack 堆疊 堆栈
+function 函式 函数
+function call 呼叫 调用
+callback 回呼 回调
+return value 回傳值 返回值
+macro 巨集 宏
+enum 列舉 枚举
+variable 變數 变量
+pointer 指標 指针
+array 陣列 数组
+linked list 鏈結串列 链表
+loop 迴圈 循环
+declaration 宣告 声明
+identifier 識別字 标识符
+character / string 字元／字串 字符／字符串
+byte 位元組 字节
+boolean 布林 布尔
+binary 二進位 二进制
+object 物件 对象
+type 型別／類型 类型
+module 模組 模块
+component 元件 组件
+build 建置 构建
+compile / assembler 編譯／組譯器 编译／汇编器
+debug 除錯 调试
+optimize 最佳化 优化
+implement 實作 实现
+global / local 全域／區域 全局／局部
+constant 常數 常量
+comment (in code) 註解 注释
+indentation 縮排 缩进
+inline 行內 内联
+generate 產生 生成
+load / loader 載入／載入器 加载／加载器
+export / import 匯出／匯入 导出／导入
+link / linker 連結／連結器 链接／链接器
+repository 儲存庫 存储库／仓库
+distributed 分散式 分布式
+header file 標頭檔 头文件
+configuration file 設定檔 配置文件
+file system 檔案系統 文件系统
+settings / configuration 設定 设置／配置
+======================== ========================== ====================
+
+介面與其他術語
+--------------
+
+======================== ========================== ====================
+英文 zh_TW zh_CN（對照）
+======================== ========================== ====================
+menu 選單 菜单
+window 視窗 窗口
+toolbar 工具列 工具栏
+field 欄位 字段
+icon 圖示 图标
+mouse / cursor 滑鼠／游標 鼠标／光标
+paste 貼上 粘贴
+print / printer 列印／印表機 打印／打印机
+disk (hard disk) 磁碟（硬碟） 磁盘（硬盘）
+text / plain text 文字／純文字 文本／纯文本
+mailbox 信箱 邮箱
+account 帳戶／帳號 帐户
+tracking 追蹤 跟踪
+advanced 進階 高级
+free software 自由軟體 自由软件／免费软件
+======================== ========================== ====================
+
+特定用語說明
+------------
+
+- **access 與 visit**：access（資料、記憶體、資源的存取）譯為「存取」；
+ visit（造訪網站、頁面或連結）譯為「造訪」。兩者在 zh_CN 皆作「訪問」，
+ zh_TW 依語意區分。
+
+- **Fellow**：現有翻譯將 Linux Foundation Fellow 譯為「院士」。「院士」在
+ 臺灣多指中央研究院等學術機構的頭銜，「研究員」也不完全對等，實務上亦常
+ 直接保留英文。此譯法尚在討論中，暫維持現有譯法，待社群取得共識後再統一。
+
+- **mailing list**：譯為「郵件列表」（zh_CN 亦作「邮件列表」）。
+
+- **-stable 與穩定版**：核心的 ``-stable`` 樹保留英文原名 ``-stable``；泛指
+ 時譯為「穩定版核心」。既有翻譯中「穩定版」與 ``-stable`` 混用者不強制
+ 統一，新增或更新的翻譯請套用此慣例。
+
+用字慣例
+--------
+
+除術語之外，zh_TW翻譯採用臺灣標準用字，例如「為」（不用「爲」）、「裡」
+（不用「裏」）、「著」（不用「着」）、「才」（不用「纔」）、「啟」（不用
+「啓」）、「只」（不用「隻」）與「發布」（不用「發佈」）。
+
+標點符號沿用現有文件樹的全形標點。每行寬度沿用原文慣例（每行約75個半形
+字元寬）。
+
+中文與英文、數字相鄰時不加空格，例如「Linux核心」而非「Linux 核心」；此為
+現有zh_TW文件樹的主要慣例。本規則適用於新增的翻譯與改寫過的段落，既有檔案
+不另行回頭修改。行內標記（``literal``、:ref: 等）前後仍依reStructuredText
+的需要保留必要的空白。
diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst
index 660a74d2023c..95809012a9ef 100644
--- a/Documentation/translations/zh_TW/index.rst
+++ b/Documentation/translations/zh_TW/index.rst
@@ -119,9 +119,10 @@ TODOList:
術語表
------
-TODOList:
+.. toctree::
+ :maxdepth: 1
-* glossary
+ glossary
索引和表格
--
2.43.0
^ permalink raw reply related [flat|nested] 20+ messages in thread[parent not found: <de2ddee4-7907-42bc-bc2f-af9f6d5bb613@hust.edu.cn>]