[PATCH 00/25] docs/zh_TW: process: resync translations with the English originals

[PATCH 00/25] docs/zh_TW: process: resync translations with the English originals

[Chen-Yu Yeh]

This series brings 25 of the zh_TW process/ translations back in line
with their current English originals.

The "update to commit" markers in these files cannot be trusted.  While
preparing the earlier process/ terminology series I found translations
whose marker named a recent commit while the text still followed a much
older revision, so every English change in between had never been
translated.  checktransupdate.py takes the marker at its word and cannot
catch this.  Each file was therefore compared section by section against
the full current English text, not just the diff since the marker.  Each
commit message lists what was added or removed, and the marker is reset
to the latest substantive English commit.

Mistranslations found along the way are fixed in the same patch, and
leftover mainland Chinese terms in the touched text are localized.

Not in this series, to keep these diffs reviewable:

 - Whole-file terminology unification (e.g. 補丁 -> 修補程式,
   許可證 -> 授權條款, quotation marks -> 「」) together with an update
   of glossary.rst.  This will follow as a separate series, so some
   files still mix old and new terms for now.
 - programming-language.rst, whose current marker points at a merge
   commit; it will be resynced after 7.4-rc1.

checkpatch reports "Unrecognized email address" for some lines in
2.Process.rst and submitting-patches.rst.  These lines describe tags
such as Cc: and Acked-by: and trigger the same warnings in the English
originals.

The series is based on the docs-next branch of
https://github.com/kernel-zh/linux-zh_TW.

Chen-Yu Yeh (25):
  docs/zh_TW: process: sync 1.Intro.rst with the English original
  docs/zh_TW: process: sync 2.Process.rst with the English original
  docs/zh_TW: process: sync 4.Coding.rst with the English original
  docs/zh_TW: process: sync 5.Posting.rst with the English original
  docs/zh_TW: process: sync 6.Followthrough.rst with the English
    original
  docs/zh_TW: process: sync 7.AdvancedTopics.rst with the English
    original
  docs/zh_TW: process: sync 8.Conclusion.rst with the English original
  docs/zh_TW: process: sync code-of-conduct-interpretation.rst with the
    English original
  docs/zh_TW: process: sync code-of-conduct.rst with the English
    original
  docs/zh_TW: process: sync gdb-kernel-debugging.rst with the English
    original
  docs/zh_TW: process: sync development-process.rst with the English
    original
  docs/zh_TW: process: sync email-clients.rst with the English original
  docs/zh_TW: process: sync kernel-driver-statement.rst with the English
    original
  docs/zh_TW: process: sync kernel-enforcement-statement.rst with the
    English original
  docs/zh_TW: process: sync management-style.rst with the English
    original
  docs/zh_TW: process: sync security-bugs.rst with the English original
  docs/zh_TW: process: sync volatile-considered-harmful.rst with the
    English original
  docs/zh_TW: process: sync 3.Early-stage.rst with the English original
  docs/zh_TW: process: sync coding-style.rst with the English original
  docs/zh_TW: process: sync embargoed-hardware-issues.rst with the
    English original
  docs/zh_TW: process: sync howto.rst with the English original
  docs/zh_TW: process: sync license-rules.rst with the English original
  docs/zh_TW: process: sync stable-api-nonsense.rst with the English
    original
  docs/zh_TW: process: sync submit-checklist.rst with the English
    original
  docs/zh_TW: process: sync submitting-patches.rst with the English
    original

 .../translations/zh_TW/process/1.Intro.rst    |  16 +-
 .../translations/zh_TW/process/2.Process.rst  | 176 ++++----
 .../zh_TW/process/3.Early-stage.rst           | 192 ++++----
 .../translations/zh_TW/process/4.Coding.rst   | 414 +++++++++---------
 .../translations/zh_TW/process/5.Posting.rst  | 141 +++---
 .../zh_TW/process/6.Followthrough.rst         | 247 ++++++-----
 .../zh_TW/process/7.AdvancedTopics.rst        |  53 ++-
 .../zh_TW/process/8.Conclusion.rst            |  27 +-
 .../code-of-conduct-interpretation.rst        |  16 +-
 .../zh_TW/process/code-of-conduct.rst         |  54 +--
 .../zh_TW/process/coding-style.rst            | 286 +++++++-----
 .../debugging/gdb-kernel-debugging.rst        | 104 +++--
 .../zh_TW/process/development-process.rst     |  12 +-
 .../zh_TW/process/email-clients.rst           |  78 ++--
 .../process/embargoed-hardware-issues.rst     |  51 +--
 .../translations/zh_TW/process/howto.rst      | 182 ++++----
 .../zh_TW/process/kernel-driver-statement.rst |  24 +-
 .../process/kernel-enforcement-statement.rst  |  59 +--
 .../zh_TW/process/license-rules.rst           |  86 +++-
 .../zh_TW/process/management-style.rst        | 294 +++++++------
 .../zh_TW/process/security-bugs.rst           | 296 +++++++++++--
 .../zh_TW/process/stable-api-nonsense.rst     | 243 +++++-----
 .../zh_TW/process/submit-checklist.rst        | 159 ++++---
 .../zh_TW/process/submitting-patches.rst      | 338 ++++++++------
 .../process/volatile-considered-harmful.rst   | 115 ++---
 25 files changed, 2109 insertions(+), 1554 deletions(-)

-- 
2.43.0

[PATCH 01/25] docs/zh_TW: process: sync 1.Intro.rst with the English original

[Chen-Yu Yeh]

Re-check the whole translation against the current English text.  The
only English change since the last sync,
commit 4a0be1a25d98 ("Documentation: process: Capitalize Git, Quilt, and
Mercurial consistently"), capitalizes "Git", which the translation
already does.

While at it, fix a few translation errors:

 - "language" in "with, optionally, language allowing distribution
   under later versions of the GPL" means license wording, not a
   (natural) language; translate it as 條文.
 - "false economy" was translated literally as 在經濟上是錯誤的;
   use 因小失大 to convey the idiom.
 - Restructure the broken sentence about code that cannot be
   contributed.
 - Add the missing "too" (也) in the embedded systems paragraph.

update to commit 4a0be1a25d98 ("Documentation: process: Capitalize
Git, Quilt, and Mercurial consistently")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../translations/zh_TW/process/1.Intro.rst       | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/1.Intro.rst b/Documentation/translations/zh_TW/process/1.Intro.rst
index 65c5ae095504..d246de92bec9 100644
--- a/Documentation/translations/zh_TW/process/1.Intro.rst
+++ b/Documentation/translations/zh_TW/process/1.Intro.rst
@@ -95,8 +95,8 @@ Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。
 有些公司和開發人員偶爾會想，為什麼他們要費心學習如何與核心社群合作，並將程
 式碼放入主線核心（“主線”是由Linus Torvalds維護的核心，Linux發行商將其用作
 基礎）。在短期內，貢獻程式碼看起來像是一種可以避免的開銷；維護獨立程式碼並
-直接支援使用者似乎更容易。事實上，保持程式碼獨立（“樹外”）是在經濟上是錯誤
-的。
+直接支援使用者似乎更容易。事實上，保持程式碼獨立（「樹外」）看似省事，其實是
+因小失大。
 
 為了說明樹外程式碼成本，下面給出核心開發過程的一些相關方面；本文稍後將更詳細地
 討論其中的大部分內容。請考慮：
@@ -161,15 +161,15 @@ Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。
 尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因為他們
 相信自己正在商用一種使用凍結核心版本的獨立產品，在發布後不需要再進行開發。
 這個論點忽略了廣泛的程式碼審查的價值以及允許使用者向產品添加功能的價值。但這些
-產品的商業壽命有限，之後必須發布新版本的產品。在這一點上，程式碼在主線上並得到
-良好維護的供應商將能夠更好地佔位，以使新產品快速上市。
+產品的商業壽命也是有限的，之後必須發布新版本的產品。在這一點上，程式碼在主線
+上並得到良好維護的供應商將能夠更好地佔位，以使新產品快速上市。
 
 許可
 ----
 
 程式碼是根據一些許可證提供給Linux核心的，但是所有程式碼都必須與GNU通用公共許可
 證（GPLv2）的版本2相容，該版本是覆蓋整個核心分發的許可證。在實踐中，這意味
-著所有程式碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD
+著所有程式碼貢獻都由GPLv2（可選地附帶允許在更高版本的GPL下分發的條文）或3子句BSD
 許可（New BSD License，譯者注）覆蓋。任何不包含在相容許可證中的貢獻都不會
 被接受到核心中。
 
@@ -182,9 +182,9 @@ Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。
 
 所有貢獻給核心的程式碼都必須是合法的自由軟體。因此，不接受身分不明或匿名的
 貢獻者的程式碼。所有貢獻者都需要在他們的程式碼上“sign off（簽發）”，聲明程
-式碼可以在GPL下與核心一起分發。無法提供未被其所有者許可為自由軟體的程式碼，
-或可能為核心造成版權相關問題的程式碼（例如，由缺乏適當保護的反向工程工作派
-生的程式碼）不能被接受。
+式碼可以在GPL下與核心一起分發。未被其所有者許可為自由軟體的程式碼，或可能
+為核心造成版權相關問題的程式碼（例如，由缺乏適當保護的反向工程工作派生的程
+式碼）都不能被貢獻。
 
 有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答
 案，但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於
-- 
2.43.0

[PATCH 02/25] docs/zh_TW: process: sync 2.Process.rst with the English original

[Chen-Yu Yeh]

The last update claimed to follow commit 46298375477b ("linux-next:
update maintainer info."), but a section-by-section comparison against
the current English text shows it never picked up several earlier and
later changes.  Bring it in line with the full current original:

- add the missing sentence that no upcoming release has known plans
  for long-term support
- rewrite the top-posting hint to recommend interleaved replies and
  link to the corresponding section of submitting-patches.rst
- capitalize Git and Quilt consistently, and replace "他或她" with a
  gender-neutral wording
- fix the 5.2.1 date in the 5.2 table, the Mercurial and Quilt URLs,
  the LWN URL and the drivers/staging/ path
- keep Andrew Morton's quote verbatim in its literal block and add the
  translation after it
- retranslate sentences whose meaning had drifted (delaying the final
  release, "when the process works", the TODO file, distributors, how
  well the process works without tools, bringing in-house developers up
  to speed, linux-next as an expected snapshot)
- fix leftover mainland terms and conversion artifacts (內核, 視頻,
  搜索, 回復, 被髮布, 一箇)
- expand tabs in the tables and literal blocks

update to commit fdd100ee60a0 ("docs: process: use gender-neutral
pronouns")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../translations/zh_TW/process/2.Process.rst  | 176 +++++++++---------
 1 file changed, 93 insertions(+), 83 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/2.Process.rst b/Documentation/translations/zh_TW/process/2.Process.rst
index cf9bd1b1444a..72a0cc1f7652 100644
--- a/Documentation/translations/zh_TW/process/2.Process.rst
+++ b/Documentation/translations/zh_TW/process/2.Process.rst
@@ -29,8 +29,8 @@ Linux核心使用一種鬆散的、基於時間的滾動發布開發模式。每
        認為足夠大時才會遞增9（例如，Linux 5.0是繼Linux 4.20之後發布的）。
 
 對於每個版本的補丁合併，遵循一個相對簡單的規則。在每個開發週期的開頭，“合併
-視窗”被開啟。這時，被認為足夠穩定（並且被開發社群接受）的程式碼被合併到主線內
-核中。在這段時間內，新開發週期的大部分變更（以及所有主要變更）將以接近每天
+視窗”被開啟。這時，被認為足夠穩定（並且被開發社群接受）的程式碼被合併到主線核
+心中。在這段時間內，新開發週期的大部分變更（以及所有主要變更）將以接近每天
 1000次變更（“補丁”或“變更集”）的速度合併。
 
 （順便說一句，值得注意的是，合併視窗期間整合的更改並不是憑空產生的；它們是經
@@ -41,7 +41,7 @@ Linux核心使用一種鬆散的、基於時間的滾動發布開發模式。每
 將被稱為9.x-rc1。-rc1 版本是一個信號，表示合併新特性的時間已經過去，穩定下一
 個核心的時間已經到來。
 
-在接下來的6到10周內，只有修復問題的補丁才應該提交給主線。有時會允許更大的
+在接下來的6到10週內，只有修復問題的補丁才應該提交給主線。有時會允許更大的
 更改，但這種情況很少發生；試圖在合併視窗外合併新功能的開發人員往往受不到
 友好的接待。一般來說，如果您錯過了給定特性的合併視窗，最好的做法是等待下一
 個開發週期。（偶爾會對未支援硬體的驅動程式進行例外；如果它們不改變已有程式碼，
@@ -53,60 +53,63 @@ Linux核心使用一種鬆散的、基於時間的滾動發布開發模式。每
 
 例如，這裡是5.4的開發週期進行情況（2019年）:
 
-	==============  ==============================
-	九月 15         5.3 穩定版發布
-	九月 30         5.4-rc1 合併視窗關閉
-	十月 6          5.4-rc2
-	十月 13         5.4-rc3
-	十月 20         5.4-rc4
-	十月 27         5.4-rc5
-	十一月 3        5.4-rc6
-	十一月 10       5.4-rc7
-	十一月 17       5.4-rc8
-	十一月 24       5.4 穩定版發布
-	==============  ==============================
+        ==============  ===============================
+        九月 15         5.3 穩定版發布
+        九月 30         5.4-rc1 合併視窗關閉
+        十月 6          5.4-rc2
+        十月 13         5.4-rc3
+        十月 20         5.4-rc4
+        十月 27         5.4-rc5
+        十一月 3        5.4-rc6
+        十一月 10       5.4-rc7
+        十一月 17       5.4-rc8
+        十一月 24       5.4 穩定版發布
+        ==============  ===============================
 
 開發人員如何決定何時結束開發週期並建立穩定版本？最重要的指標是以前版本的
 迴歸列表。不歡迎出現任何錯誤，但是那些破壞了以前能工作的系統的錯誤被認為是
 特別嚴重的。因此，導致迴歸的補丁是不受歡迎的，很可能在穩定期內刪除。
 
 開發人員的目標是在穩定發布之前修復所有已知的迴歸。在現實世界中，這種完美是
-很難實作的；在這種規模的專案中，變數太多了。需要說明的是，延遲最終版本只會
+很難實作的；在這種規模的專案中，變數太多了。到了某個時候，再延遲最終版本只會
 使問題變得更糟；等待下一個合併視窗的更改將變多，導致下次出現更多的迴歸錯誤。
 因此，大多數核心版本都有一些已知的迴歸錯誤，不過，希望沒有一個是嚴重的。
 
 一旦一個穩定的版本發布，它的持續維護工作就被移交給“穩定團隊”，目前由Greg
 Kroah-Hartman和Sasha Levin組成。穩定團隊將使用9.x.y編號方案不定期地發布穩
-定版本的更新。要合入更新版本，補丁必須（1）修復一個重要的缺陷，且（2）已經
-合併到下一個開發版本主線中。核心通常會在其初始版本後的一個以上的開發週期內
-收到穩定版更新。例如，5.2核心的歷史如下（2019年）：
-
-	==============  ===============================
-        七月 7 	        5.2 穩定版發布
-	七月 13	        5.2.1
-	七月 21	        5.2.2
-	七月 26	        5.2.3
-	七月 28	        5.2.4
-	七月 31	        5.2.5
-	...	        ...
-	十月 11         5.2.21
-	==============  ===============================
+定版本的更新。
+
+要合入更新版本，補丁必須（1）修復一個重要的缺陷，且（2）已經合併到下一個開
+發版本主線中。核心通常會在其初始版本後的一個以上的開發週期內收到穩定版更新。
+例如，5.2核心的歷史如下（2019年）：
+
+        ==============  ===============================
+        七月 7          5.2 穩定版發布
+        七月 14         5.2.1
+        七月 21         5.2.2
+        七月 26         5.2.3
+        七月 28         5.2.4
+        七月 31         5.2.5
+        ...             ...
+        十月 11         5.2.21
+        ==============  ===============================
 
 5.2.21是5.2版本的最終穩定更新。
 
 有些核心被指定為“長期”核心；它們將得到更長時間的支援。當前的長期核心
 版本及其維護者的列表，請參考以下連結：
 
-	https://www.kernel.org/category/releases.html
+        https://www.kernel.org/category/releases.html
 
-長期支援核心的選擇純粹是維護人員是否有需求和時間來維護該版本的問題。
+長期支援核心的選擇純粹是維護人員是否有需求和時間來維護該版本的問題。目前
+沒有已知的計畫要為任何即將推出的特定版本提供長期支援。
 
 補丁的生命週期
 --------------
 
-補丁不會直接從開發人員的鍵盤進入主線核心。相反，有一個稍微複雜（如果有些非
+補丁不會直接從開發人員的鍵盤進入主線核心。相反，有一個稍微複雜（儘管有些非
 正式）的過程，旨在確保對每個補丁進行品質審查，並確保每個補丁實作了一個在主
-線中需要的更改。對於小的修復，這個過程可能會很快完成，，而對於較大或有爭議
+線中需要的更改。對於小的修復，這個過程可能會很快完成，而對於較大或有爭議
 的變更，可能會持續數年。許多開發人員的沮喪來自於對這個過程缺乏理解或者試圖
 繞過它。
 
@@ -119,12 +122,12 @@ Kroah-Hartman和Sasha Levin組成。穩定團隊將使用9.x.y編號方案不定
   是在不涉及社群的情況下完成的，但是如果可能的話，最好是在公開的情況下完成
   這項工作；這樣可以節省很多稍後再重新設計的時間。
 
-- 早期評審。補丁被髮布到相關的郵件列表中，列表中的開發人員會回覆他們可能有
+- 早期評審。補丁被發布到相關的郵件列表中，列表中的開發人員會回覆他們可能有
   的任何評論。如果一切順利的話，這個過程應該會發現補丁的任何主要問題。
 
 - 更廣泛的評審。當補丁接近準備好納入主線時，它應該被相關的子系統維護人員
   接受——儘管這種接受並不能保證補丁會一直延伸到主線。補丁將出現在維護人員的
-  子系統樹中，並進入 -next 樹（如下所述）。當流程進行時，此步驟將會對補丁
+  子系統樹中，並進入 -next 樹（如下所述）。當流程運作順利時，此步驟將會對補丁
   進行更廣泛的審查，並發現由於將此補丁與其他人所做的工作合併而導致的任何
   問題。
 
@@ -157,14 +160,14 @@ Kroah-Hartman和Sasha Levin組成。穩定團隊將使用9.x.y編號方案不定
 補丁的規模。核心開發人員處理這種增長的方式是使用圍繞信任鏈建置的助理系統。
 
 核心程式碼庫在邏輯上被分解為一組子系統：網路、特定體系結構支援、記憶體管理、視
-頻設備等。大多數子系統都有一個指定的維護人員，其總體負責該子系統中的程式碼。
+訊設備等。大多數子系統都有一個指定的維護人員，其總體負責該子系統中的程式碼。
 這些子系統維護者（鬆散地）是他們所管理的核心部分的“守門員”；他們（通常）
 會接受一個補丁以包含到主線核心中。
 
 子系統維護人員每個人都管理著自己版本的核心原始程式碼樹，通常（並非總是）使
 用Git。Git等工具（以及Quilt或Mercurial等相關工具）允許維護人員追蹤補丁列表，
-包括作者資訊和其他元資料。在任何給定的時間，維護人員都可以確定他或她的儲存
-庫中的哪些補丁在主線中找不到。
+包括作者資訊和其他元資料。在任何給定的時間，維護人員都可以確定其儲存庫中的
+哪些補丁在主線中找不到。
 
 當合併視窗開啟時，頂級維護人員將要求Linus從儲存庫中“拉出”他們為合併選擇
 的補丁。如果Linus同意，補丁流將流向他的儲存庫，成為主線核心的一部分。
@@ -172,9 +175,9 @@ Linus對拉取中接收到的特定補丁的關注程度各不相同。很明顯
 關注。但是一般來說，Linus相信子系統維護人員不會向上遊發送壞補丁。
 
 子系統維護人員反過來也可以從其他維護人員那裡獲取補丁。例如，網路樹是由首先
-在專用於網路設備驅動程式、無線網路等的樹中積累的補丁建置的。此儲存鏈可以
-任意長，但很少超過兩個或三個連結。由於鏈中的每個維護者都信任那些管理較低
-級別樹的維護者，所以這個過程稱為“信任鏈”。
+在專用於網路設備驅動程式、無線網路等的樹中積累的補丁建置的。這條儲存庫鏈可
+以任意長，但很少超過兩三個環節。由於鏈中的每個維護者都信任那些管理較低級別
+樹的維護者，所以這個過程稱為“信任鏈”。
 
 顯然，在這樣的系統中，獲取核心補丁取決於找到正確的維護者。直接向Linus發送
 補丁通常不是正確的方法。
@@ -184,17 +187,17 @@ Next 樹
 
 子系統樹鏈引導補丁流到核心，但它也提出了一個有趣的問題：如果有人想查看為
 下一個合併視窗準備的所有補丁怎麼辦？開發人員將感興趣的是，還有什麼其他的
-更改有待解決，以瞭解是否存在需要擔心的衝突；例如，更改核心核心函式原型的
-修補程式將與使用該函式舊形式的任何其他修補程式衝突。審查人員和測試人員希望
-在所有這些變更到達主線核心之前，能夠存取它們的整合形式的變更。您可以從所有
-相關的子系統樹中提取更改，但這將是一項複雜且容易出錯的工作。
+更改有待解決，以瞭解是否存在需要擔心的衝突；例如，一個修改核心中核心函式原型
+的補丁，將與所有使用該函式舊形式的其他補丁衝突。審查人員和測試人員希望在所有
+這些變更到達主線核心之前，能夠存取它們的整合形式的變更。您可以從所有相關的子
+系統樹中提取更改，但這將是一項龐大且容易出錯的工作。
 
 解決方案以-next樹的形式出現，在這裡子系統樹被收集以供測試和審查。這些樹中
 由Andrew Morton維護的較老的一個，被稱為“-mm”（用於記憶體管理，建立時為此）。
 -mm 樹整合了一長串子系統樹中的補丁；它還包含一些旨在幫助除錯的補丁。
 
 除此之外，-mm 還包含大量由Andrew直接選擇的補丁。這些補丁可能已經發布在郵件
-列表上，或者它們可能應用於核心中未指定子系統樹的部分。同時，-mm 作為最後
+列表上，或者它們可能應用於核心中未指定子系統樹的部分。因此，-mm 作為最後
 手段的子系統樹；如果沒有其他明顯的路徑可以讓補丁進入主線，那麼它很可能最
 終選擇-mm 樹。累積在-mm 中的各種補丁最終將被轉發到適當的子系統樹，或者直接
 發送到Linus。在典型的開發週期中，大約5-10%的補丁透過-mm 進入主線。
@@ -205,9 +208,9 @@ Next 樹
 
 然而，使用MMOTM樹可能會十分令人頭疼；它甚至可能無法編譯。
 
-下一個週期補丁合併的主要樹是linux-next，由Mark Brown維護。根據設計
-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/
 
@@ -218,29 +221,29 @@ Staging 樹
 ----------
 
 核心原始程式碼樹包含drivers/staging/目錄，其中有許多驅動程式或檔案系統的子目錄
-正在被添加到核心樹中。它們在仍然需要更多的修正的時候可以保留在driver/staging/
+正在被添加到核心樹中。它們在仍然需要更多的修正的時候可以保留在drivers/staging/
 目錄中；一旦完成，就可以將它們移到核心中。這是一種追蹤不符合Linux核心編碼或
 品質標準的驅動程式的方法，人們可能希望使用它們並追蹤開發。
 
 Greg Kroah-Hartman 目前負責維護staging樹。仍需要修正的驅動程式將發送給他，
 每個驅動程式在drivers/staging/中都有自己的子目錄。除了驅動程式原始檔之外，
-目錄中還應該有一個TODO檔案。TODO檔案列出了驅動程式需要接受的暫停的工作，
-以及驅動程式的任何補丁都應該抄送的人員列表。當前的規則要求，staging的驅動
-程式必須至少正確編譯。
+目錄中還應該有一個TODO檔案。TODO檔案列出了驅動程式被正式納入核心前尚待完成
+的工作，以及驅動程式的任何補丁都應該抄送的人員列表。當前的規則要求，staging
+的驅動程式必須至少正確編譯。
 
-Staging 是一種讓新的驅動程式進入主線的相對容易的方法，它們會幸運地引起其他
-開發人員的注意，並迅速改進。然而，進入staging並不是故事的結尾；staging中
-沒有看到常規進展的程式碼最終將被刪除。經銷商也傾向於相對不願意使用staging驅動
-程式。因此，在成為一個合適的主線驅動的路上，staging 僅是一箇中轉站。
+Staging 是一種讓新的驅動程式進入主線的相對容易的方法，運氣好的話，它們會引
+起其他開發人員的注意並迅速改進。然而，進入staging並不是故事的結尾；staging
+中沒有看到常規進展的程式碼最終將被刪除。發行版廠商也往往不太願意啟用staging
+驅動程式。因此，staging充其量只是成為合適主線驅動程式之路上的一個中轉站。
 
 工具
 ----
 
 從上面的文字可以看出，核心開發過程在很大程度上依賴於在不同方向上聚集補丁的
-能力。如果沒有適當強大的工具，整個系統將無法在任何地方正常工作。關於如何使用
-這些工具的教程遠遠超出了本文件的範圍，但還是用一點篇幅介紹一些關鍵點。
+能力。如果沒有適當強大的工具，整個系統遠不可能運作得像現在這樣好。關於如何
+使用這些工具的教程遠遠超出了本文件的範圍，但還是用一點篇幅介紹一些關鍵點。
 
-到目前為止，核心社群使用的主要原始程式碼管理系統是git。Git是在自由軟體社群
+到目前為止，核心社群使用的主要原始程式碼管理系統是Git。Git是在自由軟體社群
 中開發的許多分散式版本控制系統之一。它非常適合核心開發，因為它在處理大型儲
 存庫和大量補丁時效能非常好。它也以難以學習和使用而著稱，儘管隨著時間的推移
 它變得更好了。對於核心開發人員來說，對Git的某種熟悉幾乎是一種要求；即使他
@@ -253,20 +256,20 @@ Staging 是一種讓新的驅動程式進入主線的相對容易的方法，它
 
 此頁面包含了文件和教程的連結。
 
-在不使用git的核心開發人員中，最流行的選擇幾乎肯定是Mercurial：
+在不使用Git的核心開發人員中，最流行的選擇幾乎肯定是Mercurial：
 
-        http://www.seleric.com/mercurial/
+        https://www.selenic.com/mercurial/
 
 Mercurial與Git共享許多特性，但它提供了一個介面，許多人覺得它更易於使用。
 
 另一個值得了解的工具是Quilt:
 
-        https://savannah.nongnu.org/projects/quilt
+        https://savannah.nongnu.org/projects/quilt/
 
 Quilt 是一個補丁管理系統，而不是原始程式碼管理系統。它不會隨著時間的推移追
 蹤歷史；相反，它面向根據不斷發展的程式碼庫追蹤一組特定的更改。一些主要的子
 系統維護人員使用Quilt來管理打算向上遊移動的補丁。對於某些樹的管理（例如-mm），
-quilt 是最好的工具。
+Quilt 是最好的工具。
 
 郵件列表
 --------
@@ -284,7 +287,7 @@ quilt 是最好的工具。
 列表。
 
 當然，核心開發的核心郵件列表是linux-kernel。這個列表是一個令人生畏的地方：
-每天的資訊量可以達到500條，噪音很高，談話技術性很強，且參與者並不總是表現出
+每天的郵件量可以達到500封，噪音很高，談話技術性很強，且參與者並不總是表現出
 高度的禮貌。但是，沒有其他地方可以讓核心開發社群作為一個整體聚集在一起；
 不使用此列表的開發人員將錯過重要資訊。
 
@@ -295,25 +298,26 @@ quilt 是最好的工具。
 - 不要試圖跟上每一次談話——沒人會這樣。重要的是要篩選感興趣的主題（但請注意
   長時間的對話可能會偏離原來的主題，儘管未改變電子郵件的主題）和參與的人。
 
-- 不要回復挑事的人。如果有人試圖激起憤怒，請忽略他們。
+- 不要回覆挑事的人。如果有人試圖激起憤怒，請忽略他們。
 
 - 當回覆Linux核心電子郵件（或其他列表上的電子郵件）時，請為所有相關人員保留
   Cc: 抄送頭。如果沒有確實的理由（如明確的請求），則不應刪除收件人。一定要
-  確保你要回復的人在抄送列表中。這個慣例也使你不必在回覆郵件時明確要求被抄送。
+  確保你要回覆的人在抄送列表中。這個慣例也使你不必在回覆郵件時明確要求被抄送。
 
-- 在提出問題之前，搜索列表存檔（和整個網路）。有些開發人員可能會對那些顯然
+- 在提出問題之前，搜尋列表存檔（和整個網路）。有些開發人員可能會對那些顯然
   沒有完成家庭作業的人感到不耐煩。
 
-- 避免頂部回覆（把你的答案放在你要回復的引文上面的做法）。這會讓你的回答更難
-  理解，印象也很差。
+- 使用交錯式（“行內”）回覆，這會讓你的回覆更容易閱讀。（也就是避免置頂回覆，
+  即把你的答案放在你要回覆的引文上面的做法。）更多細節請參閱
+  :ref:`Documentation/process/submitting-patches.rst <tw_interleaved_replies>`。
 
 - 在正確的郵件列表發問。linux-kernel 可能是通用的討論場所，但它不是尋找所有
   子系統開發人員的最佳場所。
 
-最後一點——找到正確的郵件列表——是開發人員常出錯的地方。在linux-kernel上提出
-與網路相關的問題的人幾乎肯定會收到一個禮貌的建議，轉到netdev列表上提出，因
-為這是大多數網路開發人員經常出現的列表。還有其他列表可用於scsi、
-video4linux、ide、filesystem等子系統。查找郵件列表的最佳位置是與核心原始程
+最後一點——找到正確的郵件列表——是新手開發人員常出錯的地方。在linux-kernel上
+提出與網路相關的問題的人幾乎肯定會收到一個禮貌的建議，轉到netdev列表上提出，
+因為這是大多數網路開發人員經常出現的列表。還有其他列表可用於SCSI、
+video4linux、IDE、filesystem等子系統。查找郵件列表的最佳位置是與核心原始程
 式碼一起打包的MAINTAINERS檔案。
 
 開始核心開發
@@ -323,10 +327,10 @@ video4linux、ide、filesystem等子系統。查找郵件列表的最佳位置
 使得關係的開始比本應的更困難。
 
 公司通常希望聘請知名的開發人員來啟動開發團隊。實際上，這是一種有效的技術。
-但它也往往是昂貴的，而且對增加有經驗的核心開發人員的數量沒有多大幫助。考
-慮到時間投入，可以讓內部開發人員加快Linux核心的開發速度。利用這段時間可以
-讓僱主擁有一批既瞭解核心又瞭解公司的開發人員，還可以幫助培訓其他人。從中期
-來看，這通常是更有利可圖的方法。
+但它也往往是昂貴的，而且對增加有經驗的核心開發人員的數量沒有多大幫助。只要投
+入一些時間，就可以讓內部開發人員熟悉Linux核心開發。利用這段時間可以讓僱主擁
+有一批既瞭解核心又瞭解公司的開發人員，還可以幫助培訓其他人。從中期來看，這通
+常是更有利可圖的方法。
 
 可以理解的是，單個開發人員往往對起步感到茫然。從一個大型專案開始可能會很
 嚇人；人們往往想先用一些較小的東西來試試水。由此，一些開發人員開始建立修補
@@ -338,11 +342,17 @@ Andrew Morton 為有抱負的核心開發人員提供了如下建議
 
 ::
 
-	所有核心開發者的第一個專案肯定應該是“確保核心在您可以操作的所有
-	機器上始終完美執行”。通常的方法是和其他人一起解決問題（這可能需
-	要堅持！），但就是如此——這是核心開發的一部分。
+        The #1 project for all kernel beginners should surely be "make sure
+        that the kernel runs perfectly at all times on all machines which
+        you can lay your hands on".  Usually the way to do this is to work
+        with others on getting things fixed up (this can require
+        persistence!) but that's fine - it's a part of kernel development.
 
-(http://lwn.net/Articles/283982/)
+（中譯：所有核心初學者的第一個專案肯定應該是“確保核心在您能接觸到的所有機器
+上始終完美執行”。通常的方法是和其他人一起把問題修好（這可能需要堅持！），
+但這沒關係——這是核心開發的一部分。）
+
+(https://lwn.net/Articles/283982/)。
 
 在沒有明顯問題需要解決的情況下，通常建議開發人員查看當前的迴歸和開放缺陷
 列表。從來都不缺少需要解決的問題；透過解決這些問題，開發人員將從該過程獲得
-- 
2.43.0

[PATCH 03/25] docs/zh_TW: process: sync 4.Coding.rst with the English original

[Chen-Yu Yeh]

The translation carried no "update to commit" marker and was still the
converted zh_CN text.  A section-by-section comparison against the
current English text shows it never picked up several changes and
mistranslated a number of sentences.  Bring it in line with the full
current original:

- add the missing paragraph on EditorConfig
- add the missing "There are, of course, some catches." sentence in
  the internal API section
- replace the Coccinelle :ref: that pointed a URL at the coccinelle.rst
  label with the plain project URL, as in the original
- fix the sparse and LWN URLs, and the coding-style.rst reference that
  displayed a zh_CN path
- keep Linus's quote verbatim in its literal block and add the
  translation after it
- retranslate sentences whose meaning had drifted (the always-zero
  argument, driver abstraction layers, multiple evaluation of macro
  arguments, the inline function temptation, Devicescape being offered
  for inclusion, failure recovery paths, fault injection percentages,
  distributors, compiler warnings that should not appear, documentation
  being the exception, rare deadlocks)
- spell Devicescape and Coccinelle correctly, and fix the *why*
  emphasis that was not rendered
- replace mainland terms with Taiwanese usage (內核, 代碼, 內存, 線程,
  函數, 接口, 文檔, 信息, ...) and the 爲/着/啓 conversion artifacts
- expand tabs in the literal block

update to commit 5adb3698bbe8 ("coccinelle: update Coccinelle website URL")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../translations/zh_TW/process/4.Coding.rst   | 414 +++++++++---------
 1 file changed, 216 insertions(+), 198 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/4.Coding.rst b/Documentation/translations/zh_TW/process/4.Coding.rst
index 423d51f4b3de..288c42dbede1 100644
--- a/Documentation/translations/zh_TW/process/4.Coding.rst
+++ b/Documentation/translations/zh_TW/process/4.Coding.rst
@@ -6,283 +6,301 @@
 
 .. _tw_development_coding:
 
-使代碼正確
+讓程式碼正確
 ======================
 
-雖然一個堅實的、面向社區的設計過程有很多值得說道的，但是任何內核開發項目工作
-的證明都反映在代碼中。它是將由其他開發人員檢查併合並（或不合並）到主線樹中
-的代碼。所以這段代碼的質量決定了項目的最終成功。
+雖然一個堅實的、以社群為導向的設計過程有很多值得說道的，但是任何核心開發專案
+的成果最終都體現在程式碼中。程式碼才是其他開發人員要檢查、並合併（或不合併）
+到主線樹中的東西。所以這些程式碼的品質決定了專案的最終成功。
 
-本節將檢查編碼過程。我們將從內核開發人員常犯的幾種錯誤開始。然後重點將轉移
-到正確的做法和相關有用的工具上。
+本節將探討撰寫程式碼的過程。我們將從核心開發人員常犯的幾種錯誤開始。然後重點
+將轉移到正確的做法和相關有用的工具上。
 
 陷阱
 ----
 
-代碼風格
-********
+程式碼風格
+**********
 
-內核長期以來都有其標準的代碼風格，如
-:ref:`Documentation/translations/zh_CN/process/coding-style.rst <tw_codingstyle>`
-中所述。在多數時候，該文檔中描述的準則至多被認爲是建議性的。因此，內核中存在
-大量不符合代碼風格準則的代碼。這種代碼的存在會給內核開發人員帶來兩方面的危害。
+核心長期以來都有其標準的程式碼風格，如
+:ref:`Documentation/process/coding-style.rst <tw_codingstyle>` 中所述。在其中
+大部分時間裡，該文件中描述的準則至多被認為是建議性的。因此，核心中存在大量不
+符合程式碼風格準則的程式碼。這種程式碼的存在會給核心開發人員帶來兩方面的危害。
 
-首先，相信內核代碼標準並不重要，也不強制執行。但事實上，如果沒有按照標準
-編寫代碼，那麼新代碼將很難加入到內核中；許多開發人員甚至會在審查代碼之前要求
-對代碼進行重新格式化。一個像內核這麼大的代碼庫需要一些統一格式的代碼，以使
-開發人員能夠快速理解其中的任何部分。所以再也經不起奇怪格式的代碼的折騰了。
+第一種危害是認為核心程式碼標準並不重要，也不會強制執行。但事實上，如果沒有按
+照標準編寫程式碼，那麼新程式碼將很難加入到核心中；許多開發人員甚至會在審查程
+式碼之前要求對程式碼進行重新格式化。一個像核心這麼大的程式碼庫需要一定程度的
+一致性，以使開發人員能夠快速理解其中的任何部分。所以格式怪異的程式碼已經沒有
+容身之地了。
 
-內核的代碼風格偶爾會與僱主的強制風格發生衝突。在這種情況下，必須在代碼合併
-之前遵從內核代碼風格。將代碼放入內核意味着以多種方式放棄一定程度的控制權——
-包括控制代碼樣式。
+核心的程式碼風格偶爾會與雇主的強制風格發生衝突。在這種情況下，必須在程式碼合
+併之前遵從核心程式碼風格。將程式碼放入核心意味著以多種方式放棄一定程度的控制
+權——包括控制程式碼的格式。
 
-另一個危害是認爲已經在內核中的代碼迫切需要修復代碼樣式。開發者可能會開始編寫
-重新格式化補丁，作爲熟悉開發過程的一種方式，或者作爲將其名字寫入內核變更日誌
-的一種方式，或者兩者兼而有之。但是純代碼風格的修復被開發社區視爲噪音，它們往
-往受到冷遇。因此，最好避免編寫這種類型的補丁。在由於其他原因處理一段代碼的
-同時順帶修復其樣式是很自然的，但是不應該僅爲了更改代碼樣式而更改之。
+另一個陷阱是認為已經在核心中的程式碼迫切需要修正程式碼風格。開發者可能會開始
+編寫重新格式化的補丁，作為熟悉開發流程的一種方式，或者作為將其名字寫入核心變
+更日誌的一種方式，或者兩者兼而有之。但是純粹修正程式碼風格的補丁被開發社群視
+為噪音，它們往往受到冷遇。因此，最好避免編寫這種類型的補丁。在由於其他原因處
+理一段程式碼的同時順帶修正其風格是很自然的，但是不應該僅為了更改程式碼風格而
+更改之。
 
-代碼風格文檔也不應該被視爲絕對不可違反的規則。如果有一個足夠的理由反對這種
-樣式（例如爲了80列限制拆分行會導致可讀性大大降低），那麼就這樣做吧。
+程式碼風格文件也不應該被視為絕對不可違反的規則。如果有充分的理由違反這種風格
+（例如為了符合80欄的限制而拆分某一行，會導致可讀性大大降低），那麼就這樣做吧。
 
 注意您還可以使用 ``clang-format`` 工具來幫助您處理這些規則，快速自動重新格式
-化部分代碼，和審閱完整的文件以發現代碼樣式錯誤、拼寫錯誤和可能的改進。它還
-可以方便地排序 ``#includes`` 、對齊變量/宏、重排文本和其他類似任務。有關詳細
-信息，請參閱文檔 :ref:`Documentation/dev-tools/clang-format.rst <clangformat>`
+化部分程式碼，和審閱完整的檔案以發現程式碼風格錯誤、拼寫錯誤和可能的改進。它
+還可以方便地排序 ``#includes`` 、對齊變數/巨集、重排文字和其他類似任務。有關
+詳細資訊，請參閱
+:ref:`Documentation/dev-tools/clang-format.rst <clangformat>` 。
+
+如果您使用的編輯器相容於 EditorConfig，一些基本的編輯器設定（例如縮排和行尾字
+元）將會自動設定。更多資訊請參閱 EditorConfig 官方網站：
+https://editorconfig.org/
 
 抽象層
 ******
 
-計算機科學教授教學生以靈活性和信息隱藏的名義廣泛使用抽象層。當然，內核廣泛
-地使用了抽象；任何涉及數百萬行代碼的項目都必須做到這一點以存續下來。但經驗
-表明，過度或過早的抽象可能和過早的優化一樣有害。抽象應用在適當層級，
-不要過度。
-
-簡單點，先考慮一個調用時始終只有一個參數且總爲零的函數。我們可以保留這個參數，
-以在需要使用它時提供的額外靈活性。不過，在那時實現了這個額外參數的代碼很有
-可能以某種從未被注意到的微妙方式被破壞——因爲它從未被使用過。或者當需要額外
-的靈活性時，它並未以符合程序員當初期望的方式來實現。內核開發人員通常會提交
-補丁來刪除未使用的參數；一般來說，一開始就不應該添加這些參數。
-
-隱藏硬件訪問的抽象層——通常爲了允許大量的驅動程序兼容多個操作系統——尤其不受
-歡迎。這樣的層使代碼變得模糊，可能會造成性能損失；它們不屬於Linux內核。
-
-另一方面，如果您發現自己從另一個內核子系統複製了大量的代碼，那麼是時候
-瞭解一下：是否需要將這些代碼中的部分提取到單獨的庫中，或者在更高的層次上
-實現這些功能。在整個內核中複製相同的代碼沒有價值。
-
-#ifdef 和預處理
-***************
-
-C預處理器似乎給一些C程序員帶來了強大的誘惑，他們認爲它是一種將大量靈活性加入
-源代碼中的方法。但是預處理器不是C，大量使用它會導致代碼對其他人來說更難閱讀，
-對編譯器來說更難檢查正確性。使用了大量預處理器幾乎總是代碼需要一些
-清理工作的標誌。
-
-使用#ifdef的條件編譯實際上是一個強大的功能，它在內核中使用。但是很少有人希望
-看到代碼被鋪滿#ifdef塊。一般規定，ifdef的使用應儘可能限制在頭文件中。條件
-編譯代碼可以限制函數，如果代碼不存在，這些函數就直接變成空的。然後編譯器將
-悄悄地優化對空函數的調用。使得代碼更加清晰，更容易理解。
-
-C預處理器宏存在許多危險性，包括可能對具有副作用且沒有類型安全的表達式進行多
-重評估。如果您試圖定義宏，請考慮創建一個內聯函數替代。結果相同的代碼，內聯
-函數更容易閱讀，不會多次計算其參數，並且允許編譯器對參數和返回值執行類型檢查。
-
-內聯函數
+電腦科學教授教導學生以靈活性和資訊隱藏的名義廣泛使用抽象層。當然，核心廣泛
+地使用了抽象；任何涉及數百萬行程式碼的專案若不這樣做，都無法存續下來。但經驗
+表明，過度或過早的抽象可能和過早的最佳化一樣有害。抽象只應該用到所需的程度，
+不要更多。
+
+簡單來說，考慮一個函式，它的某個參數被所有呼叫者傳入的值都是零。我們可以保留
+這個參數，以防將來有人需要使用它所提供的額外靈活性。不過，到了那個時候，實作
+這個額外參數的程式碼很有可能已經以某種從未被注意到的微妙方式被破壞——因為它從
+未被使用過。或者當需要額外的靈活性時，需求出現的方式並不符合程式設計師當初的
+預期。核心開發人員通常會提交補丁來刪除未使用的參數；一般來說，一開始就不應該
+加入這些參數。
+
+隱藏硬體存取的抽象層——通常是為了讓驅動程式的大部分程式碼能用於多個作業系統
+——尤其不受歡迎。這樣的層使程式碼變得晦澀，可能會造成效能損失；它們不屬於
+Linux核心。
+
+另一方面，如果您發現自己從另一個核心子系統複製了大量的程式碼，那麼是時候問問
+自己：是否應該將這些程式碼中的部分提取到單獨的函式庫中，或者在更高的層次上實
+作這些功能。在整個核心中複製相同的程式碼沒有價值。
+
+#ifdef 和前置處理器的一般使用
+*****************************
+
+C前置處理器似乎給一些C程式設計師帶來了強大的誘惑，他們認為它是一種在原始檔中
+有效率地編入大量靈活性的方法。但是前置處理器不是C，大量使用它會導致程式碼對其
+他人來說更難閱讀，對編譯器來說更難檢查正確性。大量使用前置處理器幾乎總是程式
+碼需要一些清理工作的標誌。
+
+使用#ifdef的條件編譯確實是一個強大的功能，核心中也有使用。但是很少有人希望看
+到程式碼裡到處散布著#ifdef區塊。一般來說，#ifdef的使用應儘可能限制在標頭檔中。
+條件編譯的程式碼可以限制在函式之中，若該程式碼不需要存在，這些函式就直接變成
+空的。然後編譯器將悄悄地把對空函式的呼叫最佳化掉。這樣會使程式碼更加清晰，更
+容易理解。
+
+C前置處理器巨集存在許多危險性，包括對具有副作用的表達式可能進行多次求值，以及
+沒有型別安全。如果您想要定義巨集，請考慮改為建立一個行內函式。產生的程式碼是
+相同的，但行內函式更容易閱讀，不會多次對其參數求值，並且允許編譯器對參數和回
+傳值執行型別檢查。
+
+行內函式
 ********
 
-不過，內聯函數本身也存在風險。程序員可以傾心於避免函數調用和用內聯函數填充源
-文件所固有的效率。然而，這些功能實際上會降低性能。因爲它們的代碼在每個調用站
-點都被複制一遍，所以最終會增加編譯內核的大小。此外，這也對處理器的內存緩存
-造成壓力，從而大大降低執行速度。通常內聯函數應該非常小，而且相對較少。畢竟
-函數調用的成本並不高；大量創建內聯函數是過早優化的典型例子。
+不過，行內函式本身也存在風險。程式設計師可能會迷戀於避免函式呼叫所帶來的效率，
+而在原始檔中塞滿行內函式。然而，這些函式實際上可能會降低效能。因為它們的程式
+碼在每個呼叫處都被複製一遍，所以最終會增加編譯後核心的大小。此外，這也對處理
+器的記憶體快取造成壓力，從而大大降低執行速度。通常行內函式應該非常小，而且相
+對較少。畢竟函式呼叫的成本並不高；大量建立行內函式是過早最佳化的典型例子。
 
-一般來說，內核程序員會自冒風險忽略緩存效果。在數據結構課程開頭中的經典
-時間/空間權衡通常不適用於當代硬件。空間 *就是* 時間，因爲一個大的程序比一個
-更緊湊的程序運行得慢。
+一般來說，核心程式設計師若忽略快取效應，後果自負。資料結構入門課程中教授的經
+典時間/空間權衡通常不適用於當代硬體。空間 *就是* 時間，因為一個較大的程式會比
+一個更緊湊的程式執行得慢。
 
-較新的編譯器越來越激進地決定一個給定函數是否應該內聯。因此，隨意放置使用
-“inline”關鍵字可能不僅僅是過度的，也可能是無用的。
+較新的編譯器越來越積極地參與決定一個給定函式是否真的應該被行內展開。因此，隨
+意放置“inline”關鍵字可能不僅僅是過度的，也可能是無關緊要的。
 
 鎖
-**
+****
 
-2006年5月，“deviceescape”網絡堆棧在前呼後擁下以GPL發佈，並被納入主線內核。
-這是一個受歡迎的消息；Linux中對無線網絡的支持充其量被認爲是不合格的，而
-Deviceescape堆棧承諾修復這種情況。然而直到2007年6月（2.6.22），這段代碼才真
+2006年5月，“Devicescape”網路堆疊在大張旗鼓下以GPL發布，並提供給主線核心收錄。
+這是一個受歡迎的消息；Linux中對無線網路的支援充其量被認為是不合格的，而
+Devicescape堆疊承諾修復這種情況。然而直到2007年6月（2.6.22），這段程式碼才真
 正進入主線。發生了什麼？
 
-這段代碼出現了許多閉門造車的跡象。但一個大麻煩是，它並不是爲多處理器系統而
-設計。在合併這個網絡堆棧（現在稱爲mac80211）之前，需要對其進行一個鎖方案的
-改造。
+這段程式碼出現了許多在公司內部閉門開發的跡象。但其中一個特別大的問題是，它並
+不是為多處理器系統而設計的。在合併這個網路堆疊（現在稱為mac80211）之前，需要
+為它補上一套鎖定機制。
 
-曾經，Linux內核代碼可以在不考慮多處理器系統所帶來的併發性問題的情況下進行
-開發。然而現在，這個文檔就是在雙核筆記本電腦上寫的。即使在單處理器系統上，
-爲提高響應能力所做的工作也會提高內核內的併發性水平。編寫內核代碼而不考慮鎖
-的日子早已遠去。
+曾經，Linux核心程式碼可以在不考慮多處理器系統所帶來的並行性問題的情況下進行
+開發。然而現在，這個文件就是在雙核筆記型電腦上寫的。即使在單處理器系統上，為
+提高回應能力所做的工作也會提高核心內的並行性水準。編寫核心程式碼而不考慮鎖的
+日子早已遠去。
 
-可以由多個線程併發訪問的任何資源（數據結構、硬件寄存器等）必須由鎖保護。新
-的代碼應該謹記這一要求；事後修改鎖是一項相當困難的任務。內核開發人員應該花
-時間充分了解可用的鎖原語，以便爲工作選擇正確的工具。對併發性缺乏關注的代碼
-很難進入主線。
+可以由多個執行緒並行存取的任何資源（資料結構、硬體暫存器等）必須由鎖保護。新
+的程式碼應該謹記這一要求；事後再補上鎖定是一項相當困難的任務。核心開發人員應
+該花時間充分了解可用的鎖原語，以便為工作選擇正確的工具。對並行性缺乏關注的程
+式碼很難進入主線。
 
 迴歸
 ****
 
-最後一個值得一提的危險是迴歸：它可能會引起導致現有用戶的某些東西中斷的改變
-（這也可能會帶來很大的改進）。這種變化被稱爲“迴歸”，迴歸已經成爲主線內核
-最不受歡迎的問題。除了少數例外情況，如果迴歸不能及時修正，會導致迴歸的修改
-將被取消。最好首先避免迴歸發生。
+最後一個值得一提的危險是：做出一個會讓現有使用者的某些東西壞掉的變更（這種變
+更也可能帶來很大的改進）是很誘人的。這種變更被稱為“迴歸”，迴歸已經成為主線核
+心最不受歡迎的問題。除了少數例外情況，如果迴歸不能及時修正，導致迴歸的變更將
+被撤回。最好一開始就避免迴歸發生。
 
-人們常常爭論，如果迴歸帶來的功能遠超過產生的問題，那麼迴歸是否爲可接受的。
-如果它破壞了一個系統卻爲十個系統帶來新的功能，爲何不改改態度呢？2007年7月，
-Linus對這個問題給出了最佳答案:
+人們常常爭論，如果一項變更讓更多人的東西能正常運作，而產生問題的人較少，那麼
+這種迴歸就是合理的。如果一項變更每破壞一個系統，就能為十個系統帶來新的功能，
+為何不做呢？2007年7月，Linus對這個問題給出了最佳答案:
 
 ::
 
-	所以我們不會通過引入新問題來修復錯誤。這種方式是靠不住的，沒人知道
-	是否真的有進展。是前進兩步、後退一步，還是前進一步、後退兩步？
+        So we don't fix bugs by introducing new problems.  That way lies
+        madness, and nobody ever knows if you actually make any real
+        progress at all. Is it two steps forwards, one step back, or one
+        step forward and two steps back?
 
-（http://lwn.net/Articles/243460/）
+（中譯：所以我們不會透過引入新問題來修復錯誤。那樣做會讓人發瘋，而且沒人知道
+是否真的有任何實際的進展。是前進兩步、後退一步，還是前進一步、後退兩步？）
 
-特別不受歡迎的一種迴歸類型是用戶空間ABI的任何變化。一旦接口被導出到用戶空間，
-就必須無限期地支持它。這一事實使得用戶空間接口的創建特別具有挑戰性：因爲它們
-不能以不兼容的方式進行更改，所以必須一次就對。因此，用戶空間接口總是需要大量
-的思考、清晰的文檔和廣泛的審查。
+(https://lwn.net/Articles/243460/)。
 
+特別不受歡迎的一種迴歸類型是使用者空間ABI的任何變化。一旦介面被匯出到使用者
+空間，就必須無限期地支援它。這一事實使得使用者空間介面的建立特別具有挑戰性：
+因為它們不能以不相容的方式進行更改，所以必須一次就做對。因此，使用者空間介面
+總是需要大量的思考、清晰的文件和廣泛的審查。
 
-代碼檢查工具
-------------
 
-至少目前，編寫無錯誤代碼仍然是我們中很少人能達到的理想狀態。不過，我們希望做
-的是，在代碼進入主線內核之前，儘可能多地捕獲並修復這些錯誤。爲此，內核開發人
-員已經提供了一系列令人印象深刻的工具，可以自動捕獲各種各樣的隱藏問題。計算機
-發現的任何問題都是一個以後不會困擾用戶的問題，因此，只要有可能，就應該使用
-自動化工具。
+程式碼檢查工具
+--------------
+
+至少目前，編寫無錯誤程式碼仍然是我們中很少人能達到的理想狀態。不過，我們希望
+做到的是，在程式碼進入主線核心之前，儘可能多地捕獲並修復這些錯誤。為此，核心
+開發人員已經彙集了一系列令人印象深刻的工具，可以自動捕獲各種各樣難以察覺的問
+題。電腦發現的任何問題都是一個以後不會困擾使用者的問題，因此，只要有可能，就
+應該使用自動化工具。
 
 第一步是注意編譯器產生的警告。當前版本的GCC可以檢測（並警告）大量潛在錯誤。
-通常，這些警告都指向真正的問題。提交以供審閱的代碼一般不會產生任何編譯器警告。
-在消除警告時，注意瞭解真正的原因，並儘量避免僅“修復”使警告消失而不解決其原因。
+通常，這些警告都指向真正的問題。提交以供審閱的程式碼一般不應產生任何編譯器警
+告。在消除警告時，注意了解真正的原因，並儘量避免僅“修復”使警告消失而不解決其
+原因。
 
-請注意，並非所有編譯器警告都默認啓用。使用“make KCFLAGS=-W”構建內核以
+請注意，並非所有編譯器警告都預設啟用。使用“make KCFLAGS=-W”建置核心以
 獲得完整集合。
 
-內核提供了幾個配置選項，可以打開調試功能；大多數配置選項位於“kernel hacking”
-子菜單中。對於任何用於開發或測試目的的內核，都應該啓用其中幾個選項。特別是，
+核心提供了幾個配置選項，可以打開除錯功能；大多數配置選項位於“kernel hacking”
+子選單中。對於任何用於開發或測試目的的核心，都應該啟用其中幾個選項。特別是，
 您應該打開：
 
- - FRAME_WARN 獲取大於給定數量的堆棧幀的警告。
-   這些警告生成的輸出可能比較冗長，但您不必擔心來自內核其他部分的警告。
+ - FRAME_WARN 對大於給定大小的堆疊框架發出警告。
+   這些警告生成的輸出可能比較冗長，但您不必擔心來自核心其他部分的警告。
 
- - DEBUG_OBJECTS 將添加代碼以跟蹤內核創建的各種對象的生命週期，並在出現問題
-   時發出警告。如果你要添加創建（和導出）關於其自己的複雜對象的子系統，請
-   考慮打開對象調試基礎結構的支持。
+ - DEBUG_OBJECTS 將加入程式碼以追蹤核心建立的各種物件的生命週期，並在操作順序
+   出錯時發出警告。如果您要加入一個會建立（並匯出）自己的複雜物件的子系統，請
+   考慮為物件除錯基礎設施加入支援。
 
- - DEBUG_SLAB 可以發現各種內存分配和使用錯誤；它應該用於大多數開發內核。
+ - DEBUG_SLAB 可以發現各種記憶體配置和使用錯誤；它應該用於大多數開發核心。
 
  - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP 和 DEBUG_MUTEXES 會發現許多常見的
    鎖錯誤。
 
-還有很多其他調試選項，其中一些將在下面討論。其中一些有顯著的性能影響，不應
-一直使用。在學習可用選項上花費一些時間，可能會在短期內得到許多回報。
-
-其中一個較重的調試工具是鎖檢查器或“lockdep”。該工具將跟蹤系統中每個鎖
-（spinlock或mutex）的獲取和釋放、獲取鎖的相對順序、當前中斷環境等等。然後，
-它可以確保總是以相同的順序獲取鎖，相同的中斷假設適用於所有情況等等。換句話
-說，lockdep可以找到許多導致系統死鎖的場景。在部署的系統中，這種問題可能會
-很痛苦（對於開發人員和用戶而言）；LockDep允許提前以自動方式發現問題。具有
-任何類型的非普通鎖的代碼在提交合並前應在啓用lockdep的情況下運行測試。
-
-作爲一個勤奮的內核程序員，毫無疑問，您將檢查任何可能失敗的操作（如內存分配）
-的返回狀態。然而，事實上，最終的故障復現路徑可能完全沒有經過測試。未測試的
-代碼往往會出問題；如果所有這些錯誤處理路徑都被執行了幾次，那麼您可能對代碼
-更有信心。
-
-內核提供了一個可以做到這一點的錯誤注入框架，特別是在涉及內存分配的情況下。
-啓用故障注入後，內存分配的可配置失敗的百分比；這些失敗可以限定在特定的代碼
-範圍內。在啓用了故障注入的情況下運行，程序員可以看到當情況惡化時代碼如何響
-應。有關如何使用此工具的詳細信息，請參閱
+還有很多其他除錯選項，其中一些將在下面討論。其中一些有顯著的效能影響，不應
+一直使用。在學習可用選項上花費一些時間，很可能在短時間內就得到數倍的回報。
+
+其中一個較重的除錯工具是鎖檢查器或“lockdep”。該工具將追蹤系統中每個鎖
+（spinlock或mutex）的取得和釋放、取得鎖的相對順序、當前中斷環境等等。然後，
+它可以確保總是以相同的順序取得鎖，相同的中斷假設適用於所有情況等等。換句話
+說，lockdep可以找到許多在極少數情況下可能導致系統死鎖的場景。在已部署的系統
+中，這種問題可能會很痛苦（對於開發人員和使用者而言）；lockdep允許提前以自動
+方式發現問題。具有任何非簡單鎖定的程式碼在提交合併前應在啟用lockdep的情況下
+執行測試。
+
+作為一個勤奮的核心程式設計師，毫無疑問，您將檢查任何可能失敗的操作（如記憶體
+配置）的回傳狀態。然而，事實上，由此產生的失敗復原路徑可能完全沒有經過測試。
+未測試的程式碼往往會出問題；如果所有這些錯誤處理路徑都被執行過幾次，那麼您對
+程式碼會更有信心。
+
+核心提供了一個可以做到這一點的故障注入框架，特別是在涉及記憶體配置的情況下。
+啟用故障注入後，可設定比例的記憶體配置會被刻意設為失敗；這些失敗可以限定在特
+定的程式碼範圍內。在啟用了故障注入的情況下執行，程式設計師可以看到當情況惡化
+時程式碼如何回應。有關如何使用此工具的詳細資訊，請參閱
 Documentation/fault-injection/fault-injection.rst。
 
-“sparse”靜態分析工具可以發現其他類型的錯誤。sparse可以警告程序員用戶空間
-和內核空間地址之間的混淆、大端序與小端序的混淆、在需要一組位標誌的地方傳遞
-整數值等等。sparse必須單獨安裝(如果您的分發服務器沒有將其打包，
-可以在 https://sparse.wiki.kernel.org/index.php/Main_page 找到）,
-然後可以通過在make命令中添加“C=1”在代碼上運行它。
-
-“Coccinelle”工具 :ref:`https://coccinelle.gitlabpages.inria.fr/website/ <devtools_coccinelle>`
-能夠發現各種潛在的編碼問題；它還可以爲這些問題提出修復方案。在
-scripts/coccinelle目錄下已經打包了相當多的內核“語義補丁”；運行
-“make coccicheck”將運行這些語義補丁並報告發現的任何問題。有關詳細信息，請參閱
-:ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>`
+“sparse”靜態分析工具可以發現其他類型的錯誤。sparse可以警告程式設計師使用者空
+間和核心空間位址之間的混淆、大端序與小端序數值的混用、在需要一組位元旗標的地
+方傳遞整數值等等。sparse必須單獨安裝（如果您的發行版沒有將其打包，
+可以在 https://sparse.wiki.kernel.org/index.php/Main_Page 找到），
+然後可以透過在make命令中加入“C=1”在程式碼上執行它。
 
+“Coccinelle”工具
+(https://coccinelle.gitlabpages.inria.fr/website)
+能夠發現各種潛在的編碼問題；它還可以為這些問題提出修復方案。在
+scripts/coccinelle目錄下已經打包了相當多的核心“語義補丁”；執行
+“make coccicheck”將執行這些語義補丁並報告發現的任何問題。有關詳細資訊，請參閱
+:ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>` 。
 
-其他類型的可移植性錯誤最好通過爲其他體系結構編譯代碼來發現。如果沒有S/390系統
-或Blackfin開發板，您仍然可以執行編譯步驟。可以在以下位置找到一大堆用於x86系統的
-交叉編譯器：
+其他類型的可移植性錯誤最好透過為其他架構編譯程式碼來發現。如果您手邊沒有S/390
+系統或Blackfin開發板，您仍然可以執行編譯步驟。可以在以下位置找到一大套用於x86
+系統的交叉編譯器：
 
         https://www.kernel.org/pub/tools/crosstool/
 
 花一些時間安裝和使用這些編譯器將有助於避免以後的尷尬。
 
-文檔
+文件
 ----
 
-文檔通常比內核開發規則更爲例外。即便如此，足夠的文檔將有助於簡化將新代碼合併
-到內核中的過程，使其他開發人員的生活更輕鬆，並對您的用戶有所幫助。在許多情況
-下，添加文檔已基本上是強制性的。
+在核心開發中，文件往往是例外而非常態。即便如此，足夠的文件將有助於簡化將新程
+式碼合併到核心中的過程，使其他開發人員的生活更輕鬆，並對您的使用者有所幫助。
+在許多情況下，加入文件已基本上是強制性的。
 
-任何補丁的第一個文檔是其關聯的變更日誌。日誌條目應該描述正在解決的問題、解決
-方案的形式、處理補丁的人員、對性能的任何相關影響，以及理解補丁可能需要的任何
-其他內容。確保變更日誌說明了*爲什麼*補丁值得應用；大量開發者未能提供這些信息。
+任何補丁的第一份文件是其關聯的變更日誌。日誌條目應該描述正在解決的問題、解決
+方案的形式、參與補丁工作的人員、對效能的任何相關影響，以及理解補丁可能需要的
+任何其他內容。確保變更日誌說明了 *為什麼* 補丁值得應用；令人驚訝的是，有相當
+多的開發者沒有提供這項資訊。
 
-任何添加新用戶空間接口的代碼——包括新的sysfs或/proc文件——都應該包含該接口
-的文檔，該文檔使用戶空間開發人員能夠知道他們在使用什麼。請參閱
-Documentation/ABI/README，瞭解如何此文檔格式以及需要提供哪些信息。
+任何加入新使用者空間介面的程式碼——包括新的sysfs或/proc檔案——都應該包含該介面
+的文件，讓使用者空間開發人員能夠知道他們在使用什麼。請參閱
+Documentation/ABI/README，了解此文件應如何格式化以及需要提供哪些資訊。
 
-文檔 :ref:`Documentation/admin-guide/kernel-parameters.rst <kernelparameters>`
-描述了內核的所有引導時間參數。任何添加新參數的補丁都應該向該文檔添加適當的
-條目。
+檔案 :ref:`Documentation/admin-guide/kernel-parameters.rst <kernelparameters>`
+描述了核心的所有開機參數。任何加入新參數的補丁都應該向該檔案加入適當的條目。
 
-任何新的配置選項都必須附有幫助文本，幫助文本需清楚地解釋這些選項以及用戶可能
-希望何時使用它們。
+任何新的配置選項都必須附有說明文字，清楚地解釋這些選項以及使用者可能希望何時
+選用它們。
 
-許多子系統的內部API信息通過專門格式化的註釋進行記錄；這些註釋可以通過
-“kernel-doc”腳本以多種方式提取和格式化。如果您在具有kerneldoc註釋的子系統中
-工作，則應該維護它們，並根據需要爲外部可用的功能添加它們。即使在沒有如此記錄
-的領域中，爲將來添加kerneldoc註釋也沒有壞處；實際上，這對於剛開始開發內核的人
-來說是一個有用的活動。這些註釋的格式以及如何創建kerneldoc模板的一些信息可以在
+許多子系統的內部API資訊透過特殊格式的註解進行記錄；這些註解可以透過
+“kernel-doc”腳本以多種方式提取和格式化。如果您在具有kerneldoc註解的子系統中
+工作，則應該維護它們，並根據需要為外部可用的函式加入註解。即使在尚未如此記錄
+的領域中，為將來加入kerneldoc註解也沒有壞處；實際上，這對於剛開始開發核心的人
+來說是一個有用的活動。這些註解的格式以及如何建立kerneldoc模板的一些資訊可以在
 :ref:`Documentation/doc-guide/ <doc_guide>` 上找到。
 
-任何閱讀大量現有內核代碼的人都會注意到，註釋的缺失往往是最值得注意的。同時，
-對新代碼的要求比過去更高；合併未註釋的代碼將更加困難。這就是說，人們並不期望
-詳細註釋的代碼。代碼本身應該是自解釋的，註釋闡釋了更微妙的方面。
+任何閱讀大量現有核心程式碼的人都會注意到，註解的缺失往往是最顯眼的。再次強調，
+對新程式碼的要求比過去更高；合併未加註解的程式碼將更加困難。話雖如此，人們也
+不希望看到註解過度冗長的程式碼。程式碼本身應該是易讀的，註解則用來闡釋較微妙
+的部分。
 
-某些事情應該總是被註釋。使用內存屏障時，應附上一行文字，解釋爲什麼需要設置內存
-屏障。數據結構的鎖規則通常需要在某個地方解釋。一般來說，主要數據結構需要全面
-的文檔。應該指出代碼中分立的位之間不明顯的依賴性。任何可能誘使代碼管理人進行
-錯誤的“清理”的事情都需要一個註釋來說明爲什麼要這樣做。等等。
+某些事情應該總是加上註解。使用記憶體屏障時，應附上一行文字，解釋為什麼需要該
+屏障。資料結構的鎖規則通常需要在某個地方解釋。一般來說，主要資料結構需要全面
+的文件。不同程式碼片段之間不明顯的相依性應該指出來。任何可能誘使程式碼清理者
+進行錯誤“清理”的地方，都需要一個註解來說明為什麼要這樣做。等等。
 
 
 內部API更改
 -----------
 
-內核提供給用戶空間的二進制接口不能被破壞，除非逼不得已。而內核的內部編程接口
-是高度流動的，當需要時可以更改。如果你發現自己不得不處理一個內核API，或者僅
-僅因爲它不滿足你的需求導致無法使用特定的功能，這可能是API需要改變的一個標誌。
-作爲內核開發人員，您有權進行此類更改。
-
-的確可以進行API更改，但更改必須是合理的。因此任何進行內部API更改的補丁都應該
-附帶關於更改內容和必要原因的描述。這種變化也應該拆分成一個單獨的補丁，而不是
-埋在一個更大的補丁中。
+核心提供給使用者空間的二進位介面不能被破壞，除非逼不得已。而核心的內部程式設
+計介面是高度流動的，當需要時可以更改。如果您發現自己不得不繞過一個核心API，
+或者僅僅因為它不滿足您的需求而不使用某個特定功能，這可能是API需要改變的一個
+標誌。作為核心開發人員，您有權進行此類更改。
 
-另一個要點是，更改內部API的開發人員通常要負責修復內核樹中被更改破壞的任何代碼。
-對於一個廣泛使用的函數，這個責任可以導致成百上千的變化，其中許多變化可能與其他
-開發人員正在做的工作相沖突。不用說，這可能是一項大工程，所以最好確保理由是
-可靠的。請注意，coccinelle工具可以幫助進行廣泛的API更改。
+當然，這其中有一些需要注意的地方。API可以更改，但更改必須有充分的理由。因此任
+何進行內部API更改的補丁都應該附帶關於更改內容和必要原因的描述。這種變化也應
+該拆分成一個單獨的補丁，而不是埋在一個更大的補丁中。
 
-在進行不兼容的API更改時，應儘可能確保編譯器捕獲未更新的代碼。這將幫助您確保找
-到該接口的樹內用處。它還將警告開發人員樹外代碼存在他們需要響應的更改。支持樹外
-代碼不是內核開發人員需要擔心的事情，但是我們也不必使樹外開發人員的生活有不必要
-的困難。
+另一個要點是，更改內部API的開發人員通常要負責修復核心樹中被該更改破壞的任何
+程式碼。對於一個廣泛使用的函式，這個責任可能導致成百上千的變化，其中許多變化
+可能與其他開發人員正在做的工作相衝突。不用說，這可能是一項大工程，所以最好確
+保理由是可靠的。請注意，Coccinelle工具可以幫助進行大範圍的API更改。
 
+在進行不相容的API更改時，應儘可能確保未更新的程式碼會被編譯器捕獲。這將幫助
+您確保找到該介面在樹內的所有使用處。它還會提醒樹外程式碼的開發人員，有一項他
+們需要回應的更改。支援樹外程式碼不是核心開發人員需要擔心的事情，但是我們也不
+必讓樹外開發人員的生活比必要的更困難。
-- 
2.43.0

[PATCH 04/25] docs/zh_TW: process: sync 5.Posting.rst with the English original

[Chen-Yu Yeh]

The translation claims to be up to date with commit 0a83293322fd ("doc:
development-process: add notice on testing"), but a section-by-section
comparison against the current English text shows it still carried
wording from an older original and mistranslated a number of sentences.
Bring it in line with the full current original:

- drop the "since "Co-developed-by:" denotes authorship" clause that is
  no longer in the original, and fix the order it gave: a
  "Signed-off-by:" must follow each "Co-developed-by:", not the other
  way round
- add the missing reference to the reviewer's statement under
  "Reviewed-by:"
- use gender-neutral wording for "Signed-off-by:", following the English
- capitalize Git and Quilt when they name the tools, and fix the
  "git bisct" and "coilt" typos
- retranslate sentences whose meaning had drifted (reasonable detail,
  half-baked patches, reasonable configuration combinations, the
  employer "likely" owning the work, branching off at an arbitrary spot,
  the summary line, adding the From line when in doubt, gratuitous
  white-space changes, erring on the side of too many copies, copying
  the original poster, and mail threading, which was rendered as
  execution threads)
- replace mainland terms with Taiwanese usage (代碼, 激活, 響應, 嵌套,
  分銷商, 專案 for "items", ...)
- show English paths in the :ref: links to submitting-patches.rst,
  submit-checklist.rst and email-clients.rst, as the other synced files
  do, which keeps the lines within 80 columns
- replace the en dash in --chain-reply-to and the full-width colon
  after Cc, and expand tabs in the literal blocks

update to commit fdd100ee60a0 ("docs: process: use gender-neutral
pronouns")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../translations/zh_TW/process/5.Posting.rst  | 141 +++++++++---------
 1 file changed, 71 insertions(+), 70 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/5.Posting.rst b/Documentation/translations/zh_TW/process/5.Posting.rst
index d54b16364474..51af92e18802 100644
--- a/Documentation/translations/zh_TW/process/5.Posting.rst
+++ b/Documentation/translations/zh_TW/process/5.Posting.rst
@@ -11,31 +11,31 @@
 
 您的工作遲早會準備好提交給社群進行審查，並最終包含到主線核心中。毫不稀奇，
 核心開發社群已經發展出一套用於發布補丁的約定和過程；遵循這些約定和過程將使
-參與其中的每個人的生活更加輕鬆。本文件試圖描述這些約定的部分細節；更多資訊
-也可在以下文件中找到
-:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+參與其中的每個人的生活更加輕鬆。本文件試圖以相當程度的細節描述這些期望；更多
+資訊也可在以下文件中找到
+:ref:`Documentation/process/submitting-patches.rst <tw_submittingpatches>`
 和
-:ref:`Documentation/translations/zh_TW/process/submit-checklist.rst <tw_submitchecklist>`。
+:ref:`Documentation/process/submit-checklist.rst <tw_submitchecklist>`。
 
 何時寄送
 --------
 
 在補丁完全“準備好”之前，避免發布補丁是一種持續的誘惑。對於簡單的補丁，這
 不是問題。但是如果正在完成的工作很複雜，那麼在工作完成之前從社群獲得反饋就
-可以獲得很多好處。因此，您應該考慮發布正在進行的工作，甚至維護一個可用的Git
+可以獲得很多好處。因此，您應該考慮發布正在進行的工作，甚至公開一個可用的Git
 樹，以便感興趣的開發人員可以隨時趕上您的工作。
 
 當發布中有尚未準備好被包含的程式碼，最好在發布中說明。還應提及任何有待完成的
-主要工作和任何已知問題。很少有人會願意看那些被認為是半生不熟的補丁，但是
-那些願意的人會帶著他們的點子來一起幫助你把工作推向正確的方向。
+主要工作和任何已知問題。願意看那些已知是半成品的補丁的人會比較少，但是那些
+願意看的人，會抱著能幫助你把工作推向正確方向的想法而來。
 
 建立補丁之前
 ------------
 
 在考慮將補丁發送到開發社群之前，有許多事情應該做。包括：
 
- - 儘可能地測試程式碼。利用核心的除錯工具，確保核心使用了所有可能的設定選
-   項組合進行建置，使用交叉編譯器為不同的架構進行建置等。添加測試，最好使
+ - 儘可能地測試程式碼。利用核心的除錯工具，確保核心在所有合理的設定選項組合
+   下都能建置，使用交叉編譯器為不同的架構進行建置等。添加測試，最好使
    用現有的測試框架（如KUnit），並將其作為補丁系列中單獨的一員（關於補丁系
    列，見下一節）。注意，對某些子系統而言這可能是強制性的。例如，函式庫函
    式（位於lib/下）幾乎在所有地方被廣泛使用，應當有適當的測試。
@@ -45,20 +45,20 @@
  - 您的更改是否具有效能影響？如果是這樣，您應該執行基準測試來顯示您的變更的
    影響（或好處）；結果的摘要應該包含在補丁中。
 
- - 確保您有權發布程式碼。如果這項工作是為僱主完成的，僱主對這項工作具有所
-   有權，並且必須同意根據GPL對其進行發布。
+ - 確保您有權發布程式碼。如果這項工作是為僱主完成的，僱主很可能對這項工作擁
+   有權利，並且必須同意根據GPL對其進行發布。
 
 一般來說，在發布程式碼之前進行一些額外的思考，幾乎總是能在短時間內得到回報。
 
 補丁準備
 --------
 
-準備補丁發布的工作量可能很驚人，但在此嘗試節省時間通常是不明智的，即使在短期
-內亦然。
+準備補丁發布的工作量可能很驚人，但再說一次，在此嘗試節省時間通常是不明智的，
+即使在短期內亦然。
 
 必須針對核心的特定版本準備補丁。一般來說，補丁應該基於Linus的Git樹中的當前
 主線。當以主線為基礎時，請從一個衆所周知的發布點開始——如穩定版本或 -rc
-版本發布點——而不是在一個任意的主線分支點。
+版本發布點——而不是從主線上任意一點分支出去。
 
 也可能需要針對-mm、linux-next或子系統樹產生版本，以便於更廣泛的測試和審查。
 根據補丁的區域以及其他地方的情況，針對其他樹建立的補丁可能需要大量的工作來
@@ -66,7 +66,7 @@
 
 只有最簡單的更改才應格式化為單個補丁；其他所有更改都應作為一系列邏輯更改進行。
 分割補丁是一門藝術；一些開發人員花了很長時間來弄清楚如何按照社群期望的方式來
-分割。不過，這些經驗法則也許有幫助：
+分割。不過，有一些經驗法則會很有幫助：
 
  - 您發布的補丁系列幾乎肯定不會是開發過程中版本控制系統中的一系列更改。相反，
    需要對您所做更改的最終形式加以考慮，然後以有意義的方式進行拆分。開發人員對
@@ -78,12 +78,12 @@
    檢查並驗證它所做的事情的更改。
 
  - 換種方式重申上述準則，也就是說：不要在同一補丁中混合不同類型的更改。如果
-   一個補丁修復了一個關鍵的安全漏洞，又重新排列了一些結構，還重新格式化了代
-   碼，那麼它很有可能會被忽略，從而導致重要的修復丟失。
+   一個補丁修復了一個關鍵的安全漏洞，又重新排列了一些結構，還重新格式化了程
+   式碼，那麼它很有可能會被忽略，從而導致重要的修復丟失。
 
  - 每個補丁都應該能建立一個可以正確地建置和執行的核心；如果補丁系列在中間被
    斷開，那麼結果仍應是一個正常工作的核心。部分應用一系列補丁是使用
-   “git bisct”工具查找回歸的一個常見場景；如果結果是一個損壞的核心，那麼將使
+   “git bisect”工具查找迴歸的一個常見場景；如果結果是一個損壞的核心，那麼將使
    那些從事追蹤問題的高尚工作的開發人員和使用者的生活更加艱難。
 
  - 不要過分分割。一位開發人員曾經將一組針對單一檔案的編輯分成500個單獨的補丁
@@ -93,7 +93,7 @@
  - 用一系列補丁添加一個全新的基礎設施，但是該設施在系列中的最後一個補丁啟用
    整個變更之前不能使用，這看起來很誘人。如果可能的話，應該避免這種誘惑；
    如果這個系列增加了迴歸，那麼二分法將指出最後一個補丁是導致問題的補丁，
-   即使真正的bug在其他地方。只要有可能，添加新程式碼的補丁程式應該立即激活該
+   即使真正的bug在其他地方。只要有可能，添加新程式碼的補丁應該立即啟用該
    程式碼。
 
 建立完美補丁系列的工作可能是一個令人沮喪的過程，在完成“真正的工作”之後需要
@@ -106,11 +106,11 @@
 需要被格式化成一條訊息，以快速而清晰地將其目的傳達到世界其他地方。為此，
 每個補丁將由以下部分組成：
 
- - 可選的“From”行，表明補丁作者。只有當你透過電子郵件發送別人的補丁時，這一行
-   才是必須的，但是為防止疑問加上它也不會有什麼壞處。
+ - 可選的“From”行，表明補丁作者。只有當你透過電子郵件轉發別人的補丁時，這一行
+   才是必須的，但是在不確定時加上它也不會有什麼壞處。
 
  - 一行描述，說明補丁的作用。對於在沒有其他上下文的情況下看到該訊息的讀者
-   來說，該訊息應足以確定修補程式的範圍；此行將顯示在“short form（簡短格式）”
+   來說，該訊息應足以確定補丁的範圍；此行將顯示在“short form（簡短格式）”
    變更日誌中。此訊息通常需要先加上子系統名稱前綴，然後是補丁的目的。例如：
 
    ::
@@ -123,46 +123,47 @@
  - 一個或多個標記行，至少有一個由補丁作者的 Signed-off-by 簽名。標記將在下面
    詳細描述。
 
-上面的專案一起構成補丁的變更日誌。寫一則好的變更日誌是一門至關重要但常常被
+以上各項一起構成補丁的變更日誌。寫一則好的變更日誌是一門至關重要但常常被
 忽視的藝術；值得花一點時間來討論這個問題。當你編寫變更日誌時，你應該記住有
 很多不同的人會讀你的話。其中包括子系統維護人員和審查人員，他們需要決定是否
-應該合併補丁，分銷商和其他維護人員試圖決定是否應該將補丁反向移植到其他核心，
-缺陷搜尋人員想知道補丁是否導致他們正在追查的問題，以及想知道核心如何變化的
-使用者等等。一個好的變更日誌以最直接和最簡潔的方式向所有這些人傳達所需的資訊。
-
-在結尾，總結行應該描述變更的影響和動機，以及在一行約束條件下可能發生的變化。
-然後，詳細的描述可以詳述這些主題，並提供任何需要的附加資訊。如果補丁修復了
-一個缺陷，請引用引入該缺陷的提交（如果可能，請在引用提交時同時提供其 id 和
-標題）。如果某個問題與特定的日誌或編譯器輸出相關聯，請包含該輸出以幫助其他
-人搜索同一問題的解決方案。如果更改是為了支援以後補丁中的其他更改，那麼應當
-說明。如果更改了內部API，請詳細說明這些更改以及其他開發人員應該如何響應。
-一般來說，你越把自己放在每個閱讀你變更日誌的人的位置上，變更日誌（和核心
-作為一個整體）就越好。
-
-不需要說，變更日誌是將變更提交到版本控制系統時使用的文字。接下來將是：
+應該合併補丁，發行版廠商和其他維護人員試圖決定是否應該將補丁反向移植到其他
+核心，缺陷搜尋人員想知道補丁是否導致他們正在追查的問題，以及想知道核心如何
+變化的使用者等等。一個好的變更日誌以最直接和最簡潔的方式向所有這些人傳達所需
+的資訊。
+
+為此，摘要行應該在一行的限制下，儘可能描述清楚變更的影響和動機。然後，詳細
+的描述可以詳述這些主題，並提供任何需要的附加資訊。如果補丁修復了一個缺陷，
+請儘可能引用引入該缺陷的提交（並請在引用提交時同時提供其commit ID和標題）。
+如果某個問題與特定的日誌或編譯器輸出相關聯，請包含該輸出以幫助其他人搜索同
+一問題的解決方案。如果更改是為了支援以後補丁中的其他更改，那麼應當說明。如
+果更改了內部API，請詳細說明這些更改以及其他開發人員應該如何回應。一般來說，
+你越把自己放在每個閱讀你變更日誌的人的位置上，變更日誌（和核心作為一個整體）
+就越好。
+
+不用說，變更日誌就應該是將變更提交到版本控制系統時使用的文字。接下來將是：
 
  - 補丁本身，採用統一的（“-u”）補丁格式。使用“-p”選項來diff將使函式名與
-   更改相關聯，從而使結果補丁更容易被其他人讀取。
+   更改相關聯，從而使結果補丁更容易被其他人閱讀。
 
 前面已簡要提到的標籤（tag）用於提供補丁如何產生的線索。
-:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+:ref:`Documentation/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")
+        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
+        Link: https://example.com/somewhere.html  optional-other-stuff
 
 依照企鵝老大（Chief Penguin）的指導，只有當Link:標籤指向的有用資訊無法在
 提交本身中找到時，才應該把它加到提交中。
 
 如果URL指向此補丁所修復的公開缺陷報告，請改用“Closes:”標籤::
 
-	Closes: https://example.com/issues/1234  optional-other-stuff
+        Closes: https://example.com/issues/1234  optional-other-stuff
 
 一些缺陷追蹤系統能夠在帶有此類標籤的提交被套用時自動關閉問題。一些監控
 郵件列表的機器人也會追蹤這類標籤並採取相應動作。私有缺陷追蹤系統和無效
@@ -170,28 +171,29 @@
 
 另一種標籤用於記錄誰參與了補丁的開發。它們每個都使用如下格式::
 
-	tag: Full Name <email address>  optional-other-stuff
+        tag: Full Name <email address>  optional-other-stuff
 
 常用的標籤有：
 
- - Signed-off-by: 這是一個開發人員的證明，證明他或她有權提交補丁以包含到核
-   心中。這表明同意開發者來源認證協議，其全文見
-   :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
-   如果沒有合適的簽字，則不能合併到主線中。
+ - Signed-off-by: 這是一個開發人員的證明，證明自己有權提交補丁以包含到核心
+   中。這表明同意開發者來源認證協議，其全文見
+   :ref:`Documentation/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>`
+ - Co-developed-by: 聲明補丁是由多個開發人員共同建立的；當多人共同處理一個
+   補丁時，它用於標示共同作者（除了 From: 標籤所標示的作者之外）。每個
+   Co-developed-by: 之後都必須緊跟著相應共同作者的 Signed-off-by:。具體內容
+   和範例見
+   :ref:`Documentation/process/submitting-patches.rst <tw_submittingpatches>`。
 
  - Acked-by: 表示另一個開發人員（通常是相關程式碼的維護人員）同意補丁適合包含
    在核心中。
 
  - Tested-by: 聲明某人已經測試了補丁並確認它可以工作。
 
- - Reviewed-by: 表示某開發人員已經審查了補丁的正確性；有關詳細資訊，請參閱
-   :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+ - Reviewed-by: 表示某開發人員已經審查了補丁的正確性；更多細節請參閱
+   :ref:`Documentation/process/submitting-patches.rst <tw_submittingpatches>`
+   中的審查者聲明。
 
  - Reported-by: 指定報告此補丁修復的問題的使用者；此標籤用於向測試我們的
    程式碼並在發現問題時告知我們的人們（他們常常沒有得到應有的重視）表示
@@ -202,7 +204,7 @@
  - Suggested-by: 標籤表明補丁的想法是由被指名者建議的，確保其想法獲得
    讚譽。希望這能激勵他們在未來繼續幫助我們。
 
- - Cc：指定某人收到了補丁的副本，並有機會對此發表評論。
+ - Cc: 指定某人收到了補丁的副本，並有機會對此發表評論。
 
 在補丁中添加上述標籤時要小心：除了Cc:、Reported-by:和Suggested-by:之外，
 所有標籤都需要被指名者的明確許可。對於這三個標籤，如果根據lore存檔或提交
@@ -216,15 +218,15 @@
 
 在寄送補丁之前，您還需要注意以下幾點：
 
- - 您確定您的郵件發送程式不會損壞補丁嗎？被郵件客戶端更改空白或修飾了行的補丁
-   無法被另一端接受，並且通常不會進行任何詳細檢查。如果有任何疑問，先把補丁寄
-   給你自己，讓你自己確定它是完好無損的。
+ - 您確定您的郵件發送程式不會損壞補丁嗎？被郵件客戶端任意更動空白或自動換行
+   的補丁在另一端將無法套用，並且通常不會有人仔細檢查。如果有任何疑問，先把
+   補丁寄給你自己，讓你自己確定它是完好無損的。
 
-   :ref:`Documentation/translations/zh_TW/process/email-clients.rst <tw_email_clients>`
+   :ref:`Documentation/process/email-clients.rst <tw_email_clients>`
    提供了一些有用的提示，可以讓特定的郵件客戶端正常發送補丁。
 
- - 你確定你的補丁沒有荒唐的錯誤嗎？您應該始終透過scripts/checkpatch.pl檢查
-   補丁程式，並解決它提出的問題。請記住，checkpatch.pl，雖然體現了對核心補丁
+ - 你確定你的補丁沒有愚蠢的錯誤嗎？您應該始終透過scripts/checkpatch.pl檢查
+   補丁，並解決它提出的問題。請記住，checkpatch.pl，雖然體現了對核心補丁
    應該是什麼樣的大量思考，但它並不比您聰明。如果修復checkpatch.pl給的問題會
    使程式碼變得更糟，請不要這樣做。
 
@@ -232,20 +234,20 @@
 引用補丁的部分。相反，只需將補丁直接放到您的訊息中。
 
 寄出補丁時，重要的是將副本發送給任何可能感興趣的人。與其他一些專案不同，核心
-鼓勵人們甚至錯誤地發送過多的副本；不要假定相關人員會看到您在郵件列表中的發布。
+鼓勵人們寧可發送過多的副本；不要假定相關人員會看到您在郵件列表中的發布。
 尤其是，副本應發送至：
 
  - 受影響子系統的維護人員。如前所述，MAINTAINERS檔案是查找這些人員的首選地方。
 
  - 其他在同一領域工作的開發人員，尤其是那些現在可能在那裡工作的開發人員。使用
-   git查看還有誰修改了您正在處理的檔案，這很有幫助。
+   Git查看還有誰修改了您正在處理的檔案，這很有幫助。
 
- - 如果您對某錯誤報告或功能請求做出響應，也可以抄送原始發送人。
+ - 如果您是在回應某個錯誤報告或功能請求，也應抄送原始發文者。
 
  - 將副本發送到相關郵件列表，或者若無相關列表，則發送到linux-kernel列表。
 
  - 如果您正在修復一個缺陷，請考慮該修復是否應進入下一個穩定更新。如果是這樣，
-   補丁副本也應發到stable@vger.kernel.org 。另外，在補丁本身的標籤中添加一個
+   補丁副本也應發到 stable@vger.kernel.org 。另外，在補丁本身的標籤中添加一個
    “Cc: stable@vger.kernel.org”；這將使穩定版團隊在修復進入主線時收到通知。
 
 當為一個補丁選擇接收者時，最好清楚你認為誰最終會接受這個補丁並將其合併。雖然
@@ -257,7 +259,7 @@
 
 ::
 
-	[PATCH nn/mm] subsys: one-line description of the patch
+        [PATCH nn/mm] subsys: one-line description of the patch
 
 其中“nn”是補丁的序號，“mm”是系列中補丁的總數，“subsys”是受影響子系統的
 名稱。當然，一個單獨的補丁可以省略nn/mm。
@@ -267,7 +269,6 @@
 因此，請確保補丁本身具有完整的變更日誌資訊。
 
 一般來說，多部分補丁的第二部分和後續部分應作為對第一部分的回覆發送，以便它們
-在接收端都連接在一起。像git和coilt這樣的工具有命令，可以透過適當的執行緒發送
-一組補丁。但是，如果您有一長串補丁，並正使用git，請不要使用–-chain-reply-to
-選項，以避免建立過深的嵌套。
-
+在接收端都串在同一個討論串中。像Git和Quilt這樣的工具有命令，可以用正確的討論
+串結構寄出一組補丁。但是，如果您有一長串補丁，並正使用Git，請不要使用
+--chain-reply-to選項，以避免建立過深的巢狀結構。
-- 
2.43.0

[PATCH 05/25] docs/zh_TW: process: sync 6.Followthrough.rst with the English original

[Chen-Yu Yeh]

The translation carried no "update to commit" marker and was still the
converted zh_CN text.  A section-by-section comparison against the
current English text shows it never picked up the coding-style and
code-sharing advice, and mistranslated a number of sentences.  Bring it
in line with the full current original:

- add the missing item on being prepared for coding style requests and
  for factoring code out into shared parts of the kernel
- retranslate sentences whose meaning had drifted (posting a perfect
  series "with the addition of" your engineering skills, a patch "of
  any significance", Linux still being around a decade from now,
  promoting employers' agendas at the expense of your own, Andrew
  Morton's suggestion of a code comment instead of a code change,
  patches going nowhere, subsystem trees feeding linux-next, everything
  applying cleanly, "where there are testers, there will be bug
  reports", nobody else fixing the regression for you, the limited
  resistance to patches opposed by the maintainer, and the community
  remembering your reaction)
- replace mainland terms with Taiwanese usage (內核, 代碼, 內存, 默認,
  信息, 響應, 硬件, 登錄, 郵件客戶端, ...) and the 爲/着/裏/喫
  conversion artifacts
- write MAINTAINERS file by name instead of translating it
- wrap the :Original: line to keep it within 80 columns, as in
  stable-api-nonsense.rst

update to commit fdd100ee60a0 ("docs: process: use gender-neutral
pronouns")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/6.Followthrough.rst         | 247 +++++++++---------
 1 file changed, 128 insertions(+), 119 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/6.Followthrough.rst b/Documentation/translations/zh_TW/process/6.Followthrough.rst
index 76082a15677f..81d16a088ba4 100644
--- a/Documentation/translations/zh_TW/process/6.Followthrough.rst
+++ b/Documentation/translations/zh_TW/process/6.Followthrough.rst
@@ -2,146 +2,155 @@
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :ref:`Documentation/process/6.Followthrough.rst <development_followthrough>`
+:Original: :ref:`Documentation/process/6.Followthrough.rst
+           <development_followthrough>`
 
 .. _tw_development_followthrough:
 
 跟進
 ====
 
-此時，您已經遵循了到目前爲止給出的指導方針，並且，隨着您自己的工程技能的增加，
-已經發布了一系列完美的補丁。即使是經驗豐富的內核開發人員也能犯的最大錯誤之一
-是，認爲他們的工作現在已經完成了。事實上，發佈補丁意味着進入流程的下一個階段，
-可能還需要做很多工作。
+此時，您已經遵循了到目前為止給出的指導方針，再加上您自己的工程技能，已經發
+布了一系列完美的補丁。即使是經驗豐富的核心開發人員也可能犯的最大錯誤之一，
+是認為他們的工作現在已經完成了。事實上，發布補丁意味著進入流程的下一個階段，
+可能還有相當多的工作要做。
 
-一個補丁在首次發佈時就非常出色、沒有改進的餘地，這是很罕見的。內核開發流程已
-認識到這一事實，因此它非常注重對已發佈代碼的改進。作爲代碼的作者，您應該與
-內核社區合作，以確保您的代碼符合內核的質量標準。如果不參與這個過程，很可能會
-無法將補丁合併到主線中。
+一個補丁在首次發布時就好到沒有改進的餘地，這是很罕見的。核心開發流程認識到
+這一事實，因此非常注重對已發布程式碼的改進。作為程式碼的作者，您應該與核心
+社群合作，以確保您的程式碼符合核心的品質標準。如果不參與這個過程，很可能會
+導致您的補丁無法被合併到主線中。
 
 與審閱者合作
 ------------
 
-任何意義上的補丁都會導致其他開發人員在審查代碼時發表大量評論。對於許多開發
-人員來說，與審閱人員合作可能是內核開發過程中最令人生畏的部分。但是如果你
+任何有一定份量的補丁，都會在其他開發人員審閱程式碼時引來不少評論。對於許多
+開發人員來說，與審閱者合作可能是核心開發過程中最令人生畏的部分。但是如果你
 記住一些事情，生活會變得容易得多：
 
- - 如果你已經很好地解釋了你的補丁，審閱人員會理解它的價值，以及爲什麼你會
-   費盡心思去寫它。但是這個並不能阻止他們提出一個基本的問題：在五年或十年後
-   維護含有此代碼的內核會怎麼樣？你可能被要求做出的許多改變——從編碼風格的
-   調整到大量的重寫——都來自於對Linux的理解，即從現在起十年後，Linux仍將
-   在開發中。
-
- - 代碼審查是一項艱苦的工作，這是一項相對喫力不討好的工作；人們記得誰編寫了
-   內核代碼，但對於那些審查它的人來說，幾乎沒有什麼長久的名聲。因此，審閱
-   人員可能會變得暴躁，尤其是當他們看到同樣的錯誤被一遍又一遍地犯下時。如果
-   你得到了一個看起來憤怒、侮辱或完全冒犯你的評論，請抑制以同樣方式回應的衝動。
-   代碼審查是關於代碼的，而不是關於人的，代碼審閱人員不會親自攻擊您。
-
- - 同樣，代碼審閱人員也不想以犧牲你僱主的利益爲代價來宣傳他們僱主的議程。
-   內核開發人員通常希望今後幾年能在內核上工作，但他們明白他們的僱主可能會改
-   變。他們真的，幾乎毫無例外地，致力於創造他們所能做到的最好的內核；他們並
-   沒有試圖給僱主的競爭對手造成不適。
-
-所有這些歸根結底就是，當審閱者向您發送評論時，您需要注意他們正在進行的技術
-評論。不要讓他們的表達方式或你自己的驕傲阻止此事。當你在一個補丁上得到評論
-時，花點時間去理解評論人想說什麼。如果可能的話，請修復審閱者要求您修復的內
-容。然後回覆審閱者：謝謝他們，並描述你將如何回答他們的問題。
-
-請注意，您不必同意審閱者建議的每個更改。如果您認爲審閱者誤解了您的代碼，請
-解釋到底發生了什麼。如果您對建議的更改有技術上的異議，請描述它並證明您對該
-問題的解決方案是正確的。如果你的解釋有道理，審閱者會接受的。不過，如果你的
-解釋證明缺乏說服力，尤其是當其他人開始同意審稿人的觀點時，請花些時間重新考慮
-一下。你很容易對自己解決問題的方法視而不見，以至於你沒有意識到某些東西完全
-是錯誤的，或者你甚至沒有解決正確的問題。
-
-Andrew Morton建議，每一個不會導致代碼更改的審閱評論都應該產生一個額外的代碼
-註釋；這可以幫助未來的審閱人員避免第一次出現的問題。
-
-一個致命的錯誤是忽視評論，希望它們會消失。它們不會走的。如果您在沒有對之前
-收到的評論做出響應的情況下重新發布代碼，那麼很可能會發現補丁毫無用處。
-
-說到重新發布代碼：請記住，審閱者不會記住您上次發佈的代碼的所有細節。因此，
-提醒審閱人員以前提出的問題以及您如何處理這些問題總是一個好主意；補丁變更
-日誌是提供此類信息的好地方。審閱者不必搜索列表檔案來熟悉上次所說的內容；
-如果您幫助他們直接開始，當他們重新查看您的代碼時，心情會更好。
-
-如果你已經試着做正確的事情，但事情仍然沒有進展呢？大多數技術上的分歧都可以
-通過討論來解決，但有時人們仍需要做出決定。如果你真的認爲這個決定對你不利，
-你可以試着向有更高權力的人上訴。對於本文，更高權力的人是 Andrew Morton 。
-Andrew 在內核開發社區中非常受尊敬；他經常爲似乎被絕望阻塞的事情清障。儘管
-如此，不應輕易就直接找 Andrew ，也不應在所有其他替代方案都被嘗試之前找他。
-當然，記住，他也可能不同意你的意見。
+ - 如果你已經很好地解釋了你的補丁，審閱者會理解它的價值，以及為什麼你會
+   費盡心思去寫它。但是這個價值並不能阻止他們提出一個基本的問題：五年或十
+   年後，維護一個含有此程式碼的核心會是什麼樣子？你可能被要求做出的許多改
+   變——從程式碼風格的調整到大量的重寫——都源於這樣的認識：十年後，Linux仍
+   將存在，並且仍在開發中。
+
+ - 程式碼審查是一項艱苦的工作，而且相對吃力不討好；人們記得誰編寫了核心程
+   式碼，但審查它的人卻很少能留下長久的名聲。因此，審閱者可能會變得暴躁，
+   尤其是當他們看到同樣的錯誤被一遍又一遍地犯下時。如果你收到的審閱意見看
+   起來憤怒、侮辱或完全冒犯，請抑制以同樣方式回應的衝動。程式碼審查針對的
+   是程式碼，而不是人，審閱者並不是在對您進行人身攻擊。
+
+ - 同樣，審閱者也不是要以犧牲你的利益為代價，來推動他們僱主的議程。核心開
+   發人員通常預期自己今後幾年仍會從事核心工作，但他們明白自己的僱主可能會
+   改變。他們真的幾乎毫無例外地致力於打造他們所能做到的最好的核心；他們並
+   沒有試圖給自己僱主的競爭對手製造麻煩。
+
+ - 對於看似無謂的程式碼風格修改要求，以及把部分程式碼抽出到核心共用部分的
+   要求，要有心理準備。維護人員的工作之一，就是讓各處看起來保持一致。有時
+   這意味著，你在驅動程式中為了繞過某個問題而寫的巧妙 hack，其實需要變成一
+   個通用的核心功能，供下次使用。
+
+所有這些歸根結底就是，當審閱者向您發送評論時，您需要注意他們提出的技術觀察。
+不要讓他們的表達方式或你自己的驕傲妨礙這一點。當你在一個補丁上得到審閱評論
+時，花點時間去理解審閱者想說什麼。如果可能的話，請修復審閱者要求您修復的內
+容。然後回覆審閱者：感謝他們，並描述你將如何回答他們的問題。
+
+請注意，您不必同意審閱者建議的每個更改。如果您認為審閱者誤解了您的程式碼，
+請解釋實際情況。如果您對建議的更改有技術上的異議，請描述它，並說明您對該問
+題的解決方案的理由。如果你的解釋有道理，審閱者會接受的。不過，如果你的解釋
+缺乏說服力，尤其是當其他人開始同意審閱者的觀點時，請花些時間重新考慮一下。
+你很容易被自己解決問題的方法蒙蔽，以至於沒有意識到某些東西根本上就是錯的，
+或者你甚至沒有在解決正確的問題。
+
+Andrew Morton建議，每一個沒有導致程式碼更改的審閱評論，都應該改為產生一個額
+外的程式碼註解；這可以幫助未來的審閱者避免再提出第一次出現過的問題。
+
+一個致命的錯誤是忽視審閱評論，希望它們會自行消失。它們不會消失的。如果您在
+沒有回應上次收到的評論的情況下重新發布程式碼，那麼很可能會發現您的補丁毫無
+進展。
+
+說到重新發布程式碼：請記住，審閱者不會記得您上次發布的程式碼的所有細節。因
+此，提醒審閱者先前提出的問題以及您如何處理這些問題，總是一個好主意；補丁變
+更日誌是提供此類資訊的好地方。審閱者不應該需要搜尋郵件列表存檔，才能熟悉上
+次討論的內容；如果您幫助他們快速進入狀況，當他們重新查看您的程式碼時，心情
+會更好。
+
+如果你已經試著把每件事都做對，但事情仍然沒有進展呢？大多數技術上的分歧都可
+以透過討論來解決，但有時就是必須有人做出決定。如果你真的認為這個決定錯誤地
+對你不利，你總是可以試著向更高權力者上訴。在撰寫本文時，這個更高權力者往往
+是 Andrew Morton。Andrew 在核心開發社群中非常受尊敬；他經常能夠疏通看似完全
+陷入僵局的情況。儘管如此，不應輕易就直接找 Andrew ，也不應在所有其他替代方
+案都被嘗試之前找他。當然，也請記住，他也可能不同意你的意見。
 
 接下來會發生什麼
 ----------------
 
-如果一個補丁被認爲適合添加到內核中，並且大多數審查問題得到解決，下一步通常
-是進入子系統維護人員的樹中。工作方式因子系統而異；每個維護人員都有自己的
-工作方式。特別是可能有不止一棵樹——也許一棵樹專門用於計劃下一個合併窗口的
-補丁，另一棵樹用於長期工作。
-
-對於應用到不屬於明顯子系統樹（例如內存管理修補程序）的區域的修補程序，默認樹
-通常上溯到-mm。影響多個子系統的補丁也可以最終進入-mm樹。
-
-包含在子系統樹中可以提高補丁的可見性。現在，使用該樹的其他開發人員將默認獲
-得補丁。子系統樹通常也爲Linux提供支持，使其內容對整個開發社區可見。在這一點
-上，您很可能會從一組新的審閱者那裏得到更多的評論；這些評論需要像上一輪那樣
-得到回應。
-
-在這時也會發生點什麼，這取決於你的補丁的性質，是否與其他人正在做的工作發生
-衝突。在最壞的情況下，嚴重的補丁衝突可能會導致一些工作被擱置，以便剩餘的補丁
-可以成形併合並。另一些時候，衝突解決將涉及到與其他開發人員合作，可能還會
-在樹之間移動一些補丁，以確保所有的應用都是乾淨的。這項工作可能是一件痛苦的
-事情，但也需慶幸現在的幸福：在linux-next樹出現之前，這些衝突通常只在合併窗口
-中出現，必須迅速解決。現在可以在合併窗口打開之前的空閒時間解決這些問題。
-
-有朝一日，如果一切順利，您將登錄並看到您的補丁已經合併到主線內核中。祝賀你！
-然而，一旦慶祝完了（並且您已經將自己添加到維護人員文件中），就一定要記住
-一個重要的小事實：工作仍然沒有完成。併入主線也帶來了它的挑戰。
-
-首先，補丁的可見性再次提高。可能會有以前不知道這個補丁的開發者的新一輪評論。
-忽略它們可能很有誘惑力，因爲您的代碼不再存在任何被合併的問題。但是，要抵制
-這種誘惑，您仍然需要對有問題或建議的開發人員作出響應。
-
-不過，更重要的是：將代碼包含在主線中會將代碼交給更多的一些測試人員。即使您
-爲尚未可用的硬件提供了驅動程序，您也會驚訝於有多少人會將您的代碼構建到內核
-中。當然，如果有測試人員，也可能會有錯誤報告。
-
-最糟糕的錯誤報告是迴歸。如果你的補丁導致迴歸，你會發現多到讓你不舒服的眼睛盯
-着你；迴歸需要儘快修復。如果您不願意或無法修復迴歸（其他人都不會爲您修復），
-那麼在穩定期內，您的補丁幾乎肯定會被移除。除了否定您爲使補丁進入主線所做的
-所有工作之外，如果由於未能修復迴歸而取消補丁，很可能會使將來的工作更難被合併。
-
-在處理完任何迴歸之後，可能還有其他普通缺陷需要處理。穩定期是修復這些錯誤並
-確保代碼在主線內核版本中的首次發佈儘可能可靠的最好機會。所以，請回應錯誤
-報告，並儘可能解決問題。這就是穩定期的目的；一旦解決了舊補丁的任何問題，就
-可以開始盡情創建新補丁。
-
-別忘了，還有其他節點也可能會創建缺陷報告：下一個主線穩定版本，當著名的發行
-商選擇包含您補丁的內核版本時等等。繼續響應這些報告是您工作的基本素養。但是
-如果這不能提供足夠的動機，那麼也需要考慮：開發社區會記住那些在合併後對代碼
-失去興趣的開發人員。下一次你發佈補丁時，他們會以你以後不會持續維護它爲前提
-來評估它。
+如果一個補丁被認為適合添加到核心中，並且大多數審閱問題都已解決，下一步通常
+是進入子系統維護人員的樹中。具體如何運作因子系統而異；每個維護人員都有自己
+的工作方式。特別是，可能有不止一棵樹——也許一棵樹專門用於計劃在下一個合併視
+窗合併的補丁，另一棵樹用於較長期的工作。
+
+對於不屬於任何明顯子系統樹的領域的補丁（例如記憶體管理補丁），預設的樹通常
+是-mm。影響多個子系統的補丁也可能最終經由-mm樹合併。
+
+被納入子系統樹可以提高補丁的能見度。現在，使用該樹的其他開發人員將預設獲得
+該補丁。子系統樹通常也會匯入linux-next，使其內容對整個開發社群可見。此時，
+您很可能會從一批新的審閱者那裡得到更多的評論；這些評論需要像上一輪那樣得到
+回應。
+
+在這個階段，取決於您補丁的性質，也可能會出現與其他人正在進行的工作發生衝突
+的情況。在最壞的情況下，嚴重的補丁衝突可能會導致一些工作被擱置，以便剩餘的
+補丁可以成形並合併。另一些時候，解決衝突將涉及與其他開發人員合作，可能還會
+在樹之間移動一些補丁，以確保所有補丁都能乾淨地套用。這項工作可能令人頭痛，
+但也該慶幸：在linux-next樹出現之前，這些衝突通常只在合併視窗期間出現，必須
+倉促解決。現在可以在合併視窗開啟之前從容地解決這些問題。
+
+有朝一日，如果一切順利，您將登入並看到您的補丁已經合併到主線核心中。恭喜！
+然而，一旦慶祝完了（並且您已經將自己添加到MAINTAINERS檔案中），就值得記住
+一個重要的小事實：工作仍然沒有完成。併入主線也帶來了它自己的挑戰。
+
+首先，補丁的能見度再次提高。可能會有以前不知道這個補丁的開發人員提出新一輪
+的評論。忽略它們可能很有誘惑力，因為您的程式碼已經不存在能否被合併的問題了。
+但是，要抵制這種誘惑；您仍然需要回應那些有問題或建議的開發人員。
+
+不過，更重要的是：被納入主線會將您的程式碼交到更大一群測試人員的手中。即使
+您貢獻的是尚未上市的硬體的驅動程式，您也會驚訝於有多少人會將您的程式碼建置
+到他們的核心中。當然，有測試人員的地方，就會有錯誤報告。
+
+最糟糕的錯誤報告是迴歸。如果你的補丁導致迴歸，你會發現多到讓你不舒服的眼睛
+盯著你；迴歸需要儘快修復。如果您不願意或無法修復迴歸（而且也沒有其他人替您
+修復），那麼在穩定期內，您的補丁幾乎肯定會被移除。除了抹煞您為使補丁進入主
+線所做的所有工作之外，因未能修復迴歸而被撤下補丁，很可能會使您將來的工作更
+難被合併。
+
+在處理完任何迴歸之後，可能還有其他普通錯誤需要處理。穩定期是修復這些錯誤的
+最好機會，並確保您的程式碼在主線核心版本中首次亮相時儘可能穩固。所以，請回
+應錯誤報告，並儘可能解決問題。這就是穩定期的目的；一旦舊補丁的任何問題都處
+理好了，就可以開始建立很酷的新補丁。
+
+別忘了，還有其他里程碑也可能會產生錯誤報告：下一個主線穩定版本、知名發行商
+採用包含您補丁的核心版本時等等。繼續回應這些報告，是對自己工作的基本自豪。
+但是如果這還不足以成為動機，那麼也值得考慮：開發社群會記住那些在程式碼合併
+後就失去興趣的開發人員。下一次你發布補丁時，他們會以你之後不會在場維護它為
+前提來評估它。
 
 其他可能發生的事情
 ------------------
 
-某天，當你打開你的郵件客戶端時，看到有人給你寄了一個代碼補丁。畢竟，這是
-讓您的代碼公開存在的好處之一。如果您同意這個補丁，您可以將它轉發給子系統
-維護人員（確保包含一個正確的From:行，這樣屬性是正確的，並添加一個您自己的
-signoff ），或者回復一個 Acked-by: 讓原始發送者向上發送它。
+某天，當你打開你的郵件用戶端時，可能會看到有人寄給你一個針對你程式碼的補丁。
+畢竟，這是讓您的程式碼公開的好處之一。如果您同意這個補丁，您可以將它轉發給
+子系統維護人員（確保包含一個正確的From:行，使作者歸屬正確，並添加一個您自己
+的 signoff），或者回覆一個 Acked-by: 讓原始發送者將它向上提交。
 
 如果您不同意補丁，請禮貌地回覆，解釋原因。如果可能的話，告訴作者需要做哪些
-更改才能讓您接受補丁。合併代碼的編寫者和維護者所反對的補丁的確存在着一定的
-阻力，但僅此而已。如果你被認爲不必要的阻礙了好的工作，那麼這些補丁最終會
-繞過你並進入主線。在Linux內核中，沒有人對任何代碼擁有絕對的否決權。可能除
-了Linus。
-
-在非常罕見的情況下，您可能會看到完全不同的東西：另一個開發人員發佈了針對您
-的問題的不同解決方案。在這時，兩個補丁之一可能不會被合併，“我的補丁首先
-發佈”不被認爲是一個令人信服的技術論據。如果有別人的補丁取代了你的補丁而進
-入了主線，那麼只有一種方法可以回應你：很高興你的問題解決了，請繼續工作吧。
-以這種方式把某人的工作推到一邊可能導致傷心和氣餒，但是社區會記住你的反應，
-即使很久以後他們已經忘記了誰的補丁真正被合併。
+更改才能讓您接受補丁。對於程式碼的作者和維護者所反對的補丁，合併時確實存在
+一定的阻力，但這種阻力也只有這麼大。如果你被認為在不必要地阻礙好的工作，那
+麼這些補丁最終會繞過你並進入主線。在Linux核心中，沒有人對任何程式碼擁有絕對
+的否決權。可能除了Linus。
+
+在非常罕見的情況下，您可能會看到完全不同的東西：另一個開發人員針對您的問題
+發布了不同的解決方案。這時，兩個補丁之一很可能不會被合併，而且“我的補丁先
+發布”並不被認為是一個令人信服的技術論據。如果有別人的補丁取代了你的補丁而
+進入了主線，那麼只有一種回應方式：為你的問題得到解決感到高興，然後繼續你的
+工作。自己的工作以這種方式被推到一邊，可能令人受傷和氣餒，但是在社群早已忘
+記究竟是誰的補丁被合併之後很久，他們仍會記得你的反應。
 
-- 
2.43.0

[PATCH 06/25] docs/zh_TW: process: sync 7.AdvancedTopics.rst with the English original

[Chen-Yu Yeh]

The translation was marked as updated to commit 5ce70894f6ca ("Doc:
correct spelling and wording mistakes"), but its content predates
commit 93431e0607e5 ("Replace HTTP links with HTTPS ones:
documentation") and commit 6e55b1cbf05d ("docs: try to encourage
(netdev?) reviewers"): the lwn.net link was still http:// and the
reviewing section lacked the paragraphs added by "docs: try to encourage
(netdev?) reviewers".  A section-by-section comparison against the
current English text brings it in line with the full current original:

- add the _reviews label and the missing reviewing advice: asking
  others to chime in when a discussion stalls, reviews in plain English
  being encouraged even when a Reviewed-by tag is given, and throwing
  in a compliment once in a while
- switch the lwn.net link to https
- capitalize Git where the original now refers to the tool, and fix the
  BitKeeper spelling
- retranslate sentences whose meaning had drifted (pushing changes that
  do not fast-forward, overriding that check, moving work into public
  branches once it is reasonably advanced, ill-advised changes slipping
  in below the review radar)
- keep the Linus quote in its literal block in English and add a
  Chinese translation after it, as in 2.Process.rst
- replace tabs with spaces in the URL block, and wrap the :Original:
  line to keep it within 80 columns, as in stable-api-nonsense.rst

update to commit 4a0be1a25d98 ("Documentation: process: Capitalize Git,
Quilt, and Mercurial consistently")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/7.AdvancedTopics.rst        | 53 +++++++++++++------
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
index 392c00213078..161c1afdd43f 100644
--- a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
@@ -2,7 +2,8 @@
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :ref:`Documentation/process/7.AdvancedTopics.rst <development_advancedtopics>`
+:Original: :ref:`Documentation/process/7.AdvancedTopics.rst
+           <development_advancedtopics>`
 
 .. _tw_development_advancedtopics:
 
@@ -15,20 +16,20 @@
 使用Git管理補丁
 ---------------
 
-核心使用分散式版本控制始於2002年初，當時Linus首次開始使用專有的Bitkeeper應用
+核心使用分散式版本控制始於2002年初，當時Linus首次開始使用專有的BitKeeper應用
 程式。雖然BitKeeper存在爭議，但它所體現的軟體版本管理方法卻肯定不是。分散式
 版本控制可以立即加速核心開發專案。現在有好幾種自由的BitKeeper替代品。
 但無論好壞，核心專案都已經選擇了Git作為其工具。
 
 使用Git管理補丁可以使開發人員的生活更加輕鬆，尤其是隨著補丁數量的增長。Git也
 有其粗糙的邊角和一定的危險性，它是一個年輕和強大的工具，仍然在其開發人員完善
-中。本文件不會試圖教會讀者如何使用git；這會是個巨長的文件。相反，這裡的重點
+中。本文件不會試圖教會讀者如何使用Git；這會是個巨長的文件。相反，這裡的重點
 將是Git如何特別適合核心開發過程。想要加快用Git速度的開發人員可以在以下網站上
 找到更多資訊：
 
-	https://git-scm.com/
+        https://git-scm.com/
 
-	https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
+        https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
 
 同時網上也能找到各種各樣的教程。
 
@@ -39,7 +40,7 @@
 快進合併、推拉、遊離頭等。一開始可能有點嚇人，但這些概念不難透過一點學習來
 理解。
 
-使用git產生透過電子郵件提交的補丁是提高速度的一個很好的練習。
+使用Git產生透過電子郵件提交的補丁是提高速度的一個很好的練習。
 
 當您準備好開始建立Git樹供其他人查看時，無疑需要一個可以從中拉取的伺服器。
 如果您有一個可以連上網際網路的系統，那麼使用git-daemon設定這樣的伺服器相對
@@ -50,14 +51,14 @@
 正常的Git工作流程涉及到許多分支的使用。每一條開發線都可以分為單獨的“主題
 分支”，並獨立維護。Git的分支很容易使用，沒有理由不使用它們。而且，在任何
 情況下，您都不應該在任何您打算讓其他人從中拉取的分支中進行開發。應該小心地
-建立公開可用的分支；當開發分支處於完整狀態並已準備好時(而不是之前）才合併
+建立公開可用的分支；當開發分支處於完整狀態並已準備好時（而不是之前）才合併
 開發分支的補丁。
 
 Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不方便的補丁（比如說，
 一個打破二分法的補丁，或者有其他一些明顯的缺陷）可以在適當的位置修復，或者
 完全從歷史中消失。一個補丁系列可以被重寫，就好像它是在今天的主線上寫的一樣，
 即使你已經花了幾個月的時間在寫它。可以透明地將更改從一個分支轉移到另一個
-分支。等等。明智地使用git修改歷史的能力可以幫助建立問題更少的乾淨補丁集。
+分支。等等。明智地使用Git修改歷史的能力可以幫助建立問題更少的乾淨補丁集。
 
 然而，過度使用這種功能可能會導致其他問題，而不僅僅是對建立完美專案歷史的
 簡單癡迷。重寫歷史將重寫該歷史中包含的更改，將經過測試（希望如此）的核心樹
@@ -67,11 +68,11 @@ Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不
 在此後通常被認為是不可變的。
 
 因此，一旦將一組更改推送到公開可用的伺服器上，就不應該重寫這些更改。如果您
-嘗試強制進行無法快進合併的更改（即不共享同一歷史記錄的更改），Git將嘗試強制
-執行此規則。這可能覆蓋檢查，有時甚至需要重寫導出的樹。在樹之間移動變更集以
-避免linux-next中的衝突就是一個例子。但這種行為應該是罕見的。這就是為什麼
-開發應該在私有分支中進行（必要時可以重寫）並且只有在公共分支處於合理的較新
-狀態時才轉移到公共分支中的原因之一。
+嘗試推送無法快進合併的更改（即不共享同一歷史記錄的更改），Git將嘗試強制執行
+此規則。可以覆蓋這項檢查，有時也可能確實需要重寫已導出的樹。在樹之間移動變更
+集以避免linux-next中的衝突就是一個例子。但這種行為應該是罕見的。這就是為什麼
+開發應該在私有分支中進行（必要時可以重寫），並且只有在開發進入相當成熟的狀態
+時才轉移到公共分支中的原因之一。
 
 當主線（或其他一組變更所基於的樹）前進時，很容易與該樹合併以保持領先地位。
 對於一個私有的分支，rebasing 可能是一個很容易跟上另一棵樹的方法，但是一旦
@@ -83,16 +84,21 @@ Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不
 就不必重複相同的工作。
 
 關於Git這樣的工具的一個最大的反覆抱怨是：補丁從一個儲存庫到另一個儲存庫的
-大量移動使得很容易陷入錯誤建議的變更中，這些變更避開審查雷達進入主線。當內
+大量移動使得考慮欠周的變更很容易混入，在審查雷達之下溜進主線。當內
 核開發人員看到這種情況發生時，他們往往會感到不高興；在Git樹上放置未審閱或
 主題外的補丁可能會影響您將來讓樹被拉取的能力。引用Linus的話:
 
 ::
 
-   你可以給我發補丁，但當我從你那裡拉取一個Git補丁時，我需要知道你清楚
-   自己在做什麼，我需要能夠相信事情而 *無需* 手動檢查每個單獨的更改。
+        You can send me patches, but for me to pull a Git patch from you, I
+        need to know that you know what you're doing, and I need to be able
+        to trust things *without* then having to go and check every
+        individual change by hand.
 
-（http://lwn.net/Articles/224135/）。
+（中譯：你可以給我發補丁，但當我從你那裡拉取一個Git補丁時，我需要知道你清楚
+自己在做什麼，我需要能夠相信事情而 *無需* 手動檢查每個單獨的更改。）
+
+(https://lwn.net/Articles/224135/)。
 
 為了避免這種情況，請確保給定分支中的所有補丁都與相關主題緊密相關；“驅動程式
 修復”分支不應更改核心記憶體管理程式碼。而且，最重要的是，不要使用Git樹來繞過
@@ -107,6 +113,8 @@ Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不
 更改。在這方面 git request-pull 命令非常有用；它將按照其他開發人員所期望的
 格式化請求，並檢查以確保您已記得將這些更改推送到公共伺服器。
 
+.. _tw_development_advancedtopics_reviews:
+
 審閱補丁
 --------
 
@@ -121,9 +129,20 @@ Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不
 閱者最好的建議是：把審閱評論當成問題而不是批評。詢問“在這條路徑中如何釋放
 鎖？”總是比說“這裡的鎖是錯誤的”更好。
 
+出現分歧時，另一個有用的技巧是邀請其他人加入討論。如果幾輪交流後討論陷入
+僵局，就請其他審閱者或維護者發表意見。通常，與某位審閱者意見一致的人除非被
+點名，否則往往保持沉默。多人的意見會帶來成倍的分量。
+
 不同的開發人員將從不同的角度審查程式碼。部分人會主要關注程式碼風格以及程式
 碼行是否有尾隨空格。其他人會主要關注補丁作為一個整體實作的變更是否對核心有
 好處。同時也有人會檢查是否存在鎖問題、堆疊使用過度、可能的安全問題、在其他
 地方發現的程式碼重複、足夠的文件、對效能的不利影響、使用者空間ABI更改等。
 所有類型的檢查，只要它們能引導更好的程式碼進入核心，都是受歡迎和值得的。
 
+並沒有嚴格要求一定要使用 ``Reviewed-by`` 這類特定標籤。事實上，即使提供了
+標籤，也鼓勵用淺白的英文寫下審閱意見，這樣資訊量更大，例如：“我看過了這次
+提交的 A、B 和 C 方面，看起來沒有問題。”顯然，某種形式的審閱訊息或回覆是
+必要的，否則維護者根本無從得知審閱者是否看過這個補丁！
+
+最後但同樣重要的是，補丁審閱可能會變成一個專注於指出問題的負面過程。請偶爾
+給予稱讚，特別是對新手！
-- 
2.43.0

[PATCH 07/25] docs/zh_TW: process: sync 8.Conclusion.rst with the English original

[Chen-Yu Yeh]

The translation carried no "update to commit" marker.  Its first
paragraph still followed the wording from before
commit 9db370de2780 ("docs: process: remove outdated
submitting-drivers.rst"): it called howto.rst "an important starting
point" and described submitting-patches.rst as "something which all
kernel developers should read", while the English text now simply says
to start with howto.rst and also read submitting-patches.rst.  A
section-by-section comparison against the current English text brings it
in line with the full current original:

- retranslate the opening paragraph to match the current wording, and
  write TeX as in the original
- retranslate the sentence on why the kernel has progressed as quickly
  and as well as it has, which had been rendered as "as fast as before"
- wrap the :Original: line, the cross-references and the LDD3 entry to
  keep them within 80 columns, as in 7.AdvancedTopics.rst and
  5.Posting.rst

update to commit 9db370de2780 ("docs: process: remove outdated
submitting-drivers.rst")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/8.Conclusion.rst            | 27 ++++++++++---------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst
index 2436263c6506..fdba290d0eba 100644
--- a/Documentation/translations/zh_TW/process/8.Conclusion.rst
+++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst
@@ -2,7 +2,8 @@
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :ref:`Documentation/process/8.Conclusion.rst <development_conclusion>`
+:Original: :ref:`Documentation/process/8.Conclusion.rst
+           <development_conclusion>`
 
 .. _tw_development_conclusion:
 
@@ -10,13 +11,13 @@
 ========
 
 關於Linux核心開發和相關主題的資訊來源很多。首先是在核心原始碼分發中找到的
-文件目錄。頂級
-:ref:`Documentation/translations/zh_TW/process/howto.rst <tw_process_howto>`
-文件是一個重要的起點；
-:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
-也是所有核心開發人員都應該閱讀的內容。許多內部核心API都是使用kerneldoc機制
-記錄的；“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式產生這些文件
-（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文件）。
+文件目錄。請從頂層的
+:ref:`Documentation/process/howto.rst <tw_process_howto>`
+開始；也請閱讀
+:ref:`Documentation/process/submitting-patches.rst <tw_submittingpatches>`。
+許多內部核心 API 都是使用 kerneldoc 機制記錄的；“make htmldocs”或“make pdfdocs”
+可用於以 HTML 或 PDF 格式產生這些文件（儘管某些發行版提供的 TeX 版本會遇到內部
+限制，無法正確處理文件）。
 
 不同的網站在各個細節層次上討論核心開發。本文作者想謙虛地建議用 https://lwn.net/
 作為來源；有關許多特定核心主題的資訊可以透過以下網址的 LWN 核心索引找到：
@@ -31,8 +32,8 @@
 
 關於核心開發有很多書：
 
-  《Linux設備驅動程序》第三版（Jonathan Corbet、Alessandro Rubini和Greg Kroah-Hartman）
-  線上版本在 https://lwn.net/Kernel/LDD3/
+  《Linux設備驅動程序》第三版（Jonathan Corbet、Alessandro Rubini和
+  Greg Kroah-Hartman）。線上版本在 https://lwn.net/Kernel/LDD3/ 。
 
   《Linux核心設計與實現》（Robert Love）
 
@@ -54,9 +55,9 @@
 以及您如何參與這個過程。
 
 最後，重要的是參與。任何開源軟體專案都不會超過其貢獻者投入其中的總和。Linux
-核心的發展速度和以前一樣快，因為它得到了大量開發人員的幫助，他們都在努力使它
-變得更好。核心是一個最成功的例子，說明了當成千上萬的人為了一個共同的目標一起
-工作時，可以做出什麼。
+核心之所以能發展得如此迅速、如此良好，是因為有一大群人數驚人的開發人員協助，
+他們都在努力使它變得更好。核心是一個最成功的例子，說明了當成千上萬的人為了一個
+共同的目標一起工作時，可以做出什麼。
 
 不過，核心總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣
 重要的是，Linux生態系統中的大多數其他參與者可以透過為核心做出貢獻而受益。
-- 
2.43.0

[PATCH 08/25] docs/zh_TW: process: sync code-of-conduct-interpretation.rst with the English original

[Chen-Yu Yeh]

The previous update claimed to track
commit 04c4bb90ae6e ("Documentation/CoC: Spell out the TAB role in
enforcement decisions"), but the conflict mediator contact was still the
one from before commit 5fddf8962b42 ("docs: update mediator contact
information in CoC doc") and commit 8bfdfa0d6b92 ("docs: update mediator
information in CoC docs").  Update it to Joanna Lee
<jlee@linuxfoundation.org>.

While at it, translate "file" in the Maintainers and Scope sections as
檔案 and keep the MAINTAINERS file name untranslated, matching the rest
of process/, and rewrap lines that exceeded 80 columns.

update to commit 04c4bb90ae6e ("Documentation/CoC: Spell out the TAB
role in enforcement decisions")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../process/code-of-conduct-interpretation.rst   | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 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 4fc568409198..6f87b104a96d 100644
--- a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
+++ b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
@@ -2,16 +2,18 @@
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst <code_of_conduct_interpretation>`
+:Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst
+           <code_of_conduct_interpretation>`
 
 .. _tw_code_of_conduct_interpretation:
 
 Linux核心貢獻者契約行為準則解釋
 ===============================
 
-:ref:`tw_code_of_conduct` 準則是一個通用文件，旨在為幾乎所有開源社群提供一套規則。
-每個開源社群都是獨一無二的，Linux核心也不例外。因此，本文描述了Linux核心社群中
-如何解釋它。我們也不希望這種解釋隨著時間的推移是靜態的，並將根據需要進行調整。
+:ref:`tw_code_of_conduct` 準則是一個通用文件，旨在為幾乎所有開源社群提供一套
+規則。每個開源社群都是獨一無二的，Linux核心也不例外。因此，本文描述了Linux核心
+社群中如何解釋它。我們也不希望這種解釋隨著時間的推移是靜態的，並將根據需要
+進行調整。
 
 與開發軟體的“傳統”方法相比，Linux核心開發工作是一個非常個人化的過程。你的貢獻
 和背後的想法將被仔細審查，往往導致批判和批評。審查將幾乎總是需要改進，材料才
@@ -23,7 +25,7 @@ Linux核心貢獻者契約行為準則解釋
 ------
 
 行為準則多次使用“維護者”一詞。在核心社群中，“維護者”是負責子系統、驅動程式或
-文件的任何人，並在核心原始程式碼樹的維護者文件中列出。
+檔案的任何人，並在核心原始程式碼樹的 MAINTAINERS 檔案中列出。
 
 責任
 ----
@@ -39,7 +41,7 @@ Linux核心貢獻者契約行為準則解釋
 維護人員應該願意在出現問題時提供幫助，並在需要時與社群中的其他人合作。如果您
 不確定如何處理出現的情況，請不要害怕聯繫技術諮詢委員會（TAB）或其他維護人員。
 除非您願意，否則不會將其視為違規報告。如果您不確定是否該聯繫TAB 或任何其他維
-護人員，請聯繫我們的衝突調解人 Mishi Choudhary <mishi@linux.com>。
+護人員，請聯繫我們的衝突調解人 Joanna Lee <jlee@linuxfoundation.org>。
 
 最後，“善待對方”才是每個人的最終目標。我們知道每個人都是人，有時我們都會失敗，
 但我們所有人的首要目標應該是努力友好地解決問題。執行行為準則將是最後的選擇。
@@ -64,7 +66,7 @@ Linux核心貢獻者契約行為準則解釋
 
 Linux核心社群主要在一組公共電子郵件列表上進行交互，這些列表分佈在由多個不同
 公司或個人控制的多個不同伺服器上。所有這些列表都在核心原始程式碼樹中的
-MAINTAINERS 文件中定義。發送到這些郵件列表的任何電子郵件都被視為包含在行為
+MAINTAINERS 檔案中定義。發送到這些郵件列表的任何電子郵件都被視為包含在行為
 準則中。
 
 使用 kernel.org bugzilla和其他子系統bugzilla 或bug追蹤工具的開發人員應該遵循
-- 
2.43.0

[PATCH 09/25] docs/zh_TW: process: sync code-of-conduct.rst with the English original

[Chen-Yu Yeh]

The translation carried no "update to commit" marker.  A
section-by-section comparison against the current English text shows
that every section is present, including the conduct@kernel.org contact
from commit f3f76d640141 ("Code of Conduct: Change the contact email
address") and the Interpretation section from commit f7e585843217 ("Code
of Conduct: Provide links between the two documents"), but the text was
still a mechanical conversion of zh_CN:

- fix leftover mainland terms (內核, 社區, 項目, 代碼, 信息, 文檔, 通過,
  在線/離線, 帳戶) and use 為 instead of 爲
- retranslate items whose meaning had drifted: "commits" (承諾),
  "ethnicity" (rendered as 種族 like "race"), "socio-economic status"
  (split into two items), "empathy", "unwelcome sexual attention or
  advances", "physical address", "official" project e-mail address and
  social media account, and "online or offline event"
- restore "appropriate to the circumstances" in the Enforcement section
- restructure the Responsibilities sentence so that "inappropriate,
  threatening, offensive, or harmful" qualifies the behaviors for which
  a contributor may be banned

update to commit f3f76d640141 ("Code of Conduct: Change the contact
email address")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/code-of-conduct.rst         | 54 +++++++++----------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/code-of-conduct.rst b/Documentation/translations/zh_TW/process/code-of-conduct.rst
index 0266cd74a0b1..d6b253d3bac6 100644
--- a/Documentation/translations/zh_TW/process/code-of-conduct.rst
+++ b/Documentation/translations/zh_TW/process/code-of-conduct.rst
@@ -6,69 +6,69 @@
 
 .. _tw_code_of_conduct:
 
-貢獻者契約行爲準則
+貢獻者契約行為準則
 ++++++++++++++++++
 
 我們的誓言
 ==========
 
-爲了營造一個開放、友好的環境，我們作爲貢獻者和維護人承諾，讓我們的社區和參
-與者，擁有一個無騷擾的體驗，無論年齡、體型、殘疾、種族、性別特徵、性別認同
-和表達、經驗水平、教育程度、社會狀況，經濟地位、國籍、個人外貌、種族、宗教
-或性身份和取向。
+為了營造一個開放、友好的環境，我們作為貢獻者和維護人員承諾，讓參與我們的專案
+和社群成為每個人都不受騷擾的體驗，無論年齡、體型、身心障礙、族裔、性別特徵、
+性別認同和表達、經驗水平、教育程度、社會經濟地位、國籍、個人外貌、種族、宗教
+或性認同和性取向。
 
 我們的標準
 ==========
 
-有助於創造積極環境的行爲包括：
+有助於創造積極環境的行為包括：
 
 * 使用歡迎和包容的語言
 * 尊重不同的觀點和經驗
 * 優雅地接受建設性的批評
-* 關注什麼對社區最有利
-* 對其他社區成員表示同情
+* 關注什麼對社群最有利
+* 對其他社群成員展現同理心
 
-參與者的不可接受行爲包括：
+參與者的不可接受行為包括：
 
-* 使用性意味的語言或意象以及不受歡迎的性注意或者更過分的行爲
-* 煽動、侮辱/貶損評論以及個人或政治攻擊
+* 使用帶有性意味的語言或圖像，以及不受歡迎的性關注或性挑逗
+* 惡意挑釁、侮辱/貶損的評論以及人身或政治攻擊
 * 公開或私下騷擾
-* 未經明確許可，發佈他人的私人信息，如物理或電子地址。
-* 在專業場合被合理認爲不適當的其他行爲
+* 未經明確許可，公開他人的私人資訊，如實體或電子地址
+* 在專業場合中可被合理認為不適當的其他行為
 
 我們的責任
 ==========
 
-維護人員負責澄清可接受行爲的標準，並應針對任何不可接受行爲採取適當和公平的
+維護人員負責澄清可接受行為的標準，並應針對任何不可接受行為採取適當和公平的
 糾正措施。
 
-維護人員有權和責任刪除、編輯或拒絕與本行爲準則不一致的評論、承諾、代碼、
-wiki編輯、問題和其他貢獻，或暫時或永久禁止任何貢獻者從事他們認爲不適當、
-威脅、冒犯或有害的其他行爲。
+維護人員有權利和責任刪除、編輯或拒絕與本行為準則不一致的評論、提交、程式碼、
+wiki 編輯、問題和其他貢獻，或暫時或永久禁止任何從事他們認為不適當、威脅、
+冒犯或有害之其他行為的貢獻者。
 
 範圍
 ====
 
-當個人代表項目或其社區時，本行爲準則既適用於項目空間，也適用於公共空間。
-代表一個項目或社區的例子包括使用一個正式的項目電子郵件地址，通過一個正式
-的社交媒體帳戶發佈，或者在在線或離線事件中擔任指定的代表。項目維護人員可以
-進一步定義和澄清項目的表示。
+當個人代表專案或其社群時，本行為準則既適用於專案空間，也適用於公共空間。
+代表一個專案或社群的例子包括使用專案的官方電子郵件地址、透過官方社群媒體帳號
+發佈內容，或者在線上或線下活動中擔任指定的代表。專案維護人員可以進一步定義和
+澄清專案的代表方式。
 
 執行
 ====
 
-如有濫用、騷擾或其他不可接受的行爲，可聯繫行爲準則委員會<conduct@kernel.org>。
-所有投訴都將接受審查和調查，並將得到必要和適當的答覆。行爲準則委員會有義務
-對事件報告人保密。具體執行政策的進一步細節可單獨公佈。
+如有濫用、騷擾或其他不可接受的行為，可聯繫行為準則委員會 <conduct@kernel.org>。
+所有投訴都將接受審查和調查，並將得到視情況認為必要和適當的回應。行為準則委員會
+有義務對事件報告人保密。具體執行政策的進一步細節可另行公佈。
 
 歸屬
 ====
 
-本行爲準則改編自《貢獻者契約》，版本1.4，可從
+本行為準則改編自《貢獻者契約》，版本 1.4，可從
 https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 獲取。
 
 解釋
 ====
 
-有關Linux內核社區如何解釋此文檔，請參閱 :ref:`tw_code_of_conduct_interpretation`
-
+有關 Linux 核心社群將如何解釋此文件，請參閱
+:ref:`tw_code_of_conduct_interpretation` 。
-- 
2.43.0

[PATCH 10/25] docs/zh_TW: process: sync gdb-kernel-debugging.rst with the English original

[Chen-Yu Yeh]

The translation carries "update to commit d5af79c05e93 ("Documentation:
move dev-tools debugging files to process/debugging/")", but as
commit e07f694cbd09 ("docs/zh_TW: move gdb-kernel-debugging to
process/debugging/") already noted, that marker was the oldest baseline
checktransupdate.py could see after the move, not the version the text
follows.  A section-by-section comparison against the current English
text shows the translation includes the lx_per_cpu examples from
commit 09e1d93a421f ("scripts/gdb: update documentation for
lx_per_cpu"), but lacks the "make scripts_gdb" step from
commit 6b219431037b ("docs/scripts/gdb: add necessary make scripts_gdb
step") and the "Debugging GDB scripts" section from
commit 7f7f468548ce ("Documentation: Provide hints on how to debug
Python GDB scripts").  Bring it in line with the full current original:

- add the "Build the gdb scripts" step and the "Debugging GDB scripts"
  section
- drop text the original does not have: the "(kernel source build)"
  note on the cd step and the "(command not found)" note on the
  auto-load warning, and a duplicated word in the breakpoint step
- translate "convenience functions" and "a snapshot of the initial
  version" as written instead of as "debugging helpers" and "some
  examples of the initial version"
- replace the mainland terms left over from the zh_CN conversion
  (調試, 內核, 模塊, 加載, 接口, 硬件, 信息, 文檔, 命令行, 函數, 字段,
  斷點, 鏡像, 控制檯, ...) with Taiwanese usage, and use 為, 啟 and 才
- add the SPDX-License-Identifier line carried by the other zh_TW
  translations in process/

Now that the file is in sync, drop the unmaintained-zh_TW.rst notice
that commit 6561dd301873 ("docs/zh_TW: add a notice for translations
not kept in sync") added until it was updated.

update to commit 7f7f468548ce ("Documentation: Provide hints on how to
debug Python GDB scripts")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../debugging/gdb-kernel-debugging.rst        | 104 ++++++++++--------
 1 file changed, 60 insertions(+), 44 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/debugging/gdb-kernel-debugging.rst b/Documentation/translations/zh_TW/process/debugging/gdb-kernel-debugging.rst
index 45f178c0bf59..81e6433f16e4 100644
--- a/Documentation/translations/zh_TW/process/debugging/gdb-kernel-debugging.rst
+++ b/Documentation/translations/zh_TW/process/debugging/gdb-kernel-debugging.rst
@@ -1,67 +1,75 @@
+.. SPDX-License-Identifier: GPL-2.0
+
 .. highlight:: none
 
 .. include:: ../../disclaimer-zh_TW.rst
-.. include:: ../../unmaintained-zh_TW.rst
 
 :Original: Documentation/process/debugging/gdb-kernel-debugging.rst
 
-通過gdb調試內核和模塊
-=====================
+透過gdb對核心與模組除錯
+=======================
+
+核心除錯器kgdb、QEMU等hypervisor，或基於JTAG的硬體介面，都能在執行期間使用
+gdb對Linux核心及其模組除錯。Gdb提供了強大的python腳本介面，核心也提供了一組
+輔助腳本，可以簡化典型的核心除錯步驟。本文是一份簡短的教學，說明如何啟用與
+使用這些腳本。本文以QEMU/KVM虛擬機器作為目標，但其中的範例也同樣適用於其他
+gdb stub。
 
-Kgdb內核調試器、QEMU等虛擬機管理程序或基於JTAG的硬件接口，支持在運行時使用gdb
-調試Linux內核及其模塊。Gdb提供了一個強大的python腳本接口，內核也提供了一套
-輔助腳本以簡化典型的內核調試步驟。本文檔爲如何啓用和使用這些腳本提供了一個簡要的教程。
-此教程基於QEMU/KVM虛擬機，但文中示例也適用於其他gdb stub。
 
+需求
+----
 
-環境配置要求
-------------
+- gdb 7.2+（建議：7.4+），並啟用python支援（各發行版通常都已啟用）
 
-- gdb 7.2+ (推薦版本: 7.4+) 且開啓python支持 (通常發行版上都已支持)
 
-設置
+設定
 ----
 
-- 創建一個QEMU/KVM的linux虛擬機（詳情請參考 www.linux-kvm.org 和 www.qemu.org ）。
-  對於交叉開發，https://landley.net/aboriginal/bin 提供了一些鏡像和工具鏈，
-  可以幫助搭建交叉開發環境。
+- 為QEMU/KVM建立一台Linux虛擬機器（詳情請參考www.linux-kvm.org與
+  www.qemu.org）。若要進行交叉開發，https://landley.net/aboriginal/bin 提供了
+  一批機器映像檔與工具鏈，可以作為起點。
+
+- 建置核心時啟用CONFIG_GDB_SCRIPTS，但保持CONFIG_DEBUG_INFO_REDUCED關閉。
+  如果你的架構支援CONFIG_FRAME_POINTER，請保持啟用。
 
-- 編譯內核時開啓CONFIG_GDB_SCRIPTS，關閉CONFIG_DEBUG_INFO_REDUCED。
-  如果架構支持CONFIG_FRAME_POINTER，請保持開啓。
+- 在guest上安裝該核心，必要時在核心命令列加上“nokaslr”以關閉KASLR。
+  另外，QEMU也可以透過-kernel、-append、-initrd這些命令列選項直接啟動核心。
+  這通常只在你不依賴模組時才有用。關於此模式的詳細資訊，請參閱QEMU文件。
+  在這種情況下，如果架構支援KASLR，應該在停用CONFIG_RANDOMIZE_BASE的情況下
+  建置核心。
 
-- 在guest環境上安裝該內核。如有必要，通過在內核command line中添加“nokaslr”來關閉KASLR。
-  此外，QEMU允許通過-kernel、-append、-initrd這些命令行選項直接啓動內核。
-  但這通常僅在不依賴內核模塊時纔有效。有關此模式的更多詳細信息，請參閱QEMU文檔。
-  在這種情況下，如果架構支持KASLR，應該在禁用CONFIG_RANDOMIZE_BASE的情況下構建內核。
+- 建置gdb腳本（v5.1以上的核心需要此步驟）::
 
-- 啓用QEMU/KVM的gdb stub，可以通過如下方式實現
+    make scripts_gdb
 
-    - 在VM啓動時，通過在QEMU命令行中添加“-s”參數
+- 啟用QEMU/KVM的gdb stub，可以
+
+    - 在VM啟動時，於QEMU命令列加上“-s”
 
   或
 
-    - 在運行時通過從QEMU監視控制檯發送“gdbserver”
+    - 在執行期間，從QEMU monitor主控台下達“gdbserver”
 
-- 切換到/path/to/linux-build(內核源碼編譯)目錄
+- cd /path/to/linux-build
 
-- 啓動gdb：gdb vmlinux
+- 啟動gdb：gdb vmlinux
 
-  注意：某些發行版可能會將gdb腳本的自動加載限制在已知的安全目錄中。
-  如果gdb報告拒絕加載vmlinux-gdb.py（相關命令找不到），請將::
+  注意：某些發行版可能會將gdb腳本的自動載入限制在已知安全的目錄。
+  如果gdb回報拒絕載入vmlinux-gdb.py，請將::
 
     add-auto-load-safe-path /path/to/linux-build
 
-  添加到~/.gdbinit。更多詳細信息，請參閱gdb幫助信息。
+  加入~/.gdbinit。詳情請參閱gdb的說明。
 
-- 連接到已啓動的guest環境::
+- 連線到已開機的guest::
 
     (gdb) target remote :1234
 
 
-使用Linux提供的gdb腳本的示例
-----------------------------
+使用Linux提供的gdb輔助工具的範例
+--------------------------------
 
-- 加載模塊（以及主內核）符號::
+- 載入模組（以及主核心）的符號::
 
     (gdb) lx-symbols
     loading vmlinux
@@ -74,18 +82,18 @@ Kgdb內核調試器、QEMU等虛擬機管理程序或基於JTAG的硬件接口
     ...
     loading @0xffffffffa0000000: /home/user/linux/build/drivers/ata/ata_generic.ko
 
-- 對一些尚未加載的模塊中的函數函數設置斷點，例如::
+- 對某個尚未載入的模組函式設定中斷點，例如::
 
     (gdb) b btrfs_init_sysfs
     Function "btrfs_init_sysfs" not defined.
     Make breakpoint pending on future shared library load? (y or [n]) y
     Breakpoint 1 (btrfs_init_sysfs) pending.
 
-- 繼續執行::
+- 讓目標繼續執行::
 
     (gdb) c
 
-- 加載模塊並且能觀察到正在加載的符號以及斷點命中::
+- 在目標上載入模組，觀察符號的載入以及中斷點的觸發::
 
     loading @0xffffffffa0034000: /home/user/linux/build/lib/libcrc32c.ko
     loading @0xffffffffa0050000: /home/user/linux/build/lib/lzo/lzo_compress.ko
@@ -95,7 +103,7 @@ Kgdb內核調試器、QEMU等虛擬機管理程序或基於JTAG的硬件接口
     Breakpoint 1, btrfs_init_sysfs () at /home/user/linux/fs/btrfs/sysfs.c:36
     36              btrfs_kset = kset_create_and_add("btrfs", NULL, fs_kobj);
 
-- 查看內核的日誌緩衝區::
+- 傾印目標核心的日誌緩衝區::
 
     (gdb) lx-dmesg
     [     0.000000] Initializing cgroup subsys cpuset
@@ -107,21 +115,21 @@ Kgdb內核調試器、QEMU等虛擬機管理程序或基於JTAG的硬件接口
     [     0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
     ....
 
-- 查看當前task struct結構體的字段（僅x86和arm64支持）::
+- 檢視目前task struct的欄位（僅支援x86與arm64）::
 
     (gdb) p $lx_current().pid
     $1 = 4998
     (gdb) p $lx_current().comm
     $2 = "modprobe\000\000\000\000\000\000\000"
 
-- 對當前或指定的CPU使用per-cpu函數::
+- 針對目前或指定的CPU使用per-cpu函式::
 
     (gdb) p $lx_per_cpu(runqueues).nr_running
     $3 = 1
     (gdb) p $lx_per_cpu(runqueues, 2).nr_running
     $4 = 0
 
-- 使用container_of查看更多hrtimers信息::
+- 使用container_of輔助函式深入檢視hrtimers::
 
     (gdb) set $leftmost = $lx_per_cpu(hrtimer_bases).clock_base[0].active.rb_root.rb_leftmost
     (gdb) p *$container_of($leftmost, "struct hrtimer", "node")
@@ -144,10 +152,11 @@ Kgdb內核調試器、QEMU等虛擬機管理程序或基於JTAG的硬件接口
     }
 
 
-命令和輔助調試功能列表
-----------------------
+命令與函式列表
+--------------
 
-命令和輔助調試功能可能會隨着時間的推移而改進，此文顯示的是初始版本的部分示例::
+命令與便利函式（convenience function）的數量可能會隨時間演進，以下只是初始
+版本的快照::
 
  (gdb) apropos lx
  function lx_current -- Return current task
@@ -159,6 +168,13 @@ Kgdb內核調試器、QEMU等虛擬機管理程序或基於JTAG的硬件接口
  lx-lsmod -- List currently loaded modules
  lx-symbols -- (Re-)load symbols of Linux kernel and currently loaded modules
 
-可以通過“help <command-name>”或“help function <function-name>”命令
-獲取指定命令或指定調試功能的更多詳細信息。
+命令的詳細說明可以透過“help <command-name>”取得，便利函式的詳細說明則可以
+透過“help function <function-name>”取得。
+
+除錯GDB腳本
+-----------
+
+GDB並未啟用完整的Python回溯（backtrace），這可能讓除錯GDB腳本變得比必要的
+更困難。以下設定可以印出python環境的完整回溯::
 
+ (gdb) set python print-stack full
-- 
2.43.0

[PATCH 11/25] docs/zh_TW: process: sync development-process.rst with the English original

[Chen-Yu Yeh]

The translation carried no "update to commit" marker.
commit 2b7703e15a55 ("docs: use toctree :caption: and move
introduction") moved the introductory paragraph above the table of
contents, but the zh_TW file now has that paragraph twice: once above
the toctree, as in the English text, and a second, older copy left below
it in simplified-style characters (軟件, 裏, 瞭解).  A comparison
against the current English text brings it in line with the full current
original:

- drop the stale copy of the introduction below the toctree
- retranslate the introduction and the title with zh_TW terminology
  (內核→核心, 文檔→文件, 社區→社群, 編程→程式設計), and rephrase "in a
  way which is accessible to" instead of the literal "可以訪問"
- wrap the :Original: line and the introduction to keep them within
  80 columns, as in 8.Conclusion.rst

update to commit 2b7703e15a55 ("docs: use toctree :caption: and move
introduction")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/development-process.rst            | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/development-process.rst b/Documentation/translations/zh_TW/process/development-process.rst
index 1d22aa0d3711..906e635cf830 100644
--- a/Documentation/translations/zh_TW/process/development-process.rst
+++ b/Documentation/translations/zh_TW/process/development-process.rst
@@ -2,14 +2,18 @@
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :ref:`Documentation/process/development-process.rst <development_process_main>`
+:Original: :ref:`Documentation/process/development-process.rst
+           <development_process_main>`
 
 .. _tw_development_process_main:
 
-內核開發過程指南
+核心開發過程指南
 ================
 
-本文檔的目的是幫助開發人員（及其經理）以最小的挫折感與開發社區合作。它試圖記錄這個社區如何以一種不熟悉Linux內核開發（或者實際上是自由軟體開發）的人可以訪問的方式工作。雖然這裡有一些技術資料，但這是一個面向過程的討論，不需要深入了解內核編程就可以理解。
+本文件的目的是幫助開發人員（及其經理）以最少的挫折與開發社群合作。它試圖以
+一種讓不熟悉 Linux 核心開發（或者說，一般的自由軟體開發）的人也能理解的方式，
+記錄這個社群的運作方式。雖然這裡有一些技術內容，但這基本上是一份以流程為主的
+討論，不需要對核心程式設計有深入了解也能讀懂。
 
 .. toctree::
    :caption: 內容
@@ -24,5 +28,3 @@
    6.Followthrough
    7.AdvancedTopics
    8.Conclusion
-
-本文檔的目的是幫助開發人員（及其經理）以最小的挫折感與開發社區合作。它試圖記錄這個社區如何以一種不熟悉Linux內核開發（或者實際上是自由軟件開發）的人可以訪問的方式工作。雖然這裏有一些技術資料，但這是一個面向過程的討論，不需要深入瞭解內核編程就可以理解。
-- 
2.43.0

[PATCH 12/25] docs/zh_TW: process: sync email-clients.rst with the English original

[Chen-Yu Yeh]

The translation is marked "update to commit 4971ca2007e3 ("docs:
process: email-client: add Thunderbird "Toggle Line Wrap" extension")",
but it never picked up commit 7fe7de7be828 ("Docs/process/email-clients:
Document HacKerMaiL") or the IMAP comment alignment from
commit 91031ca349ee ("docs: improve comment consistency in .muttrc
example configuration").  A comparison against the current English text
brings it in line with the full current original:

- add the missing HacKerMaiL (TUI) section
- restore the omitted "find the button for your main dropdown menu"
  step in the Thunderbird section
- keep text/plain, format=flowed, enabled/disabled, mutt and the
  youracc@server.something placeholder as literals, as in the original
- align the "IMAP" comment in the .muttrc example with the original
- fix mistranslations: "apply" (適用於→套用), "does not work" for
  Gmail, "graphical user interface" and a typo in the Claws section
- localize terminology (保存→儲存, 擴展→擴充套件, 點擊→點選, 禁用→停用,
  連接→連線, 查看→檢視, 會話→討論串, 內聯→行內, 回車換行→CRLF)

update to commit 4971ca2007e3 ("docs: process: email-client: add
Thunderbird "Toggle Line Wrap" extension")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/email-clients.rst           | 78 ++++++++++---------
 1 file changed, 42 insertions(+), 36 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/email-clients.rst b/Documentation/translations/zh_TW/process/email-clients.rst
index 272e3073521d..b3d97e9e83c0 100644
--- a/Documentation/translations/zh_TW/process/email-clients.rst
+++ b/Documentation/translations/zh_TW/process/email-clients.rst
@@ -15,8 +15,8 @@ Git
 現在大多數開發人員使用 ``git send-email`` 而不是常規的電子郵件客戶端。這方面
 的手冊非常好。在接收端，維護人員使用 ``git am`` 載入補丁。
 
-如果你是 ``git`` 新手，那麼把你的第一個補丁發送給你自己。將其保存為包含所有
-標題的原始文字。執行 ``git am raw_email.txt`` ，然後使用 ``git log`` 查看更
+如果你是 ``git`` 新手，那麼把你的第一個補丁發送給你自己。將其儲存為包含所有
+標題的原始文字。執行 ``git am raw_email.txt`` ，然後使用 ``git log`` 檢視更
 改日誌。如果工作正常，再將補丁發送到相應的郵件列表。
 
 
@@ -24,7 +24,7 @@ Git
 --------
 
 Linux核心補丁是透過郵件被提交的，最好把補丁作為郵件體的內嵌文字。有些維護者
-接收附件，但是附件的內容格式應該是"text/plain"。然而，附件一般是不贊成的，
+接收附件，但是附件的內容格式應該是 ``text/plain`` 。然而，附件一般是不贊成的，
 因為這會使補丁的引用部分在評論過程中變得很困難。
 
 同時也強烈建議在補丁或其他郵件的正文中使用純文字格式。https://useplaintext.email
@@ -34,7 +34,7 @@ Linux核心補丁是透過郵件被提交的，最好把補丁作為郵件體的
 用來發送Linux核心補丁的郵件客戶端在發送補丁時應該處於文字的原始狀態。例如，
 他們不能改變或者刪除製表符或者空格，甚至是在每一行的開頭或者結尾。
 
-不要透過"format=flowed"模式發送補丁。這樣會引起不可預期以及有害的斷行。
+不要透過 ``format=flowed`` 模式發送補丁。這樣會引起不可預期以及有害的斷行。
 
 不要讓你的郵件客戶端進行自動換行。這樣也會破壞你的補丁。
 
@@ -42,16 +42,16 @@ Linux核心補丁是透過郵件被提交的，最好把補丁作為郵件體的
 碼方式，如果你使用UTF-8編碼方式發送郵件，那麼你將會避免一些可能發生的字元
 集問題。
 
-郵件客戶端應該產生並且保持“References:”或者“In-Reply-To:”郵件頭，這樣郵件會話
+郵件客戶端應該產生並且保持“References:”或者“In-Reply-To:”郵件頭，這樣郵件討論串
 就不會中斷。
 
 複製貼上(或者剪貼貼上)通常不能用於補丁，因為製表符會轉換為空格。使用
 xclipboard,xclip或者xcutsel也許可以，但是最好測試一下或者避免使用複製貼上。
 
-不要在使用PGP/GPG簽名的郵件中包含補丁。這樣會使得很多腳本不能讀取和適用於你的
+不要在使用PGP/GPG簽名的郵件中包含補丁。這樣會使得很多腳本不能讀取和套用你的
 補丁。（這個問題應該是可以修復的）
 
-在給核心郵件列表發送補丁之前，給自己發送一個補丁是個不錯的主意，保存接收到的
+在給核心郵件列表發送補丁之前，給自己發送一個補丁是個不錯的主意，儲存接收到的
 郵件，將補丁用'patch'命令打上，如果成功了，再給核心郵件列表發送。
 
 
@@ -64,7 +64,7 @@ xclipboard,xclip或者xcutsel也許可以，但是最好測試一下或者避免
 說明：
 
 - TUI = 以文字為基礎的使用者介面
-- GUI = 圖形介面使用者介面
+- GUI = 圖形使用者介面
 
 Alpine (TUI)
 ************
@@ -73,8 +73,8 @@ Alpine (TUI)
 
 在 :menuselection:`Sending Preferences` 選單：
 
-- :menuselection:`Do Not Send Flowed Text` 必須開啟
-- :menuselection:`Strip Whitespace Before Sending` 必須關閉
+- :menuselection:`Do Not Send Flowed Text` 必須設為 ``enabled``
+- :menuselection:`Strip Whitespace Before Sending` 必須設為 ``disabled``
 
 當寫郵件時，游標應該放在補丁會出現的地方，然後按下 `CTRL-R` 組合鍵，使指
 定的補丁檔案嵌入到郵件中。
@@ -86,7 +86,7 @@ Claws Mail (GUI)
 
 用 :menuselection:`Message-->Insert File` (`CTRL-I`) 或外部編輯器插入補丁。
 
-若要在Claws編輯視窗重修改插入的補丁，需關閉
+若要在Claws編輯視窗中修改插入的補丁，需關閉
 :menuselection:`Configuration-->Preferences-->Compose-->Wrapping`
 的 `Auto wrapping` 。
 
@@ -110,11 +110,11 @@ Kmail (GUI)
 
 一些開發者成功的使用它發送補丁。
 
-預設撰寫設定禁用HTML格式是合適的；不要啟用它。
+預設撰寫設定停用HTML格式是合適的；不要啟用它。
 
 當書寫一封郵件的時候，在選項下面不要選擇自動換行。唯一的缺點就是你在郵件中輸
 入的任何文字都不會被自動換行，因此你必須在發送補丁之前手動換行。最簡單的方法
-就是啟用自動換行來書寫郵件，然後把它保存為草稿。一旦你在草稿中再次開啟它，它
+就是啟用自動換行來書寫郵件，然後把它儲存為草稿。一旦你在草稿中再次開啟它，它
 已經全部自動換行了，那麼你的郵件雖然沒有選擇自動換行，但是還不會失去已有的自
 動換行。
 
@@ -132,13 +132,13 @@ Kmail (GUI)
 你可以安全地用GPG簽名附件，但是內嵌補丁最好不要使用GPG簽名它們。作為內嵌文字
 插入的簽名補丁將使其難以從7-bit編碼中提取。
 
-如果你非要以附件的形式發送補丁，那麼就右鍵點擊附件，然後選擇
-:menuselection:`屬性` ，開啟 :menuselection:`建議自動顯示` ，使附件內聯更容
-易讓讀者看到。
+如果你非要以附件的形式發送補丁，那麼就右鍵點選附件，然後選擇
+:menuselection:`屬性` ，開啟 :menuselection:`建議自動顯示` ，使附件以行內方式
+顯示，更容易讓讀者看到。
 
-當你要保存將要發送的內嵌文字補丁，你可以從訊息列表窗格選擇包含補丁的郵件，然
+當你要儲存以內嵌文字發送的補丁，你可以從訊息列表窗格選擇包含補丁的郵件，然
 後右鍵選擇 :menuselection:`另存新檔` 。如果整個電子郵件的組成正確，您可直接將
-其作為補丁使用。電子郵件以當前使用者可讀寫權限保存，因此您必須 ``chmod`` ，以
+其作為補丁使用。電子郵件以當前使用者可讀寫權限儲存，因此您必須 ``chmod`` ，以
 使其在複製到別處時使用者組和其他人可讀。
 
 Lotus Notes (GUI)
@@ -154,7 +154,7 @@ IBM Verse (Web GUI)
 Mutt (TUI)
 **********
 
-很多Linux開發人員使用mutt客戶端，這證明它肯定工作得非常漂亮。
+很多Linux開發人員使用 ``mutt`` 客戶端，這證明它肯定工作得非常漂亮。
 
 Mutt不自帶編輯器，所以不管你使用什麼編輯器，不自動斷行就行。大多數編輯器都有
 :menuselection:`插入檔案` 選項，它可以在不改變檔案內容的情況下插入檔案。
@@ -188,7 +188,7 @@ Mutt不自帶編輯器，所以不管你使用什麼編輯器，不自動斷行
 Mutt 是高度可設定的。 這裡是個使用mutt透過 Gmail 發送的補丁的最小設定::
 
   # .muttrc
-  # ================  IMAP ====================
+  # ================  IMAP  ====================
   set imap_user = 'yourusername@gmail.com'
   set imap_pass = 'yourpassword'
   set spoolfile = imaps://imap.gmail.com/INBOX
@@ -237,7 +237,7 @@ Sylpheed (GUI)
 - 內嵌文字可以很好的工作（或者使用附件）。
 - 允許使用外部的編輯器。
 - 收件箱較多時非常慢。
-- 如果透過non-SSL連接，無法使用TLS SMTP授權。
+- 如果透過non-SSL連線，無法使用TLS SMTP授權。
 - 撰寫視窗的標尺很有用。
 - 將地址添加到通訊簿時無法正確理解顯示的名稱。
 
@@ -246,13 +246,13 @@ Thunderbird (GUI)
 
 Thunderbird是Outlook的翻版，它很容易損壞文字，但也有一些方法強制修正。
 
-在完成修改後（包括安裝擴展），您需要重新啟動Thunderbird。
+在完成修改後（包括安裝擴充套件），您需要重新啟動Thunderbird。
 
 - 允許使用外部編輯器：
 
-  使用Thunderbird發補丁最簡單的方法是使用擴展來開啟您最喜歡的外部編輯器。
+  使用Thunderbird發補丁最簡單的方法是使用擴充套件來開啟您最喜歡的外部編輯器。
 
-  下面是一些能夠做到這一點的擴展樣例。
+  下面是一些能夠做到這一點的擴充套件樣例。
 
   - “External Editor Revived”
 
@@ -268,8 +268,8 @@ Thunderbird是Outlook的翻版，它很容易損壞文字，但也有一些方
 
     https://github.com/exteditor/exteditor
 
-    下載並安裝此擴展，然後開啟 :menuselection:`新增訊息` 視窗, 用
-    :menuselection:`查看-->工具列-->自訂...` 給它增加一個按鈕，直接點擊此
+    下載並安裝此擴充套件，然後開啟 :menuselection:`新增訊息` 視窗, 用
+    :menuselection:`檢視-->工具列-->自訂...` 給它增加一個按鈕，直接點選此
     按鈕即可使用外部編輯器。
 
     請注意，“External Editor”要求你的編輯器不能fork，換句話說，編輯器必須在
@@ -282,14 +282,14 @@ Thunderbird是Outlook的翻版，它很容易損壞文字，但也有一些方
 若要修正內部編輯器，請執行以下操作：
 
 - 修改你的Thunderbird設定，不要使用 ``format=flowed`` ！
-  回到主視窗，按照
-  :menuselection:`主選單-->偏好設定-->常規-->設定編輯器...`
+  回到主視窗，找到主下拉選單的按鈕，按照
+  :menuselection:`主選單-->偏好設定-->一般-->設定編輯器...`
   開啟Thunderbird的設定編輯器。
 
   - 將 ``mailnews.send_plaintext_flowed`` 設為 ``false``
 
   - 將 ``mailnews.wraplength`` 從 ``72`` 改為 ``0`` ，**或者** 安裝
-    “Toggle Line Wrap”擴展
+    “Toggle Line Wrap”擴充套件
 
     https://github.com/jan-kiszka/togglelinewrap
 
@@ -299,11 +299,11 @@ Thunderbird是Outlook的翻版，它很容易損壞文字，但也有一些方
 
 - 不要寫HTML郵件！
   回到主視窗，開啟
-  :menuselection:`主選單-->帳戶設定-->你的@郵件.地址-->通訊錄/編寫&地址簿` ，
-  關掉 ``以HTML格式編寫訊息`` 。
+  :menuselection:`主選單-->帳戶設定-->youracc@server.something-->撰寫與定址`
+  ，在那裡關掉 ``以HTML格式編寫訊息`` 選項。
 
-- 只用純文字格式查看郵件！
-  回到主視窗， :menuselection:`主選單-->查看-->訊息體為-->純文字` ！
+- 只用純文字格式檢視郵件！
+  回到主視窗， :menuselection:`主選單-->檢視-->訊息體為-->純文字` ！
 
 TkRat (GUI)
 ***********
@@ -313,14 +313,20 @@ TkRat (GUI)
 Gmail (Web GUI)
 ***************
 
-不要使用它發送補丁。
+無法用來發送補丁。
 
 Gmail網頁客戶端自動地把製表符轉換為空格。
 
-雖然製表符轉換為空格問題可以被外部編輯器解決，但它同時還會使用回車換行把每行
-拆分為78個字元。
+雖然製表符轉換為空格問題可以被外部編輯器解決，但它同時還會用CRLF形式的換行把
+每行拆分為78個字元。
 
 另一個問題是Gmail還會把任何含有非ASCII的字元的訊息改用base64編碼，如歐洲人的
 名字。
 
+HacKerMaiL (TUI)
+****************
 
+HacKerMaiL（hkml）是一個以public-inbox為基礎的簡易郵件管理工具，不需要訂閱郵件
+列表。它由DAMON維護者開發與維護，目標是支援DAMON及一般核心子系統的簡易開發流程。
+詳情請參閱README：
+https://github.com/sjp38/hackermail/blob/master/README.md
-- 
2.43.0

[PATCH 13/25] docs/zh_TW: process: sync kernel-driver-statement.rst with the English original

[Chen-Yu Yeh]

The translation carries no "update to commit" marker.  A comparison
against the current English text shows the content is complete: the
signer list matches all 177 names, including Aaro Koskinen from
commit b13267ba579d ("documentation: add my name to kernel driver
statement"), and the process_statement_driver label from
commit edba5eecfd6e ("doc:it_IT: add some process/* translations") is
referenced. The prose, however, was converted from zh_CN and still reads
in mainland terminology:

- localize terminology (內核→核心, 模塊→模組, 驅動程序→驅動程式,
  用戶→使用者, 社區→社群, 代碼→程式碼, 支持→支援, 靈活性→彈性,
  封閉源→閉源, 爲→為)
- render "adopt a policy of supporting their customers" as a policy
  rather than "taking measures", and make "We speak only for
  ourselves" read naturally
- wrap the :Original: line to stay within 80 columns

update to commit edba5eecfd6e ("doc:it_IT: add some process/*
translations")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/kernel-driver-statement.rst | 24 ++++++++++---------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/kernel-driver-statement.rst b/Documentation/translations/zh_TW/process/kernel-driver-statement.rst
index 34bcb6f164cb..11de92a7bcf3 100644
--- a/Documentation/translations/zh_TW/process/kernel-driver-statement.rst
+++ b/Documentation/translations/zh_TW/process/kernel-driver-statement.rst
@@ -4,22 +4,24 @@
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :ref:`Documentation/process/kernel-driver-statement.rst <process_statement_driver>`
+:Original: :ref:`Documentation/process/kernel-driver-statement.rst
+           <process_statement_driver>`
 
-內核驅動聲明
-------------
+核心驅動程式聲明
+----------------
 
-關於Linux內核模塊的立場聲明
+關於Linux核心模組的立場聲明
 ===========================
 
-我們，以下署名的Linux內核開發人員，認爲任何封閉源Linux內核模塊或驅動程序都是
-有害的和不可取的。我們已經一再發現它們對Linux用戶，企業和更大的Linux生態系統
-有害。這樣的模塊否定了Linux開發模型的開放性，穩定性，靈活性和可維護性，並使
-他們的用戶無法使用Linux社區的專業知識。提供閉源內核模塊的供應商迫使其客戶
-放棄Linux的主要優勢或選擇新的供應商。因此，爲了充分利用開源所提供的成本節省和
-共享支持優勢，我們敦促供應商採取措施，以開源內核代碼在Linux上爲其客戶提供支持。
+我們，以下署名的Linux核心開發人員，認為任何閉源的Linux核心模組或驅動程式都是
+有害且不可取的。我們一再發現它們對Linux使用者、企業以及更廣大的Linux生態系統
+有害。這樣的模組否定了Linux開發模式的開放性、穩定性、彈性和可維護性，並使
+其使用者無法獲得Linux社群的專業知識。提供閉源核心模組的供應商迫使其客戶
+放棄Linux的關鍵優勢，或是另選新的供應商。因此，為了充分享有開源所帶來的成本
+節省與共享支援的好處，我們敦促供應商採取以開源核心程式碼在Linux上支援其客戶的
+政策。
 
-我們只爲自己說話，而不是我們今天可能會爲之工作，過去或將來會爲之工作的任何公司。
+我們僅代表自己發言，而非代表我們目前、過去或將來可能任職的任何公司。
 
  - Dave Airlie
  - Nick Andrew
-- 
2.43.0

[PATCH 14/25] docs/zh_TW: process: sync kernel-enforcement-statement.rst with the English original

[Chen-Yu Yeh]

The translation carries no "update to commit" marker.  A comparison
against the current English text shows the content is complete: the
signer list matches all 109 names, including the later additions such as
Arnaldo Carvalho de Melo, Kees Cook and Luis R. Rodriguez.  But the file
still begins its label line with the byte order mark that
commit 9e255e2b9afe ("Documentation: drop optional BOMs") removed from
the original, and the prose was converted from zh_CN:

- drop the byte order mark, as in the original
- retranslate sentences whose meaning had drifted: the additional
  permissions apply "with respect to any non-defensive assertion of
  rights under the license" (rendered as "as any non-defensive
  assertion"), and the uncertainty to eliminate is "about our
  expectations regarding compliance or enforcement" (rendered as our
  own uncertainty about regulatory compliance)
- rewrite the two quoted GPL-3.0 provisions so that the conditions
  read in order, without the duplicated "reinstated permanently" in
  (b), and use 版權持有人 for "copyright holder" throughout
- localize terminology (內核→核心, 社區→社群, 用戶→使用者, 項目→專案,
  分發→散布, 爲→為), and translate "Except where noted below" as
  such instead of "except as mentioned below"
- wrap the :Original: line to stay within 80 columns and drop the
  blank line at the end of the file

update to commit 9e255e2b9afe ("Documentation: drop optional BOMs")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../process/kernel-enforcement-statement.rst  | 59 ++++++++++---------
 1 file changed, 31 insertions(+), 28 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst b/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst
index d54d20529294..9a518ce322c2 100644
--- a/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst
+++ b/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst
@@ -1,45 +1,49 @@
 .. SPDX-License-Identifier: GPL-2.0
 
-.. _tw_process_statement_kernel:
+.. _tw_process_statement_kernel:
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>`
+:Original: :ref:`Documentation/process/kernel-enforcement-statement.rst
+           <process_statement_kernel>`
 
-Linux 內核執行聲明
+Linux 核心執行聲明
 ------------------
 
-作爲Linux內核的開發人員，我們對如何使用我們的軟體以及如何實施軟體許可證有著
-濃厚的興趣。遵守GPL-2.0的互惠共享義務對我們軟體和社區的長期可持續性至關重要。
+作為Linux核心的開發人員，我們對我們的軟體如何被使用，以及我們軟體的許可證
+如何被執行，有著濃厚的興趣。遵守GPL-2.0的互惠共享義務，對我們軟體和社群的
+長期永續發展至關重要。
 
-雖然有權強制執行對我們社區的貢獻中的單獨版權權益，但我們有共同的利益，即確保
-個人強制執行行動的方式有利於我們的社區，不會對我們軟體生態系統的健康和增長
-產生意外的負面影響。爲了阻止無益的執法行動，我們同意代表我們自己和我們版權
-利益的任何繼承人對Linux內核用戶作出以下符合我們開發社區最大利益的承諾:
+雖然對貢獻給我們社群的內容中各自獨立的版權權益，確實有權強制執行，但我們
+共同關心的是，確保個別的執行行動以有利於我們社群的方式進行，而不會對我們
+軟體生態系統的健康與成長造成意料之外的負面影響。為了遏止無益的執行行動，
+我們同意代表我們自己以及我們版權權益的任何繼受者，向Linux核心的使用者作出
+以下承諾，這符合我們開發社群的最大利益：
 
-    儘管有GPL-2.0的終止條款，我們同意，採用以下GPL-3.0條款作爲我們許可證下的
-    附加許可，作爲任何對許可證下權利的非防禦性主張，這符合我們開發社區的最佳
-    利益。
+    儘管有GPL-2.0的終止條款，我們同意，對於依本許可證所提出的任何非防禦性
+    權利主張，採用以下GPL-3.0條款作為我們許可證下的額外許可，這符合我們開發
+    社群的最大利益。
 
-        但是，如果您停止所有違反本許可證的行爲，則您從特定版權持有人處獲得的
-        許可證將被恢復：（a）暫時恢復，除非版權持有人明確並最終終止您的許可證；
-        以及（b）永久恢復, 如果版權持有人未能在你終止違反後60天內以合理方式
-        通知您違反本許可證的行爲，則永久恢復您的許可證。
+        但是，如果您停止所有違反本許可證的行為，則您從特定版權持有人處
+        獲得的授權將會恢復：（a）暫時恢復，除非且直到該版權持有人明確並
+        最終終止您的授權；以及（b）永久恢復，如果該版權持有人未能在您
+        停止違反後60天內，以某種合理方式通知您違反的情事。
 
-        此外，如果版權所有者以某種合理的方式通知您違反了本許可，這是您第一次
-        從該版權所有者處收到違反本許可的通知（對於任何作品），並且您在收到通知
-        後的30天內糾正違規行爲。則您從特定版權所有者處獲得的許可將永久恢復.
+        此外，如果版權持有人以某種合理方式通知您違反的情事，而這是您
+        第一次從該版權持有人處收到違反本許可證的通知（就任何作品而言），
+        並且您在收到通知後30天內糾正違反行為，則您從該特定版權持有人處
+        獲得的授權將永久恢復。
 
-我們提供這些保證的目的是鼓勵更多地使用該軟體。我們希望公司和個人使用、修改和
-分發此軟體。我們希望以公開和透明的方式與用戶合作，以消除我們對法規遵從性或強制
-執行的任何不確定性，這些不確定性可能會限制我們軟體的採用。我們將法律行動視爲
-最後手段，只有在其他社區努力未能解決這一問題時才採取行動。
+我們提供這些保證的目的是鼓勵更多人使用該軟體。我們希望公司和個人使用、修改和
+散布此軟體。我們希望以公開和透明的方式與使用者合作，消除外界對我們在遵循或
+執行許可證方面之期望的任何不確定性，以免這些不確定性限制我們軟體的採用。
+我們將法律行動視為最後手段，只有在社群的其他努力未能解決問題時才會採取。
 
-最後，一旦一個不合規問題得到解決，我們希望用戶會感到歡迎，加入我們爲之努力的
-這個項目。共同努力，我們會更強大。
+最後，一旦不合規的問題得到解決，我們希望該使用者會感到受歡迎，加入我們在這個
+專案上的努力。攜手合作，我們會更強大。
 
-除了下面提到的以外，我們只爲自己說話，而不是爲今天、過去或將來可能爲之工作的
-任何公司說話。
+除下文另有註明者外，我們僅代表自己發言，而非代表我們目前、過去或將來可能任職
+的任何公司。
 
   - Laura Abbott
   - Bjorn Andersson (Linaro)
@@ -150,4 +154,3 @@ Linux 內核執行聲明
   - Wei Yongjun
   - Lv Zheng
   - Marc Zyngier (Arm Ltd)
-
-- 
2.43.0

[PATCH 15/25] docs/zh_TW: process: sync management-style.rst with the English original

[Chen-Yu Yeh]

The translation carries no "update to commit" marker.  A comparison
against the current English text shows every section and footnote is
present, including the :ref: to the decisions label from
commit f77af637f29d ("doc:process: add links where missing"), but the
prose was converted from zh_CN and many sentences drifted from the
original:

- restore the emphasis the original puts on words such as **they**
  (commit 26f67b4c6e4c ("Documentation: management-style: Fix formatting
  of emphsized word")), **avoid**, **two**, **in private** and **will**
- retranslate sentences whose meaning had been lost: "doubly
  managerial for making two inconsequential decisions", "coming up
  smelling like roses", "Oops, not again", "Suck up to them", "in a
  sanctimonious voice", "doesn't scan nearly as well", "Tag, you're
  it", the flame-war hint in footnote 3 and the first footnote
- call people 笨蛋 consistently for "d*ckhead" (one place said 壞人)
- keep the book and song titles in English, as in the original
- localize terminology (內核→核心, 文檔→文件, 項目→專案, 網絡→網路,
  爲→為, 着→著, 裏→裡)
- number the section headings "1)" ... "6)" as in the original and drop
  the blank line at the end of the file

update to commit 26f67b4c6e4c ("Documentation: management-style: Fix
formatting of emphsized word")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/management-style.rst        | 294 +++++++++---------
 1 file changed, 153 insertions(+), 141 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/management-style.rst b/Documentation/translations/zh_TW/process/management-style.rst
index 2cef0ef25ede..0d583a089f31 100644
--- a/Documentation/translations/zh_TW/process/management-style.rst
+++ b/Documentation/translations/zh_TW/process/management-style.rst
@@ -6,204 +6,216 @@
 
 .. _tw_managementstyle:
 
-Linux內核管理風格
+Linux核心管理風格
 =================
 
-這是一個簡短的文檔，描述了Linux內核首選的（或胡編的，取決於您問誰）管理風格。
-它的目的是在某種程度上參照 :ref:`process/coding-style.rst <codingstyle>`
-主要是爲了避免反覆回答 [#cnf1]_ 相同（或類似）的問題。
+這是一份簡短的文件，描述Linux核心偏好的（或者說是胡謅的，看你問誰）管理風格。
+它某種程度上是要與 :ref:`process/coding-style.rst <codingstyle>` 文件相互
+呼應，而寫它主要是為了避免一再回答 [#cnf1]_ 相同（或類似）的問題。
 
-管理風格是非常個人化的，比簡單的編碼風格規則更難以量化，因此本文檔可能與實
-際情況有關，也可能與實際情況無關。起初它是一個玩笑，但這並不意味着它可能不
-是真的。你得自己決定。
+管理風格是非常個人化的事，比單純的程式碼風格規則難以量化得多，因此本文件
+可能與現實有關，也可能無關。它起初只是個玩笑，但這並不代表它實際上就不是
+真的。你得自己判斷。
 
-順便說一句，在談到“核心管理者”時，主要是技術負責人，而不是在公司內部進行傳
-統管理的人。如果你簽署了採購訂單或者對你的團隊的預算有任何瞭解，你幾乎肯定
-不是一個核心管理者。這些建議可能適用於您，也可能不適用於您。
+順帶一提，這裡所說的“核心管理者”，指的完全是技術上的領導者，而不是在公司
+內部從事傳統管理工作的人。如果你會簽採購單，或是對你所屬團隊的預算有任何
+概念，那你幾乎可以肯定不是核心管理者。這些建議對你可能適用，也可能不適用。
 
-首先，我建議你購買“高效人的七個習慣”，而不是閱讀它。燒了它，這是一個偉大的
-象徵性姿態。
+首先，我建議你買一本“Seven Habits of Highly Effective People”，然後 **不要**
+讀它。燒了它，這是個很棒的象徵性舉動。
 
-.. [#cnf1] 本文件並不是通過回答問題，而是通過讓提問者痛苦地明白，我們不知道
-   答案是什麼。
+.. [#cnf1] 本文件達成這個目的的方式，與其說是回答問題，不如說是讓提問者
+   痛苦地明白：我們根本不知道答案是什麼。
 
-不管怎樣，這裏是：
+不管怎樣，開始吧：
 
 .. _tw_decisions:
 
-1）決策
--------
+1) 決策
+--------
 
-每個人都認爲管理者做決定，而且決策很重要。決定越大越痛苦，管理者就必須越高級。
-這很明顯，但事實並非如此。
+每個人都以為管理者負責做決策，而且決策很重要。決策越重大、越痛苦，做決策的
+管理者就得越高階。這個道理非常深刻又顯而易見，但實際上並不正確。
 
-最重要的是 **避免** 做出決定。尤其是，如果有人告訴你“選擇（a）或（b），
-我們真的需要你來做決定”，你就是陷入麻煩的管理者。你管理的人比你更瞭解細節，
-所以如果他們來找你做技術決策，你完蛋了。你顯然沒有能力爲他們做這個決定。
+遊戲規則是 **避免** 做決策。尤其是，如果有人跟你說“選（a）還是（b），我們
+真的需要你來決定”，那麼身為管理者的你就麻煩了。你管理的人最好比你更了解
+細節，所以如果他們來找你做技術決策，你就完蛋了。你顯然沒有能力替他們做這個
+決策。
 
-（推論：如果你管理的人不比你更瞭解細節，你也會被搞砸，儘管原因完全不同。
-也就是說，你的工作是錯的，他們應該管理你的才智）
+（推論：如果你管理的人並不比你更了解細節，那你也完蛋了，只是原因完全不同：
+你入錯行了，應該反過來由 **他們** 來管理才華洋溢的你才對。）
 
-所以最重要的是 **避免** 做出決定，至少是那些大而痛苦的決定。做一些小的
-和非結果性的決定是很好的，並且使您看起來好像知道自己在做什麼，所以內核管理者
-需要做的是將那些大的和痛苦的決定變成那些沒有人真正關心的小事情。
+所以遊戲規則是 **避免** 做決策，至少要避免那些重大又痛苦的決策。做些小而
+無關緊要的決策沒有問題，還能讓你看起來像是知道自己在做什麼，所以核心管理者
+要做的，就是把那些重大又痛苦的決策變成沒有人真正在乎的小事。
 
-這有助於認識到一個大的決定和一個小的決定之間的關鍵區別是你是否可以在事後修正
-你的決定。任何決定都可以通過始終確保如果你錯了（而且你一定會錯），你以後總是
-可以通過回溯來彌補損失。突然間，你就要做兩個無關緊要的決定，一個是錯誤的，另
-一個是正確的。
+認清一點會有幫助：大決策和小決策之間的關鍵差別，在於你事後能否修正這個
+決策。只要始終確保在你犯錯時（而且你 **一定** 會犯錯），之後總是能透過走
+回頭路來彌補損害，任何決策都可以變成小決策。突然間，你因為做了 **兩個**
+無關緊要的決策（錯的那個 **和** 對的那個），而顯得加倍有管理者的架勢。
 
-人們甚至會認爲這是真正的領導能力（咳，胡說，咳）。
+而且大家甚至會把這視為真正的領導力（*咳* 胡扯 *咳*）。
 
-因此，避免重大決策的關鍵在於避免做那些無法挽回的事情。不要被引導到一個你無法
-逃離的角落。走投無路的老鼠可能很危險——走投無路的管理者真可憐。
+因此，避免重大決策的關鍵就變成：避免去做無法挽回的事。不要被逼進一個無法
+逃脫的角落。走投無路的老鼠也許很危險——走投無路的管理者則只是可悲。
 
-事實證明，由於沒有人會愚蠢到讓內核管理者承擔巨大的財政責任，所以通常很容易
-回溯。既然你不可能浪費掉你無法償還的鉅額資金，你唯一可以回溯的就是技術決策，
-而回溯很容易：只要告訴大家你是個不稱職的傻瓜，說對不起，然後撤銷你去年讓別
-人所做的毫無價值的工作。突然間，你一年前做的決定不在是一個重大的決定，因爲
-它很容易被推翻。
+事實證明，由於 **反正** 不會有人蠢到真的讓核心管理者承擔龐大的財務責任，
+所以要走回頭路通常相當容易。既然你不可能浪費掉一大筆你可能還不起的錢，你
+唯一能走回頭路的就是技術決策，而在這方面走回頭路非常容易：只要告訴大家你是
+個無能的蠢蛋，說聲抱歉，然後把過去一年你讓大家做的那些毫無價值的工作全部
+撤銷。突然間，你一年前做的決策終究不算重大決策，因為它很容易就能撤銷。
 
-事實證明，有些人對接受這種方法有困難，原因有兩個：
+事實證明，有些人對這種做法有困難，原因有二：
 
- - 承認你是個白癡比看起來更難。我們都喜歡保持形象，在公共場合說你錯了有時
-   確實很難。
- - 如果有人告訴你，你去年所做的工作終究是不值得的，那麼對那些可憐的低級工
-   程師來說也是很困難的，雖然實際的 **工作** 很容易刪除，但你可能已經不可
-   挽回地失去了工程師的信任。記住：“不可撤銷”是我們一開始就試圖避免的，
-   而你的決定終究是一個重大的決定。
+ - 承認自己是個白癡比看起來要難。我們都喜歡維持形象，公開站出來說自己錯了，
+   有時候確實非常困難。
+ - 有人告訴你，你過去一年做的工作終究沒有價值，這對那些可憐的基層工程師來說
+   也可能很難受。雖然實際的 **工作** 只要刪掉就能輕鬆撤銷，但你可能已經無可
+   挽回地失去了那位工程師的信任。記住：“無可挽回”正是我們一開始就想避免的，
+   而你的決策終究還是變成了重大決策。
 
-令人欣慰的是，這兩個原因都可以通過預先承認你沒有任何線索，提前告訴人們你的
-決定完全是初步的，而且可能是錯誤的事情來有效地緩解。你應該始終保留改變主意
-的權利，並讓人們 **意識** 到這一點。當你 **還沒有** 做過真正愚蠢的事情的時
-候，承認自己是愚蠢的要容易得多。
+令人高興的是，這兩個原因都可以有效緩解：只要事先坦承你根本完全摸不著頭緒，
+並且預先告訴大家你的決策純屬初步，而且可能是錯的。你應該永遠保留改變主意的
+權利，並讓大家非常 **清楚** 這一點。而且在你 **還沒** 做出真正愚蠢的事之前，
+承認自己很蠢要容易得多。
 
-然後，當它真的被證明是愚蠢的時候，人們就轉動他們的眼珠說“哎呀，下次不要了”。
+接著，當它真的被證明很蠢時，大家只會翻個白眼說“唉呀，又來了”。
 
-這種對不稱職的先發制人的承認，也可能使真正做這項工作的人也會三思是否值得做。
-畢竟，如果他們不確定這是否是一個好主意，你肯定不應該通過向他們保證他們所做
-的工作將會進入（內核）鼓勵他們。在他們開始一項巨大的努力之前，至少讓他們三
-思而後行。
+這種先發制人地承認自己無能的做法，也可能讓真正做事的人三思這件事是否值得
+做。畢竟，如果連 **他們** 都不確定這是不是個好主意，你就絕對不該向他們保證
+他們做的東西會被收錄，藉此鼓勵他們。至少要讓他們在展開大工程之前三思。
 
-記住：他們最好比你更瞭解細節，而且他們通常認爲他們對每件事都有答案。作爲一
-個管理者，你能做的最好的事情不是灌輸自信，而是對他們所做的事情進行健康的批
-判性思考。
+記住：他們最好比你更了解細節，而且他們通常已經自認對每件事都有答案。身為
+管理者，你能做的最好的事不是灌輸信心，而是讓他們對自己所做的事抱持適度的
+批判性思考。
 
-順便說一句，另一種避免做出決定的方法是看起來很可憐的抱怨 “我們不能兩者兼
-得嗎？” 相信我，它是有效的。如果不清楚哪種方法更好，他們最終會弄清楚的。
-最終的答案可能是兩個團隊都會因爲這種情況而感到沮喪，以至於他們放棄了。
+順帶一提，另一種避免做決策的方法，是哀怨地嘟囔一句“我們不能兩個都做嗎？”，
+然後裝出一副可憐相。相信我，這招有效。如果不清楚哪種做法比較好，他們最後
+會自己搞清楚。最後的答案可能是兩個團隊都對這種狀況感到非常挫折，乾脆直接
+放棄。
 
-這聽起來像是一個失敗，但這通常是一個跡象，表明兩個項目都有問題，而參與其中
-的人不能做決定的原因是他們都是錯誤的。你最終會聞到玫瑰的味道，你避免了另一
-個你本可以搞砸的決定。
+這聽起來也許像是失敗，但通常這表示兩個專案都有問題，而相關人員之所以無法
+做出決定，是因為他們都錯了。結果你反而一身光鮮地脫身，又避開了一個你原本
+可能搞砸的決策。
 
-2）人
------
 
-大多數人都是白癡，做一名管理者意味着你必須處理好這件事，也許更重要的是,
-**他們** 必須處理好你。
+2) 人
+------
 
-事實證明，雖然很容易糾正技術錯誤，但不容易糾正人格障礙。你只能和他們的和
-你的（人格障礙）共處。
+大多數人都是白癡，而身為管理者，意味著你必須面對這件事，也許更重要的是，
+**他們** 必須面對 **你**。
 
-但是，爲了做好作爲內核管理者的準備，最好記住不要燒掉任何橋樑，不要轟炸任何
-無辜的村民，也不要疏遠太多的內核開發人員。事實證明，疏遠人是相當容易的，而
-親近一個疏遠的人是很難的。因此，“疏遠”立即屬於“不可逆”的範疇，並根據
-:ref:`tw_decisions` 成爲絕不可以做的事情。
+事實證明，技術上的錯誤很容易撤銷，人格上的缺陷可就沒那麼容易撤銷了。你只能
+跟他們的——還有你自己的——人格缺陷共處。
 
-這裏只有幾個簡單的規則：
+不過，為了做好當核心管理者的準備，最好記住不要自斷後路、不要轟炸無辜的
+村民，也不要疏遠太多核心開發者。事實證明，疏遠別人相當容易，要挽回他們卻
+很難。因此，“疏遠”立刻就屬於“不可逆”的範疇，根據 :ref:`tw_decisions` 而
+成為絕對不能做的事。
 
- (1) 不要叫人笨蛋（至少不要在公共場合）
- (2) 學習如何在忘記規則(1)時道歉
+這裡只有幾條簡單的規則：
 
-問題在於 #1 很容易去做，因爲你可以用數百萬種不同的方式說“你是一個笨蛋” [#cnf2]_
-有時甚至沒有意識到，而且幾乎總是帶着一種白熱化的信念，認爲你是對的。
+ (1) 不要罵人笨蛋（至少不要在公開場合）
+ (2) 學會在忘記規則(1)時道歉
 
-你越確信自己是對的（讓我們面對現實吧，你可以把幾乎所有人都稱爲壞人，而且你
-經常是對的），事後道歉就越難。
+規則 #1 的問題在於它非常容易犯，因為你可以用數百萬種不同的方式說“你是個
+笨蛋” [#cnf2]_，有時甚至自己都沒意識到，而且幾乎總是帶著自認為正確的熾熱
+信念。
 
-要解決此問題，您實際上只有兩個選項：
+而你越確信自己是對的（說實話，你幾乎可以罵 **任何人** 是笨蛋，而且你往往
+**會** 是對的），事後就越難道歉。
 
- - 非常擅長道歉
- - 把“愛”均勻地散開，沒有人會真正感覺到自己被不公平地瞄準了。讓它有足夠的
-   創造性，他們甚至可能會覺得好笑。
+要解決這個問題，你其實只有兩個選擇：
 
-選擇永遠保持禮貌是不存在的。沒有人會相信一個如此明顯地隱藏了他們真實性格的人。
+ - 變得非常擅長道歉
+ - 把“愛”平均地撒出去，讓沒有人真的覺得自己被不公平地針對。做得夠有創意的話，
+   他們甚至可能會覺得好笑。
 
-.. [#cnf2] 保羅·西蒙演唱了“離開愛人的50種方法”，因爲坦率地說，“告訴開發者
-   他們是D*CKHEAD" 的100萬種方法都無法確認。但我確信他已經這麼想了。
+始終保持禮貌這個選項其實並不存在。沒有人會信任一個如此明顯地隱藏自己真實
+性格的人。
 
-3）人2 - 好人
--------------
+.. [#cnf2] Paul Simon唱的是“Fifty Ways to Leave Your Lover”（離開愛人的五十種
+   方法），因為坦白說，“A Million Ways to Tell a Developer They're a
+   D*ckhead”（告訴開發者他們是笨蛋的一百萬種方法）唱起來可遠沒那麼順口。但我
+   相信他一定考慮過。
 
-雖然大多數人都是白癡，但不幸的是，據此推論你也是白癡，儘管我們都自我感覺良
-好，我們比普通人更好（讓我們面對現實吧，沒有人相信他們是普通人或低於普通人），
-我們也應該承認我們不是最鋒利的刀，而且會有其他人比你更不像白癡。
 
-有些人對聰明人反應不好。其他人利用它們。
+3) 人（之二）——好的那種
+------------------------
 
-作爲內核維護人員，確保您在第二組中。接受他們，因爲他們會讓你的工作更容易。
-特別是，他們能夠爲你做決定，這就是遊戲的全部內容。
+雖然事實證明大多數人都是白癡，但遺憾的是，由此得出的推論就是你也是白癡。
+而且雖然我們都可以安心地相信自己比一般人強（說實話，從來沒有人相信自己只是
+普通或低於普通水準），我們也應該承認自己並不是最聰明的那一個，總會有其他人
+沒有你那麼白癡。
 
-所以當你發現一個比你聰明的人時，就順其自然吧。你的管理職責在很大程度上變成
-了“聽起來像是個好主意——去嘗試吧”，或者“聽起來不錯，但是XXX呢？”“。第二個版
-本尤其是一個很好的方法，要麼學習一些關於“XXX”的新東西，要麼通過指出一些聰明
-人沒有想到的東西來顯得更具管理性。無論哪種情況，你都會贏。
+有些人對聰明人反應很差。其他人則會善用他們。
 
-要注意的一件事是認識到一個領域的偉大不一定會轉化爲其他領域。所以你可能會向
-特定的方向刺激人們，但讓我們面對現實吧，他們可能擅長他們所做的事情，而且對
-其他事情都很差勁。好消息是，人們往往會自然而然地重拾他們擅長的東西，所以當
-你向某個方向刺激他們時，你並不是在做不可逆轉的事情，只是不要用力推。
+身為核心維護者，你要確保自己屬於第二種人。巴結他們，因為他們就是會讓你的
+工作更輕鬆的人。尤其是，他們能替你做決策，而這正是這場遊戲的重點所在。
 
-4）責備
--------
+所以當你找到比你聰明的人時，就順勢而行吧。你的管理職責大致上會變成說“聽起來
+是個好主意——放手去做吧”，或是“聽起來不錯，但是xxx呢？”。尤其第二種說法是個
+很棒的方式，不是能讓你學到一些關於“xxx”的新東西，就是能藉由指出那位聰明人
+沒想到的事，讓你顯得 **格外** 有管理者的架勢。無論哪種情況，你都是贏家。
 
-事情會出問題的，人們希望去責備人。貼標籤，你就是受責備的人。
+要注意的一點是，要認清在某個領域的傑出不一定能轉移到其他領域。所以你也許會
+推著大家往特定方向走，但說實話，他們可能擅長自己做的事，其他事卻都很爛。
+好消息是，人們往往會自然而然地回到自己擅長的事情上，所以當你 **真的** 推他們
+往某個方向走時，你並不是在做什麼不可逆的事，只是別推得太用力。
 
-事實上，接受責備並不難，尤其是當人們意識到這不 **全是** 你的過錯時。這讓我
-們找到了承擔責任的最佳方式：爲別人承擔這件事。你會感覺很好，他們會感覺很好，
-沒有受到指責. 那誰，失去了他們的全部36GB色情收藏的人，因爲你的無能將勉強承
-認，你至少沒有試圖逃避責任。
 
-然後讓真正搞砸了的開發人員（如果你能找到他們）私下知道他們搞砸了。不僅是爲
-了將來可以避免，而且爲了讓他們知道他們欠你一個人情。而且，也許更重要的是，
-他們也可能是能夠解決問題的人。因爲，讓我們面對現實吧，肯定不是你。
+4) 歸咎
+--------
 
-承擔責任也是你首先成爲管理者的原因。這是讓人們信任你，讓你獲得潛在的榮耀的
-一部分，因爲你就是那個會說“我搞砸了”的人。如果你已經遵循了以前的規則，你現
-在已經很擅長說了。
+事情總會出錯，而大家會想找個人來怪罪。抓到了，換你當鬼。
 
-5）應避免的事情
----------------
+其實承擔責任並沒有那麼難，尤其是在大家多少意識到這不 **全是** 你的錯的時候。
+這就帶出了承擔責任的最佳方式：替別人扛下來。你會因為扛下責任而感覺良好，
+他們會因為沒被怪罪而感覺良好，而那個因為你的無能而失去整整36GB色情收藏的人，
+也會不情願地承認你至少沒有試圖推卸責任。
 
-有一件事人們甚至比被稱爲“笨蛋”更討厭，那就是在一個神聖的聲音中被稱爲“笨蛋”。
-第一個你可以道歉，第二個你不會真正得到機會。即使你做得很好，他們也可能不再
-傾聽。
+然後 **私下** 讓真正搞砸的開發者（如果你找得到他們）知道他們搞砸了。這不只
+是為了讓他們將來能避免再犯，也是為了讓他們知道自己欠你一次人情。而且，也許
+更重要的是，他們很可能也是能修好它的人。因為，說實話，那絕對不會是你。
 
-我們都認爲自己比別人強，這意味着當別人裝腔作勢時，這會讓我們很惱火。你也許
-在道德和智力上比你周圍的每個人都優越，但不要試圖太明顯，除非你真的打算激怒
-某人 [#cnf3]_
+承擔責任也正是你當初能成為管理者的原因。這是讓大家信任你、讓你有機會獲得
+榮耀的一部分，因為你就是那個會說“我搞砸了”的人。而如果你遵循了前面的規則，
+現在你應該已經很擅長說這句話了。
 
-同樣，不要對事情太客氣或太微妙。禮貌很容易落得落花流水，把問題隱藏起來，
-正如他們所說，“在互聯網上，沒人能聽到你的含蓄。”用一個鈍器把這一點錘進去，
-因爲你不能真的依靠別人來獲得你的觀點。
 
-一些幽默可以幫助緩和直率和道德化。過度到荒謬的地步，可以灌輸一個觀點，而不
-會讓接受者感到痛苦，他們只是認爲你是愚蠢的。因此，它可以幫助我們擺脫對批評
-的個人心理障礙。
+5) 應避免的事
+--------------
 
-.. [#cnf3] 提示：與你的工作沒有直接關係的網絡新聞組是消除你對他人不滿的好
-   方法。偶爾寫些侮辱性的帖子，打個噴嚏，讓你的情緒得到淨化。別把牢騷帶回家
+有一件事比被叫“笨蛋”更讓人討厭，那就是被人用一副道貌岸然的語氣叫“笨蛋”。
+前者你還可以道歉，後者你就不太會有道歉的機會了。即使你在其他方面做得很好，
+他們可能也不會再聽你說話了。
 
-6）爲什麼是我？
----------------
+我們都認為自己比其他任何人都強，這表示當別人擺架子時，會 **真的** 讓我們很
+不爽。你也許在道德和智識上都勝過身邊的每一個人，但除非你真的 **有意** 激怒
+某人 [#cnf3]_，否則不要表現得太明顯。
 
-既然你的主要責任似乎是爲別人的錯誤承擔責任，並且讓別人痛苦地明白你是不稱職
-的，那麼顯而易見的問題之一就變成了爲什麼首先要這樣做。
+同樣地，也不要對事情太客氣或太含蓄。禮貌很容易做過頭而把問題掩蓋起來，而且
+正如俗話說的：“在網路上，沒有人聽得出你的含蓄。”用一個又大又鈍的東西把重點
+敲進去，因為除此之外你真的無法指望別人理解你的重點。
 
-首先，雖然你可能會或可能不會聽到十幾歲女孩（或男孩，讓我們不要在這裏評判或
-性別歧視）敲你的更衣室門，你會得到一個巨大的個人成就感爲“負責”。別介意你真
-的在領導別人，你要跟上別人，儘可能快地追趕他們。每個人都會認爲你是負責人。
+一點幽默有助於緩和直率與說教。誇張到荒謬的地步，可以讓重點深入人心，又不會
+讓接收者感到痛苦，他們只會覺得你在耍寶。因此，它有助於突破我們每個人面對
+批評時都有的心理障礙。
 
-如果你可以做到這個， 這是個偉大的工作！
+.. [#cnf3] 提示：與你的工作沒有直接關係的網路新聞群組，是發洩你對其他人的
+   不滿的好地方。偶爾帶著輕蔑寫幾篇侮辱人的文章，好好來場論戰，你就會覺得
+   身心都被淨化了。只是別在自家門口拉屎。
 
+
+6) 為什麼是我？
+----------------
+
+既然你的主要責任似乎就是替別人的錯誤背黑鍋，並且讓其他所有人都痛苦地清楚
+看到你有多無能，那麼顯而易見的問題就變成：當初為什麼要做這份工作？
+
+首先，雖然你不一定會有尖叫的少女（或少年，在這裡我們就別帶著評判眼光或性別
+歧視了）來敲你更衣室的門，但你 **一定** 會因為“負責掌管”而獲得巨大的個人
+成就感。別在意事實上你的領導方式，是努力跟上其他所有人，並盡可能快地追在
+他們後面跑。大家還是會認為你是負責人。
+
+如果你應付得來，這是一份很棒的工作。
-- 
2.43.0

[PATCH 16/25] docs/zh_TW: process: sync security-bugs.rst with the English original

[Chen-Yu Yeh]

The translation still mirrors the 2021 text: a short "Contact" section
pointing at security@kernel.org and a coordination section about the old
vs.openwall.org list and its "[vs]" subject prefix.  Since then the
English document has been rewritten section by section, so retranslate
it in full against the current text:

- add "Preparing your report" with the mandatory and desirable items
  (commit 496fa1befba1 ("Documentation: clarify the mandatory and
  desirable info for security reports"), commit e447f7f33fa0 ("docs:
  security-bugs: clarify what counts as a valid version"))
- add "What qualifies as a security bug", including the threat-model
  link and the rule that AI-found bugs are to be treated as public
  (commit a03ef333fbd6 ("Documentation: security-bugs: explain what is
  and is not a security bug"), commit 561458db0d6b ("docs:
  security-bugs: add a link to the threat-model documentation"),
  commit 4bf85afb9f3e ("Documentation: security-bugs: clarify
  requirements for AI-assisted reports"))
- add "Identifying contacts" with the get_maintainer.pl examples
  (commit a72b832a4823 ("Documentation: explain how to find maintainers
  addresses for security reports"))
- add "Responsible use of AI to find bugs" and the steps an AI assistant
  must follow (commit 4bf85afb9f3e ("Documentation: security-bugs:
  clarify requirements for AI-assisted reports"),
  commit 6ffecfe0805e ("docs: security-bugs: clarify some mandatory
  steps for AI reports"))
- add "Sending the report": collaboration with the reporter, when to
  "Cc:" the security team, the plain-text requirement
  (commit d49172bbd7eb ("Documentation: clarify the expected
  collaboration with security bugs reporters"),
  commit ceddb2c001d9 ("Documentation: insist on the plain-text
  requirement for security reports"),
  commit aed3c3346765 ("Documentation: security-bugs: do not
  systematically Cc the security team"))
- replace the coordination and CVE sections with the current
  "Coordination with other groups" and "CVE assignment" text
  (commit 4fee0915e649 ("Documentation: security-bugs.rst: update
  preferences when dealing with the linux-distros group"),
  commit 0217f3944aeb ("Documentation: security-bugs.rst: linux-distros
  relaxed their rules"), commit 3c1897ae4b6b ("Documentation:
  security-bugs.rst: clarify CVE handling"),
  commit 5928d411557e ("Documentation: Document the Linux Kernel CVE
  process"))
- localize terminology (內核→核心, 信息→資訊, 代碼→程式碼, 爲→為,
  發佈→發布)

zh_TW has no translation of process/cve.rst, so the CVE section names
Documentation/process/cve.rst as plain text rather than a :doc: link.

Now that the file is in sync, drop the not-kept-in-sync notice.

update to commit 6ffecfe0805e ("docs: security-bugs: clarify some
mandatory steps for AI reports")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/security-bugs.rst           | 296 +++++++++++++++---
 1 file changed, 249 insertions(+), 47 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/security-bugs.rst b/Documentation/translations/zh_TW/process/security-bugs.rst
index 783d7c77b5fa..bdb8f8f35a9c 100644
--- a/Documentation/translations/zh_TW/process/security-bugs.rst
+++ b/Documentation/translations/zh_TW/process/security-bugs.rst
@@ -1,74 +1,276 @@
 .. SPDX-License-Identifier: GPL-2.0
 
 .. include:: ../disclaimer-zh_TW.rst
-.. include:: ../unmaintained-zh_TW.rst
 
 :Original: :doc:`../../../process/security-bugs`
 
 安全缺陷
 =========
 
-Linux內核開發人員非常重視安全性。因此我們想知道何時發現了安全漏洞，以便儘快
-修復和披露。請向Linux內核安全團隊報告安全漏洞。
+Linux 核心開發人員非常重視安全性。因此，我們希望在發現安全缺陷時能夠得知，
+以便盡快修復並披露。
 
-聯絡
------
+準備你的報告
+------------
 
-可以通過電子郵件<security@kernel.org>聯繫Linux內核安全團隊。這是一個安全人員
-的私有列表，他們將幫助驗證錯誤報告並開發和發佈修復程序。如果您已經有了一個
-修復，請將其包含在您的報告中，這樣可以大大加快進程。安全團隊可能會從區域維護
-人員那裏獲得額外的幫助，以理解和修復安全漏洞。
+和任何缺陷報告一樣，安全缺陷報告需要開發人員進行大量的分析工作，因此你能提供
+的問題資訊越多越好。如果你不清楚哪些資訊有幫助，請參閱
+Documentation/admin-guide/reporting-issues.rst 中概述的步驟。以下資訊在
+**任何** 安全缺陷報告中都是絕對必要的：
 
-與任何缺陷一樣，提供的信息越多，診斷和修復就越容易。如果您不清楚哪些信息有用，
-請查看“Documentation/translations/zh_CN/admin-guide/reporting-issues.rst”中
-概述的步驟。任何利用漏洞的攻擊代碼都非常有用，未經報告者同意不會對外發布，除
-非已經公開。
+  * **受影響的核心版本範圍**：沒有標明版本的報告將不會被處理。注意，像「最新
+    的 mainline」這類會隨時間改變的版本是不可接受的，必須提供穩定的識別方式，
+    例如 commit ID 或確切的版本號碼。非來自 kernel.org 的核心（例如發行版
+    核心）的版本號碼對維護者沒有意義，也不會被處理。相當一部分報告針對的是
+    已經修復的缺陷，因此務必在較新的版本（開發樹或最新的穩定版）上驗證漏洞，
+    至少要確認自發現問題的版本以來，相關程式碼沒有改變。
 
-請儘可能發送無附件的純文本電子郵件。如果所有的細節都藏在附件裏，那麼就很難對
-一個複雜的問題進行上下文引用的討論。把它想象成一個
-:doc:`常規的補丁提交 <../process/submitting-patches>` （即使你還沒有補丁）：
-描述問題和影響，列出復現步驟，然後給出一個建議的解決方案，所有這些都是純文本的。
+  * **問題描述**：必須詳細描述問題，附上顯示問題如何出現的追蹤記錄，並說明你
+    為什麼認為觀察到的行為是核心的問題。
 
-披露和限制信息
----------------
+  * **重現程式**：開發人員需要能夠重現問題，才能確認修復有效。這包括觸發問題
+    的方法，以及確認問題確實發生的方法。需要提供依賴項簡單的重現程式（原始碼、
+    shell 腳本、一系列操作步驟、檔案系統映像檔等）。只有二進位執行檔的重現程式
+    不被接受。可用的漏洞利用程式（exploit）非常有幫助，未經報告者同意不會對外
+    發布，除非它們已經公開。按照定義，無法重現的問題就無法被利用，因此也不是
+    安全缺陷。
 
-安全列表不是公開渠道。爲此，請參見下面的協作。
+  * **條件**：如果缺陷取決於特定的設定選項、sysctl、權限、時序、程式碼修改等，
+    應該一併註明。
 
-一旦開發出了健壯的補丁，發佈過程就開始了。對公開的缺陷的修復會立即發佈。
+此外，以下資訊也非常需要：
 
-儘管我們傾向於在未公開缺陷的修復可用時即發佈補丁，但應報告者或受影響方的請求，
-這可能會被推遲到發佈過程開始後的7日內，如果根據缺陷的嚴重性需要更多的時間，
-則可額外延長到14天。推遲發佈修復的唯一有效原因是爲了適應QA的邏輯和需要發佈
-協調的大規模部署。
+  * **疑似的缺陷位置**：疑似存在缺陷的檔案名稱與函式非常重要，至少有助於把報告
+    轉給適當的維護者。如果無法提供（例如「每次執行這個指令系統都會凍結」），
+    安全團隊會協助找出缺陷的來源。
 
-雖然可能與受信任的個人共享受限信息以開發修復，但未經報告者許可，此類信息不會
-與修復程序一起發佈或發佈在任何其他披露渠道上。這包括但不限於原始錯誤報告和
-後續討論（如有）、漏洞、CVE信息或報告者的身份。
+  * **建議的修復**：在原始碼中分析過缺陷成因的報告者，幾乎總是很清楚該如何修復
+    它，因為他們花了很長時間研究缺陷及其影響。提出經過測試的修復能為維護者節省
+    大量時間，即使該修復最終並不正確也一樣，因為它有助於理解缺陷。提出經過測試
+    的修復時，請務必將其整理成可以直接合併的格式（請參閱
+    Documentation/process/submitting-patches.rst）。如果修復被接受，這能省去
+    一些來回溝通，而你也會因為發現並修復這個問題而獲得認可。注意，在這種情況
+    下，當報告者與作者是同一人時，只需要 ``Signed-off-by:`` 標籤，不需要
+    ``Reported-by:``。
 
-換句話說，我們唯一感興趣的是修復缺陷。提交給安全列表的所有其他資料以及對報告
-的任何後續討論，即使在解除限制之後，也將永久保密。
+  * **緩解措施**：在分析缺陷的過程中，經常會找到一些緩解問題的方法。分享這些
+    方法很有用，因為在終端使用者套用修復之前的這段時間，它們有助於保護使用者。
 
-協調
-------
+什麼才算安全缺陷
+----------------
 
-對敏感缺陷（例如那些可能導致權限提升的缺陷）的修復可能需要與私有郵件列表
-<linux-distros@vs.openwall.org>進行協調，以便分發供應商做好準備，在公開披露
-上游補丁時發佈一個已修復的內核。發行版將需要一些時間來測試建議的補丁，通常
-會要求至少幾天的限制，而供應商更新發布更傾向於週二至週四。若合適，安全團隊
-可以協助這種協調，或者報告者可以從一開始就包括linux發行版。在這種情況下，請
-記住在電子郵件主題行前面加上“[vs]”，如linux發行版wiki中所述：
-<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>。
+大多數缺陷都應該公開處理，才能讓最多的人參與並找到最好的解決方案，這一點很
+重要。就本質而言，在少數參與者之間以非公開討論處理的缺陷，比較不容易得到最好
+的修復（例如可能遺漏合理的使用情境、測試能力有限）。
 
-CVE分配
+事實上，透過安全團隊回報的缺陷，大多只是一般缺陷，只因為不了解 Linux 核心的
+威脅模型（如 Documentation/process/threat-model.rst 所述）而被錯誤地認定為
+安全缺陷；它們原本應該透過 Documentation/admin-guide/reporting-issues.rst
+所述的一般管道回報。
+
+安全列表是為緊急缺陷而設的：這類缺陷讓攻擊者在設定正確的生產系統上獲得原本不
+應擁有的能力，而且容易被利用，對許多使用者構成迫切的威脅。回報之前，請想一想
+這個問題在這樣的系統上是否確實跨越了信任邊界。
+
+**如果你藉助 AI 找到缺陷，就必須將其視為已公開**。雖然你可能有合理的理由認為
+並非如此，但安全團隊的經驗顯示，以這種方式發現的缺陷總是會同時被多位研究人員
+發現，而且往往就在同一天。在這種情況下，不要公開分享重現程式，因為這可能造成
+意料之外的傷害；只要說明有重現程式即可，維護者如果需要，可能會私下向你索取。
+
+如果你不確定某個問題是否符合條件，寧可選擇私下回報：安全團隊寧願分流處理一份
+模稜兩可的報告，也不願錯過真正的漏洞。然而，把一般缺陷回報到安全列表並不會讓
+它們處理得更快，反而會消耗其他報告所需的分流人力。
+
+找出聯絡對象
+------------
+
+回報安全缺陷最有效的方式，是直接寄給受影響子系統的維護者，並 Cc: Linux 核心
+安全團隊。在這個階段不要寄到公開的郵件列表，除非你有充分的理由認為這個問題已經
+公開或很容易被發現（例如任何人都能重複執行、廣泛可得的自動化漏洞掃描工具所找到
+的結果，或是使用 AI 工具找到的問題）。
+
+如果你要回報的問題影響核心中的多個部分，即使這些問題相當類似，也請分別寄送訊息
+（想想看，維護者們不會同時處理這些問題）。唯一的例外是，問題涉及的是由完全相同
+的一組維護者所維護、彼此密切相關的部分，而且這些部分預期會由同一個 commit 一次
+修復，這時一起回報或許是可以接受的。
+
+對大多數第一次回報的人來說，困難之一是找出報告該寄給哪些收件人。在 Linux 核心
+中，所有正式的維護者都是受信任的，因此不小心把錯誤的維護者加進收件人，後果基本
+上只是給那個人多一點雜訊，並不嚴重。因此，找出維護者名單的一個合適方法（核心
+安全人員也是這麼做的）是使用 get_maintainer.pl 腳本，並調整參數讓它只列出
+維護者。把檔案名稱傳給這個腳本時，它會在 MAINTAINERS 檔案中尋找該路徑，找出
+相關維護者的階層式名單。第一次以最精細的過濾層級呼叫它，多數時候會回傳這個特定
+檔案的少數幾位維護者::
+
+  $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
+    drivers/example.c
+  Developer One <dev1@example.com> (maintainer:example driver)
+  Developer Two <dev2@example.org> (maintainer:example driver)
+
+接著就應該把訊息寄給這兩位維護者。如果指令沒有回傳任何結果，表示受影響的檔案
+屬於一個更大的子系統，因此我們應該放寬範圍::
+
+  $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
+  Developer One <dev1@example.com> (maintainer:example subsystem)
+  Developer Two <dev2@example.org> (maintainer:example subsystem)
+  Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
+  Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])
+
+在這裡，挑選最前面、範圍最明確的那幾位就足夠了。名單很長時，可以像下面這樣
+產生一行以逗號分隔、適合用在郵件客戶端 To: 欄位的電子郵件地址列表::
+
+  $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+    --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+    --pattern-depth 1 drivers/example.c
+  dev1@example.com, dev2@example.org
+
+或者像下面這樣產生範圍較廣的名單::
+
+  $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+    --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+    drivers/example.c
+  dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org
+
+如果到了這一步，你仍然難以找出正確的維護者，**而且只有在這種情況下**，才可以
+只把報告寄給 Linux 核心安全團隊。你的訊息會經過分流處理，如有需要，你會收到
+應該聯絡誰的指示。你的訊息也可能被原封不動地轉寄給相關維護者。
+
+負責任地使用 AI 尋找缺陷
+------------------------
+
+提交給安全團隊的缺陷報告中，有相當大一部分其實是借助 AI 工具進行程式碼審查的
+結果。雖然這可以是在鮮少有人探索的領域中找到缺陷的有效手段，卻也造成維護者的
+負擔過重，有時他們不得不因為這類報告的品質或準確度太差而忽略它們。因此，報告者
+必須特別注意以下幾點，它們往往讓這些報告變得不必要地難以處理：
+
+  * **長度**：AI 產生的報告往往過於冗長，包含多個章節與過多細節。這使得受影響
+    的檔案、版本與影響等重要資訊難以找到。請確保先列出清楚的問題摘要與所有關鍵
+    細節。不要讓負責分流的工程師閱讀好幾頁的文字。請設定你的工具，讓它產生簡潔、
+    像人寫的報告。
+
+  * **格式**：大多數 AI 產生的報告充斥著 Markdown 標記。這些裝飾讓尋找重要資訊
+    變得更困難，而且在轉寄或回覆所涉及的引用過程中也無法保留。寄出之前，請
+    **務必把報告轉換成純文字**，不要帶任何格式裝飾。
+
+  * **影響評估**：許多 AI 產生的報告缺乏對核心威脅模型的理解（請參閱
+    Documentation/process/threat-model.rst），並費盡心思杜撰理論上的後果。
+    這只會增加雜訊，讓分流更複雜。請只陳述可驗證的事實（例如「這個缺陷讓任何
+    使用者都能取得 CAP_NET_ADMIN」），不要列舉推測性的影響。請在評估過程中讓
+    你的工具閱讀這份文件。
+
+  * **重現程式**：AI 工具通常有能力產生重現程式。請務必確保你的工具提供重現
+    程式，並 **徹底測試它**。如果重現程式無法運作，或工具無法產生重現程式，就
+    應該嚴肅質疑這份報告的有效性。注意，由於報告會被張貼到公開的郵件列表，重現
+    程式只應在維護者要求時才分享。
+
+  * **提出修復**：許多 AI 工具其實比較擅長寫程式碼，而不是評估程式碼。請在回報
+    問題之前，要求你的工具提出修復並 **測試它**。如果因為修復依賴罕見的硬體或
+    幾乎絕跡的網路協定而無法測試，這個問題很可能就不是安全缺陷。無論如何，如果
+    提出了修復，它都必須遵守 Documentation/process/submitting-patches.rst，並
+    包含一個 'Fixes:' 標籤，指出引入該缺陷的 commit。
+
+沒有考慮這些要點的報告，可能會面臨被忽略的風險。
+
+評估報告時請運用常識。如果受影響的檔案已經超過一年沒有被修改，而且只由單一個人
+維護，那麼它的使用量很可能已經下降，受影響的使用者幾乎不存在（例如非常老舊硬體
+的驅動程式、過時的檔案系統）。在這種情況下，沒有必要用不重要的報告佔用維護者的
+時間。如果問題顯然微不足道且可被公開發現，你應該直接回報到公開的郵件列表。
+
+至少，在使用 AI 助理尋找並回報缺陷時，要讓助理在開始之前先閱讀這份文件與
+threat-model.rst，並讓它遵循 coding-assistants.rst 中描述的程序：在最新的
+mainline 樹上工作並記下 commit ID、確認缺陷確實存在、撰寫修復、建置時沒有警告
+且通過 checkpatch 檢查、以 Fixes 標籤提交 commit，並用 get_maintainer.pl 找出
+維護者。
+
+除了該程序之外，AI 助理 **必須**：
+
+1. 準備一份說明問題的純文字報告。報告必須包含本文開頭列為絕對必要的四個項目：
+   遵循上述程序時記下的受影響版本或 commit ID、問題描述、重現程式或其狀態，以及
+   觸發條件。
+2. 在報告開頭加上一個暫時的段落，列出收件人地址（補丁寄給維護者加郵件列表，報告
+   與重現程式只寄給維護者），並附上提醒報告者確認其郵件客戶端設定正確的說明（請
+   參閱 email-clients.rst），再由報告者自行刪除這個暫時的段落。
+
+更詳細的流程請參閱 https://github.com/masoncl/kres.git 。
+
+寄送報告
 --------
 
-安全團隊通常不分配CVE，我們也不需要它們來進行報告或修復，因爲這會使過程不必
-要的複雜化，並可能耽誤缺陷處理。如果報告者希望在公開披露之前分配一個CVE編號，
-他們需要聯繫上述的私有linux-distros列表。當在提供補丁之前已有這樣的CVE編號時，
-如報告者願意，最好在提交消息中提及它。
+報告只能透過電子郵件寄送。請使用可正常收發的電子郵件地址，最好就是你希望出現在
+``Reported-by`` 標籤（如果有的話）中的地址。如果不確定，請先把報告寄給自己。
 
-保密協議
----------
+安全團隊與維護者幾乎總是需要報告最初所提供內容以外的額外資訊，並仰賴與報告者
+積極而有效率的協作來進行進一步的測試（例如驗證版本、設定選項、緩解措施或補丁）。
+在聯絡安全團隊之前，報告者必須確保自己有空說明發現、參與討論並執行額外的測試。
+如果報告者沒有即時回應，或無法有效地討論其發現，而溝通又沒有很快改善，報告就
+可能被擱置。
+
+報告必須寄給維護者。如果你的訊息收件人只有兩位或更少，你也必須一律 Cc: Linux
+核心安全團隊，他們會確保訊息送達正確的人，並能協助小型維護團隊處理他們可能不
+熟悉的流程。對於較大的團隊，在你最初的幾份報告，或需要特定協助時（例如重新寄送
+一封一週內都沒有得到回應的訊息），請 Cc: Linux 核心安全團隊。當你在幾份報告之後
+已經熟悉這個流程，寄給大型團隊時就不再需要 Cc: 安全列表。可以透過電子郵件
+<security@kernel.org> 聯絡 Linux 核心安全團隊。這是一個由安全人員組成的私有
+列表，他們會協助驗證缺陷報告，並協助開發修復的開發人員。安全團隊可能會請相關
+領域的維護者提供額外協助，以理解並修復安全漏洞。
+
+請盡可能寄送不帶附件的 **純文字** 電子郵件。如果所有細節都藏在附件裡，就很難
+針對一個複雜的問題進行引用上下文的討論。把它想成一次
+:doc:`一般的補丁提交 <../process/submitting-patches>`
+（即使你還沒有補丁）：描述問題和影響，列出重現步驟，然後附上建議的修復，全部
+都以純文字呈現。Markdown、HTML 與 RST 格式的報告特別不受歡迎，因為它們對人類
+來說相當難讀，還會促使人使用專門的檢視器，有時甚至是線上檢視器，而這對機密的
+安全報告來說，按照定義就是不可接受的。注意，有些郵件客戶端預設會弄亂純文字的
+格式，更多資訊請參閱 Documentation/process/email-clients.rst。
+
+披露與保密期資訊
+----------------
+
+安全列表不是披露管道。關於披露，請參閱下面的「協調」一節。
+
+一旦開發出可靠的修復，發布流程就會開始。已公開缺陷的修復會立即發布。
+
+雖然我們傾向在修復可用時就立即發布尚未公開缺陷的修復，但應報告者或受影響方的
+要求，發布可以從發布流程開始起延後最多 7 個日曆天；如果大家同意缺陷的嚴重程度
+需要更多時間，可以例外延長到 14 個日曆天。延後發布修復唯一正當的理由，是為了
+配合 QA 以及需要協調發布的大規模部署的作業安排。
 
-Linux內核安全團隊不是一個正式的機構實體，因此無法簽訂任何保密協議。
+雖然為了開發修復，保密期內的資訊可能會與受信任的個人分享，但未經報告者許可，
+這些資訊不會隨修復一起發布，也不會在任何其他披露管道上公開。這包括但不限於原始
+的缺陷報告與後續討論（如果有的話）、漏洞利用程式、CVE 資訊或報告者的身分。
+
+換句話說，我們唯一關心的是修好缺陷。提交到安全列表的所有其他資訊，以及關於該
+報告的任何後續討論，即使在保密期解除之後，也會永久保密。
+
+與其他團隊協調
+--------------
+
+核心安全團隊只專注於修復缺陷，而其他團隊則專注於修復發行版中的問題，以及協調
+作業系統廠商之間的披露。協調通常由 "linux-distros" 郵件列表負責，披露則由公開
+的 "oss-security" 郵件列表負責，兩者關係密切，並在 linux-distros wiki 中有所
+介紹：
+<https://oss-security.openwall.org/wiki/mailing-lists/distros>
+
+請注意，由於這三個列表追求的目標不同，它們各自的政策與規則也不同。核心安全團隊
+與其他團隊之間的協調並不容易，因為對核心安全團隊而言，偶爾設定的保密期（受最多
+允許天數的限制）是從修復可用時開始計算，而 "linux-distros" 則是從首次張貼到該
+列表時開始計算，不論修復是否可用。
+
+因此，核心安全團隊強烈建議，身為潛在安全問題的報告者，在受影響程式碼的維護者
+接受修復之前，以及在你讀過上述的發行版 wiki 頁面、並完全理解聯絡
+"linux-distros" 會對你和核心社群帶來哪些要求之前，千萬不要聯絡 "linux-distros"
+郵件列表。這也表示，一般來說同時 Cc: 兩個列表並沒有意義，除非是在修復已被接受
+但尚未合併的期間，或許為了協調而這麼做。換句話說，在修復被接受之前不要 Cc:
+"linux-distros"，而在修復被合併之後，不要 Cc: 核心安全團隊。
+
+CVE 分配
+--------
+
+安全團隊不分配 CVE，也不要求報告或修復必須有 CVE，因為這可能讓流程變得不必要地
+複雜，並可能延誤缺陷的處理。如果報告者希望為已確認的問題分配 CVE 識別碼，可以
+聯絡核心 CVE 分配團隊取得（請參閱 Documentation/process/cve.rst）。
+
+保密協議
+--------
 
+Linux 核心安全團隊不是正式的組織，因此無法簽訂任何保密協議。
-- 
2.43.0

[PATCH 17/25] docs/zh_TW: process: sync volatile-considered-harmful.rst with the English original

[Chen-Yu Yeh]

The translation carries no "update to commit" marker.  A comparison
against the current English text shows every paragraph is present, but
the prose was converted from zh_CN and several sentences drifted from
the original:

- cpu_relax() "happens to serve as a compiler barrier", not a memory
  barrier
- the use of volatile "is likely to be seen as a bug" and will bring
  additional scrutiny, rather than simply being a bug
- I/O memory accesses are "always" done through accessor functions,
  and "busy-waiting is generally an anti-social act"
- render the "fixing it would be more trouble than it is worth" clause
  of the jiffies item and the "justification" required of patches
  removing volatile variables as in the original
- restore the emphasis on "within" in the critical section paragraph
- localize terminology (內核→核心, 代碼→程式碼, 內存→記憶體,
  寄存器→暫存器, 變量→變數, 訪問→存取, 優化→最佳化, 線程→執行緒,
  網絡適配器→網路卡, 爲→為, 裏→裡)
- use the same heading underline characters as the original, and put
  the references and credit lines in separate paragraphs so they no
  longer run together in the rendered output

update to commit 93431e0607e5 ("Replace HTTP links with HTTPS ones:
documentation")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../process/volatile-considered-harmful.rst   | 115 +++++++++---------
 1 file changed, 59 insertions(+), 56 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst b/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst
index edfc83f32672..6c54c9442524 100644
--- a/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst
+++ b/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst
@@ -7,92 +7,95 @@
 :Original: :ref:`Documentation/process/volatile-considered-harmful.rst
            <volatile_considered_harmful>`
 
-爲什麼不應該使用“volatile”類型
-==============================
+為什麼不應該使用“volatile”類型
+------------------------------
 
-C程序員通常認爲volatile表示某個變量可以在當前執行的線程之外被改變；因此，在內核
-中用到共享數據結構時，常常會有C程序員喜歡使用volatile這類變量。換句話說，他們經
-常會把volatile類型看成某種簡易的原子變量，當然它們不是。在內核中使用volatile幾
-乎總是錯誤的；本文檔將解釋爲什麼這樣。
+C程式設計師常認為volatile表示變數可能在目前的執行緒之外被改變；因此，在核心中
+使用共享資料結構時，他們有時會想用volatile。換句話說，他們常把volatile類型當成
+某種簡易的原子變數，但它並不是。在核心程式碼中使用volatile幾乎從來都不正確；
+本文件將說明原因。
 
-理解volatile的關鍵是知道它的目的是用來消除優化，實際上很少有人真正需要這樣的應
-用。在內核中，程序員必須防止意外的併發訪問破壞共享的數據結構，這其實是一個完全
-不同的任務。用來防止意外併發訪問的保護措施，可以更加高效的避免大多數優化相關的
-問題。
+理解volatile的關鍵在於：它的目的是抑制最佳化，而這幾乎從來不是我們真正想做的
+事。在核心中，必須保護共享資料結構免受不必要的並行存取，這是一個完全不同的任
+務。防範不必要並行的過程，也能以更有效率的方式避免幾乎所有與最佳化相關的問題。
 
-像volatile一樣，內核提供了很多原語來保證併發訪問時的數據安全（自旋鎖, 互斥量,內
-存屏障等等），同樣可以防止意外的優化。如果可以正確使用這些內核原語，那麼就沒有
-必要再使用volatile。如果仍然必須使用volatile，那麼幾乎可以肯定在代碼的某處有一
-個bug。在正確設計的內核代碼中，volatile能帶來的僅僅是使事情變慢。
+和volatile一樣，核心中讓資料並行存取變得安全的原語（自旋鎖、互斥鎖、記憶體屏障
+等）也是為了防止不必要的最佳化而設計的。如果正確使用了這些原語，就不需要再使用
+volatile。如果仍然需要volatile，那麼程式碼中幾乎肯定在某處有bug。在正確撰寫的
+核心程式碼中，volatile只會讓事情變慢。
 
-思考一下這段典型的內核代碼::
+思考一下這段典型的核心程式碼::
 
     spin_lock(&the_lock);
     do_something_on(&shared_data);
     do_something_else_with(&shared_data);
     spin_unlock(&the_lock);
 
-如果所有的代碼都遵循加鎖規則，當持有the_lock的時候，不可能意外的改變shared_data的
-值。任何可能訪問該數據的其他代碼都會在這個鎖上等待。自旋鎖原語跟內存屏障一樣—— 它
-們顯式的用來書寫成這樣 —— 意味着數據訪問不會跨越它們而被優化。所以本來編譯器認爲
-它知道在shared_data裏面將有什麼，但是因爲spin_lock()調用跟內存屏障一樣，會強制編
-譯器忘記它所知道的一切。那麼在訪問這些數據時不會有優化的問題。
+如果所有程式碼都遵循加鎖規則，那麼在持有the_lock期間，shared_data的值不可能意
+外改變。任何其他想要操作該資料的程式碼都會在這個鎖上等待。自旋鎖原語會充當記憶
+體屏障——它們是刻意這樣撰寫的——這表示資料存取不會被跨越它們而最佳化。所以編譯器
+可能自認為知道shared_data裡會是什麼，但由於spin_lock()呼叫充當記憶體屏障，會強
+制編譯器忘掉它所知道的一切。存取這些資料時不會有最佳化的問題。
 
-如果shared_data被聲名爲volatile，鎖操作將仍然是必須的。就算我們知道沒有其他人正在
-使用它，編譯器也將被阻止優化對臨界區內shared_data的訪問。在鎖有效的同時，
-shared_data不是volatile的。在處理共享數據的時候，適當的鎖操作可以不再需要
-volatile —— 並且是有潛在危害的。
+如果把shared_data宣告為volatile，加鎖仍然是必要的。但編譯器也會因此無法在臨界
+區 *內* 最佳化對shared_data的存取，而此時我們明知沒有其他人能操作它。在持有鎖期
+間，shared_data並不是volatile的。處理共享資料時，正確的加鎖讓volatile變得不必要
+——而且可能有害。
 
-volatile的存儲類型最初是爲那些內存映射的I/O寄存器而定義。在內核裏，寄存器訪問也應
-該被鎖保護，但是人們也不希望編譯器“優化”臨界區內的寄存器訪問。內核裏I/O的內存訪問
-是通過訪問函數完成的；不贊成通過指針對I/O內存的直接訪問，並且不是在所有體系架構上
-都能工作。那些訪問函數正是爲了防止意外優化而寫的，因此，再說一次，volatile類型不
-是必需的。
+volatile儲存類別原本是為記憶體映射的I/O暫存器而設計的。在核心中，暫存器存取同樣
+應該受鎖保護，但我們也不希望編譯器“最佳化”臨界區內的暫存器存取。不過在核心中，
+I/O記憶體存取一律透過存取函式完成；直接透過指標存取I/O記憶體是不被認可的做法，
+而且並非在所有架構上都能運作。這些存取函式就是為了防止不必要的最佳化而撰寫的，
+所以，再說一次，volatile是不必要的。
 
-另一種引起用戶可能使用volatile的情況是當處理器正忙着等待一個變量的值。正確執行一
-個忙等待的方法是::
+另一種可能讓人想使用volatile的情況，是處理器忙等（busy-wait）某個變數的值。執行
+忙等的正確方式是::
 
     while (my_variable != what_i_want)
         cpu_relax();
 
-cpu_relax()調用會降低CPU的能量消耗或者讓位於超線程雙處理器；它也作爲內存屏障一樣出
-現，所以，再一次，volatile不是必需的。當然，忙等待一開始就是一種反常規的做法。
+cpu_relax()呼叫可以降低CPU功耗，或讓位給超執行緒（hyperthreaded）的另一個邏輯處
+理器；它同時也剛好充當編譯器屏障，所以，再說一次，volatile是不必要的。當然，忙
+等本身通常就是一種不顧他人的行為。
 
-在內核中，一些稀少的情況下volatile仍然是有意義的：
+在核心中，仍有少數罕見的情況下使用volatile是合理的：
 
-  - 在一些體系架構的系統上，允許直接的I/0內存訪問，那麼前面提到的訪問函數可以使用
-    volatile。基本上，每一個訪問函數調用它自己都是一個小的臨界區域並且保證了按照
-    程序員期望的那樣發生訪問操作。
+  - 在確實支援直接存取I/O記憶體的架構上，上述存取函式可能會使用volatile。基本
+    上，每一次存取函式呼叫本身就成為一個小的臨界區，確保存取依照程式設計師預期
+    的方式發生。
 
-  - 某些會改變內存的內聯彙編代碼雖然沒有什麼其他明顯的附作用，但是有被GCC刪除的可
-    能性。在彙編聲明中加上volatile關鍵字可以防止這種刪除操作。
+  - 會修改記憶體、但沒有其他可見副作用的行內組合語言程式碼，有被GCC刪除的風險。
+    在asm敘述中加上volatile關鍵字可以防止這種刪除。
 
-  - Jiffies變量是一種特殊情況，雖然每次引用它的時候都可以有不同的值，但讀jiffies
-    變量時不需要任何特殊的加鎖保護。所以jiffies變量可以使用volatile，但是不贊成
-    其他跟jiffies相同類型變量使用volatile。Jiffies被認爲是一種“愚蠢的遺留物"
-    （Linus的話）因爲解決這個問題比保持現狀要麻煩的多。
+  - jiffies變數很特殊，每次引用它時都可能得到不同的值，但讀取它時不需要任何特殊
+    的加鎖。所以jiffies可以是volatile，但強烈不贊成再新增其他這類變數。在這方
+    面，jiffies被認為是一個“愚蠢的歷史遺留”問題（Linus的原話）；修正它的麻煩會
+    比它的價值還大。
 
-  - 由於某些I/0設備可能會修改連續一致的內存,所以有時,指向連續一致內存的數據結構
-    的指針需要正確的使用volatile。網絡適配器使用的環狀緩存區正是這類情形的一個例
-    子，其中適配器用改變指針來表示哪些描述符已經處理過了。
+  - 指向一致性記憶體（coherent memory）中、可能被I/O裝置修改的資料結構的指標，有
+    時可以正當地使用volatile。網路卡使用的環形緩衝區就是這類情況的一個例子，網路
+    卡會改變其中的指標，以表示哪些描述符已經處理完畢。
 
-對於大多代碼，上述幾種可以使用volatile的情況都不適用。所以，使用volatile是一種
-bug並且需要對這樣的代碼額外仔細檢查。那些試圖使用volatile的開發人員需要退一步想想
-他們真正想實現的是什麼。
+對大多數程式碼來說，上述使用volatile的理由都不適用。因此，使用volatile很可能被
+視為bug，並使程式碼受到額外的審查。想使用volatile的開發者應該退一步，想想自己真
+正想達成的是什麼。
 
-非常歡迎刪除volatile變量的補丁 － 只要證明這些補丁完整的考慮了併發問題。
+一般都歡迎移除volatile變數的補丁——只要附上能證明並行問題已經過周全考慮的理由。
 
-註釋
-----
+
+參考資料
+========
 
 [1] https://lwn.net/Articles/233481/
+
 [2] https://lwn.net/Articles/233482/
 
 致謝
-----
+====
+
+最初由Randy Dunlap推動並進行研究
 
-最初由Randy Dunlap推動並作初步研究
 由Jonathan Corbet撰寫
-參考Satyam Sharma，Johannes Stezenbach，Jesper Juhl，Heikki Orsila，
-H. Peter Anvin，Philipp Hahn和Stefan Richter的意見改善了本檔。
 
+感謝Satyam Sharma、Johannes Stezenbach、Jesper Juhl、Heikki Orsila、
+H. Peter Anvin、Philipp Hahn和Stefan Richter的意見讓本文件得以改進。
-- 
2.43.0

[PATCH 18/25] docs/zh_TW: process: sync 3.Early-stage.rst with the English original

[Chen-Yu Yeh]

The translation carries no "update to commit" marker.  A comparison
against the current English text shows it never picked up several
later changes, and the prose was converted from zh_CN with a number of
sentences that drifted from the original:

- add the missing sentence from
  commit f1a693994b1c ("Documentation/process: use
  scripts/get_maintainer.pl on patches") that running the script on a
  patch is the preferred way to get the Cc list
- use the HTTPS LWN and Linux Foundation NDA URLs from
  commit 93431e0607e5 ("Replace HTTP links with HTTPS ones:
  documentation") and commit 997023047459 ("docs: Update the location of
  the LF NDA program"), and capitalize Git and write "git log" as in
  commit 4a0be1a25d98 ("Documentation: process: Capitalize Git, Quilt,
  and Mercurial consistently")
- retranslate sentences whose meaning had drifted: audio "dropouts"
  (rendered as exiting), "your author has seen" (rendered as "some
  author posted"), "no shortage of people with grand plans and little
  code", code "not cleared for release under a GPL-compatible
  license", a company that "legitimately" cannot disclose its plans,
  "a hostile reaction", and the Devicescape and AppArmor items
- spell Devicescape and AppArmor as in the original
- localize terminology (內核→核心, 代碼→程式碼, 項目→專案, 模塊→模組,
  用戶→使用者, 社區→社群, 文件系統→檔案系統, 信息→資訊, 補丁→修補程式,
  爲→為, 裏→裡)
- expand the tabs in the quoted block

update to commit 4a0be1a25d98 ("Documentation: process: Capitalize Git,
Quilt, and Mercurial consistently")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/3.Early-stage.rst           | 192 +++++++++---------
 1 file changed, 96 insertions(+), 96 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/3.Early-stage.rst b/Documentation/translations/zh_TW/process/3.Early-stage.rst
index 7d7ecf9658e5..deb5baa4e53f 100644
--- a/Documentation/translations/zh_TW/process/3.Early-stage.rst
+++ b/Documentation/translations/zh_TW/process/3.Early-stage.rst
@@ -9,155 +9,155 @@
 早期規劃
 ========
 
-當考慮一個Linux內核開發項目時，很可能會直接跳進去開始編碼。然而，與任何重要
-的項目一樣，許多成功的基礎最好是在第一行代碼編寫之前就打下。在早期計劃和
-溝通中花費一些時間可以在之後節省更多的時間。
+當考慮一個Linux核心開發專案時，很容易想直接跳進去開始寫程式。然而，與任何
+重要的專案一樣，許多成功的基礎最好是在寫下第一行程式碼之前就打好。在早期規
+劃和溝通上花一些時間，可以在之後節省更多的時間。
 
 搞清問題
 --------
 
-與任何工程項目一樣，成功的內核改善從清晰描述要解決的問題開始。在某些情況
-下，這個步驟很容易：例如當某個特定硬件需要驅動程序時。不過，在其他情況下，
-很容易將實際問題與建議的解決方案混在一起，這可能會導致麻煩。
+與任何工程專案一樣，成功的核心改進從清楚描述要解決的問題開始。在某些情況
+下，這個步驟很容易：例如當某個特定硬體需要驅動程式時。不過，在其他情況下，
+很容易將實際問題與建議的解決方案混為一談，這可能會導致麻煩。
 
-舉個例子：幾年前，Linux音頻的開發人員尋求一種方法來運行應用程序，而不會因
-系統延遲過大而導致退出或其他問題。他們得到的解決方案是一個連接到Linux安全
-模塊（LSM）框架中的內核模塊；這個模塊可以配置爲允許特定的應用程序訪問實時
-調度程序。這個模塊被實現併發到linux-kernel郵件列表，在那裏它立即遇到了麻煩。
+舉個例子：幾年前，從事Linux音訊工作的開發人員尋求一種方法，讓應用程式在執
+行時不會因系統延遲過大而產生斷音或其他雜音。他們得到的解決方案是一個掛接到
+Linux安全模組（LSM）框架中的核心模組；這個模組可以設定為允許特定的應用程式
+使用即時排程器。這個模組被實作出來並發送到linux-kernel郵件列表，在那裡它立
+即遇到了麻煩。
 
-對於音頻開發人員來說，這個安全模塊足以解決他們當前的問題。但是，對於更廣泛的
-內核社區來說，這被視爲對LSM框架的濫用（LSM框架並不打算授予他們原本不具備的
-進程特權），並對系統穩定性造成風險。他們首選的解決方案包括短期的通過rlimit
-機制進行實時調度訪問，以及長期的減少延遲的工作。
+對於音訊開發人員來說，這個安全模組足以解決他們眼前的問題。但是，對於更廣泛的
+核心社群來說，這被視為對LSM框架的濫用（LSM框架並不是用來授予行程原本不具備
+的特權的），並對系統穩定性造成風險。他們偏好的解決方案是短期內透過rlimit機
+制取得即時排程的權限，長期則持續進行減少延遲的工作。
 
-然而，音頻社區無法超越他們實施的特定解決方案來看問題；他們不願意接受替代方案。
-由此產生的分歧使這些開發人員對整個內核開發過程感到失望；其中一個開發人員返回
-到audio列表併發布了以下內容：
+然而，音訊社群無法跳脫他們已實作的特定解決方案來看問題；他們不願意接受替代
+方案。由此產生的分歧使這些開發人員對整個核心開發過程感到幻滅；其中一位開發
+人員回到一個音訊郵件列表上，發表了以下內容：
 
-	有很多非常好的Linux內核開發人員，但他們往往會被一羣傲慢的傻瓜所壓倒。
-	試圖向這些人傳達用戶需求是浪費時間。他們太“聰明”了，根本聽不到少數
-	人的話。
+        有很多非常好的Linux核心開發人員，但他們的聲音往往被一大群傲慢的
+        傻瓜蓋過。試圖向這些人傳達使用者的需求是浪費時間。他們太「聰明」
+        了，根本不屑聽凡夫俗子的話。
 
-（http://lwn.net/Articles/131776/）
+(https://lwn.net/Articles/131776/)。
 
-實際情況卻是不同的；與特定模塊相比，內核開發人員更關心繫統穩定性、長期維護
+實際情況卻是不同的；與特定模組相比，核心開發人員更關心系統穩定性、長期維護
 以及找到問題的正確解決方案。這個故事的寓意是把重點放在問題上——而不是具體的
-解決方案上——並在開始編寫代碼之前與開發社區討論這個問題。
+解決方案上——並在投入時間寫出大量程式碼之前，先與開發社群討論這個問題。
 
-因此，在考慮一個內核開發項目時，我們應該得到一組簡短問題的答案：
+因此，在考慮一個核心開發專案時，應該先得到以下幾個簡短問題的答案：
 
  - 需要解決的問題究竟是什麼？
 
- - 受此問題影響的用戶有哪些？解決方案應該解決哪些使用案例？
+ - 受此問題影響的使用者有哪些？解決方案應該涵蓋哪些使用情境？
 
- - 內核現在爲何沒能解決這個問題？
+ - 核心目前在處理這個問題上有何不足？
 
-只有這樣，才能開始考慮可能的解決方案。
+只有這樣，開始考慮可能的解決方案才有意義。
 
 
 早期討論
 --------
 
-在計劃內核開發項目時，在開始實施之前與社區進行討論是很有意義的。早期溝通可以
-通過多種方式節省時間和麻煩：
+在規劃核心開發專案時，在開始實作之前與社群進行討論是很有意義的。早期溝通可以
+透過多種方式節省時間和麻煩：
 
- - 很可能問題是由內核以您不理解的方式解決的。Linux內核很大，具有許多不明顯
-   的特性和功能。並不是所有的內核功能都像人們所希望的那樣有文檔記錄，而且很
-   容易遺漏一些東西。某作者發佈了一個完整的驅動程序，重複了一個其不
-   知道的現有驅動程序。重新發明現有輪子的代碼不僅浪費，而且不會被接受到主線
-   內核中。
+ - 很可能核心已經以您沒有理解的方式處理了這個問題。Linux核心很大，具有許多不
+   明顯的特性和功能。並不是所有的核心功能都有人們所希望的那樣完善的文件，很容
+   易遺漏一些東西。本文作者就曾見過有人發布一個完整的驅動程式，卻與一個新作者
+   不知道的既有驅動程式重複。重新發明輪子的程式碼不僅浪費，而且也不會被主線核
+   心接受。
 
- - 建議的解決方案中可能有一些要素不適合併入主線。在編寫代碼之前，最好先了解
-   這樣的問題。
+ - 建議的解決方案中可能有一些要素無法被接受合併到主線。在編寫程式碼之前，最好
+   先發現這類問題。
 
  - 其他開發人員完全有可能考慮過這個問題；他們可能有更好的解決方案的想法，並且
-   可能願意幫助創建這個解決方案。
+   可能願意幫助實作這個解決方案。
 
-在內核開發社區的多年經驗給了我們一個明確的教訓：閉門設計和開發的內核代碼總是
-有一些問題，這些問題只有在代碼發佈到社區中時纔會被發現。有時這些問題很嚴重，
-需要數月或數年的努力才能使代碼達到內核社區的標準。例如：
+與核心開發社群多年來的經驗給了我們一個明確的教訓：閉門設計和開發的核心程式碼
+總是有一些問題，這些問題只有在程式碼發布到社群中時才會被發現。有時這些問題很
+嚴重，需要數月或數年的努力才能使程式碼達到核心社群的標準。例如：
 
- - 設計並實現了單處理器系統的DeviceScape網絡棧。只有使其適合於多處理器系統，
-   才能將其合併到主線中。在代碼中修改鎖等等是一項困難的任務；因此，這段代碼
-   （現在稱爲mac80211）的合併被推遲了一年多。
+ - Devicescape網路堆疊是針對單處理器系統設計和實作的。在使其適用於多處理器系
+   統之前，它無法合併到主線中。事後為程式碼加上鎖等機制是一項困難的任務；因
+   此，這段程式碼（現在稱為mac80211）的合併被推遲了一年多。
 
- - Reiser4文件系統包含許多功能，核心內核開發人員認爲這些功能應該在虛擬文件
-   系統層中實現。它還包括一些特性，這些特性在不將系統暴露於用戶引起的死鎖的
-   情況下是不容易實現的。這些問題過遲發現——以及拒絕處理其中一些問題——已經
-   導致Reiser4置身主線內核之外。
+ - Reiser4檔案系統包含許多功能，而核心的主要開發人員認為這些功能應該在虛擬檔
+   案系統層中實作。它還包括一些特性，這些特性很難在不讓系統面臨使用者引起的死
+   鎖的情況下實作。這些問題過晚才被揭露——以及拒絕處理其中一些問題——導致
+   Reiser4一直被排除在主線核心之外。
 
- - Apparmor安全模塊以被認爲不安全和不可靠的方式使用內部虛擬文件系統數據結構。
-   這種擔心（包括其他）使Apparmor多年來無法進入主線。
+ - AppArmor安全模組使用內部虛擬檔案系統資料結構的方式，被認為不安全且不可靠。
+   這個顧慮（以及其他顧慮）使AppArmor多年來無法進入主線。
 
-在這些情況下，與內核開發人員的早期討論，可以避免大量的痛苦和額外的工作。
+在這些情況下，只要及早與核心開發人員討論，就可以避免大量的痛苦和額外的工作。
 
 找誰交流？
 ----------
 
-當開發人員決定公開他們的計劃時，下一個問題是：我們從哪裏開始？答案是找到正確
-的郵件列表和正確的維護者。對於郵件列表，最好的方法是在維護者(MAINTAINERS)文件
-中查找要發佈的相關位置。如果有一個合適的子系統列表，那麼其上發佈通常比在
-linux-kernel上發佈更可取；您更有可能接觸到在相關子系統中具有專業知識的開發
-人員，並且環境可能具支持性。
+當開發人員決定公開他們的計畫時，下一個問題是：我們從哪裡開始？答案是找到正確
+的郵件列表和正確的維護者。對於郵件列表，最好的方法是在MAINTAINERS檔案中尋找
+適合發表的相關位置。如果有一個合適的子系統郵件列表，那麼在那裡發表通常比在
+linux-kernel上發表更好；您更有可能接觸到在相關子系統中具有專業知識的開發人
+員，而且那裡的環境可能更友善。
 
-找到維護人員可能會有點困難。同樣，維護者文件是開始的地方。但是，該文件往往不
-是最新的，並且並非所有子系統都在那裏顯示。實際上，維護者文件中列出的人員可能
-不是當前實際擔任該角色的人員。因此，當對聯繫誰有疑問時，一個有用的技巧是使用
-git（尤其是“git-log”）查看感興趣的子系統中當前活動的用戶。看看誰在寫補丁、
-誰會在這些補丁上加上Signed-off-by行簽名（如有）。這些人將是幫助新開發項目的
-最佳人選。
+找到維護者可能會比較困難一些。同樣，MAINTAINERS檔案是開始的地方。但是，該檔
+案往往不一定是最新的，並且並非所有子系統都列在那裡。實際上，MAINTAINERS檔案
+中列出的人員可能不是目前實際擔任該角色的人員。因此，當不確定要聯繫誰時，一個
+有用的技巧是使用Git（尤其是「git log」）查看感興趣的子系統中目前有誰在活動。
+看看誰在寫修補程式，以及有誰（如果有的話）在這些修補程式上加上Signed-off-by
+行。這些人將是幫助新開發專案的最佳人選。
 
-找到合適的維護者有時是非常具有挑戰性的，以至於內核開發人員添加了一個腳本來
-簡化這個過程：
+找到合適的維護者有時相當具有挑戰性，以至於核心開發人員加入了一個腳本來簡化
+這個過程：
 
 ::
 
 	.../scripts/get_maintainer.pl
 
-當給定“-f”選項時，此腳本將返回指定文件或目錄的當前維護者。如果在命令行上
-給出了一個補丁，它將列出可能接收補丁副本的維護人員。有許多選項可以調節
-get_maintainer.pl搜索維護者的嚴格程度；請小心使用更激進的選項，因爲最終結果
-可能會包括對您正在修改的代碼沒有真正興趣的開發人員。
+當給定「-f」選項時，此腳本將回傳指定檔案或目錄目前的維護者。如果在命令列上
+傳入一個修補程式，它將列出可能應該收到該修補程式副本的維護者。這是取得修補
+程式Cc名單的建議方式（而不是使用「-f」選項）。有許多選項可以調整
+get_maintainer.pl搜尋維護者的積極程度；請小心使用較激進的選項，因為最終可能
+會包括對您正在修改的程式碼沒有真正興趣的開發人員。
 
-如果所有其他方法都失敗了，那麼與Andrew Morton交流是跟蹤特定代碼段維護人員
-的一種有效方法。
+如果所有其他方法都失敗了，那麼與Andrew Morton交流是找出特定程式碼維護者的一
+種有效方法。
 
-何時郵寄？
+何時發表？
 ----------
 
-如果可能的話，在早期階段發佈你的計劃只會更有幫助。描述正在解決的問題以及已經
-制定的關於如何實施的任何計劃。您可以提供的任何信息都可以幫助開發社區爲項目
-提供有用的輸入。
+如果可能的話，在早期階段發表您的計畫只會有幫助。描述正在解決的問題，以及已經
+擬定的實作計畫。您所能提供的任何資訊都可以幫助開發社群對專案提供有用的意見。
 
-在這個階段可能發生的一件令人沮喪的事情不是得到反對意見，而是很少或根本沒有
-反饋。令人傷心的事實是：（1）內核開發人員往往很忙；（2）不缺少有宏偉計劃但
-代碼（甚至代碼設想）很少的人去支持他們；（3）沒有人有義務審查或評論別人發表
-的想法。除此之外，高層級的設計常常隱藏着一些問題，這些問題只有在有人真正嘗試
-實現這些設計時纔會被發現；因此，內核開發人員寧願看到代碼。
+在這個階段可能發生的一件令人沮喪的事情不是得到敵意的反應，而是很少或根本沒有
+反應。令人傷心的事實是：（1）核心開發人員往往很忙；（2）有宏大計畫卻只有很少
+程式碼（甚至連寫出程式碼的指望都沒有）支撐的人並不少見；（3）沒有人有義務審
+查或評論別人發表的想法。除此之外，高層次的設計常常隱藏著一些問題，這些問題只
+有在有人真正嘗試實作這些設計時才會被發現；因此，核心開發人員寧願看到程式碼。
 
-如果發佈請求評論（RFC）並沒得到什麼有用的評論，不要以爲這意味着無人對此項目
-有興趣，同時你也不能假設你的想法沒有問題。在這種情況下，最好的做法是繼續進
-行，把你的進展隨時通知社區。
+如果發表徵求意見（RFC）並沒得到什麼回應，不要以為這意味著無人對此專案有興
+趣。不幸的是，您也不能假設您的想法沒有問題。在這種情況下，最好的做法是繼續
+進行，並隨時讓社群知道您的進展。
 
 獲得官方認可
 -----------------------
 
-如果您的工作是在公司環境中完成的，就像大多數Linux內核工作一樣；顯然，在您將
-公司的計劃或代碼發佈到公共郵件列表之前，必須獲得有適當權利經理的許可。發佈
-不確定是否兼容GPL的代碼尤其會帶來問題；公司的管理層和法律人員越早能夠就發佈
-內核開發項目達成一致，對參與的每個人都越好。
+如果您的工作是在公司環境中完成的——就像大多數Linux核心工作一樣——那麼顯然，
+在您將公司的計畫或程式碼發表到公開郵件列表之前，必須獲得有適當權限的主管許
+可。發表尚未獲准以GPL相容授權發布的程式碼尤其會帶來問題；公司的管理層和法務
+人員越早能夠就發表核心開發專案達成一致，對參與的每個人都越好。
 
-一些讀者可能會認爲他們的核心工作是爲了支持還沒有正式承認存在的產品。將僱主
-的計劃公佈在公共郵件列表上可能不是一個可行的選擇。在這種情況下，有必要考慮
-保密是否真的是必要的；通常不需要把開發計劃關在門內。
+一些讀者此時可能會認為，他們的核心工作是為了支援一個尚未正式公開的產品。將
+雇主的計畫公開在公開郵件列表上可能不是一個可行的選擇。在這種情況下，值得考
+慮保密是否真的有必要；通常並沒有真正的必要把開發計畫關在門後。
 
-的確，有些情況下一家公司在開發過程的早期無法合法地披露其計劃。擁有經驗豐富
-的內核開發人員的公司可能選擇以開環的方式進行開發，前提是他們以後能夠避免
-嚴重的集成問題。對於沒有這種內部專業知識的公司，最好的選擇往往是聘請外部
-開發者根據保密協議審查計劃。Linux基金會運行了一個NDA程序，旨在幫助解決這種
-情況；更多信息參見：
+話雖如此，也確實有些情況是公司有正當理由無法在開發過程的早期公開其計畫。擁
+有經驗豐富的核心開發人員的公司，可能會選擇以開環的方式進行開發，前提是他們
+以後能夠避免嚴重的整合問題。對於沒有這種內部專業知識的公司，最好的選擇往往
+是聘請外部開發者在保密協定下審查計畫。Linux基金會運作了一個NDA計畫，旨在幫
+助處理這類情況；更多資訊參見：
 
-    http://www.linuxfoundation.org/nda/
-
-這種審查通常足以避免以後出現嚴重問題，而無需公開披露項目。
+    https://www.linuxfoundation.org/nda/
 
+這種審查通常足以避免以後出現嚴重問題，而無需公開披露專案。
-- 
2.43.0

[PATCH 19/25] docs/zh_TW: process: sync coding-style.rst with the English original

[Chen-Yu Yeh]

The translation is marked "update to
commit 323fa4b9608b ("Documentation: Fix syntax of kmalloc_objs example
in coding style doc")", but that commit only touched the memory
allocation examples.  A comparison against the current English text
shows the rest of the file never picked up a number of earlier changes:

- add the loop braces example from
  commit 1dbba2cf30c9 ("Documentation/CodingStyle: Add an example for
  braces")
- add the 80-column wording from
  commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column
  warning") and drop the old "strongly preferred" sentence
- add the boilerplate kernel-doc paragraph from
  commit e5880f95a979 ("docs: process: discourage pointless boilerplate
  kdoc") and use the doc_guide reference and tools/docs/kernel-doc as in
  the original
- drop the net/ comment style removed by commit 82b8000c28b5 ("net: drop
  special comment style")
- add the EditorConfig paragraph from commit 5a602de99797 ("Add
  .editorconfig file for basic formatting") and the clangformat
  reference from commit e3b10a02ca2f ("Docs: Move clang-format from
  process/ to dev-tools/")
- add the function-like macro guidance from
  commit 6813216bbdba ("Documentation: coding-style: ask function-like
  macros to evaluate parameters")
- use <linux/dev_printk.h> as in commit c04639a7d2fb ("coding-style.rst:
  trivial: fix location of driver model macros") and add the dev_dbg
  guidance from commit 5c7944ca7b13 ("coding-style: Add guidance to
  prefer dev_dbg")
- point to array_size.h, stddef.h and minmax.h instead of kernel.h as in
  commit 197bbebd2581 ("docs: Update documentation to avoid mentioning
  of kernel.h")
- translate section 22 "Do not crash the kernel" from
  commit 1cfd9d7e43d5 ("coding-style.rst: document BUG() and WARN()
  rules ("do not crash the kernel")")")
- use the talk title "Kernel CodingStyle" from
  commit 775a445d9a63 ("coding-style: fix title of Greg K-H's talk")
- remove a duplicated overflow sentence in section 14, link
  memory-allocation.rst through its label instead of the zh_CN path,
  and render "zeroed array" correctly
- retranslate sentences whose meaning had drifted: the "deliberately
  broken" example, the trailing whitespace and patch series note,
  accessor functions, dev_dbg()/VERBOSE_DEBUG, the inline maintenance
  trade-off and the "!!" construction for bool
- restore the English inline literals (double-indenting, help
  readability, one err bugs, classes, ...) and the English convention
  block in section 16, each followed by a Chinese rendering
- fix cntusr(), GW-BASIC and Dennis M. Ritchie
- localize terminology (屏幕→螢幕, 嵌套→巢狀, 操作符→運算子, 補丁→修補程式,
  協議→協定, 設備→裝置, 分配→配置, 優先級→優先順序, 體系結構→架構, ...)

update to commit 323fa4b9608b ("Documentation: Fix syntax of
kmalloc_objs example in coding style doc")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/coding-style.rst            | 286 +++++++++++-------
 1 file changed, 185 insertions(+), 101 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst
index 5778b707503f..c900506a17d3 100644
--- a/Documentation/translations/zh_TW/process/coding-style.rst
+++ b/Documentation/translations/zh_TW/process/coding-style.rst
@@ -27,17 +27,17 @@ Linux 核心程式碼風格
 2！) 字元深，這幾乎相當於嘗試將圓周率的值定義為 3。
 
 理由：縮排的全部意義就在於清楚的定義一個控制塊起止於何處。尤其是當你盯著你的
-屏幕連續看了 20 小時之後，你將會發現大一點的縮排會使你更容易分辨縮排。
+螢幕連續看了 20 小時之後，你將會發現大一點的縮排會使你更容易分辨縮排。
 
 現在，有些人會抱怨 8 個字元的縮排會使程式碼向右邊移動的太遠，在 80 個字元
-的終端屏幕上就很難讀這樣的程式碼。這個問題的答案是，如果你需要 3 級以上的
-縮排，不管用何種方式你的程式碼已經有問題了，應該修正你的程式。
+的終端機螢幕上就很難讀這樣的程式碼。這個問題的答案是，如果你需要 3 級以上
+的縮排，不管用何種方式你的程式碼已經有問題了，應該修正你的程式。
 
-簡而言之，8 個字元的縮排可以讓程式碼更容易閱讀，還有一個好處是當你的函式嵌套太
+簡而言之，8 個字元的縮排可以讓程式碼更容易閱讀，還有一個好處是當你的函式巢狀太
 深的時候可以給你警告。留心這個警告。
 
 在 switch 語句中消除多級縮排的首選的方式是讓 ``switch`` 和從屬於它的 ``case``
-標籤對齊於同一列，而不要 ``兩次縮排`` ``case`` 標籤。比如：
+標籤對齊於同一列，而不要把 ``case`` 標籤 ``double-indenting`` (兩次縮排)。比如：
 
 .. code-block:: c
 
@@ -84,8 +84,7 @@ Linux 核心程式碼風格
 也不要在一行裡放多個賦值語句。核心程式碼風格超級簡單。就是避免可能導致別人誤讀
 的表達式。
 
-除了註解、文件和 Kconfig 之外，不要使用空格來縮排，前面的例子是例外，是有意為
-之。
+除了註解、文件和 Kconfig 之外，絕不使用空格來縮排，前面的例子是故意寫錯的。
 
 選用一個好的編輯器，不要在行尾留空格。
 
@@ -95,7 +94,7 @@ Linux 核心程式碼風格
 
 程式碼風格的意義就在於使用平常使用的工具來維持程式碼的可讀性和可維護性。
 
-每一行的長度的限制是 80 列，我們強烈建議您遵守這個慣例。
+單行長度的首選上限是 80 列。
 
 長於 80 列的語句要打散成有意義的片段。除非超過 80 列能顯著增加可讀性，並且不
 會隱藏資訊。
@@ -148,7 +147,7 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮排大小
 
 全世界的異端可能會抱怨這個不一致性是……呃……不一致，不過所有思維健全的人
 都知道 (a) K&R 是 **正確的** 並且 (b) K&R 是正確的。此外，不管怎樣函式都是特
-殊的 (C 函式是不能嵌套的)。
+殊的 (C 函式是不能巢狀定義的)。
 
 注意結束大括號獨自佔據一行，除非它後面跟著同一個語句的剩餘部分，也就是 do 語
 句中的 ``while`` 或者 if 語句中的 ``else`` ，像這樣：
@@ -174,8 +173,8 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮排大小
 理由：K&R。
 
 也請注意這種大括號的放置方式也能使空 (或者差不多空的) 行的數量最小化，同時不
-失可讀性。因此，由於你的屏幕上的新行是不可再生資源 (想想 25 行的終端屏幕)，你
-將會有更多的空行來放置註解。
+失可讀性。因此，由於你的螢幕上的新行是不可再生資源 (想想 25 行的終端機螢幕)，
+你將會有更多的空行來放置註解。
 
 當只有一個單獨的語句的時候，不用加不必要的大括號。
 
@@ -204,6 +203,15 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮排大小
 		otherwise();
 	}
 
+此外，當迴圈內含有不只一個簡單語句時，也要使用大括號：
+
+.. code-block:: c
+
+	while (condition) {
+		if (test)
+			do_something();
+	}
+
 3.1) 空格
 *********
 
@@ -239,32 +247,32 @@ Linux 核心的空格使用方式 (主要) 取決於它是用於函式還是關
 	unsigned long long memparse(char *ptr, char **retptr);
 	char *match_strdup(substring_t *s);
 
-在大多數二元和三元操作符兩側使用一個空格，例如下面所有這些操作符::
+在大多數二元和三元運算子兩側使用一個空格，例如下面所有這些運算子::
 
 	=  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :
 
-但是一元操作符後不要加空格::
+但是一元運算子後不要加空格::
 
 	&  *  +  -  ~  !  sizeof  typeof  alignof  __attribute__  defined
 
-後綴自加和自減一元操作符前不加空格::
+後置遞增和遞減一元運算子前不加空格::
 
 	++  --
 
-前綴自加和自減一元操作符後不加空格::
+前置遞增和遞減一元運算子後不加空格::
 
 	++  --
 
-``.`` 和 ``->`` 結構體成員操作符前後不加空格。
+``.`` 和 ``->`` 結構體成員運算子前後不加空格。
 
-不要在行尾留空白。有些可以自動縮排的編輯器會在新行的行首加入適量的空白，然
-後你就可以直接在那一行輸入程式碼。不過假如你最後沒有在那一行輸入程式碼，有
-些編輯器就不會移除已經加入的空白，就像你故意留下一個只有空白的行。包含行尾
-空白的行就這樣產生了。
+不要在行尾留空白。有些具備 ``smart`` 縮排功能的編輯器會在新行的行首加入適量
+的空白，然後你就可以直接在那一行輸入程式碼。不過假如你最後沒有在那一行輸入
+程式碼，有些編輯器就不會移除已經加入的空白，就像你故意留下一個只有空白的行。
+包含行尾空白的行就這樣產生了。
 
-當 git 發現補丁包含了行尾空白的時候會警告你，並且可以應你的要求去掉行尾空白；
-不過如果你是正在打一系列補丁，這樣做會導致後面的補丁失敗，因為你改變了補丁的
-上下文。
+當 Git 發現修補程式引入了行尾空白時會警告你，並且可以應你的要求去掉行尾空白；
+不過如果你正在套用一系列修補程式，這樣做可能會改變它們的上下文行，導致該系列
+中後面的修補程式套用失敗。
 
 
 4) 命名
@@ -279,7 +287,7 @@ C 程式員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
 
 全域變數 (只有當你 **真正** 需要它們的時候再用它) 需要有一個具描述性的名字，就
 像全域函式。如果你有一個可以計算活動使用者數量的函式，你應該叫它
-``count_active_users()`` 或者類似的名字，你不應該叫它 ``cntuser()`` 。
+``count_active_users()`` 或者類似的名字，你不應該叫它 ``cntusr()`` 。
 
 在函式名中包含函式類型 (所謂的匈牙利命名法) 是腦子出了問題——編譯器知道那些類
 型而且能夠檢查那些類型，這樣做只能把程式員弄糊塗了。
@@ -306,7 +314,7 @@ C 程式員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
     'blocklist/passlist'
 
 引入新用法的例外情況是：維護使用者空間ABI/API，或更新現有（截至2020年）硬體或
-協議規範的程式碼時要求這些術語。對於新規範，儘可能將術語的規範用法轉換為核心
+協定規範的程式碼時要求這些術語。對於新規範，儘可能將術語的規範用法轉換為核心
 編碼標準。
 
 .. warning::
@@ -333,7 +341,8 @@ C 程式員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
 
 你就知道 ``a`` 是什麼了。
 
-很多人認為 typedef ``能提高可讀性`` 。實際不是這樣的。它們只在下列情況下有用：
+很多人認為 typedef ``help readability`` (能提高可讀性)。實際不是這樣的。它們只
+在下列情況下有用：
 
  (a) 完全不透明的物件 (這種情況下要主動使用 typedef 來 **隱藏** 這個物件實際上
      是什麼)。
@@ -342,8 +351,9 @@ C 程式員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
 
      .. note::
 
-       不透明性和“存取函式”本身是不好的。我們使用 pte_t 等類型的原因在於真
-       的是完全沒有任何共用的可存取資訊。
+       不透明性和 ``accessor functions`` (存取函式) 本身並不是好東西。我們對
+       pte_t 等類型使用它們的原因在於，那裡真的是完全 **沒有** 任何可移植的可存
+       取資訊。
 
  (b) 清楚的整數類型，如此，這層抽象就可以 **幫助** 消除到底是 ``int`` 還是
      ``long`` 的混淆。
@@ -370,8 +380,8 @@ C 程式員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
      因此，Linux 特有的等同於標準類型的 ``u8/u16/u32/u64`` 類型和它們的有符號
      類型是被允許的——儘管在你自己的新程式碼中，它們不是強制要求要使用的。
 
-     當編輯已經使用了某個類型集的已有程式碼時，你應該遵循那些程式碼中已經做出的選
-     擇。
+     當編輯已經使用了某個類型集的已有程式碼時，你應該遵循那些程式碼中已經做出
+     的選擇。
 
  (e) 可以在使用者空間安全使用的類型。
 
@@ -390,7 +400,7 @@ C 程式員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
 -------
 
 函式應該簡短而漂亮，並且只完成一件事情。函式應該可以一屏或者兩屏顯示完 (我們
-都知道 ISO/ANSI 屏幕大小是 80x24)，只做一件事情，而且把它做好。
+都知道 ISO/ANSI 螢幕大小是 80x24)，只做一件事情，而且把它做好。
 
 一個函式的最大長度是和該函式的複雜度和縮排級數成反比的。所以，如果你有一個理
 論上很簡單的只有一個很長 (但是簡單) 的 case 語句的函式，而且你需要在每個 case
@@ -467,13 +477,13 @@ Linux 裡這是提倡的做法，因為這樣可以很簡單的給讀者提供
 
 選擇一個能夠說明 goto 行為或它為何存在的標籤名。如果 goto 要釋放 ``buffer``,
 一個不錯的名字可以是 ``out_free_buffer:`` 。別去使用像 ``err1:`` 和 ``err2:``
-這樣的GW_BASIC 名稱，因為一旦你添加或刪除了 (函式的) 退出路徑，你就必須對它們
+這樣的 GW-BASIC 名稱，因為一旦你添加或刪除了 (函式的) 退出路徑，你就必須對它們
 重新編號，這樣會難以去檢驗正確性。
 
 使用 goto 的理由是：
 
 - 無條件語句容易理解和追蹤
-- 嵌套程度減小
+- 巢狀層數減少
 - 可以避免由於修改時忘記更新個別的退出點而導致錯誤
 - 讓編譯器省去刪除冗餘程式碼的工作 ;)
 
@@ -501,7 +511,8 @@ Linux 裡這是提倡的做法，因為這樣可以很簡單的給讀者提供
 		return result;
 	}
 
-一個需要注意的常見錯誤是 ``單 err 錯誤`` ，就像這樣：
+一個需要注意的常見錯誤是 ``one err bugs`` (只用一個 err 標籤造成的錯誤)，就像
+這樣：
 
 .. code-block:: c
 
@@ -537,8 +548,9 @@ Linux 裡這是提倡的做法，因為這樣可以很簡單的給讀者提供
 也可以加上它做這些事情的原因。
 
 當註解核心 API 函式時，請使用 kernel-doc 格式。詳見
-Documentation/translations/zh_CN/doc-guide/index.rst 和
-tools/docs/kernel-doc 。
+:ref:`Documentation/doc-guide/ <doc_guide>` 裡的檔案和
+``tools/docs/kernel-doc``。請注意，過度註解的危險同樣適用於 kernel-doc 註解。
+不要加入只是重複函式簽名中顯而易見的資訊的樣板 kernel-doc。
 
 長 (多行) 註解的首選風格是：
 
@@ -553,17 +565,6 @@ tools/docs/kernel-doc 。
 	 * with beginning and ending almost-blank lines.
 	 */
 
-對於在 net/ 和 drivers/net/ 的檔案，首選的長 (多行) 註解風格有些不同。
-
-.. code-block:: c
-
-	/* The preferred comment style for files in net/ and drivers/net
-	 * looks like this.
-	 *
-	 * It is nearly the same as the generally preferred comment style,
-	 * but there is no initial almost-blank line.
-	 */
-
 註解資料也是很重要的，不管是基本類型還是衍生類型。為了方便實作這一點，每一行
 應只宣告一個資料 (不要使用逗號來一次宣告多個資料)。這樣你就有空間來為每個資料
 寫一段小註解來解釋它們的用途了。
@@ -572,7 +573,7 @@ tools/docs/kernel-doc 。
 9) 你已經把事情弄糟了
 ---------------------
 
-這沒什麼，我們都是這樣。可能你長期使用 Unix 的朋友已經告訴你``GNU emacs``
+這沒什麼，我們都是這樣。可能你長期使用 Unix 的朋友已經告訴你 ``GNU emacs``
 能自動幫你格式化 C 原始程式碼，而且你也注意到了，確實是這樣，不過它所使用
 的預設值和我們想要的相去甚遠 (實際上，甚至比隨機打的還要差——無數個猴子在
 GNU emacs 裡打字永遠不會創造出一個好程式)
@@ -638,7 +639,8 @@ GNU emacs 裡打字永遠不會創造出一個好程式)
 不過，GNU indent 也有和 GNU emacs 一樣有問題的設定，所以你需要給它一些命令選
 項。不過，這還不算太糟糕，因為就算是 GNU indent 的作者也認同 K&R 的權威性
 (GNU 的人並不是壞人，他們只是在這個問題上被嚴重的誤導了)，所以你只要給 indent
-指定選項 ``-kr -i8`` (代表 ``K&R，8 字元縮排``)，或使用 ``scripts/Lindent``
+指定選項 ``-kr -i8`` (代表 ``K&R, 8 character indents``，即 K&R 風格、8 字元
+縮排)，或使用 ``scripts/Lindent``
 這樣就可以以最時髦的方式縮排原始程式碼。
 
 ``indent`` 有很多選項，特別是重新格式化註解的時候，你可能需要看一下它的手冊。
@@ -646,14 +648,18 @@ GNU emacs 裡打字永遠不會創造出一個好程式)
 
 請注意，您還可以使用 ``clang-format`` 工具幫助您處理這些規則，快速自動重新
 格式化部分程式碼，並審閱整個檔案以發現程式碼風格錯誤、打字錯誤和可能的改進。
-它還可以方便地排序 ``#include`` ，對齊變數/巨集，重排文字和其他類似任務。
-詳見 Documentation/dev-tools/clang-format.rst 。
+它還可以方便地排序 ``#includes``，對齊變數/巨集，重排文字和其他類似任務。
+詳見 :ref:`Documentation/dev-tools/clang-format.rst <clangformat>`。
+
+如果你使用的編輯器相容於 EditorConfig，一些基本的編輯器設定，例如縮排和行尾
+字元，會自動設定好。更多資訊請參閱 EditorConfig 官方網站：
+https://editorconfig.org/
 
 
 10) Kconfig 設定檔
 --------------------
 
-對於遍佈源碼樹的所有 Kconfig* 設定文件來說，它們縮排方式有所不同。緊挨著
+對於遍佈原始碼樹的所有 Kconfig* 設定檔來說，它們縮排方式有所不同。緊挨著
 ``config`` 定義的行，用一個製表符縮排，然而 help 資訊的縮排則額外增加 2 個空
 格。舉個例子::
 
@@ -674,7 +680,7 @@ GNU emacs 裡打字永遠不會創造出一個好程式)
 	depends on ADFS_FS
 	...
 
-要查看設定文件的完整文件，請看 Documentation/kbuild/kconfig-language.rst 。
+要查看設定檔的完整文件，請看 Documentation/kbuild/kconfig-language.rst 。
 
 
 11) 資料結構
@@ -691,12 +697,12 @@ GNU emacs 裡打字永遠不會創造出一個好程式)
 注意上鎖 **不能** 取代引用計數。上鎖是為了保持資料結構的一致性，而引用計數是一
 個記憶體管理技巧。通常二者都需要，不要把兩個搞混了。
 
-很多資料結構實際上有 2 級引用計數，它們通常有不同 ``類`` 的使用者。子類計
-數器統計子類使用者的數量，每當子類計數器減至零時，全域計數器減一。
+很多資料結構實際上有 2 級引用計數，它們通常有不同 ``classes`` (類別) 的使用者。
+子類別計數器統計子類別使用者的數量，每當子類別計數器減至零時，全域計數器減一。
 
-這種 ``多級引用計數`` 的例子可以在記憶體管理 (``struct mm_struct``:
-mm_users 和mm_count)，和檔案系統 (``struct super_block``: s_count 和
-s_active) 中找到。
+這種 ``multi-level-reference-counting`` (多級引用計數) 的例子可以在記憶體管理
+(``struct mm_struct``: mm_users 和 mm_count) 和檔案系統 (``struct super_block``:
+s_count 和 s_active) 中找到。
 
 記住：如果另一個執行線索可以找到你的資料結構，但這個資料結構沒有引用計數器，
 這裡幾乎肯定是一個 bug。
@@ -727,6 +733,27 @@ s_active) 中找到。
 				do_this(b, c);		\
 		} while (0)
 
+帶有未使用參數的類函式巨集應該改寫成 static inline 函式，以避免未使用變數的
+問題：
+
+.. code-block:: c
+
+	static inline void fun(struct foo *foo)
+	{
+	}
+
+由於歷史慣例，許多檔案仍然採用「轉型為 (void)」的方式來對參數求值，但並不建議
+這樣做。行內函式可以解決「有副作用的表達式被求值不只一次」的問題，避開未使用
+變數的問題，而且不知為何通常也比巨集有更好的文件說明。
+
+.. code-block:: c
+
+	/*
+	 * Avoid doing this whenever possible and instead opt for static
+	 * inline functions
+	 */
+	#define macrofun(foo) do { (void) (foo); } while (0)
+
 使用巨集的時候應避免的事情：
 
 1) 影響控制流程的巨集：
@@ -739,8 +766,8 @@ s_active) 中找到。
 				return -EBUGGERED;	\
 		} while (0)
 
-**非常** 不好。它看起來像一個函式，不過卻能導致 ``呼叫`` 它的函式退出；不要打
-亂讀者大腦裡的語法分析器。
+**非常** 不好。它看起來像一個函式呼叫，不過卻能導致 ``calling`` (呼叫它的) 函
+式退出；不要打亂讀者大腦裡的語法分析器。
 
 2) 依賴於一個固定名字的本地變數的巨集：
 
@@ -754,8 +781,8 @@ s_active) 中找到。
 3) 作為左值的帶參數的巨集： FOO(x) = y；如果有人把 FOO 變成一個行內函式的話，這
    種用法就會出錯了。
 
-4) 忘記了優先級：使用表達式定義常數的巨集必須將表達式置於一對小括號之內。帶參數
-   的巨集也要注意此類問題。
+4) 忘記了優先順序：使用表達式定義常數的巨集必須將表達式置於一對小括號之內。帶
+   參數的巨集也要注意此類問題。
 
 .. code-block:: c
 
@@ -790,29 +817,31 @@ cpp 手冊對巨集的講解很詳細。gcc internals 手冊也詳細講解了 R
 
 在小括號裡列印數字 (%d) 沒有任何價值，應該避免這樣做。
 
-<linux/device.h> 裡有一些驅動模型診斷巨集，你應該使用它們，以確保資訊對應
-於正確的設備和驅動，並且被標記了正確的訊息級別。這些巨集有：dev_err(),
-dev_warn(),dev_info() 等等。對於那些不和某個特定設備相關連的資訊，
+<linux/dev_printk.h> 裡有一些驅動模型診斷巨集，你應該使用它們，以確保資訊對
+應於正確的裝置和驅動，並且被標記了正確的訊息級別。這些巨集有：dev_err(),
+dev_warn(),dev_info() 等等。對於那些不和某個特定裝置相關連的資訊，
 <linux/printk.h> 定義了 pr_notice(), pr_info(), pr_warn(), pr_err() 和其他。
+驅動程式正常運作時應該保持安靜，所以除非出了問題，否則優先使用
+dev_dbg/pr_debug。
 
 寫出好的除錯資訊可以是一個很大的挑戰；一旦你寫出後，這些資訊在遠端除錯時能提
 供極大的幫助。然而列印除錯資訊的處理方式同列印非除錯資訊不同。其他 pr_XXX()
 函式能無條件地列印，pr_debug() 卻不；預設情況下它不會被編譯，除非定義了 DEBUG
-或設定了 CONFIG_DYNAMIC_DEBUG。實際這同樣是為了 dev_dbg()，一個相關約定是在一
-個已經開啟了 DEBUG 時，使用 VERBOSE_DEBUG 來添加 dev_vdbg()。
+或設定了 CONFIG_DYNAMIC_DEBUG。dev_dbg() 也是如此；另一個相關的慣例是使用
+VERBOSE_DEBUG，在 DEBUG 已開啟的訊息之外再加上 dev_vdbg() 訊息。
 
 許多子系統擁有 Kconfig 除錯選項來開啟對應 Makefile 裡面的 -DDEBUG；在其他
 情況下，特定檔案使用 #define DEBUG。當一條除錯資訊需要被無條件列印時，例如，
 如果已經包含一個除錯相關的 #ifdef 條件，printk(KERN_DEBUG ...) 就可被使用。
 
 
-14) 分配記憶體
+14) 配置記憶體
 --------------
 
-核心提供了下面的一般用途的記憶體分配函式：
+核心提供了下面的一般用途的記憶體配置函式：
 kmalloc(), kzalloc(), kmalloc_objs(), kzalloc_objs(), vmalloc() 和 vzalloc()。
 請參考 API 文件以獲取有關它們的詳細資訊：
-Documentation/translations/zh_CN/core-api/memory-allocation.rst 。
+:ref:`Documentation/core-api/memory-allocation.rst <memory_allocation>`
 
 傳遞結構體大小的首選形式是這樣的：
 
@@ -820,71 +849,72 @@ Documentation/translations/zh_CN/core-api/memory-allocation.rst 。
 
 	p = kmalloc_obj(*p, ...);
 
-另外一種傳遞方式中，sizeof 的操作數是結構體的名字，這樣會降低可讀性，並且可能
-會引入 bug。有可能指標變數類型被改變時，而對應的傳遞給記憶體分配函式的 sizeof
-的結果不變。
+另外一種寫法是直接寫出結構體的名字，這樣會降低可讀性，並且可能引入 bug：指標
+變數的類型被改變了，但傳遞給記憶體配置函式的對應 sizeof 卻沒有跟著改。
 
 強制轉換一個 void 指標回傳值是多餘的。C 語言本身保證了從 void 指標到其他任何
 指標類型的轉換是沒有問題的。
 
-分配一個陣列的首選形式是這樣的：
+配置一個陣列的首選形式是這樣的：
 
 .. code-block:: c
 
 	p = kmalloc_objs(*p, n, ...);
 
-分配一個零長陣列的首選形式是這樣的：
+配置一個清零的陣列的首選形式是這樣的：
 
 .. code-block:: c
 
 	p = kzalloc_objs(*p, n, ...);
 
-這兩種形式都會檢查分配大小 n * sizeof(...) 是否溢位，如果發生溢位則回傳
+這兩種形式都會檢查配置大小 n * sizeof(...) 是否溢位，如果發生溢位則回傳
 NULL。
 
-兩種形式都會檢查分配 n * sizeof(...) 大小時記憶體的溢出，如果溢出返回 NULL。
-
-在沒有 __GFP_NOWARN 的情況下使用時，這些通用分配函式都會在失敗時發起堆疊轉儲，
+在沒有 __GFP_NOWARN 的情況下使用時，這些通用配置函式都會在失敗時發起堆疊轉儲，
 因此當返回NULL時，沒有必要發出額外的失敗訊息。
 
 15) 行內弊病
 ------------
 
-有一個常見的誤解是 ``行內`` 是 gcc 提供的可以讓程式碼執行更快的一個選項。
+有一個常見的誤解是 ``inline`` 是 gcc 提供的可以讓程式碼執行更快的一個選項。
 雖然使用行內函式有時候是恰當的 (比如作為一種替代巨集的方式，請看第十二章)，
 不過很多情況下不是這樣。inline 的過度使用會使核心變大，從而使整個系統執行
 速度變慢。因為體積大核心會佔用更多的指令高速快取，而且會導致 pagecache 的
-可用記憶體減少。想象一下，一次 pagecache 未命中就會導致一次磁碟尋址，將耗
+可用記憶體減少。想象一下，一次 pagecache 未命中就會導致一次磁碟尋軌，將耗
 時 5 毫秒。5 毫秒的時間內 CPU 能執行很多很多指令。
 
 一個基本的原則是如果一個函式有 3 行以上，就不要把它變成行內函式。這個原則的一
-個例外是，如果你知道某個參數是一個編譯時常數，而且因為這個常數你確定編譯器在
-編譯時能最佳化掉你的函式的大部分程式碼，那仍然可以給它加上 inline 關鍵字。
+個例外是，如果你知道某個參數是一個編譯時期常數，而且因為這個常數你確定編譯器
+在編譯時期能最佳化掉你的函式的大部分程式碼，那仍然可以給它加上 inline 關鍵字。
 kmalloc() 行內函式就是一個很好的例子。
 
 人們經常主張給 static 的而且只用了一次的函式加上 inline，如此不會有任何損失，
 因為沒有什麼好權衡的。雖然從技術上說這是正確的，但是實際上這種情況下即使不加
-inline gcc 也可以自動使其行內。而且其他使用者可能會要求移除 inline，由此而來的
-爭論會抵消 inline 自身的潛在價值，得不償失。
+inline gcc 也可以自動使其行內。而且一旦出現第二個呼叫者，就得把 inline 移除，
+這項維護負擔的代價，超過了「提示 gcc 去做它本來就會做的事」可能帶來的價值。
 
 
 16) 函式回傳值及命名
 --------------------
 
 函式可以返回多種不同類型的值，最常見的一種是表明函式執行成功或者失敗的值。這樣
-的一個值可以表示為一個錯誤程式碼整數 (-Exxx＝失敗，0＝成功) 或者一個 ``成功``
-布林值 (0＝失敗，非0＝成功)。
+的一個值可以表示為一個錯誤碼整數 (-Exxx＝失敗，0＝成功) 或者一個 ``succeeded``
+(成功) 布林值 (0＝失敗，非0＝成功)。
 
 混合使用這兩種表達方式是難於發現的 bug 的來源。如果 C 語言本身嚴格區分整形和
 布林型變數，那麼編譯器就能夠幫我們發現這些錯誤... 不過 C 語言不區分。為了避免
 產生這種 bug，請遵循下面的慣例::
 
-	如果函式的名字是一個動作或者強制性的命令，那麼這個函式應該返回錯誤代
-	碼整數。如果是一個判斷，那麼函式應該返回一個“成功”布林值。
+	If the name of a function is an action or an imperative command,
+	the function should return an error-code integer.  If the name
+	is a predicate, the function should return a "succeeded" boolean.
+
+也就是說，如果函式的名字是一個動作或者強制性的命令，那麼這個函式應該返回錯誤
+碼整數。如果是一個判斷，那麼函式應該返回一個「成功」布林值。
 
 比如， ``add work`` 是一個命令，所以 add_work() 在成功時返回 0，在失敗時返回
 -EBUSY。類似的，因為 ``PCI device present`` 是一個判斷，所以 pci_dev_present()
-在成功找到一個匹配的設備時應該返回 1，如果找不到時應該返回 0。
+在成功找到一個匹配的裝置時應該返回 1，如果找不到時應該返回 0。
 
 所有 EXPORTed 函式都必須遵守這個慣例，所有的公共函式也都應該如此。私有
 (static) 函式不需要如此，但是我們也推薦這樣做。
@@ -897,8 +927,8 @@ inline gcc 也可以自動使其行內。而且其他使用者可能會要求移
 ----------------
 
 Linux核心布林（bool）類型是C99 _Bool類型的別名。布林值只能為0或1，而對布林的
-隱式或顯式轉換將自動將值轉換為true或false。在使用布林類型時 **不需要** 構造，
-它會消除一類錯誤。
+隱式或顯式轉換將自動將值轉換為true或false。使用 bool 類型時不需要 !! 這種寫
+法，這消除了一類錯誤。
 
 使用布林值時，應使用true和false定義，而不是1和0。
 
@@ -906,7 +936,7 @@ Linux核心布林（bool）類型是C99 _Bool類型的別名。布林值只能
 並且布林值在儲存時通常比“int”更好。
 
 如果快取行佈局或值的大小很重要，請不要使用布林，因為其大小和對齊方式根據編譯
-的體系結構而不同。針對對齊和大小進行最佳化的結構體不應使用布林。
+的架構而不同。針對對齊和大小進行最佳化的結構體不應使用布林。
 
 如果一個結構體有多個true/false值，請考慮將它們合併為具有1比特成員的位域，或使
 用適當的固定寬度類型，如u8。
@@ -919,22 +949,26 @@ Linux核心布林（bool）類型是C99 _Bool類型的別名。布林值只能
 18) 不要重新發明核心巨集
 ------------------------
 
-標頭檔 include/linux/kernel.h 包含了一些巨集，你應該使用它們，而不要自己寫一些
-它們的變種。比如，如果你需要計算一個陣列的長度，使用這個巨集
+include/linux/ 裡有許多標頭檔包含了一些巨集，你應該使用它們，而不要自己寫一
+些它們的變種。比如，如果你需要計算一個陣列的長度，使用這個巨集
 
 .. code-block:: c
 
 	#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
+它定義在 array_size.h 中。
+
 類似的，如果你要計算某結構體成員的大小，使用
 
 .. code-block:: c
 
 	#define sizeof_field(t, f) (sizeof(((t*)0)->f))
 
-還有可以做嚴格的類型檢查的 min() 和 max() 巨集，如果你需要可以使用它們。你可以
-自己看看那個標頭檔裡還定義了什麼你可以拿來用的東西，如果有定義的話，你就不應
-在你的程式碼裡自己重新定義。
+它定義在 stddef.h 中。
+
+minmax.h 裡還定義了可以做嚴格的類型檢查的 min() 和 max() 巨集，如果你需要可以
+使用它們。你可以自己看看這些標頭檔裡還定義了什麼你可以拿來用的東西，如果有定
+義的話，你就不應在你的程式碼裡自己重新定義。
 
 
 19) 編輯器模式行和其他需要羅嗦的事情
@@ -1036,11 +1070,62 @@ Vim 能夠解析這樣的標記：
 	#endif /* CONFIG_SOMETHING */
 
 
+22) 不要讓核心崩潰
+------------------
+
+一般來說，決定是否讓核心崩潰的權力屬於使用者，而不是核心開發者。
+
+避免 panic()
+************
+
+panic() 應該謹慎使用，原則上只在系統開機期間使用。例如，在開機期間記憶體耗盡
+而無法繼續時，使用 panic() 是可以接受的。
+
+使用 WARN() 而非 BUG()
+**********************
+
+不要加入使用任何 BUG() 變體的新程式碼，例如 BUG()、BUG_ON() 或 VM_BUG_ON()。
+請改用 WARN*() 變體，最好是 WARN_ON_ONCE()，並且盡可能加上復原程式碼。如果沒有
+合理的方式可以至少部分復原，就不需要復原程式碼。
+
+「我懶得做錯誤處理」不是使用 BUG() 的藉口。對於無法繼續執行的重大內部損毀，仍
+然可以使用 BUG()，但需要有充分的理由。
+
+使用 WARN_ON_ONCE() 而非 WARN() 或 WARN_ON()
+********************************************
+
+通常應優先使用 WARN_ON_ONCE()，而不是 WARN() 或 WARN_ON()，因為某個警告條件一
+旦發生，往往會發生很多次。這可能會塞滿核心日誌並使其循環覆寫，甚至可能讓系統
+變慢到過量的日誌本身變成另一個問題。
+
+不要輕易 WARN
+*************
+
+WARN*() 是為了意料之外、不應該發生的情況而設計的。WARN*() 巨集不可用於任何在
+正常運作期間預期會發生的事情。例如，它們不是前置條件或後置條件的斷言。再強調
+一次：WARN*() 不可用於預期很容易觸發的條件，例如由使用者空間的操作觸發的條件。
+如果你需要通知使用者某個問題，pr_warn_once() 是一個可能的替代方案。
+
+不必擔心 panic_on_warn 使用者
+*****************************
+
+關於 panic_on_warn 再多說幾句：請記住 ``panic_on_warn`` 是一個可用的核心選項，
+而且很多使用者會設定這個選項。這就是上面有「不要輕易 WARN」這一節的原因。然
+而，panic_on_warn 使用者的存在並不是避免審慎使用 WARN*() 的正當理由。因為任何
+啟用 panic_on_warn 的人都已經明確要求核心在 WARN*() 觸發時崩潰，這些使用者必
+須準備好承擔系統較容易崩潰的後果。
+
+使用 BUILD_BUG_ON() 做編譯時期斷言
+**********************************
+
+使用 BUILD_BUG_ON() 是可以接受而且受到鼓勵的，因為它是編譯時期斷言，在執行時期
+不會有任何影響。
+
 附錄 I) 參考資料
 ----------------
 
 The C Programming Language, 2nd Edition
-作者：Brian W. Kernighan 和 Denni M. Ritchie.
+作者：Brian W. Kernighan 和 Dennis M. Ritchie.
 Prentice Hall, Inc., 1988.
 ISBN 0-13-110362-8 (平裝), 0-13-110370-9 (精裝).
 
@@ -1075,7 +1160,6 @@ GNU 手冊 - 遵循 K&R 標準和此文字 - cpp, gcc, gcc internals and indent,
 
 WG14 是 C 語言的國際標準化工作組，URL: http://www.open-std.org/JTC1/SC22/WG14/
 
-核心文件 Documentation/process/coding-style.rst，
-作者 greg@kroah.com 發表於 OLS 2002：
+Kernel CodingStyle，作者 greg@kroah.com，發表於 OLS 2002：
 http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
 
-- 
2.43.0

[PATCH 20/25] docs/zh_TW: process: sync embargoed-hardware-issues.rst with the English original

[Chen-Yu Yeh]

The translation is marked "update to commit cead34ac1ce1 ("MAINTAINERS:
update ndesaulniers")", but a comparison against the current English
text shows it never picked up parts of two earlier changes:

- from commit 39fef15b5f2d ("Documentation:
  embargoed-hardware-issues.rst: Clarify prenotifaction"): the team only
  develops fixes, the security officers help coordinate a fix, and the
  incident list is used for coordination of fixes
- from commit a2e4bdca2c36 ("Documentation:
  embargoed-hardware-issues.rst: minor cleanups and fixes"): the
  coordinated release paragraph, including the "no pre-notification
  process" sentence, the "acknowledges or resolves an objection"
  wording, "potential experts" in the subscription paragraph and
  "subscription to incident-specific lists"
- capitalize Git as in commit 4a0be1a25d98 ("Documentation: process:
  Capitalize Git, Quilt, and Mercurial consistently")

Also retranslate sentences whose meaning had drifted: "listed entity"
(rendered as a publicly listed company), "involved developers"
(rendered as vendors), "well-connected" (rendered as easy to contact),
the response team validating the subscription request, and the emails
rather than the list being signed.  Fix the 證書籤名 typo and localize
a few terms (通信→通訊, 行業→產業, 連接→連線, 客戶端→用戶端, 聯繫方式→聯絡方式).

update to commit 4a0be1a25d98 ("Documentation: process: Capitalize Git,
Quilt, and Mercurial consistently")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../process/embargoed-hardware-issues.rst     | 51 ++++++++++---------
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
index f5096b9de1a8..612f32c2b72f 100644
--- a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
+++ b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
@@ -24,15 +24,15 @@
 
 Linux核心硬體安全小組獨立於普通的Linux核心安全小組。
 
-該小組只負責協調被限制的硬體安全問題。Linux核心中純軟體安全漏洞的報告不由
+該小組只負責為被限制的硬體安全問題開發修復。Linux 核心中純軟體安全漏洞的報告不由
 該小組處理，報告者將被引導至常規Linux核心安全小組(
 :ref:`Documentation/admin-guide/<securitybugs>`)聯繫。
 
 可以透過電子郵件 <hardware-security@kernel.org> 與小組聯繫。這是一份私密的安全
-官名單，他們將幫助您根據我們的文件化流程協調問題。
+官名單，他們將幫助您根據我們的文件化流程協調修復。
 
 郵件列表是加密的，發送到列表的電子郵件可以透過PGP或S/MIME加密，並且必須使
-用報告者的PGP密鑰或S/MIME證書籤名。該列表的PGP密鑰和S/MIME證書可從以下URL
+用報告者的PGP密鑰或S/MIME證書簽名。該列表的PGP密鑰和S/MIME證書可從以下URL
 獲得：
 
   - PGP: https://www.kernel.org/static/files/hardware-security.asc
@@ -80,29 +80,29 @@ Linux核心社群有一個專門的硬體安全小組負責初始聯繫，並監
 硬體安全小組確定開發人員（領域專家），他們將組成特定問題的初始響應小組。最初
 的響應小組可以引入更多的開發人員（領域專家）以最佳的技術方式解決這個問題。
 
-所有相關開發商承諾遵守限制規定，並對收到的資訊保密。違反承諾將導致立即從當前
+所有相關開發人員承諾遵守限制規定，並對收到的資訊保密。違反承諾將導致立即從當前
 問題中排除，並從所有相關郵件列表中刪除。此外，硬體安全小組還將把違反者排除在
 未來的問題之外。這一後果的影響在我們社群是一種非常有效的威懾。如果發生違規
 情況，硬體安全小組將立即通知相關方。如果您或任何人發現潛在的違規行為，請立即
-向硬體安全人員報告。
+向硬體安全官報告。
 
 流程
 ^^^^
 
 由於Linux核心開發的全球分散式特性，面對面的會議幾乎不可能解決硬體安全問題。
 由於時區和其他因素，電話會議很難協調，只能在絕對必要時使用。加密電子郵件已被
-證明是解決此類問題的最有效和最安全的通信方法。
+證明是解決此類問題的最有效和最安全的通訊方法。
 
 開始披露
 """"""""
 
-披露首先按照上述聯繫方式一節，透過電子郵件聯繫Linux核心硬體安全小組。此
+披露首先按照上述聯絡方式一節，透過電子郵件聯繫Linux核心硬體安全小組。此
 初始聯繫應包含問題的描述和任何已知受影響晶片的列表。如果您的組織製造或分發
 受影響的硬體，我們建議您也考慮哪些其他硬體可能會受到影響。披露方有責任及時
 聯繫受影響的晶片供應商。
 
 硬體安全小組將提供一個特定於事件的加密郵件列表，用於與報告者進行初步討論、
-進一步披露和協調。
+進一步披露和協調修復。
 
 硬體安全小組將向披露方提供一份開發人員（領域專家）名單，在與開發人員確認他們
 將遵守本諒解備忘錄和文件化流程後，應首先告知開發人員有關該問題的資訊。這些開發
@@ -114,12 +114,12 @@ Linux核心社群有一個專門的硬體安全小組負責初始聯繫，並監
 
 披露方應提供已經或應該被告知該問題的所有其他實體的聯繫人名單。這有幾個目的:
 
-  - 披露的實體列表允許跨行業通信，例如其他作業系統供應商、硬體供應商等。
+  - 披露的實體列表允許跨產業通訊，例如其他作業系統供應商、硬體供應商等。
 
   - 可聯繫已披露的實體，指定應參與緩解措施開發的專家。
 
-  - 如果需要處理某一問題的專家受僱於某一上市實體或某一上市實體的成員，則響應
-    小組可要求該實體披露該專家。這確保專家也是實體反應小組的一部分。
+  - 如果需要處理某一問題的專家受僱於某一列出的實體或某一列出的實體的成員，則
+    響應小組可要求該實體披露該專家。這確保專家也是該實體響應小組的一部分。
 
 披露
 """"
@@ -138,8 +138,9 @@ Linux核心社群有一個專門的硬體安全小組負責初始聯繫，並監
 問題開發緩解措施。
 
 郵件列表的操作方式與正常的Linux開發相同。發布、討論和審查修補程式，如果同意，
-則應用於非公共git儲存庫，參與開發人員只能透過安全連接存取該儲存庫。儲存庫包含
-針對主線核心的主開發分支，並根據需要為穩定的核心版本提供向後移植分支。
+則套用到非公開的 Git 儲存庫，參與開發人員只能透過安全連線存取該儲存庫。
+儲存庫包含針對主線核心的主開發分支，並根據需要為穩定的核心版本提供向後
+移植分支。
 
 最初的響應小組將根據需要從Linux核心開發人員社群中確定更多的專家。任何相關
 方都可以建議增補專家，每位專家都須符合上述相同的要求。
@@ -152,7 +153,7 @@ Linux核心社群有一個專門的硬體安全小組負責初始聯繫，並監
 如果披露方有令人信服的理由提出異議，則必須在五個工作日內提出異議，並立即與事件
 小組解決。如果披露方在五個工作日內未作出回應，則視為默許。
 
-在確認或解決異議後，專家由事件小組披露，並進入開發過程。
+在事件小組確認或解決異議後，專家即被披露，並進入開發過程。
 
 列表參與者不得在私有郵件列表之外交流該問題。列表參與者在處理補丁時不得使用
 任何共享資源（例如僱主的建置農場、CI系統等）。
@@ -182,8 +183,8 @@ Linux核心社群有一個專門的硬體安全小組負責初始聯繫，並監
 協調發布
 """"""""
 
-有關各方將協商限制結束的日期和時間。此時，準備好的緩解措施整合到相關的核心樹中
-併發布。
+有關各方將協商限制結束的日期和時間。屆時，準備好的緩解措施將發布到相關的
+核心樹中。沒有任何預先通知流程：緩解措施會公開發布，所有人同時取得。
 
 雖然我們理解硬體安全問題需要協調限制時間，但限制時間應限制在所有有關各方制定、
 測試和準備緩解措施所需的最短時間內。人為地延長限制時間以滿足會議討論日期或其他
@@ -229,12 +230,12 @@ CVE分配
   ============= ========================================================
 
 如果要將您的組織添加到專使名單中，請與硬體安全小組聯繫。被提名的專使必須完全
-理解和支援我們的過程，並且在Linux核心社群中很容易聯繫。
+理解和支援我們的過程，並且最好在 Linux 核心社群中有良好的人脈。
 
 加密郵件列表
 ------------
 
-我們使用加密郵件列表進行通信。這些列表的工作原理是，發送到列表的電子郵件使用
+我們使用加密郵件列表進行通訊。這些列表的工作原理是，發送到列表的電子郵件使用
 列表的PGP密鑰或列表的S/MIME證書進行加密。郵件列表軟體對電子郵件進行解密，並
 使用訂閱者的PGP密鑰或S/MIME證書為每個訂閱者分別對其進行重新加密。有關郵件列表
 軟體和用於確保列表安全和資料保護的設定的詳細資訊，請見：
@@ -249,16 +250,16 @@ S/MIME證書透過特定列表發送的電子郵件傳遞給訂閱者。
 訂閱事件特定列表
 ^^^^^^^^^^^^^^^^
 
-訂閱由響應小組處理。希望參與通信的披露方將潛在訂戶的列表發送給響應組，以便
-響應組可以驗證訂閱請求。
+事件特定列表的訂閱由響應小組處理。希望參與通訊的披露方將潛在專家的列表
+發送給響應小組，以便響應小組可以驗證訂閱請求。
 
 每個訂戶都需要透過電子郵件向響應小組發送訂閱請求。電子郵件必須使用訂閱者
-的PGP密鑰或S/MIME證書籤名。如果使用PGP密鑰，則必須從公鑰伺服器獲得該密鑰，
+的PGP密鑰或S/MIME證書簽名。如果使用PGP密鑰，則必須從公鑰伺服器獲得該密鑰，
 並且理想情況下該密鑰連接到Linux核心的PGP信任網。另請參見:
 https://www.kernel.org/signature.html.
 
-響應小組驗證訂閱者，並將訂閱者添加到列表中。訂閱後，訂閱者將收到來自郵件列
-表的電子郵件，該郵件列表使用列表的PGP密鑰或列表的S/MIME證書籤名。訂閱者的
-電子郵件客戶端可以從簽名中提取PGP密鑰或S/MIME證書，以便訂閱者可以向列表發
-送加密電子郵件。
+響應小組確認訂閱請求有效後，將訂閱者添加到列表中。訂閱後，訂閱者將收到
+來自郵件列表的電子郵件，這些郵件使用列表的PGP密鑰或列表的S/MIME證書簽名。
+訂閱者的電子郵件用戶端可以從簽名中提取PGP密鑰或S/MIME證書，以便訂閱者可以
+向列表發送加密電子郵件。
 
-- 
2.43.0

[PATCH 21/25] docs/zh_TW: process: sync howto.rst with the English original

[Chen-Yu Yeh]

The translation is marked "update to
commit 413e775efaec ("Documentation: fix links to mailing list
services")", but that commit only changed the mailing list links.  A
comparison against the current English text shows the rest of the file
never picked up a number of earlier changes:

- CC linux-api@vger.kernel.org on user-space interface changes
- submitting-patches.rst is now a single document, not two
- the merge window takes patches from linux-next instead of -mm, and
  after -rc1 the focus is on fixing regressions
- move the stable trees section back after the mainline tree, make the
  development process sections subsections as in the original, and add
  the version numbering and release cadence sentences
- replace the obsolete bugzilla and reporting-bugs.rst text in "Bug
  Reporting" and "Managing bug reports" with the current
  reporting-issues.rst and MAINTAINERS guidance
- add the missing "I've been working on this for 6 months..." item
- use the LWN link in the acknowledgements and drop the section title
  that the original does not have

Also retranslate sentences whose meaning had drifted: patches reviewed
"on their technical merits and those alone", the "a bit cheesy"
etiquette link, and patchwork rendered as "the tool patch".  Fix the
SPDX hyperlink, the "2)" list item and the closing quote of the Al Viro
quotation, and localize terminology (設備→裝置, 體系結構→架構,
擴展→擴充, 反饋→回饋, 源碼→原始碼, 計劃→計畫, 補丁→修補程式 in the
changed text, ...).

update to commit fdd100ee60a0 ("docs: process: use gender-neutral
pronouns")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../translations/zh_TW/process/howto.rst      | 182 +++++++++---------
 1 file changed, 95 insertions(+), 87 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
index 1ffc076ce26c..8dcf6b9231bf 100644
--- a/Documentation/translations/zh_TW/process/howto.rst
+++ b/Documentation/translations/zh_TW/process/howto.rst
@@ -19,14 +19,14 @@
 入門
 ----
 
-你想了解如何成為一名Linux核心開發者？或者老闆吩咐你「給這個設備寫個Linux
+你想了解如何成為一名Linux核心開發者？或者老闆吩咐你「給這個裝置寫個Linux
 驅動程式」？這篇文章的目的就是教會你達成這些目標的全部訣竅，它將描述你需
 要經過的流程以及給出如何同核心社群合作的一些提示。它還將試圖解釋核心社群
 為何這樣運作。
 
-Linux核心大部分是由C語言寫成的，一些體系結構相關的程式碼用到了組譯語言。要
+Linux核心大部分是由C語言寫成的，一些架構相關的程式碼用到了組譯語言。要
 參與核心開發，你必須精通C語言。除非你想為某個架構開發底層程式碼，否則你並
-不需要了解（任何體系結構的）組譯語言。下面列舉的書籍雖然不能替代紮實的C
+不需要了解（任何架構的）組譯語言。下面列舉的書籍雖然不能替代紮實的C
 語言教育和多年的開發經驗，但如果需要的話，做為參考還是不錯的：
 
  - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
@@ -37,9 +37,9 @@ Linux核心大部分是由C語言寫成的，一些體系結構相關的程式
    《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社]
 
 Linux核心使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準，但也用到了一些
-標準中沒有定義的擴展。核心是自給自足的C環境，不依賴於標準C庫的支援，所以
+標準中沒有定義的擴充。核心是自給自足的C環境，不依賴於標準C庫的支援，所以
 並不支援C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許
-使用。有時候確實很難弄清楚核心對工具鏈的要求和它所使用的擴展，不幸的是目
+使用。有時候確實很難弄清楚核心對工具鏈的要求和它所使用的擴充，不幸的是目
 前還沒有明確的參考資料可以解釋它們。請查閱gcc資訊頁（使用「info gcc」命令
 顯示）獲得一些這方面資訊。
 
@@ -52,14 +52,15 @@ Linux核心使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準，但
 法律問題
 --------
 
-Linux核心原始碼都是在GPL（通用公共許可證）的保護下發布的。要了解這種許可
+Linux核心原始碼都是在GPL（通用公共授權條款）的保護下發布的。要了解這種許可
 的細節請查看原始碼主目錄下的COPYING檔案。Linux核心許可準則和如何使用
-`SPDX <https://spdx.org/>` 標誌符說明在這個文件中
+`SPDX <https://spdx.org/>`_ 標誌符說明在這個文件中
 :ref:`Documentation/translations/zh_TW/process/license-rules.rst <tw_kernel_licensing>`
 如果你對它還有更深入問題請聯繫律師，而不要在Linux核心郵件組上提問。因為
 郵件組裡的人並不是律師，不要期望他們的話有法律效力。
 
 對於GPL的常見問題和解答，請造訪以下連結：
+
 	https://www.gnu.org/licenses/gpl-faq.html
 
 
@@ -67,12 +68,13 @@ Linux核心原始碼都是在GPL（通用公共許可證）的保護下發布的
 ----
 
 Linux核心程式碼中包含有大量的文件。這些文件對於學習如何與核心社群互動有著
-不可估量的價值。當一個新的功能被加入核心，最好把解釋如何使用這個功能的文
-檔也放進核心。當核心的改動導致面向使用者空間的介面發生變化時，最好將相關信
-息或手冊頁(manpages)的補丁發到alx@kernel.org，以向手冊頁(manpages)
-的維護者解釋這些變化。
+不可估量的價值。當一個新的功能被加入核心，最好也一併加入說明如何使用這個
+功能的文件。當核心的改動導致核心向使用者空間提供的介面發生變化時，最好將
+相關資訊或手冊頁（manpages）的修補程式發送給手冊頁維護者 alx@kernel.org
+來說明這項變化，並副本（CC）給 linux-api@vger.kernel.org 郵件列表。
 
 以下是核心程式碼中需要閱讀的文件：
+
   :ref:`Documentation/admin-guide/README.rst <readme>`
     文件簡要介紹了Linux核心的背景，並且描述了如何設定和編譯核心。核心的
     新使用者應該從這裡開始。
@@ -88,7 +90,9 @@ Linux核心程式碼中包含有大量的文件。這些文件對於學習如何
 
   :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
 
-    這兩份文件明確描述如何建立和發送補丁，其中包括（但不僅限於)：
+    這份文件明確詳細地描述如何成功建立和發送修補程式，其中包括（但不僅限
+    於）：
+
        - 郵件內容
        - 郵件格式
        - 選擇收件人
@@ -151,25 +155,25 @@ ReST格式的文件會產生在 Documentation/output. 目錄中。
 
 如何成為核心開發者
 ------------------
-如果你對Linux核心開發一無所知，你應該造訪「Linux核心新手」計劃：
+如果你對Linux核心開發一無所知，你應該造訪「Linux核心新手」計畫：
 
 	https://kernelnewbies.org
 
 它擁有一個可以問各種最基本的核心開發問題的郵件列表（在提問之前一定要記得
-查找已往的郵件，確認是否有人已經回答過相同的問題）。它還擁有一個可以獲得
-實時反饋的IRC聊天頻道，以及大量對於學習Linux核心開發相當有幫助的文件。
+搜尋以往的郵件，確認是否有人已經回答過相同的問題）。它還擁有一個可以獲得
+即時回饋的IRC聊天頻道，以及大量對於學習Linux核心開發相當有幫助的文件。
 
 網站簡要介紹了原始碼組織結構、子系統劃分以及目前正在進行的專案（包括核心
 中的和單獨維護的）。它還提供了一些基本的幫助資訊，比如如何編譯核心和打補丁
 。
 
 如果你想加入核心開發社群並協助完成一些任務，卻找不到從哪裡開始，可以造訪
-「Linux核心房管員」計劃：
+「Linux核心房管員」計畫：
 
 	https://kernelnewbies.org/KernelJanitors
 
 這是極佳的起點。它提供一個相對簡單的任務列表，列出核心程式碼中需要被重新
-整理或者改正的地方。透過和負責這個計劃的開發者們一同工作，你會學到將補丁
+整理或者改正的地方。透過和負責這個計畫的開發者們一同工作，你會學到將補丁
 整合進核心的基本原理。如果還沒有決定下一步要做什麼的話，你還可能會得到方
 向性的指點。
 
@@ -177,7 +181,7 @@ ReST格式的文件會產生在 Documentation/output. 目錄中。
 目的，沒什麼辦法比直接讀程式碼更有效了（大多數花招都會有相應的註解），而且
 一些特製的工具還可以提供幫助。例如，「Linux程式碼交叉引用」專案就是一個值得
 特別推薦的幫助工具，它將原始碼顯示在有編目和索引的網頁上。其中一個更新及
-時的核心源碼庫，可以透過以下地址造訪：
+時的核心原始碼庫，可以透過以下地址造訪：
 
         https://elixir.bootlin.com/
 
@@ -188,29 +192,30 @@ ReST格式的文件會產生在 Documentation/output. 目錄中。
 目前Linux核心開發流程包括幾個「主核心分支」和很多子系統相關的核心分支。這
 些分支包括：
 
-  - Linus 的核心源碼樹
+  - Linus 的核心原始碼樹
   - 多個主要版本的穩定版核心樹
   - 子系統相關的核心樹
   - linux-next 整合測試樹
 
 
 主線樹
-------
-主線樹是由Linus Torvalds 維護的。你可以在https://kernel.org 網站或者程式碼
-庫中下找到它。它的開發遵循以下步驟：
-
-  - 每當一個新版本的核心被發布，為期兩周的整合視窗將被開啟。在這段時間裡
-    維護者可以向Linus提交大段的修改，通常這些修改已經被放到-mm核心中幾個
-    星期了。提交大量修改的首選方式是使用git工具（核心的程式碼版本管理工具
-    ，更多的資訊可以在 https://git-scm.com/ 獲取），不過使用普通補丁也是
-    可以的。
-  - 兩個星期以後-rc1版本核心發布。之後只有不包含可能影響整個核心穩定性的
-    新功能的補丁才可能被接受。請注意一個全新的驅動程式（或者檔案系統）有
-    可能在-rc1後被接受是因為這樣的修改完全獨立，不會影響其他的程式碼，所以
-    沒有造成核心退步的風險。在-rc1以後也可以用git向Linus提交補丁，不過所
-    有的補丁需要同時被發送到相應的公衆郵件列表以徵詢意見。
-  - 當Linus認為當前的git源碼樹已經達到一個合理健全的狀態足以發布供人測試
-    時，一個新的-rc版本就會被發布。計劃是每周都發布新的-rc版本。
+~~~~~~
+
+主線樹是由 Linus Torvalds 維護的，可以在 https://kernel.org 或儲存庫中找到。
+它的開發遵循以下步驟：
+
+  - 每當一個新版本的核心發布後，就會開啟為期兩週的視窗。在這段期間，維護
+    者可以向 Linus 提交大量的修改，通常是已經在 linux-next 中放了幾個星期的
+    修補程式。提交大量修改的首選方式是使用 git（核心的原始碼管理工具，更多
+    資訊可以在 https://git-scm.com/ 找到），不過使用普通的修補程式也完全可以。
+  - 兩週後 -rc1 版核心發布，此時的重點是讓新核心盡可能穩固。這個階段的大
+    多數修補程式應該是修正迴歸（regression）。一直存在的 bug 不算迴歸，所以
+    只有在這類修正很重要時才推送。請注意，一個全新的驅動程式（或檔案系統）
+    可能在 -rc1 之後被接受，因為只要這樣的修改是獨立的、不影響新增程式碼以
+    外的區域，就沒有造成迴歸的風險。-rc1 發布後也可以用 git 向 Linus 發送
+    修補程式，不過這些修補程式也需要發送到公開的郵件列表以供審查。
+  - 當Linus認為目前的git原始碼樹已經達到一個合理健全的狀態足以發布供人測
+    試時，一個新的-rc版本就會被發布。目標是每週都發布新的-rc版本。
   - 這個過程一直持續下去直到核心被認為達到足夠穩定的狀態，持續時間大概是
     6個星期。
 
@@ -218,26 +223,44 @@ ReST格式的文件會產生在 Documentation/output. 目錄中。
 	「沒有人知道新核心何時會被發布，因為發布是根據已知bug的情況來決定
 	的，而不是根據一個事先制定好的時間表。」
 
+多個主要版本的穩定版核心樹
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+版本號由三個部分組成的核心是 -stable 核心。它們包含相對較小且至關重要的修
+正，針對在某個主線主要版本中發現的安全性問題或嚴重迴歸。同一個主要穩定版
+系列的每次發布都會遞增版本號的第三個部分，前兩個部分則保持不變。
+
+這種版本的核心適用於那些期望獲得最新的穩定版核心並且不想參與測試開發版或
+者實驗版的使用者。
+
+穩定版核心樹由「穩定版」小組（<stable@vger.kernel.org>）維護，並視需要發布。
+一般的發布週期大約是兩週，但如果沒有急迫的問題，也可能更久。相反地，與安全
+相關的問題可能會讓新版本幾乎立即發布。
+
+核心原始碼中的
+:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+文件具體描述了可被穩定版核心接受的修改類型以及發布的流程。
+
 子系統特定樹
-------------
+~~~~~~~~~~~~
 
 各種核心子系統的維護者——以及許多核心子系統開發人員——在原始碼庫中公開了他們
-當前的開發狀態。這樣，其他人就可以看到核心的不同區域發生了什麼。在開發速度
+目前的開發狀態。這樣，其他人就可以看到核心的不同區域發生了什麼。在開發速度
 很快的領域，可能會要求開發人員將提交的內容建立在這樣的子系統核心樹上，這樣
 就避免了提交與其他已經進行的工作之間的衝突。
 
 這些儲存庫中的大多數都是Git樹，但是也有其他的scm在使用，或者補丁佇列被發布
 為Quilt系列。這些子系統儲存庫的地址列在MAINTAINERS檔案中。其中許多可以在
-https://git.kernel.org/上瀏覽。
+https://git.kernel.org/ 上瀏覽。
 
-在將一個建議的補丁提交到這樣的子系統樹之前，需要對它進行審查，審查主要發生
-在郵件列表上（請參見下面相應的部分）。對於幾個核心子系統，這個審查過程是通
-過工具補丁追蹤的。Patchwork提供了一個Web介面，顯示補丁發布、對補丁的任何評
-論或修訂，維護人員可以將補丁標記為正在審查、接受或拒絕。大多數補丁網站都列
-在 https://patchwork.kernel.org/
+在一個提議的修補程式被提交到這樣的子系統樹之前，需要先經過審查，審查主要
+在郵件列表上進行（請參見下面相應的章節）。有幾個核心子系統會使用 patchwork
+工具來追蹤這個審查過程。Patchwork 提供一個網頁介面，顯示發布的修補程式、
+對修補程式的任何評論或修訂，維護者也可以將修補程式標記為正在審查、已接受
+或已拒絕。大多數 patchwork 網站都列在 https://patchwork.kernel.org/ 。
 
-Linux-next 整合測試樹
----------------------
+linux-next 整合測試樹
+~~~~~~~~~~~~~~~~~~~~~
 
 在將子系統樹的更新合併到主線樹之前，需要對它們進行整合測試。為此，存在一個
 特殊的測試儲存庫，其中幾乎每天都會提取所有子系統樹：
@@ -247,36 +270,16 @@ Linux-next 整合測試樹
 透過這種方式，Linux-next 對下一個合併階段將進入主線核心的內容給出了一個概要
 展望。非常歡迎冒險的測試者對linux-next進行執行時測試。
 
-多個主要版本的穩定版核心樹
------------------------------------
-由3個數字組成的核心版本號說明此核心是-stable版本。它們包含核心的相對較小且
-至關重要的修補，這些修補針對安全性問題或者嚴重的核心退步。
-
-這種版本的核心適用於那些期望獲得最新的穩定版核心並且不想參與測試開發版或
-者實驗版的使用者。
-
-穩定版核心樹版本由「穩定版」小組（郵件地址<stable@vger.kernel.org>）維護，一般
-隔周發布新版本。
-
-核心源碼中的
-:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
-文件具體描述了可被穩定版核心接受的修改類型以及發布的流程。
-
 
 報告bug
 -------
 
-bugzilla.kernel.org是Linux核心開發者們用來追蹤核心Bug的網站。我們鼓勵用
-戶在這個工具中報告找到的所有bug。如何使用核心bugzilla的細節請造訪：
-
-	http://test.kernel.org/bugzilla/faq.html
+核心原始碼主目錄中的 Documentation/admin-guide/reporting-issues.rst 文件
+描述了如何報告可能的核心 bug，並詳細說明核心開發者需要哪些資訊來幫助追查
+問題。
 
-核心源碼主目錄中的:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
-文件裡有一個很好的模板。它指導使用者如何報告可能的核心bug以及需要提供哪些資訊
-來幫助核心開發者們找到問題的根源。
 
-
-利用bug報告
+處理bug報告
 -----------
 
 練習核心開發技能的最好辦法就是修改其他人報告的bug。你不光可以幫助核心變
@@ -284,7 +287,11 @@ bugzilla.kernel.org是Linux核心開發者們用來追蹤核心Bug的網站。
 者感受到你的存在。修改bug是贏得其他開發者讚譽的最好辦法，因為並不是很多
 人都喜歡浪費時間去修改別人報告的bug。
 
-要嘗試修改已知的bug，請造訪 http://bugzilla.kernel.org 網址。
+要處理已經回報的 bug，請先找到一個你感興趣的子系統。查看 MAINTAINERS 檔案
+中該子系統的 bug 要回報到哪裡；通常是郵件列表，很少是 bug 追蹤系統。在該處
+的存檔中搜尋最近的報告，並在你認為合適的地方提供幫助。你也可以到
+https://bugzilla.kernel.org 查看 bug 報告；只有少數核心子系統會積極使用它來
+回報或追蹤問題，不過整個核心的 bug 都會被提交到那裡。
 
 
 郵件列表
@@ -310,8 +317,8 @@ MAINTAINERS檔案中可以找到不同話題對應的郵件列表。
 
 	https://subspace.kernel.org
 
-在使用這些郵件列表時，請記住保持良好的行為習慣。下面的連結提供了與這些列
-表（或任何其它郵件列表）交流的一些簡單規則，雖然內容有點濫竽充數。
+在使用這些郵件列表時，請記住保持良好的行為習慣。下面的連結雖然有點老套，
+但提供了與這些列表（或任何其他郵件列表）交流的一些簡單規則：
 
 	https://subspace.kernel.org/etiquette.html
 
@@ -337,8 +344,8 @@ MAINTAINERS檔案中可以找到不同話題對應的郵件列表。
 同核心社群合作
 ----------------
 
-核心社群的目標就是提供盡善盡美的核心。所以當你提交補丁期望被接受進核心的
-時候，它的技術價值以及其他方面都將被評審。那麼你可能會得到什麼呢？
+核心社群的目標就是提供盡善盡美的核心。所以當你提交修補程式期望被接受進核
+心的時候，它只會依據技術價值接受評審。那麼你可能會得到什麼呢？
 
   - 批評
   - 評論
@@ -377,7 +384,7 @@ MAINTAINERS檔案中可以找到不同話題對應的郵件列表。
     - 它同時解決了多個問題
     - 它刪除了2000行程式碼
     - 這是補丁，它已經解釋了我想要說明的
-    - 我在5種不同的體系結構上測試過它……
+    - 我在5種不同的架構上測試過它……
     - 這是一系列小補丁用來……
     - 這個修改提高了普通機器的效能……
 
@@ -388,6 +395,7 @@ MAINTAINERS檔案中可以找到不同話題對應的郵件列表。
     - 為了我們公司賺錢考慮必須這麼做
     - 這是我們的企業產品線所需要的
     - 這裡是描述我觀點的1000頁設計文件
+    - 我已經在這上面花了 6 個月……
     - 這是一個5000行的補丁用來……
     - 我重寫了現在亂七八糟的程式碼，這就是……
     - 我被規定了最後期限，所以這個補丁需要立刻被接受
@@ -395,7 +403,7 @@ MAINTAINERS檔案中可以找到不同話題對應的郵件列表。
 另外一個核心社群與大部分傳統公司的軟體開發隊伍不同的地方是無法面對面地交
 流。使用電子郵件和IRC聊天工具做為主要溝通工具的一個好處是性別和種族歧視
 將會更少。Linux核心的工作環境更能接受婦女和少數族羣，因為每個人在別人眼
-里只是一個郵件地址。國際化也幫助了公平的實作，因為你無法透過姓名來判斷人
+裡只是一個郵件地址。國際化也幫助了公平的實作，因為你無法透過姓名來判斷人
 的性別。男人有可能叫李麗，女人也有可能叫王剛。大多數在Linux核心上工作過
 並表達過看法的女性對在linux上工作的經歷都給出了正面的評價。
 
@@ -409,7 +417,7 @@ MAINTAINERS檔案中可以找到不同話題對應的郵件列表。
 
 Linux核心社群並不喜歡一下接收大段的程式碼。修改需要被恰當地介紹、討論並且
 拆分成獨立的小段。這幾乎完全和公司中的習慣背道而馳。你的想法應該在開發最
-開始的階段就讓大家知道，這樣你就可以及時獲得對你正在進行的開發的反饋。這
+開始的階段就讓大家知道，這樣你就可以及時獲得對你正在進行的開發的回饋。這
 樣也會讓社群覺得你是在和他們協作，而不是僅僅把他們當作傾銷新功能的物件。
 無論如何，你不要一次性地向郵件列表發送50封信，你的補丁序列應該永遠用不到
 這麼多。
@@ -423,19 +431,19 @@ Linux核心社群並不喜歡一下接收大段的程式碼。修改需要被恰
    當出了問題的時候，小的補丁也會讓除錯變得非常容易。一個一個補丁地回溯
    將會比仔細剖析一個被打上的大補丁（這個補丁破壞了其他東西）容易得多。
 
-2）不光發送小的補丁很重要，在提交之前重新編排、化簡（或者僅僅重新排列）
-   補丁也是很重要的。
+2) 不光發送小的修補程式很重要，在提交之前重新編排、化簡（或者僅僅重新排
+   列）修補程式也是很重要的。
 
 這裡有核心開發者Al Viro打的一個比方：
 	「想像一個老師正在給學生批改數學作業。老師並不希望看到學生為了得
-	到正確解法所進行的嘗試和產生的錯誤。他希望看到的是最乾淨最優雅的
-	解答。好學生了解這點，絕不會把最終解決之前的中間方案提交上去。」
+        到正確解法所進行的嘗試和產生的錯誤。老師希望看到的是最乾淨最優雅的
+        解答。好學生了解這點，絕不會把最終解決之前的中間方案提交上去。
 
 	核心開發也是這樣。維護者和評審者不希望看到一個人在解決問題時的思
-	考過程。他們只希望看到簡單和優雅的解決方案。
+        考過程。他們只希望看到簡單和優雅的解決方案。」
 
 直接給出一流的解決方案，和社群一起協作討論尚未完成的工作，這兩者之間似乎
-很難找到一個平衡點。所以最好儘早開始收集有利於你進行改進的反饋；同時也要
+很難找到一個平衡點。所以最好儘早開始收集有利於你進行改進的回饋；同時也要
 保證修改分成很多小塊，這樣在整個專案都準備好被包含進核心之前，其中的一部
 分可能會先被接收。
 
@@ -471,10 +479,10 @@ Linux核心社群並不喜歡一下接收大段的程式碼。修改需要被恰
 很多人已經做到了，而他們都曾經和現在的你站在同樣的起點上。
 
 
-感謝
-----
-感謝Paolo Ciarrocchi允許「開發流程」部分基於他所寫的文章
-(http://www.kerneltravel.net/newbie/2.6-development_process)，感謝Randy
+----------
+
+感謝 Paolo Ciarrocchi 允許「開發流程」部分基於他所寫的文章
+（https://lwn.net/Articles/94386/ ），感謝Randy
 Dunlap和Gerrit Huizenga完善了應該說和不該說的列表。感謝Pat Mochel, Hanna
 Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer,
 Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian
-- 
2.43.0

[PATCH 22/25] docs/zh_TW: process: sync license-rules.rst with the English original

[Chen-Yu Yeh]

The previous update was marked as synced to
commit ebf1bafd0907 ("LICENSES: Explicitly allow
SPDX-FileCopyrightText"), but the content still predated several earlier
English changes.  Bring the translation in line with the current English
text:

- point the deprecated licenses at LICENSES/deprecated/ and use ISC and
  GPL-1.0 as the examples, following commit 6132c37ca543 ("docs: Don't
  reference the ZLib license in license-rules.rst") and
  commit 62be257e986d ("LICENSES: Rename other to deprecated")
- add the missing "Dual Licensing Only" section from
  commit 8ea8814fcdcb ("LICENSES: Clearly mark dual license only
  licenses") and renumber the exceptions section
- restore the Linux-syscall-note example and the "/\* \*/" literal
- fix the mistranslated purpose of the MODULE_LICENSE() tag and the
  numbered list markup of the "Placement" item

Also localize a few remaining mainland terms (表達式→表示式,
通信→通訊, 擴展→擴充, 行業→產業, 當前→目前, 導入→匯入).

update to commit ebf1bafd0907 ("LICENSES: Explicitly allow
SPDX-FileCopyrightText")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/license-rules.rst           | 86 ++++++++++++++-----
 1 file changed, 65 insertions(+), 21 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/license-rules.rst b/Documentation/translations/zh_TW/process/license-rules.rst
index 0a4558b7fc76..abc1f7e40d32 100644
--- a/Documentation/translations/zh_TW/process/license-rules.rst
+++ b/Documentation/translations/zh_TW/process/license-rules.rst
@@ -31,7 +31,7 @@ MIT等許可。
 
 使用者空間API（UAPI）標頭檔描述了使用者空間程式與核心的介面，這是一種特殊
 情況。根據核心COPYING檔案中的註解，syscall介面是一個明確的邊界，它不會將
-GPL要求擴展到任何使用它與核心通信的軟體。由於UAPI標頭檔必須包含在建立在
+GPL要求擴充到任何使用它與核心通訊的軟體。由於UAPI標頭檔必須包含在建立在
 Linux核心上執行的可執行檔案的任何原始檔中，因此此例外必須記錄在特別的許可
 證表述中。
 
@@ -41,7 +41,7 @@ Linux核心上執行的可執行檔案的任何原始檔中，因此此例外必
 
 樣板文本的替代方法是在每個原始檔中使用軟體套件資料交換（SPDX）許可證識別碼。
 SPDX許可證識別碼是機器可解析的，並且是用於提供檔案內容的許可證的精確縮寫。
-SPDX許可證識別碼由Linux 基金會的SPDX 工作組管理，並得到了整個行業，工具
+SPDX許可證識別碼由Linux 基金會的SPDX 工作組管理，並得到了整個產業，工具
 供應商和法律團隊的合作夥伴的一致同意。有關詳細資訊，請參閱
 https://spdx.org/
 
@@ -53,7 +53,7 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
 許可識別碼語法
 --------------
 
-1.安置:
+1. 安置:
 
    核心檔案中的SPDX許可證識別碼應添加到可包含註解的檔案中的第一行。對於大多
    數檔案，這是第一行，除了那些在第一行中需要'#!PATH_TO_INTERPRETER'的腳本。
@@ -76,7 +76,7 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
       .dts{i}:	// SPDX-License-Identifier: <SPDX License Expression>
 
    如果特定工具無法處理標準註解樣式，則應使用工具接受的相應註解機制。這是在
-   C 標頭檔中使用“/\*\*/”樣式註解的原因。過去在使用產生的.lds檔案中觀察到
+   C 標頭檔中使用「/\* \*/」樣式註解的原因。過去在使用產生的.lds檔案中觀察到
    建置被破壞，其中'ld'無法解析C++註解。現在已經解決了這個問題，但仍然有較
    舊的組譯器工具無法處理C++樣式的註解。
 
@@ -84,9 +84,9 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
 
 3. 句法:
 
-   <SPDX許可證表達式>是SPDX許可證列表中的SPDX短格式許可證識別碼，或者在許可
+   <SPDX許可證表示式>是SPDX許可證列表中的SPDX短格式許可證識別碼，或者在許可
    證例外適用時由“WITH”分隔的兩個SPDX短格式許可證識別碼的組合。當應用多個許
-   可證時，表達式由分隔子表達式的關鍵字“AND”，“OR”組成，並由“（”，“）”包圍。
+   可證時，表示式由分隔子表示式的關鍵字“AND”，“OR”組成，並由“（”，“）”包圍。
 
    帶有“或更高”選項的[L]GPL等許可證的許可證識別碼透過使用“+”來表示“或更高”
    選項來建置。::
@@ -94,7 +94,7 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
       // 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
@@ -112,7 +112,7 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
 
       // 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
@@ -134,7 +134,7 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
 許可識別碼
 ----------
 
-當前使用的許可證以及添加到核心的程式碼許可證可以分解為：
+目前使用的許可證以及添加到核心的程式碼許可證可以分解為：
 
 1. _`優先許可`:
 
@@ -209,24 +209,25 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
 
 |
 
-2. 不推薦的許可證:
+2. 已棄用的許可證:
 
-   這些許可證只應用於現有程式碼或從其他專案導入程式碼。這些許可證在核心目錄::
+   這些許可證只應用於現有程式碼或從其他專案匯入程式碼。這些許可證位於核心
+   原始程式碼樹的目錄::
 
-      LICENSES/other/
+      LICENSES/deprecated/
 
    此目錄中的檔案包含完整的許可證文本和 `元標記`_ 。檔名與SPDX許可證識別碼
    相同，後者應用於原始檔中的許可證。
 
    例如::
 
-      LICENSES/other/ISC
+      LICENSES/deprecated/ISC
 
-   包含國際系統聯合許可文本和所需的元標籤::
+   包含 Internet Systems Consortium 許可證文本和所需的元標籤::
 
-      LICENSES/other/ZLib
+      LICENSES/deprecated/GPL-1.0
 
-   包含ZLIB許可文本和所需的元標籤.
+   包含 GPL 版本 1 許可證文本和所需的元標籤。
 
    元標籤:
 
@@ -249,7 +250,49 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
 
 |
 
-3. _`例外`:
+3. 僅限雙重許可
+
+   這些許可證只應用於對程式碼進行雙重許可，作為優先許可之外的另一個許可證。
+   這些許可證位於核心原始程式碼樹的目錄::
+
+      LICENSES/dual/
+
+   此目錄中的檔案包含完整的許可證文本和 `元標記`_ 。檔名與 SPDX 許可證識別碼
+   相同，後者應用於原始檔中的許可證。
+
+   例如::
+
+      LICENSES/dual/MPL-1.1
+
+   包含 Mozilla Public License 版本 1.1 許可證文本和所需的元標籤::
+
+      LICENSES/dual/Apache-2.0
+
+   包含 Apache License 版本 2.0 許可證文本和所需的元標籤。
+
+   元標籤:
+
+   「其他」許可證的元標籤要求與 `優先許可`_ 的要求相同。
+
+   檔案格式範例::
+
+      Valid-License-Identifier: MPL-1.1
+      SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
+      Usage-Guide:
+        Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used for
+        dual-licensed files where the other license is GPL2 compatible.
+        If you end up using this it MUST be used together with a GPL2 compatible
+        license using "OR".
+        To use the Mozilla Public License version 1.1 put the following SPDX
+        tag/value pair into a comment according to the placement guidelines in
+        the licensing rules documentation:
+      SPDX-License-Identifier: MPL-1.1
+      License-Text:
+        Full license text
+
+|
+
+4. _`例外`:
 
    某些許可證可以修改，並允許原始許可證不具有的某些例外權利。這些例外在
    核心目錄::
@@ -262,8 +305,9 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶
 
       LICENSES/exceptions/Linux-syscall-note
 
-   包含Linux核心的COPYING檔案中記錄的Linux系統呼叫例外，該檔案用於UAPI
-   標頭檔。例如::
+   包含Linux核心的COPYING檔案中記錄的Linux系統呼叫例外，該例外用於 UAPI
+   標頭檔。例如
+   /\* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note \*/::
 
       LICENSES/exceptions/GCC-exception-2.0
 
@@ -337,8 +381,8 @@ _`模組許可`
    許可證資訊（SPDX-License-Identifier），也不以任何方式表示或確定提供模組
    原始程式碼的確切許可證。
 
-   此標記的唯一目的是提供足夠的資訊，該模組是否是自由軟體或者是核心模組加
-   載器和使用者空間工具的專有模組。
+   此標記的唯一目的是為核心模組載入器和使用者空間工具提供足夠的資訊，以判斷
+   該模組是自由軟體還是專有軟體。
 
    MODULE_LICENSE（）的有效許可證字串是:
 
-- 
2.43.0

[PATCH 23/25] docs/zh_TW: process: sync stable-api-nonsense.rst with the English original

[Chen-Yu Yeh]

The translation carries no "update to commit" marker, and a comparison
against the current English text shows it still follows the original
2016 version:

- drop the "<insert link to leech comment from Andrew and Linus here>"
  placeholder removed by commit 1d2375f048b7 ("doc:process: remove note
  from 'stable api nonsense'")
- say "drivers released under a GPL-compatible license" instead of
  "GPL released drivers", following commit 8f7e6d134bda ("doc: process:
  GPL -> GPL-compatible")
- add the subtitle, restore the note block and the emphasis of the
  introduction, and split the merged paragraphs of "Stable Kernel Source
  Interfaces" and "What to do" as in the original
- use a transition instead of the "感謝" section title that the original
  does not have

Also retranslate the whole text from the English: the old text
paraphrased several sentences loosely (the "much more volatile" topic
rendered as an endless one, structure padding, a single build multiplied
by the number of distributions and releases, Greg's "you will go insane
over time") and used mainland terminology throughout (內核→核心,
代碼→程式碼, 操作系統→作業系統, 內存→記憶體, 數據→資料, 體系結構→架構,
二進制→二進位, 分配→配置, 死鎖→死結, ...).

update to commit 8f7e6d134bda ("doc: process: GPL -> GPL-compatible")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/stable-api-nonsense.rst     | 243 +++++++++---------
 1 file changed, 127 insertions(+), 116 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/stable-api-nonsense.rst b/Documentation/translations/zh_TW/process/stable-api-nonsense.rst
index 94748429c182..25adea1146c2 100644
--- a/Documentation/translations/zh_TW/process/stable-api-nonsense.rst
+++ b/Documentation/translations/zh_TW/process/stable-api-nonsense.rst
@@ -7,143 +7,154 @@
 :Original: :ref:`Documentation/process/stable-api-nonsense.rst
            <stable_api_nonsense>`
 
-Linux 內核驅動介面
-==================
+Linux 核心驅動程式介面
+========================
 
-寫作本文檔的目的，是爲了解釋爲什麼Linux既沒有二進制內核介面，也沒有穩定
-的內核介面。這裏所說的內核介面，是指內核裏的介面，而不是內核和用戶空間
-的介面。內核到用戶空間的介面，是提供給應用程序使用的系統調用，系統調用
-在歷史上幾乎沒有過變化，將來也不會有變化。我有一些老應用程序是在0.9版本
-或者更早版本的內核上編譯的，在使用2.6版本內核的Linux發佈上依然用得很好
-。用戶和應用程序作者可以將這個介面看成是穩定的。
+（你所有的問題在這裡都有解答，而且還不只這些）
 
+本文試圖解釋為什麼 Linux **既沒有二進位核心介面，也沒有穩定的核心介面**。
 
-執行綱要
---------
+.. note::
+
+  請注意，本文描述的是 **核心內部** 的介面，而不是核心與使用者空間之間
+  的介面。
+
+  核心與使用者空間之間的介面，是應用程式所使用的介面，也就是系統呼叫
+  （syscall）介面。這個介面長久以來都 **非常** 穩定，也不會被破壞。我有
+  一些在 0.9 之前某個版本的核心上建置的舊程式，到現在依然可以在最新的
+  2.6 核心版本上正常執行。使用者和應用程式開發者可以放心地把這個介面當成
+  穩定的介面。
 
-你也許以爲自己想要穩定的內核介面，但是你不清楚你要的實際上不是它。你需
-要的其實是穩定的驅動程序，而你只有將驅動程序放到公版內核的源代碼樹裏，
-纔有可能達到這個目的。而且這樣做還有很多其它好處，正是因爲這些好處使得
-Linux能成爲強壯，穩定，成熟的操作系統，這也是你最開始選擇Linux的原因。
+
+摘要
+----
+你以為自己想要穩定的核心介面，但其實你並不想要，只是你自己還不知道而已。
+你真正想要的是一個能穩定執行的驅動程式，而只有當你的驅動程式在核心主線
+樹裡，你才能得到這一點。驅動程式放進核心主線樹，你還會得到很多其他好處，
+正是這些好處讓 Linux 成為如此強壯、穩定、成熟的作業系統，而這也是你當初
+選擇使用它的原因。
 
 
-入門
------
+前言
+----
 
-只有那些寫驅動程序的“怪人”纔會擔心內核介面的改變，對廣大用戶來說，既
-看不到內核介面，也不需要去關心它。
+只有少數想要撰寫核心驅動程式的人，才需要擔心核心內部介面的改變。世界上
+大多數的人既看不到這個介面，也完全不在乎它。
 
-首先，我不打算討論關於任何非GPL許可的內核驅動的法律問題，這些非GPL許可
-的驅動程序包括不公開源代碼，隱藏源代碼，二進制或者是用源代碼包裝，或者
-是其它任何形式的不能以GPL許可公開源代碼的驅動程序。如果有法律問題，請諮
-詢律師，我只是一個程序員，所以我只打算探討技術問題（不是小看法律問題，
-法律問題很實際，並且需要一直關注）。
+首先，我 **不會** 討論任何關於封閉原始碼、隱藏原始碼、二進位 blob、原始碼
+包裝器（source wrapper），或其他任何用來描述未以 GPL 釋出原始碼的核心
+驅動程式的用語所牽涉的法律問題。如果你有任何法律問題，請諮詢律師。我是
+程式設計師，所以在這裡只會描述技術問題（這並不是要輕忽法律問題，法律問題
+是真實存在的，你也必須時時留意）。
 
-既然只談技術問題，我們就有了下面兩個主題：二進制內核介面和穩定的內核源
-代碼介面。這兩個問題是互相關聯的，讓我們先解決掉二進制介面的問題。
+所以，這裡有兩個主要的主題：二進位核心介面，以及穩定的核心原始碼介面。
+這兩者互相依賴，不過我們先討論二進位的部分，把它解決掉。
 
 
-二進制內核介面
+二進位核心介面
 --------------
-假如我們有一個穩定的內核源代碼介面，那麼自然而然的，我們就擁有了穩定的
-二進制介面，是這樣的嗎？錯。讓我們看看關於Linux內核的幾點事實：
+假設核心有穩定的原始碼介面，那麼自然也會有穩定的二進位介面，對吧？錯。
+請考慮以下關於 Linux 核心的事實：
 
-    - 取決於所用的C編譯器的版本，不同的內核數據結構裏的結構體的對齊方
-      式會有差別，代碼中不同函數的表現形式也不一樣（函數是不是被inline
-      編譯取決於編譯器行爲）。不同的函數的表現形式並不重要，但是數據
-      結構內部的對齊方式很關鍵。
+  - 取決於你使用的 C 編譯器版本，不同的核心資料結構會有不同的結構對齊
+    方式，而且可能以不同的方式包含不同的函式（函式是否被 inline）。個別
+    函式的組織方式並沒有那麼重要，但資料結構填充（padding）的差異就非常
+    重要。
 
-    - 取決於內核的配置選項，不同的選項會讓內核的很多東西發生改變：
+  - 取決於你選擇的核心建置選項，核心可能會有各式各樣不同的假設：
 
-      - 同一個結構體可能包含不同的成員變量
-      - 有的函數可能根本不會被實現（比如編譯的時候沒有選擇SMP支持
-        一些鎖函數就會被定義成空函數）。
-      - 內核使用的內存會以不同的方式對齊，這取決於不同的內核配置選
-        項。
+      - 不同的結構可能包含不同的欄位
+      - 有些函式可能根本不會被實作（例如在非 SMP 的建置中，有些鎖會被
+        編譯成什麼都沒有）。
+      - 核心內的記憶體可能會以不同的方式對齊，這取決於建置選項。
 
-    - Linux可以在很多的不同體系結構的處理器上運行。在某個體系結構上編
-      譯好的二進制驅動程序，不可能在另外一個體繫結構上正確的運行。
+  - Linux 可以在許多不同的處理器架構上執行。某個架構的二進位驅動程式，
+    不可能在另一個架構上正確執行。
 
-對於一個特定的內核，滿足這些條件並不難，使用同一個C編譯器和同樣的內核配
-置選項來編譯驅動程序模塊就可以了。這對於給一個特定Linux發佈的特定版本提
-供驅動程序，是完全可以滿足需求的。但是如果你要給不同發佈的不同版本都發
-佈一個驅動程序，就需要在每個發佈上用不同的內核設置參數都編譯一次內核，
-這簡直跟噩夢一樣。而且還要注意到，每個Linux發佈還提供不同的Linux內核，
-這些內核都針對不同的硬件類型進行了優化（有很多種不同的處理器，還有不同
-的內核設置選項）。所以每發佈一次驅動程序，都需要提供很多不同版本的內核
-模塊。
+其中有許多問題，只要針對確切的核心設定，使用與建置核心時完全相同的 C
+編譯器來編譯你的模組，就可以解決。如果你只想為某個特定 Linux 發行版的
+某個特定版本提供模組，這樣就足夠了。但是把這一次建置，乘上不同 Linux
+發行版的數量，再乘上每個發行版所支援的不同版本數量，很快你就會陷入不同
+版本、不同建置選項的惡夢。還要注意，每個 Linux 發行版的版本都包含多個
+不同的核心，各自針對不同的硬體類型調校（不同的處理器類型和不同的選項），
+所以就算只針對單一版本，你也需要建立多個版本的模組。
 
-相信我，如果你真的要採取這種發佈方式，一定會慢慢瘋掉，我很久以前就有過
-深刻的教訓...
+相信我，如果你試圖支援這種發布方式，久了一定會發瘋，我很久以前就吃過這
+個苦頭了……
 
 
-穩定的內核源代碼介面
+穩定的核心原始碼介面
 --------------------
 
-如果有人不將他的內核驅動程序，放入公版內核的源代碼樹，而又想讓驅動程序
-一直保持在最新的內核中可用，那麼這個話題將會變得沒完沒了。
-內核開發是持續而且快節奏的，從來都不會慢下來。內核開發人員在當前介面中
-找到bug，或者找到更好的實現方式。一旦發現這些，他們就很快會去修改當前的
-介面。修改介面意味着，函數名可能會改變，結構體可能被擴充或者刪減，函數
-的參數也可能發生改變。一旦介面被修改，內核中使用這些介面的地方需要同時
-修正，這樣才能保證所有的東西繼續工作。
-
-舉一個例子，內核的USB驅動程序介面在USB子系統的整個生命週期中，至少經歷
-了三次重寫。這些重寫解決以下問題：
-
-    - 把數據流從同步模式改成非同步模式，這個改動減少了一些驅動程序的
-      複雜度，提高了所有USB驅動程序的吞吐率，這樣幾乎所有的USB設備都
-      能以最大速率工作了。
-    - 修改了USB核心代碼中爲USB驅動分配數據包內存的方式，所有的驅動都
-      需要提供更多的參數給USB核心，以修正了很多已經被記錄在案的死鎖。
-
-這和一些封閉源代碼的操作系統形成鮮明的對比，在那些操作系統上，不得不額
-外的維護舊的USB介面。這導致了一個可能性，新的開發者依然會不小心使用舊的
-介面，以不恰當的方式編寫代碼，進而影響到操作系統的穩定性。
-在上面的例子中，所有的開發者都同意這些重要的改動，在這樣的情況下修改代
-價很低。如果Linux保持一個穩定的內核源代碼介面，那麼就得創建一個新的介面
-；舊的，有問題的介面必須一直維護，給Linux USB開發者帶來額外的工作。既然
-所有的Linux USB驅動的作者都是利用自己的時間工作，那麼要求他們去做毫無意
-義的免費額外工作，是不可能的。
-安全問題對Linux來說十分重要。一個安全問題被發現，就會在短時間內得到修
-正。在很多情況下，這將導致Linux內核中的一些介面被重寫，以從根本上避免安
-全問題。一旦介面被重寫，所有使用這些介面的驅動程序，必須同時得到修正，
-以確定安全問題已經得到修復並且不可能在未來還有同樣的安全問題。如果內核
-內部介面不允許改變，那麼就不可能修復這樣的安全問題，也不可能確認這樣的
-安全問題以後不會發生。
-開發者一直在清理內核介面。如果一個介面沒有人在使用了，它就會被刪除。這
-樣可以確保內核儘可能的小，而且所有潛在的介面都會得到儘可能完整的測試
-（沒有人使用的介面是不可能得到良好的測試的）。
-
-
-要做什麼
+如果你去問那些試圖讓不在核心主線樹裡的 Linux 核心驅動程式長期保持更新
+的人，這是個「火藥味」重得多的話題。
+
+Linux 核心的開發是持續且快速的，從來不會停下來放慢腳步。因此，核心開發者
+會在現有的介面中發現 bug，或是想出更好的做法。一旦如此，他們就會修改現有
+的介面，讓它運作得更好。這時函式名稱可能會改變，結構可能會變大或縮小，
+函式的參數也可能被重新設計。一旦發生這種情況，核心中所有使用這個介面的
+地方都會同時被修正，確保一切都能繼續正常運作。
+
+舉個具體的例子，核心內部的 USB 介面在這個子系統的生命週期中，至少經歷過
+三次不同的重寫。這些重寫是為了解決許多不同的問題：
+
+  - 把資料串流從同步模型改成非同步模型。這降低了許多驅動程式的複雜度，
+    並提高了所有 USB 驅動程式的傳輸量，讓我們現在幾乎可以讓所有 USB 裝置
+    以它們可能的最高速度運作。
+  - 改變了 USB 驅動程式從 USB 核心配置資料封包的方式，所有驅動程式現在都
+    需要提供更多資訊給 USB 核心，以修正許多已記錄在案的死結。
+
+這和許多封閉原始碼的作業系統形成鮮明對比，它們必須長期維護舊的 USB 介面。
+這讓新的開發者有可能不小心使用舊介面，以不恰當的方式做事，導致作業系統的
+穩定性受損。
+
+在這兩個例子中，所有開發者都同意這些是必要的重要改動，而這些改動也都以
+相對很小的代價完成了。如果 Linux 必須確保保留穩定的原始碼介面，那就得
+建立一個新介面，而舊的、有問題的介面也必須長期維護，給 USB 開發者帶來
+額外的工作。既然所有 Linux USB 開發者都是用自己的時間在工作，要求程式設計
+師無償地做毫無收穫的額外工作，是不可能的。
+
+安全性問題對 Linux 來說也非常重要。一旦發現安全性問題，它會在很短的時間
+內被修正。有好幾次，這導致核心內部介面被重寫，以防止安全性問題發生。
+一旦發生這種情況，所有使用這些介面的驅動程式也會同時被修正，確保安全性
+問題已經被修正，而且未來不會意外地再次出現。如果核心內部介面不允許改變，
+就不可能修正這類安全性問題，也無法確保它不會再次發生。
+
+核心介面會隨著時間被清理。如果某個現有介面沒有人在使用，它就會被刪除。
+這確保了核心盡可能地小，並且所有可能的介面都盡可能地得到測試（沒有人使用
+的介面幾乎不可能測試其正確性）。
+
+
+該怎麼做
 --------
 
-如果你寫了一個Linux內核驅動，但是它還不在Linux源代碼樹裏，作爲一個開發
-者，你應該怎麼做？爲每個發佈的每個版本提供一個二進制驅動，那簡直是一個
-噩夢，要跟上永遠處於變化之中的內核介面，也是一件辛苦活。
-很簡單，讓你的驅動進入內核源代碼樹（要記得我們在談論的是以GPL許可發行
-的驅動，如果你的代碼不符合GPL，那麼祝你好運，你只能自己解決這個問題了，
-你這個吸血鬼<把Andrew和Linus對吸血鬼的定義鏈接到這裏>）。當你的代碼加入
-公版內核源代碼樹之後，如果一個內核介面改變，你的驅動會直接被修改介面的
-那個人修改。保證你的驅動永遠都可以編譯通過，並且一直工作，你幾乎不需要
-做什麼事情。
-
-把驅動放到內核源代碼樹裏會有很多的好處：
-
-    - 驅動的質量會提升，而維護成本（對原始作者來說）會下降。
-    - 其他人會給驅動添加新特性。
-    - 其他人會找到驅動中的bug並修復。
-    - 其他人會在驅動中找到性能優化的機會。
-    - 當外部的介面的改變需要修改驅動程序的時候，其他人會修改驅動程序
-    - 不需要聯繫任何發行商，這個驅動會自動的隨着所有的Linux發佈一起發
-      布。
-
-和別的操作系統相比，Linux爲更多不同的設備提供現成的驅動，而且能在更多不
-同體繫結構的處理器上支持這些設備。這個經過考驗的開發模式，必然是錯不了
-的 :)
-
-感謝
-----
-感謝 Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder,
-Robert Love, and Nishanth Aravamudan 對於本文檔早期版本的評審和建議。
+那麼，如果你有一個不在核心主線樹裡的 Linux 核心驅動程式，身為開發者的你
+該怎麼做？為每個發行版的每個不同核心版本釋出二進位驅動程式是一場惡夢，
+而要跟上不斷變動的核心介面也是件苦差事。
+
+很簡單，讓你的核心驅動程式進入核心主線樹（記住，我們這裡談的是以與 GPL
+相容的授權釋出的驅動程式；如果你的程式碼不屬於這一類，那就祝你好運，你
+只能靠自己了，你這個吸血鬼）。如果你的驅動程式在核心樹裡，當核心介面改變
+時，它會由當初做出這項核心修改的人負責修正。這確保了你的驅動程式隨時都能
+建置，並且長期正常運作，而你幾乎不需要付出什麼心力。
+
+把驅動程式放進核心主線樹裡，會帶來以下非常好的附帶效果：
+
+  - 驅動程式的品質會提升，而（原始開發者的）維護成本會下降。
+  - 其他開發者會為你的驅動程式加入新功能。
+  - 其他人會找出並修正你的驅動程式中的 bug。
+  - 其他人會在你的驅動程式中找到調校效能的機會。
+  - 當外部介面的改變需要修改驅動程式時，其他人會幫你更新驅動程式。
+  - 驅動程式會自動隨著所有 Linux 發行版一起發布，不需要去請求發行版
+    加入它。
+
+Linux「開箱即用」所支援的裝置比其他任何作業系統都多，而且能在比其他任何
+作業系統更多的處理器架構上支援這些裝置，這種經過驗證的開發模式一定有它
+做對的地方 :)
+
+
+
+------
+
+感謝 Randy Dunlap、Andrew Morton、David Brownell、Hanna Linder、
+Robert Love 和 Nishanth Aravamudan 對本文早期草稿的審閱與意見。
-- 
2.43.0

[PATCH 24/25] docs/zh_TW: process: sync submit-checklist.rst with the English original

[Chen-Yu Yeh]

The translation carries no "update to commit" marker.  It was converted
from zh_CN and, apart from a few later spot fixes (CONFIG_SLUB_DEBUG,
the abi.rst reference), still follows the flat 24-item list from before
2021.  Bring it in line with the current English text:

- regroup the items into the "Review your code", "Review Kconfig
  changes", "Provide documentation", "Check your code with tools",
  "Build your code" and "Test your code" sections, following
  commit 5969fbf30274 ("docs: submit-checklist: structure by category")
  and commit 47c67ec1e8ef ("docs: submit-checklist: use subheadings")
- fold the ppc64 item into the cross-compile item and replace it with
  the word size and endianness note from commit 2783096fb1dd ("docs:
  submit-checklist: Expand on build tests against different word sizes")
- test against the latest linux-next tag instead of the -mm patchset,
  turn the checkstack note block into a sentence, and drop the htmldocs
  sentence from the kernel-doc item, as in commit 5969fbf30274 ("docs:
  submit-checklist: structure by category")
- use KCFLAGS instead of EXTRA-CFLAGS, following
  commit 163ba35ff371 ("doc: use KCFLAGS instead of EXTRA_CFLAGS to pass
  flags from command line")
- drop the sparse.rst pointer that the original does not have

Also fix the opening paragraph, which said the checklist is provided
in submitting-patches.rst rather than going beyond it, link
submitting-patches.rst and coding-style.rst through their zh_TW labels
and kernel-doc through the label used by the original, and retranslate
the text with Taiwanese terminology (內核→核心, 補丁→修補程式,
代碼→程式碼, 內存→記憶體, 構建→建置, 接口→介面, 菜單→選單, 默認→預設,
堆棧→堆疊, 字節→位元組, 體系結構→架構, ...).

update to commit 5a63f0369bda ("docs/.../submit-checklist: Use
Documentation/admin-guide/abi.rst for cross-ref of README")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/submit-checklist.rst        | 159 ++++++++++--------
 1 file changed, 91 insertions(+), 68 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst
index 452fecc7c425..7c25b99288f2 100644
--- a/Documentation/translations/zh_TW/process/submit-checklist.rst
+++ b/Documentation/translations/zh_TW/process/submit-checklist.rst
@@ -6,105 +6,128 @@
 
 .. _tw_submitchecklist:
 
-Linux內核補丁提交檢查單
-~~~~~~~~~~~~~~~~~~~~~~~
+================================
+Linux 核心修補程式提交檢查清單
+================================
 
-如果開發人員希望看到他們的內核補丁提交更快地被接受，那麼他們應該做一些基本
-的事情。
+以下是開發者若希望自己提交的核心修補程式能更快被接受，應該做到的一些基本
+事項。
 
-這些都是在 Documentation/translations/zh_CN/process/submitting-patches.rst
-和其他有關提交Linux內核補丁的文檔中提供的。
+這些事項是在
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst
+<tw_submittingpatches>`
+及其他關於提交 Linux 核心修補程式的文件所提供的內容之外，還要額外做到的。
 
-1) 如果使用工具，則包括定義/聲明該工具的文件。不要依賴其他頭文件來引入您使用
-   的頭文件。
+審查你的程式碼
+==============
 
-2) 乾淨的編譯：
+1) 如果你使用了某項功能，就 #include 定義／宣告該功能的檔案。不要依賴其他
+   標頭檔幫你引入你所用到的標頭檔。
 
-   a) 使用合適的 ``CONFIG`` 選項 ``=y``、``=m`` 和 ``=n`` 。沒有 ``gcc``
-      警告/錯誤，沒有鏈接器警告/錯誤。
+2) 依照
+   :ref:`Documentation/translations/zh_TW/process/coding-style.rst
+   <tw_codingstyle>`
+   所述，檢查你的修補程式是否符合一般的程式碼風格。
 
-   b) 通過 ``allnoconfig`` 、 ``allmodconfig``
+3) 所有記憶體屏障（例如 ``barrier()``、``rmb()``、``wmb()``）都需要在原始碼
+   中加上註解，說明它們所做事情的邏輯及原因。
 
-   c) 使用 ``O=builddir`` 時可以成功編譯
+審查 Kconfig 變更
+=================
 
-   d) 任何 Documentation/ 下的變更都能成功構建且不引入新警告/錯誤。
-      用 ``make htmldocs`` 或 ``make pdfdocs`` 檢驗構建情況並修復問題。
+1) 任何新增或修改的 ``CONFIG`` 選項都不應弄亂設定選單，且預設應為關閉，
+   除非符合 ``Documentation/kbuild/kconfig-language.rst`` 中
+   Menu attributes: default value 一節所記載的例外條件。
 
-3) 通過使用本地交叉編譯工具或其他一些構建設施在多個CPU體系結構上構建。
+2) 所有新的 ``Kconfig`` 選項都有說明文字。
 
-4) PPC64是一種很好的交叉編譯檢查體系結構，因爲它傾向於對64位的數使用無符號
-   長整型。
+3) 已針對相關的 ``Kconfig`` 組合仔細審查過。這一點很難單靠測試做對，
+   在這裡多動腦是值得的。
 
-5) 按 Documentation/translations/zh_CN/process/coding-style.rst 所述檢查您的
-   補丁是否爲常規樣式。在提交之前使用補丁樣式檢查器 ``scripts/checkpatch.pl``
-   檢查是否有輕微的衝突。您應該能夠處理您的補丁中存在的所有
-   違規行爲。
+提供文件
+========
 
-6) 任何新的或修改過的 ``CONFIG`` 選項都不應搞亂配置菜單，並默認爲關閉，除非
-   它們符合 ``Documentation/kbuild/kconfig-language.rst`` 菜單屬性：默認值中
-   記錄的例外條件。
+1) 加入 :ref:`kernel-doc <kernel_doc>` 來為全域核心 API 撰寫文件。
+   （static 函式不需要，但寫了也可以。）
 
-7) 所有新的 ``kconfig`` 選項都有幫助文本。
+2) 所有新的 ``/proc`` 項目都在 ``Documentation/`` 下有文件記載。
 
-8) 已仔細審查了相關的 ``Kconfig`` 組合。這很難用測試來糾正——腦力在這裏是有
-   回報的。
+3) 所有新的核心開機參數都記載於
+   ``Documentation/admin-guide/kernel-parameters.rst``。
 
-9) 通過 sparse 清查。
-   （參見 Documentation/translations/zh_CN/dev-tools/sparse.rst ）
+4) 所有新的模組參數都用 ``MODULE_PARM_DESC()`` 記載。
 
-10) 使用 ``make checkstack`` 並修復他們發現的任何問題。
+5) 所有新的使用者空間介面都記載於 ``Documentation/ABI/``。
+   詳情請參閱 Documentation/admin-guide/abi.rst
+   （或 ``Documentation/ABI/README``）。
+   更改使用者空間介面的修補程式應該副本（CC）給
+   linux-api@vger.kernel.org\ 。
 
-    .. note::
+6) 如果修補程式新增了任何 ioctl，也要更新
+   ``Documentation/userspace-api/ioctl/ioctl-number.rst``。
 
-        ``checkstack`` 並不會明確指出問題，但是任何一個在堆棧上使用超過512
-        字節的函數都可以進行更改。
+使用工具檢查你的程式碼
+======================
 
-11) 包括 :ref:`kernel-doc <kernel_doc_zh>` 內核文檔以記錄全局內核API。（靜態
-    函數不需要，但也可以。）使用 ``make htmldocs`` 或 ``make pdfdocs`` 檢查
-    :ref:`kernel-doc <kernel_doc_zh>` 並修復任何問題。
+1) 提交前先用修補程式風格檢查器（``scripts/checkpatch.pl``）檢查有無輕微的
+   違規。對於修補程式中仍留下的每一項違規，你都應該能說明理由。
 
-12) 通過以下選項同時啓用的測試： ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
-    ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
-    ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
-    ``CONFIG_PROVE_RCU`` 和 ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` 。
+2) 用 sparse 檢查時乾淨無誤。
 
-13) 在 ``CONFIG_SMP``, ``CONFIG_PREEMPT`` 開啓和關閉的情況下都進行構建和運行
-    時測試。
+3) 使用 ``make checkstack`` 並修正它找到的任何問題。
+   請注意 ``checkstack`` 不會明確指出問題，但任何在堆疊上使用超過 512 位元組
+   的函式，都是應該修改的候選對象。
 
-14) 所有代碼路徑都已在啓用所有死鎖檢測（lockdep）功能的情況下運行。
+建置你的程式碼
+==============
 
-15) 所有新的 ``/proc`` 條目都記錄在 ``Documentation/``
+1) 乾淨地建置：
 
-16) 所有新的內核引導參數都記錄在
-    Documentation/admin-guide/kernel-parameters.rst 中。
+  a) 使用適用或修改過的 ``CONFIG`` 選項 ``=y``、``=m`` 與 ``=n``。
+     沒有 ``gcc`` 警告／錯誤，也沒有連結器警告／錯誤。
 
-17) 所有新的模塊參數都記錄在 ``MODULE_PARM_DESC()``
+  b) 通過 ``allnoconfig``、``allmodconfig``
 
-18) 所有新的用戶空間接口都記錄在 ``Documentation/ABI/`` 中。有關詳細信息，
-    請參閱 Documentation/admin-guide/abi.rst (或 ``Documentation/ABI/README``)。
-    更改用戶空間接口的補丁應該抄送 linux-api@vger.kernel.org\ 。
+  c) 使用 ``O=builddir`` 時可以成功建置
 
-19) 已通過至少注入slab和page分配失敗進行檢查。請參閱 ``Documentation/fault-injection/`` 。
-    如果新代碼是實質性的，那麼添加子系統特定的故障注入可能是合適的。
+  d) Documentation/ 下的任何變更都能成功建置，且不產生新的警告／錯誤。
+     使用 ``make htmldocs`` 或 ``make pdfdocs`` 檢查建置結果，並修正任何
+     問題。
 
-20) 新添加的代碼已經用 ``gcc -W`` 編譯（使用 ``make EXTRA-CFLAGS=-W`` ）。這
-    將產生大量噪聲，但對於查找諸如“警告：有符號和無符號之間的比較”之類的錯誤
-    很有用。
+2) 使用本機的交叉編譯工具或其他建置環境（build farm），在多種 CPU 架構上
+   建置。
+   請注意，針對不同字組大小（32 位元與 64 位元）及不同位元組順序（big-endian
+   與 little-endian）的架構進行測試，能有效找出各種可攜性問題；這些問題源自
+   對可表示的數值範圍、資料對齊或位元組順序等的錯誤假設。
 
-21) 在它被合併到-mm補丁集中之後進行測試，以確保它仍然與所有其他排隊的補丁以
-    及VM、VFS和其他子系統中的各種更改一起工作。
+3) 新加入的程式碼已用 ``gcc -W`` 編譯過（使用 ``make KCFLAGS=-W``）。這會
+   產生大量雜訊，但很適合用來找出像「warning: comparison between signed and
+   unsigned」這類的錯誤。
 
-22) 所有內存屏障（例如 ``barrier()``, ``rmb()``, ``wmb()`` ）都需要源代碼注
-    釋來解釋它們正在執行的操作及其原因的邏輯。
+4) 如果你修改的原始碼依賴或使用了與下列 ``Kconfig`` 符號相關的任何核心 API
+   或功能，就要在停用相關 ``Kconfig`` 符號及／或設為 ``=m`` （如果有此選項）
+   的情況下，測試多種建置組合〔不必同時全部停用，只要各種／隨機的組合即可〕：
 
-23) 如果補丁添加了任何ioctl，那麼也要更新
-    ``Documentation/userspace-api/ioctl/ioctl-number.rst`` 。
+   ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``,
+   ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
+   ``CONFIG_NET``, ``CONFIG_INET=n`` （但後者需搭配 ``CONFIG_NET=y``）。
 
-24) 如果修改後的源代碼依賴或使用與以下 ``Kconfig`` 符號相關的任何內核API或
-    功能，則在禁用相關 ``Kconfig`` 符號和/或 ``=m`` （如果該選項可用）的情況
-    下測試以下多個構建[並非所有這些都同時存在，只是它們的各種/隨機組合]：
+測試你的程式碼
+==============
 
-    ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``,
-    ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
-    ``CONFIG_NET``, ``CONFIG_INET=n`` （但是最後一個需要 ``CONFIG_NET=y`` ）。
+1) 已在同時啟用 ``CONFIG_PREEMPT``、``CONFIG_DEBUG_PREEMPT``、
+   ``CONFIG_SLUB_DEBUG``、``CONFIG_DEBUG_PAGEALLOC``、``CONFIG_DEBUG_MUTEXES``、
+   ``CONFIG_DEBUG_SPINLOCK``、``CONFIG_DEBUG_ATOMIC_SLEEP``、
+   ``CONFIG_PROVE_RCU`` 與 ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` 的情況下測試過。
 
+2) 已在啟用與不啟用 ``CONFIG_SMP`` 及 ``CONFIG_PREEMPT.`` 的情況下，進行過
+   建置與執行期測試。
+
+3) 所有程式碼路徑都已在啟用所有 lockdep 功能的情況下執行過。
+
+4) 已至少透過注入 slab 與分頁配置失敗進行過檢查。請參閱
+   ``Documentation/fault-injection/``。
+   如果新程式碼的份量很大，加入子系統專屬的故障注入可能也是適當的。
+
+5) 已用 linux-next 最新的標籤測試過，確保它仍能與所有其他排隊中的修補程式，
+   以及 VM、VFS 和其他子系統的各種變更一起正常運作。
-- 
2.43.0

[PATCH 25/25] docs/zh_TW: process: sync submitting-patches.rst with the English original

[Chen-Yu Yeh]

The translation is marked "update to commit 48c3876a6a6f ("docs:
submitting-patches: Clarify that "reviewer" is a person")", but several
parts of it still follow text that the English original changed well
before that commit.  Compare it again against the current English text
and bring it in line:

- add the "Closes:" tag paragraphs and drop the old sentence that used
  "Link:" for bug reports; say that "Reported-by:" should be followed by
  "Closes:", or by "Link:" for a partial fix
- copy the list(s) as well as the maintainers, pass patch paths to
  get_maintainer.pl, send to linux-kernel@vger.kernel.org by default
  rather than "pick at least one list", and note that very few patches
  go through Linus directly
- add the paragraphs on CC-ing earlier commenters on new versions and
  on email-clients.rst, and wait "a few weeks (typically 2-3)" instead
  of "about a week"
- use "a known identity" instead of "your real name" for sign-offs
- turn the Developer's Certificate of Origin and the Reviewer's
  statement of oversight into literal blocks instead of subsections,
  following commit 83f71fbc66fb ("docs: submitting-patches: Fix section
  structure around DCO"); keep the English text verbatim and give the
  Chinese translation as a separate, reference-only literal block
- use "they" for the signer, following commit fdd100ee60a0 ("docs:
  process: use gender-neutral pronouns")
- restore the ``subsystem``, ``summary phrase``, ``patch series``,
  ``patch changelogs`` and ``from`` literals and the English Subject:
  example, and say that version tags "might" be included rather than
  "must"
- add the diffstat "-p 1 -w 70" condition, the base tree reasons
  (number of maintainer trees, the T: entry, CI) and the paragraph on
  using an official base commit
- turn the "Fixes:" note back into a plain paragraph, keep the checker
  level list attached to its paragraph as in the original, and fix the
  "In-Reply_To" typo

Also fix mistranslations: "Quantify" was rendered as "quality" and
"heuristics" as "exploratory work"; "Co-developed-by:" had the order of
the "Signed-off-by:" reversed; a single change to many files was
described as one change split into many patches.  Replace mainland terms
in the file (設備→裝置, 源碼→原始程式碼, 當前→目前, 客戶端→用戶端,
交互式→互動式, 教程→教學, 後綴→字尾, 重定向→重新導向, 哈希→雜湊值, ...)
and use 修補程式 for "patch" in new and rewritten text.

update to commit fdd100ee60a0 ("docs: process: use gender-neutral
pronouns")

Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com>
---
 .../zh_TW/process/submitting-patches.rst      | 338 +++++++++++-------
 1 file changed, 208 insertions(+), 130 deletions(-)

diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst
index 514903daae25..b747cfd76c26 100644
--- a/Documentation/translations/zh_TW/process/submitting-patches.rst
+++ b/Documentation/translations/zh_TW/process/submitting-patches.rst
@@ -16,7 +16,7 @@
 本文件以較為簡潔的行文給出了大量建議。關於核心開發流程如何進行的詳細資訊，
 參見： Documentation/translations/zh_TW/process/development-process.rst 。
 Documentation/translations/zh_TW/process/submit-checklist.rst 給出了一系列
-提交補丁之前要檢查的事項。設備樹相關的補丁，請參閱
+提交補丁之前要檢查的事項。裝置樹相關的補丁，請參閱
 Documentation/devicetree/bindings/submitting-patches.rst 。
 
 本文件假設您正在使用 ``git`` 準備你的補丁。如果您不熟悉 ``git`` ，最好學習
@@ -25,26 +25,26 @@ Documentation/devicetree/bindings/submitting-patches.rst 。
 部分子系統和維護人員的樹有一些關於其工作流程和要求的額外資訊，請參閱
 Documentation/process/maintainer-handbooks.rst 。
 
-獲取當前源碼樹
---------------
+獲取目前的原始程式碼樹
+----------------------
 
-如果您手頭沒有當前核心原始程式碼的儲存庫，請使用 ``git`` 獲取一份。您需要先獲取
+如果您手頭沒有目前核心原始程式碼的儲存庫，請使用 ``git`` 獲取一份。您需要先獲取
 主線儲存庫，它可以透過以下命令拉取::
 
     git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
 但是，請注意，您可能不想直接針對主線樹進行開發。大多數子系統維護人員運
 行自己的樹，並希望看到針對這些樹準備的補丁。請參見MAINTAINERS檔案中子系
-統的 **T:** 項以查找該樹，或者直接詢問維護者該樹是否未在其中列出。
+統的 **T:** 項以尋找該樹，或者直接詢問維護者該樹是否未在其中列出。
 
 .. _tw_describe_changes:
 
 描述你的改動
 ------------
 
-描述你的問題。無論您的補丁是一行錯誤修復還是5000行新功能，都必須有一個潛在
-的問題激勵您完成這項工作。說服審閱者相信有一個問題值得解決，讓他們讀完第一段
-後就能明白這一點。
+描述你的問題。無論您的修補程式是一行錯誤修復還是 5000 行新功能，都必須有一個
+潛在的問題激勵您完成這項工作。說服審閱者相信確實有一個值得解決的問題，而且值得
+他們在讀完第一段之後繼續讀下去。
 
 描述使用者可見的影響。直接崩潰和鎖定是相當有說服力的，但並不是所有的錯誤都
 那麼明目張膽。即使在程式碼審閱期間發現了這個問題，也要描述一下您認為它可能
@@ -53,11 +53,11 @@ Documentation/process/maintainer-handbooks.rst 。
 定位到下游的內容：觸發的場景、DMESG的摘錄、崩潰描述、效能迴歸、延遲尖峯、
 鎖定等。
 
-品質最佳化和權衡。如果您聲稱在效能、記憶體消耗、堆疊佔用空間或二進位大小方
-面有所改進，請包括支援它們的資料。但也要描述不明顯的成本。最佳化通常不是零
-成本的，而是在CPU、記憶體和可讀性之間進行權衡；或者，做探索性的工作，在不
-同的工作負載之間進行權衡。請描述最佳化的預期缺點，以便審閱者可以權衡成本和
-收益。
+量化最佳化和權衡。如果您聲稱在效能、記憶體消耗、堆疊佔用空間或二進位大小方
+面有所改進，請附上支持這些說法的資料。但也要描述不明顯的成本。最佳化通常不是
+零成本的，而是在 CPU、記憶體和可讀性之間進行權衡；或者，在啟發式演算法方面，
+是在不同的工作負載之間進行權衡。請描述最佳化的預期缺點，以便審閱者可以權衡
+成本和收益。
 
 提出問題之後，就要詳細地描述一下您實際在做的技術細節。對於審閱者來說，用簡練的
 英語描述程式碼的變化是很重要的，以驗證程式碼的行為是否符合您的意圖。
@@ -90,9 +90,8 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令
 發生衝突的可能性很大。記住，即使現在不會與您的六個字元ID發生衝突，這種情況
 也可能在五年後改變。
 
-如果該變更的相關討論或背景資訊可以在網上查閱，請加上“Link:”標籤指向它。例如
-你的補丁修復了一個缺陷，需要添加一個帶有URL的標籤指向郵件列表存檔或缺陷追蹤器
-的相關報告；如果該補丁是由一些早先郵件列表討論或網路上的記錄引起的，請指向它。
+如果該變更的相關討論或其他背景資訊可以在網上查閱，請加上「Link:」標籤指向它。
+如果該修補程式源自一些早先的郵件列表討論或網路上記錄的內容，請指向它。
 
 當連結到郵件列表存檔時，請首選lore.kernel.org郵件存檔服務。用郵件中的
 ``Message-ID`` 頭（去掉尖括號）可以建立連結URL。例如::
@@ -104,13 +103,22 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令
 不過，在沒有外部資源的情況下，也要儘量讓你的解釋可理解。除了提供郵件列表存檔或
 缺陷的URL之外，還要需要總結該補丁的相關討論要點。
 
+如果你的修補程式修復了一個錯誤，請使用「Closes:」標籤，並附上指向郵件列表存檔
+或公開缺陷追蹤器中該報告的 URL。例如::
+
+	Closes: https://example.com/issues/1234
+
+有些缺陷追蹤器能夠在套用帶有此標籤的提交時自動關閉問題。有些監看郵件列表的
+機器人也可以追蹤這類標籤並採取特定動作。禁止使用私有缺陷追蹤器和無效的 URL。
+
 如果補丁修復了特定提交中的錯誤，例如使用 ``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
@@ -133,11 +141,11 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令
 者更多的補丁檔案中。如果你的改動包含對API的修改，並且增加了一個使用該新API
 的驅動，那麼把這些修改分成兩個補丁。
 
-另一方面，如果你將一個單獨的改動做成多個補丁檔案，那麼將它們合併成一個
-單獨的補丁檔案。這樣一個邏輯上單獨的改動只被包含在一個補丁檔案裡。
+另一方面，如果你對許多檔案做了同一個改動，那麼把這些改動合併成一個修補程式。
+這樣一個邏輯上單獨的改動只被包含在一個修補程式裡。
 
-需要記住的一點是，每個補丁的更改都應易於理解，以便審閱者驗證。每個補丁都應該
-對其價值進行闡述。
+需要記住的一點是，每個修補程式的更改都應易於理解，以便審閱者驗證。每個修補程式
+本身都應該有成立的理由。
 
 如果有一個補丁依賴另外一個補丁來完成它的改動，那沒問題。直接在你的補丁
 描述裡指出 **“這個補丁依賴某補丁”** 就好了。
@@ -152,7 +160,7 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令
 檢查你的更改風格
 ----------------
 
-檢查您的補丁是否違反了基本樣式規定，詳細資訊參見
+檢查您的修補程式是否違反了基本樣式規定，詳細資訊可在
 Documentation/translations/zh_TW/process/coding-style.rst
 中找到。如果不這樣做，只會浪費審閱者的時間，並且會導致你的補丁被拒絕，甚至
 可能沒有被閱讀。
@@ -167,34 +175,32 @@ Documentation/translations/zh_TW/process/coding-style.rst
 的程式碼看起來更好，但有違規行為，那麼最好別管它。
 
 檢查者報告三個級別：
-
  - ERROR：很可能出錯的事情
  - WARNING：需要仔細審閱的事項
  - CHECK：需要思考的事情
 
-您應該能夠判斷您的補丁中存在的所有違規行為。
+您應該能夠說明您的修補程式中仍然存在的所有違規行為的理由。
 
 選擇補丁收件人
 --------------
 
-您應該總是知會任何補丁相應程式碼的子系統維護人員；查看
-MAINTAINERS檔案和原始程式碼修訂歷史記錄，以瞭解這些維護人員是誰。腳本
-scripts/get_maintainer.pl在這個步驟中非常有用。如果您找不到正在工作的子系統
-的維護人員，那麼Andrew Morton（akpm@linux-foundation.org）將充當最後的維護
+對於任何修改程式碼的修補程式，您都應該抄送給維護該程式碼的子系統維護人員及
+郵件列表；查閱 MAINTAINERS 檔案和原始程式碼修訂歷史記錄，以瞭解這些維護人員
+是誰。腳本 scripts/get_maintainer.pl 在這個步驟中非常有用（把你的修補程式的
+路徑作為參數傳給 scripts/get_maintainer.pl）。如果您找不到正在工作的子系統的
+維護人員，那麼 Andrew Morton（akpm@linux-foundation.org）將充當最後的維護
 人員。
 
-您通常還應該選擇至少一個郵件列表來接收補丁集的副本。linux-kernel@
-vger.kernel.org是所有補丁的預設列表，但是這個列表的流量已經導致了許多開發
-人員不再看它。在MAINTAINERS檔案中查找子系統特定的列表；您的補丁可能會在那
-裡得到更多的關注。不過，請不要發送垃圾郵件到無關的列表。
+所有修補程式預設都應發送到 linux-kernel@vger.kernel.org，但這個列表的流量已經
+導致了許多開發人員不再看它。不過，請不要向無關的列表和無關的人發送垃圾郵件。
 
 許多與核心相關的列表託管在kernel.org上；您可以在
 https://subspace.kernel.org 上找到它們的列表。不過，也有與核心相關
 的列表託管在其他地方。
 
 Linus Torvalds是決定改動能否進入 Linux 核心的最終裁決者。他的郵件地址是
-torvalds@linux-foundation.org 。他收到的郵件很多，所以一般來說最好 **別**
-給他發郵件。
+<torvalds@linux-foundation.org>。他收到的郵件很多，而且目前很少有修補程式
+直接經由 Linus 合入，所以一般來說你應該盡量 **避免** 寄信給他。
 
 如果您有修復可利用安全漏洞的補丁，請將該補丁發送到 security@kernel.org 。
 對於嚴重的bug，可以考慮短期禁令以允許分銷商（有時間）向使用者發布補丁；在
@@ -223,13 +229,13 @@ Linus 和其他的核心開發者需要閱讀和評論你提交的改動。對
 
 因為這個原因，所有的提交的補丁都是郵件中“內嵌”的。最簡單（和推薦）的方法就
 是使用 ``git send-email`` 。https://git-send-email.io 有 ``git send-email``
-的交互式教程。
+的互動式教學。
 
 如果你選擇不用 ``git send-email`` ：
 
 .. warning::
 
-  如果你使用剪切-貼上你的補丁，小心你的編輯器的自動換行功能破壞你的補丁
+  如果你使用剪下-貼上你的補丁，小心你的編輯器的自動換行功能破壞你的補丁
 
 不要將補丁作為MIME編碼的附件，不管是否壓縮。很多流行的郵件軟體不
 是任何時候都將MIME編碼的附件當作純文字發送的，這會使得別人無法在你的
@@ -239,7 +245,7 @@ Linus 和其他的核心開發者需要閱讀和評論你提交的改動。對
 例外：如果你的郵路損壞了補丁，那麼有人可能會要求你使用MIME重新發送補丁。
 
 請參閱 Documentation/translations/zh_TW/process/email-clients.rst
-以獲取有關設定電子郵件客戶端以使其不受影響地發送補丁的提示。
+以獲取有關設定電子郵件用戶端以使其不受影響地發送補丁的提示。
 
 回覆審閱意見
 ------------
@@ -253,6 +259,11 @@ Linus 和其他的核心開發者需要閱讀和評論你提交的改動。對
 過程，審閱者有時會變得暴躁。即使在這種情況下，也要禮貌地回應並解決他們指出的
 問題。當發送下一版時，在封面郵件或獨立補丁里加上 ``patch changelog`` 說明與
 前一版本的不同之處（參見 :ref:`tw_the_canonical_patch_format` ）。
+發布新版本時，請把曾對你的修補程式提出意見的人加進修補程式的 CC 列表，讓他們
+知道有新版本。
+
+關於電子郵件用戶端的建議和郵件列表禮儀，請參閱
+Documentation/translations/zh_TW/process/email-clients.rst 。
 
 .. _tw_interleaved_replies:
 
@@ -272,7 +283,7 @@ https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
   A: Top-posting.
   Q: What is the most annoying thing in e-mail?
 
-同樣，請裁剪掉所有與你的回覆無關的引文。這使回覆更容易查找，並節省時間和
+同樣，請裁剪掉所有與你的回覆無關的引文。這使回覆更容易尋找，並節省時間和
 空間。更多細節參見： http://daringfireball.net/2007/07/on_top ::
 
   A: No.
@@ -286,9 +297,9 @@ https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
 提交更改後，請耐心等待。審閱者是大忙人，可能無法立即審閱您的補丁。
 
 曾幾何時，補丁曾在沒收到評論的情況下消失在虛空中，但現在開發過程應該更加順
-利了。您應該在一週左右的時間內收到評論；如果沒有收到評論，請確保您已將補丁
-發送到正確的位置。在重新提交或聯繫審閱者之前至少等待一週——在諸如合併視窗之
-類的繁忙時間可能更長。
+利了。您應該在幾週內（通常是 2-3 週）收到評論；如果沒有收到評論，請確保您已
+將修補程式發送到正確的位置。在重新提交或聯繫審閱者之前至少等待一週——在諸如
+合併視窗之類的繁忙時間可能更長。
 
 在等了幾個星期後，用帶RESEND的主題重發補丁也是可以的::
 
@@ -301,7 +312,7 @@ https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
 ----------------
 
 由於到Linus和linux-kernel的電子郵件流量很高，通常會在主題行前面加上[PATCH]
-前綴。這使Linus和其他核心開發人員更容易將補丁與其他電子郵件討論區分開。
+字首。這使Linus和其他核心開發人員更容易將補丁與其他電子郵件討論區分開。
 
 ``git send-email`` 會自動為你加上。
 
@@ -311,34 +322,61 @@ https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
 為了加強對誰做了何事的追蹤，尤其是對那些透過好幾層維護者才最終到達的補丁，我
 們在透過郵件發送的補丁上引入了“簽署（sign-off）”流程。
 
-“簽署”是在補丁註解最後的一行簡單文字，認證你編寫了它或者其他
-人有權力將它作為開放原始程式碼的補丁傳遞。規則很簡單：如果你能認證如下資訊:
+「簽署」是在修補程式說明最後的一行簡單文字，認證你編寫了它，或者你有權將它
+作為開放原始碼修補程式傳遞下去。規則很簡單：如果你能認證以下內容::
+
+        Developer's Certificate of Origin 1.1
+
+        By making a contribution to this project, I certify that:
+
+        (a) The contribution was created in whole or in part by me and I
+            have the right to submit it under the open source license
+            indicated in the file; or
+
+        (b) The contribution is based upon previous work that, to the best
+            of my knowledge, is covered under an appropriate open source
+            license and I have the right under that license to submit that
+            work with modifications, whether created in whole or in part
+            by me, under the same open source license (unless I am
+            permitted to submit under a different license), as indicated
+            in the file; or
+
+        (c) The contribution was provided directly to me by some other
+            person who certified (a), (b) or (c) and I have not modified
+            it.
+
+        (d) I understand and agree that this project and the contribution
+            are public and that a record of the contribution (including all
+            personal information I submit with it, including my sign-off) is
+            maintained indefinitely and may be redistributed consistent with
+            this project or the open source license(s) involved.
+
+以下中文譯文僅供參考，以上方英文原文為準::
 
-開發者來源認證 1.1
-^^^^^^^^^^^^^^^^^^
+        開發者來源認證 1.1
 
-對於本專案的貢獻，我認證如下資訊：
+        對於本專案的貢獻，我認證如下資訊：
 
-       (a) 這些貢獻是完全或者部分的由我建立，我有權利以文件中指出
-           的開放原始程式碼許可證提交它；或者
+        (a) 這些貢獻是完全或者部分的由我建立，我有權利以檔案中指出
+            的開放原始碼許可證提交它；或者
 
-       (b) 這些貢獻基於以前的工作，據我所知，這些以前的工作受恰當的開放
-           原始程式碼許可證保護，而且，根據文件中指出的許可證，我有權提交修改後的貢獻，
-           無論是完全還是部分由我創造，這些貢獻都使用同一個開放原始程式碼許可證
-           （除非我被允許用其它的許可證）；或者
+        (b) 這些貢獻基於以前的工作，據我所知，這些以前的工作受恰當的
+            開放原始碼許可證保護，而且我有權依據該許可證，以檔案中指出
+            的同一個開放原始碼許可證（除非我被允許用其他的許可證）提交
+            修改後的作品，無論修改是完全還是部分由我創造；或者
 
-       (c) 這些貢獻由認證（a），（b）或者（c）的人直接提供給我，而
-           且我沒有修改它。
+        (c) 這些貢獻由認證（a）、（b）或者（c）的人直接提供給我，而
+            且我沒有修改它。
 
-       (d) 我理解並同意這個專案和貢獻是公開的，貢獻的記錄（包括我
-           一起提交的個人記錄，包括sign-off）被永久維護並且可以和這個專案
-           或者開放原始程式碼的許可證同步地再發行。
+        (d) 我理解並同意這個專案和貢獻是公開的，貢獻的記錄（包括我
+            一起提交的所有個人資訊，包括我的 sign-off）會被無限期保存，
+            並且可以依照這個專案或相關的開放原始碼許可證再次散布。
 
 那麼加入這樣一行::
 
   Signed-off-by: Random J Developer <random@developer.example.org>
 
-使用你的真名（抱歉，不能使用假名或者匿名。）如果使用 ``git commit -s`` 的話
+使用已知的身分（抱歉，不接受匿名貢獻。）如果使用 ``git commit -s`` 的話
 將會自動完成。撤銷也應當包含“Signed-off-by”， ``git revert -s`` 會幫你搞定。
 
 有些人會在最後加上額外的標籤。現在這些東西會被忽略，但是你可以這樣做，來標記
@@ -351,17 +389,18 @@ https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
 何時使用Acked-by:，Cc:，和Co-developed-by:
 ------------------------------------------
 
-Signed-off-by: 標籤表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。
+Signed-off-by: 標籤表示簽名者參與了修補程式的開發，或者他們在修補程式的傳遞
+路徑中。
 
 如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准/
-贊成，那麼他們可以要求在補丁的變更日誌中添加一個Acked-by:。
+贊成，那麼他們可以要求在補丁的變更日誌中新增一個Acked-by:。
 
 Acked-by: 供以某種方式對受影響程式碼負責或與之相關的人使用。最常見的情況是，
-當維護者既沒有貢獻也沒有轉發補丁時，由該維護者使用。
+當維護者既沒有貢獻也沒有轉寄補丁時，由該維護者使用。
 
 Acked-by: 也可以由其他利益相關者使用，例如具有領域知識的人（例如被修改程式
 碼的原作者）、核心uAPI補丁的使用者空間側審閱者，或某項功能的關鍵使用者。在
-這些情況下，可以視需要加上一個“# 後綴”以澄清其含義::
+這些情況下，可以視需要加上一個“# 字尾”以澄清其含義::
 
 	Acked-by: The Stakeholder <stakeholder@example.org> # As primary user
 
@@ -377,7 +416,7 @@ Acked-by: 也不如 Reviewed-by: 正式。例如，維護者可以用它表示
 Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁影響多個子系統，並
 且有一個來自某個子系統維護者的Acked-By:，那麼這通常表示只確認影響維護者程
 式碼的部分。這裡應該仔細判斷。如有疑問，應參考郵件列表存檔中的原始討論。在
-這種情況下也可以使用“# 後綴”來澄清。
+這種情況下也可以使用“# 字尾”來澄清。
 
 如果某人本應有機會對補丁進行評論，但沒有提供此類評論，您可以選擇在補丁中添加
 ``Cc:`` 標籤。此標籤記錄了討論中包含的潛在利益相關方。注意，這是僅有的三個
@@ -386,7 +425,8 @@ Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁
 
 Co-developed-by: 聲明補丁是由多個開發人員共同建立的；當幾個人在一個補丁上工
 作時，它用於給出共同作者（除了From:所給出的作者之外）。因為Co-developed-by:
-表示作者身份，所以每個Co-developed-by:必須緊跟在相關合作作者的簽署之後。標準
+表示作者身份，所以每個 Co-developed-by: 後面必須緊跟著相關共同作者的
+Signed-off-by:。標準
 簽署程式要求Signed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通
 過From:還是Co-developed-by:表明。值得注意的是，最後一個Signed-off-by:必須是
 提交補丁的開發人員。
@@ -419,35 +459,60 @@ Co-developed-by: 聲明補丁是由多個開發人員共同建立的；當幾個
 使用Reported-by:、Tested-by:、Reviewed-by:、Suggested-by:和Fixes:
 -----------------------------------------------------------------
 
-Reported-by: 給那些發現錯誤並報告錯誤的人致謝，它希望激勵他們在將來再次幫助
-我們。注意，Reported-by標籤是僅有的三個可以在未經被指名者明確許可的情況下
-使用的標籤之一（詳見下面的“標記他人需要許可”）。此標籤是為Bug設計的；請不要
-將其用於感謝功能請求。
+Reported-by 標籤給那些發現錯誤並報告錯誤的人致謝，並希望激勵他們在將來再次
+幫助我們。此標籤是為錯誤設計的；請不要將其用於感謝功能請求。除非該報告無法在
+網上查閱，否則此標籤後面應接著一個指向該報告的 Closes: 標籤。如果修補程式只
+修復了所報告問題的一部分，可以用 Link: 標籤取代 Closes:。注意，Reported-by
+標籤是僅有的三個可以在未經被指名者明確許可的情況下使用的標籤之一（詳見下面的
+「標記他人需要許可」）。
 
 Tested-by: 標籤表示補丁已由指定的人（在某些環境中）成功測試。這個標籤通知
 維護人員已經執行了一些測試，為將來的補丁提供了一種定位測試人員的方法，並彰
 顯測試人員的功勞。
 
-Reviewed-by：根據審閱者的監督聲明，表明該補丁已被審閱並被認為是可接受的：
+而 Reviewed-by: 則表示，根據 Reviewer's Statement，該修補程式已被審閱並被
+認為是可接受的::
 
+	Reviewer's statement of oversight
 
-審閱者的監督聲明
-^^^^^^^^^^^^^^^^
+	By offering my Reviewed-by: tag, I state that:
 
-透過提供我的Reviewed-by:標籤，我聲明：
+	 (a) I have carried out a technical review of this patch to
+	     evaluate its appropriateness and readiness for inclusion into
+	     the mainline kernel.
 
-        (a) 我已經對這個補丁進行了一次技術審閱，以評估它是否適合被包含到
-            主線核心中。
+	 (b) Any problems, concerns, or questions relating to the patch
+	     have been communicated back to the submitter.  I am satisfied
+	     with the submitter's response to my comments.
 
-        (b) 與補丁相關的任何問題、顧慮或問題都已反饋給提交者。我對提交者對
-            我的評論的回應感到滿意。
+	 (c) While there may be things that could be improved with this
+	     submission, I believe that it is, at this time, (1) a
+	     worthwhile modification to the kernel, and (2) free of known
+	     issues which would argue against its inclusion.
 
-        (c) 雖然這一提交可能仍可被改進，但我相信，此時，（1）對核心
-            進行了有價值的修改，（2）沒有包含爭論中涉及的已知問題。
+	 (d) While I have reviewed the patch and believe it to be sound, I
+	     do not (unless explicitly stated elsewhere) make any
+	     warranties or guarantees that it will achieve its stated
+	     purpose or function properly in any given situation.
 
-        (d) 雖然我已經審閱了補丁並認為它是健全的，但我不會（除非另有明確
-            說明）作出任何保證或擔保它會在任何給定情況下實作其規定的目的
-            或正常執行。
+以下中文譯文僅供參考，以上方英文原文為準::
+
+	審閱者的監督聲明
+
+	透過提供我的 Reviewed-by: 標籤，我聲明：
+
+	 (a) 我已經對這個修補程式進行了一次技術審閱，以評估它是否適合
+	     被包含到主線核心中，以及是否已準備就緒。
+
+	 (b) 與修補程式相關的任何問題、顧慮或疑問都已回饋給提交者。我對
+	     提交者對我的評論的回應感到滿意。
+
+	 (c) 雖然這一提交可能仍有可改進之處，但我相信，此時，（1）它是
+	     對核心有價值的修改，（2）沒有會反對將其納入的已知問題。
+
+	 (d) 雖然我已經審閱了修補程式並認為它是健全的，但我不會（除非另
+	     有明確說明）作出任何保證或擔保它會在任何給定情況下達成其所
+	     述目的或正常運作。
 
 Reviewed-by是一種觀點聲明，即補丁是對核心的適當修改，沒有任何遺留的嚴重技
 術問題。任何感興趣的審閱者（完成了審閱工作且具有已知身分的人）都可以為一個
@@ -456,7 +521,7 @@ Reviewed-by是一種觀點聲明，即補丁是對核心的適當修改，沒有
 時，通常會增加補丁進入核心的可能性。
 
 一旦從測試人員或審閱者的“Tested-by”和“Reviewed-by”標籤出現在郵件列表中，作
-者應在發送下一個版本時將其添加到適用的補丁中。但是，如果補丁在以下版本中發
+者應在發送下一個版本時將其添加到適用的補丁中。但是，如果補丁在後續版本中發
 生了實質性更改，這些標籤可能不再適用，因此應該刪除。通常，刪除某人的
 Acked-by、Tested-by或Reviewed-by標籤時，應在補丁更改日誌中（在 ``---`` 分
 隔符之後）提及並附上解釋。
@@ -470,11 +535,9 @@ Fixes: 指示補丁修復了之前提交中的一個缺陷。它可以便於確
 檢查錯誤修復。這個標籤還幫助穩定核心團隊確定應該接收修復的穩定核心版本。這是
 指示補丁修復的錯誤的首選方法。請參閱 :ref:`tw_describe_changes` 瞭解更多資訊。
 
-.. note::
-
-  附加Fixes:標籤不會改變穩定核心規則流程，也不改變所有穩定版補丁抄送
-  stable@vger.kernel.org的要求。有關更多資訊，請閱讀
-  Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
+注意：附加 Fixes: 標籤並不會繞過穩定核心規則流程，也不會取代所有穩定版候選
+修補程式都要抄送 stable@vger.kernel.org 的要求。有關更多資訊，請閱讀
+Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
 
 最後，雖然提供標籤是受歡迎的且通常非常受讚賞，但請注意，簽署者（即提交者和
 維護者）可以自行斟酌是否採用所提供的標籤。
@@ -503,7 +566,7 @@ Fixes: 指示補丁修復了之前提交中的一個缺陷。它可以便於確
 標準補丁格式
 ------------
 
-本節描述如何格式化補丁本身。請注意，如果您的補丁儲存在 ``Git`` 儲存庫中，則
+本節描述如何格式化補丁本身。請注意，如果您的補丁儲存在 ``git`` 儲存庫中，則
 可以使用 ``git format-patch`` 進行正確的補丁格式化。但是，這些工具無法建立
 必要的文字，因此請務必閱讀下面的說明。
 
@@ -512,7 +575,7 @@ Fixes: 指示補丁修復了之前提交中的一個缺陷。它可以便於確
 
 標準的補丁標題行是::
 
-    Subject: [PATCH 001/123] 子系統:一句話概述
+    Subject: [PATCH 001/123] subsystem: summary phrase
 
 標準補丁的信體包含如下部分：
 
@@ -531,30 +594,35 @@ Fixes: 指示補丁修復了之前提交中的一個缺陷。它可以便於確
 
   - 實際補丁（ ``diff`` 輸出）。
 
-標題行的格式，使得對標題行按字母序排序非常的容易——很多郵件客戶端都
+標題行的格式，使得對標題行按字母序排序非常的容易——很多郵件用戶端都
 可以支援——因為序列號是用零填充的，所以按數字排序和按字母排序是一樣的。
 
-郵件標題中的“子系統”標識哪個核心子系統將被打補丁。
+郵件標題中的 ``subsystem`` （子系統）應標明這個修補程式修改的是核心的哪個區域
+或子系統。
 
-郵件標題中的“一句話概述”扼要的描述郵件中的補丁。“一句話概述”
-不應該是一個檔名。對於一個補丁系列（“補丁系列”指一系列的多個相關補丁
-），不要對每個補丁都使用同樣的“一句話概述”。
+郵件標題中的 ``summary phrase`` （一句話概述）應扼要地描述該郵件所含的修補
+程式。``summary phrase`` 不應該是一個檔名。對於一整個修補程式系列
+（``patch series`` 指一系列有順序的多個相關修補程式），不要對每個修補程式都
+使用同樣的 ``summary phrase``。
 
-記住郵件的“一句話概述”會成為該補丁的全域唯一標識。它會進入 ``git``
-的改動記錄裡。然後“一句話概述”會被用在開發者的討論裡，用來指代這個補丁
-。使用者將希望透過搜索引擎搜索“一句話概述”來找到那些討論這個補丁的文
-章。當人們在兩三個月後使用諸如 ``gitk`` 或 ``git log --oneline`` 之類
-的工具查看數千個補丁時，也會很快看到它。
+記住郵件的 ``summary phrase`` 會成為該修補程式的全域唯一標識。它會一路進入
+``git`` 的改動記錄裡。之後 ``summary phrase`` 可能會被用在開發者的討論裡，用來
+指代這個修補程式。人們會想用搜尋引擎搜尋 ``summary phrase`` 來閱讀關於這個
+修補程式的討論。當人們在兩三個月後使用諸如 ``gitk`` 或 ``git log --oneline``
+之類的工具瀏覽可能數以千計的修補程式時，它也會是人們唯一能快速看到的內容。
 
-出於這些原因，概述必須不超過70-75個字元，並且必須描述補丁的更改以及為
-什麼需要補丁。既要簡潔又要描述性很有挑戰性，但寫得好的概述應該這樣。
+出於這些原因，``summary`` 必須不超過 70-75 個字元，並且必須既描述修補程式改了
+什麼，也描述為什麼需要這個修補程式。既要簡潔又要具描述性很有挑戰性，但寫得好
+的概述就應該做到這一點。
 
-概述的前綴可以用方括號括起來：“Subject: [PATCH <tag>...] <概述>”。標記
-不被視為概述的一部分，而是描述應該如何處理補丁。如果補丁的多個版本已發
-送出來以響應評審（即“v1，v2，v3”）則必須包含版本號，或包含“RFC”以指示
-評審請求。如果一個補丁系列中有四個補丁，那麼各個補丁可以這樣編號：1/4、2/4、
-3/4、4/4。這可以確保開發人員瞭解補丁應用的順序，且
-已經查看或應用了補丁系列中的所有補丁。
+``summary phrase`` 的前面可以加上用中括號括起來的標記：「Subject: [PATCH
+<tag>...] <summary phrase>」。這些標記不被視為概述的一部分，而是描述應該如何
+處理修補程式。常見的標記可能包括版本號碼（如果修補程式為了回應評論而發送了多個
+版本，即「v1, v2, v3」），或用「RFC」表示徵求意見（request for comments）。
+
+如果一個修補程式系列中有四個修補程式，那麼各個修補程式可以這樣編號：1/4、2/4、
+3/4、4/4。這可以確保開發人員瞭解修補程式應套用的順序，並確認他們已經審閱或
+套用了修補程式系列中的所有修補程式。
 
 一些標題的例子::
 
@@ -566,11 +634,11 @@ Fixes: 指示補丁修復了之前提交中的一個缺陷。它可以便於確
 From行
 ^^^^^^
 
-``From`` 行必須是信體裡的最上面一行，具有如下格式::
+``from`` 行必須是信體裡的最上面一行，具有如下格式：
 
         From: Patch Author <author@example.com>
 
-``From`` 行指明在永久改動日誌裡，誰會被確認為作者。如果沒有 ``From`` 行，那
+``from`` 行指明在永久改動日誌裡，誰會被確認為作者。如果沒有 ``from`` 行，那
 麼郵件頭裡的 ``From:`` 行會被用來決定改動日誌中的作者。
 
 作者可以透過在 ``from`` 行和 ``SoB`` 行中加上組織名稱，來表明其所屬單位
@@ -581,14 +649,15 @@ From行
 說明主體
 ^^^^^^^^
 
-說明文字將會被提交到永久的原始程式碼改動日誌裡，因此應針對那些早已經不記得和這
-個補丁相關的討論細節的讀者。包括補丁處理的故障症狀（核心日誌訊息、oops訊息
-等），這對於可能正在搜索提交日誌以查找適用補丁的人特別有用。文字應該寫得如
-此詳細，以便在數週、數月甚至數年後閱讀時，能夠為讀者提供所需的細節資訊，以
-掌握建立補丁的 **原因** 。
+說明文字將會被提交到永久的原始程式碼改動日誌裡，因此應讓那些早已忘記可能促成
+這個修補程式的討論細節、但具備相關能力的讀者也能理解。包括修補程式所處理的
+故障症狀（核心日誌訊息、oops 訊息等），這對於可能正在搜尋提交日誌以尋找適用
+修補程式的人特別有用。文字應該寫得如此詳細，以便在數週、數月甚至數年後閱讀
+時，能夠為讀者提供所需的細節資訊，以掌握建立補丁的 **原因** 。
 
-如果一個補丁修復了一個編譯失敗，那麼可能不需要包含 *所有* 編譯失敗；
-只要足夠讓搜索補丁的人能夠找到它就行了。與概述一樣，既要簡潔又要描述性。
+如果一個修補程式修復了一個編譯失敗，那麼可能不需要包含 *所有* 編譯失敗；
+只要足夠讓搜尋該修補程式的人能夠找到它就行了。與 ``summary phrase`` 一樣，
+既要簡潔又要具描述性。
 
 
 .. _tw_backtraces:
@@ -618,12 +687,14 @@ From行
 
 對於 ``---`` 標記之後的額外註解，一個好的用途就是用來寫 ``diffstat`` ，用
 來顯示修改了什麼檔案和每個檔案都增加和刪除了多少行。 ``diffstat`` 對於比較
-大的補丁特別有用。使用 ``diffstat`` 的選項 ``-p 1 -w 70`` 這樣檔名就會從核
-心原始程式碼樹的目錄開始，不會佔用太寬的空間（很容易適合80列的寬度，也許會
-有一些縮排。）（ ``git`` 預設會產生合適的diffstat。）
+大的補丁特別有用。如果你要在 ``---`` 標記之後附上 ``diffstat``，請使用
+``diffstat`` 的選項 ``-p 1 -w 70``，這樣檔名就會從核心原始程式碼樹的頂層開始
+列出，不會佔用太寬的空間（很容易放進 80 列的寬度，也許還能有一些縮排）。
+（ ``git`` 預設會產生合適的 diffstat。）
 
 其餘那些只適用於當時或者與維護者相關的註解，不合適放到永久的改動日誌裡的，也
-應該放這裡。較好的例子就是 ``補丁更改記錄`` ，記錄了v1和v2版本補丁之間的差異。
+應該放這裡。較好的例子就是 ``patch changelogs`` （修補程式變更記錄），記錄了 v1
+和 v2 版本修補程式之間的差異。
 
 請將此資訊放在將變更日誌與補丁的其餘部分分隔開的 ``---`` 行 **之後** 。版本
 資訊不是提交到git樹的變更日誌的一部分。只是供審閱人員使用的附加資訊。如果將
@@ -652,19 +723,23 @@ lore.kernel.org存檔連結），以幫助審閱者::
 明確回覆郵件頭（In-Reply-To）
 -----------------------------
 
-手動添加回復補丁的的郵件頭（In-Reply_To:）是有用的（例如，使用 ``git send-email`` ），
-可以將補丁與以前的相關討論關聯起來，例如，將bug補丁連結到電子郵件和bug報告。
-但是，對於多補丁系列，最好避免在回覆時使用連結到該系列的舊版本。這樣，
-補丁的多個版本就不會成為電子郵件客戶端中無法管理的引用樹。如果連結有用，
-可以使用 https://lore.kernel.org/ 重定向器（例如，在封面電子郵件文字中）
+手動為修補程式添加 In-Reply-To: 郵件頭（例如在使用 ``git send-email`` 時）
+可能會有幫助，可以將修補程式與以前的相關討論關聯起來，例如將錯誤修復連結到
+包含錯誤報告的郵件。但是，對於多修補程式系列，通常最好避免使用 In-Reply-To:
+連結到該系列的舊版本。這樣，
+補丁的多個版本就不會成為電子郵件用戶端中無法管理的引用樹。如果連結有用，
+可以使用 https://lore.kernel.org/ 重新導向器（例如，在封面電子郵件文字中）
 連結到補丁系列的早期版本。
 
 給出基礎樹資訊
 --------------
 
-當其他開發人員收到您的補丁並開始審閱時，知道應該將您的工作放到程式碼樹歷史記錄
-中的什麼位置通常很有用。這對於自動化持續整合流水（CI）特別有用，這些流水線試
-圖執行一系列測試，以便在維護人員開始審閱之前確定提交的品質。
+當其他開發人員收到您的修補程式並開始審閱時，考慮到如今維護者樹的數量之多，他們
+絕對有必要知道您的工作是基於哪個基礎提交或分支。請再次留意前面說明過的
+MAINTAINERS 檔案中的 **T:** 項。
+
+這對於自動化的持續整合（CI）流程更加重要，這些流程會嘗試執行一系列測試，以便
+在維護人員開始審閱之前確定您所提交內容的品質。
 
 如果您使用 ``git format-patch`` 產生補丁，則可以透過 ``--base`` 標誌在提交中
 自動包含基礎樹資訊。使用此選項最簡單、最方便的方法是配合主題分支::
@@ -697,9 +772,12 @@ lore.kernel.org存檔連結），以幫助審閱者::
     ``--base`` 功能是在2.9.0版git中引入的。
 
 如果您不使用git格式化補丁，仍然可以包含相同的 ``base-commit`` 尾註，以指示您
-的工作所基於的樹的提交哈希。你應該在封面郵件或系列的第一個補丁中添加它，它應
+的工作所基於的樹的提交雜湊值。你應該在封面郵件或系列的第一個補丁中添加它，它應
 該放在 ``---`` 行的下面或所有其他內容之後，即只在你的電子郵件簽名之前。
 
+請確認該基礎提交位於官方的維護者樹或主線樹中，而不是某個只有你能存取的內部
+樹，否則它將毫無用處。
+
 工具
 ----
 
-- 
2.43.0