[PATCH 0/2] docs/zh_TW: translate process/applying-patches.rst into Traditional Chinese

[PATCH 0/2] docs/zh_TW: translate process/applying-patches.rst into Traditional Chinese

[Weijie Yuan]

This series adds a Traditional Chinese translation of
Documentation/process/applying-patches.rst.

The translation is current through commit fa04150b8ef7
("Documentation: describe how to apply incremental stable patches").

And updates the zh_TW process index and existing references to point
to the new local translation.

Link to corresponding patches for zh_CN:
https://lore.kernel.org/linux-doc/20260817-apply-patches-v3-0-45e3bd2b1ccc@wyuan.org/
(There're some RFC in it, please take a look if you haven't)

Thanks!

---
Weijie Yuan (2):
      docs/zh_TW: add process/applying-patches Traditional Chinese translation
      docs/zh_TW: link to Traditional Chinese applying-patches translation

 .../translations/zh_TW/admin-guide/README.rst      |   3 +-
 .../zh_TW/process/applying-patches.rst             | 377 +++++++++++++++++++++
 Documentation/translations/zh_TW/process/howto.rst |   5 +-
 Documentation/translations/zh_TW/process/index.rst |   1 +
 4 files changed, 381 insertions(+), 5 deletions(-)


---
base-commit: f579e7e851f13365d82f2caefde9ecd548da8518
change-id: 20260817-apply-patches-tw-1fd10831c95b

[PATCH 1/2] docs/zh_TW: add process/applying-patches Traditional Chinese translation

[Weijie Yuan]

Translate process/applying-patches.rst into Traditional Chinese and add
it to the process toctree.

Update the translation through commit fa04150b8ef7
("Documentation: describe how to apply incremental stable patches")

Assisted-by: ChatGPT:Codex-5.6Terra
Signed-off-by: Weijie Yuan <wy@wyuan.org>
---
 .../zh_TW/process/applying-patches.rst             | 377 +++++++++++++++++++++
 Documentation/translations/zh_TW/process/index.rst |   1 +
 2 files changed, 378 insertions(+)

diff --git a/Documentation/translations/zh_TW/process/applying-patches.rst b/Documentation/translations/zh_TW/process/applying-patches.rst
new file mode 100644
index 000000000000..225fb7715156
--- /dev/null
+++ b/Documentation/translations/zh_TW/process/applying-patches.rst
@@ -0,0 +1,377 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_TW.rst
+
+:Original: Documentation/process/applying-patches.rst
+
+:譯者:
+
+ Weijie Yuan <wy@wyuan.org>
+
+將修補程式套用至 Linux 核心
+============================
+
+原文作者：
+	Jesper Juhl，2005 年 8 月
+
+.. note::
+
+   本文件已經過時。絕大多數情況下，您幾乎一定應該考慮使用 Git，
+   而不是手動執行 ``patch``。
+
+Linux 核心郵件列表經常有人詢問如何將修補程式套用至核心；更精確地說，
+為眾多樹或分支其中之一建立的修補程式，應以哪個版本的核心為基礎來套用。
+希望本文能夠解答這些問題。
+
+除了說明如何套用和還原修補程式，本文也會簡要介紹不同的核心樹，並舉例
+說明如何套用各核心樹特有的修補程式。
+
+
+什麼是修補程式？
+==================
+
+修補程式是一份簡短的文字文件，其中記錄了原始碼樹兩個不同版本之間的
+差異。修補程式由 ``diff`` 程式產生。
+
+若要正確套用修補程式，您必須知道它是以哪個版本為基礎產生，又會將原始碼樹
+更新成哪個版本。這兩項資訊應記錄在修補程式檔案的中繼資料中，或可從檔名
+推得。
+
+
+如何套用或還原修補程式？
+========================
+
+使用 ``patch`` 程式套用修補程式。patch 程式會讀取 diff 檔案（也稱為
+修補程式檔案），再依照檔案中的描述修改原始碼樹。
+
+Linux 核心的修補程式是相對於存放核心原始碼目錄的父目錄產生。
+
+因此，修補程式檔案中的路徑會帶有產生修補程式時所用的核心原始碼目錄名稱
+（也可能是「a/」和「b/」之類的其他目錄名稱）。
+
+這個目錄名稱通常不會恰好和本機的核心原始碼目錄名稱相同（不過，它往往有助於
+判斷未註明版本的修補程式是以哪個版本為基礎產生）。套用修補程式時，應先進入
+核心原始碼目錄，再移除修補程式檔案所列路徑中的第一個組成部分（``patch`` 的
+``-p1`` 參數正是用於此目的）。
+
+若要還原先前已套用的修補程式，請為 patch 加上 -R 參數。也就是說，若套用
+修補程式時執行的是::
+
+	patch -p1 < ../patch-x.y.z
+
+那麼可這樣還原它::
+
+	patch -R -p1 < ../patch-x.y.z
+
+
+如何將修補程式或 diff 檔案交給 ``patch``？
+=============================================
+
+和 Linux 及其他類 UNIX 作業系統中的許多操作一樣，這件事也有好幾種做法。
+
+下文所有範例都使用以下語法，透過標準輸入（stdin）將未壓縮的檔案交給 patch::
+
+	patch -p1 < path/to/patch-x.y.z
+
+如果您只想依照下文範例操作，無意瞭解 patch 的其他用法，那麼讀到這裡即可跳過
+本節剩下的內容。
+
+patch 也可以透過 -i 參數取得要處理檔案的名稱，例如::
+
+	patch -p1 -i path/to/patch-x.y.z
+
+如果修補程式檔案以 gzip 或 xz 格式壓縮，而您不想先解壓縮再套用，可改為這樣
+交給 patch::
+
+	xzcat path/to/patch-x.y.z.xz | patch -p1
+	bzcat path/to/patch-x.y.z.gz | patch -p1
+
+若想在套用前先手動解壓縮修補程式檔案（下文範例均假設您已如此操作），只要對
+檔案執行 gunzip 或 xz，例如::
+
+	gunzip patch-x.y.z.gz
+	xz -d patch-x.y.z.xz
+
+執行後會留下純文字的 patch-x.y.z 檔案。您可依喜好，透過標準輸入或 ``-i``
+參數將它交給 patch。
+
+patch 還有幾個實用的參數：``-s`` 會使 patch 除了錯誤以外不輸出任何資訊，以免
+錯誤訊息很快捲出畫面；``--dry-run`` 只會列出將發生的情況，不會實際修改檔案；
+最後，``--verbose`` 會讓 patch 輸出更詳細的處理資訊。
+
+
+套用修補程式時的常見錯誤
+==========================
+
+套用修補程式檔案時，patch 會用不同方式確認檔案是否合理。
+
+例如，patch 會檢查檔案是否像是有效的修補程式檔案，也會檢查待修改程式碼周圍的
+內容是否與修補程式提供的上下文相符。這只是它所做的兩項基本檢查。
+
+如果遇到不太對勁的地方，patch 有兩種選擇：拒絕套用變更並中止，或稍作調整，
+設法套用修補程式。
+
+patch 會嘗試調整的一種情況是：上下文和待修改的行全都相符，只有行號不同。
+例如，修補程式要修改檔案中段的內容，但檔案開頭附近因故增刪了幾行，就會出現
+這種情況。此時所有內容其實都相符，只是整體向前或向後移動了一些，patch 通常
+會相應調整行號並套用修補程式。
+
+每當 patch 必須略作調整才能相符時，它會提示修補程式是在經過模糊比對
+（**fuzz**）後套用。您應謹慎看待這類變更：patch 很可能處理正確，但並不保證
+每次都能正確處理，有時會得到錯誤結果。
+
+若某項變更無法透過模糊比對調整，patch 會直接拒絕這項變更，並留下副檔名為
+``.rej`` 的檔案（拒絕檔）。您可閱讀此檔案，確切瞭解哪項變更未能套用，再視需要
+手動處理。
+
+假如核心原始碼中沒有第三方修補程式，只有來自 kernel.org 的修補程式，且修補
+程式套用順序正確，原始碼檔案也未自行修改，那麼 patch 絕不應回報模糊比對或拒絕
+套用。若仍看到這類訊息，您的本機原始碼樹或修補程式檔案很可能已經損壞。此時應先
+嘗試重新下載修補程式；若問題依舊，建議從 kernel.org 重新下載完整的全新原始碼樹，
+從頭開始。
+
+以下進一步看看 patch 可能輸出的幾種訊息。
+
+若 patch 停下來並顯示 ``File to patch:`` 提示，表示它找不到待修補的檔案。
+最可能的原因是您忘記指定 -p1，或目前目錄不正確。偶爾也會遇到必須以 ``-p0``
+而非 ``-p1`` 套用的修補程式（查看修補程式檔案便可判斷是否如此；若確實如此，
+是修補程式建立者犯了錯，但並不致命）。
+
+若看到 ``Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines).`` 或類似訊息，
+表示 patch 必須調整變更的位置才能套用；在這個例子中，實際變更位置必須與預期
+位置相差 7 行才能相符。
+
+最終得到的檔案可能正確，也可能不正確，取決於檔案為何與預期不符。
+
+嘗試套用以其他核心版本為基礎產生的修補程式時，經常會出現這種情況。
+
+若看到 ``Hunk #3 FAILED at 2387.`` 之類的訊息，表示修補程式未能正確套用，
+patch 程式也無法透過模糊比對完成套用。此時會產生一個 ``.rej`` 檔案，其中包含
+造成修補程式失敗的變更；還會產生一個 ``.orig`` 檔案，其中是未能修改的原始內容。
+
+若看到 ``Reversed (or previously applied) patch detected!  Assume
+-R? [n]``，表示 patch 偵測到修補程式中的變更似乎已經存在。
+
+若您確實已套用過此修補程式，只是不慎又套用一次，請回答 [n]o 並中止這次套用。
+若先前套用過修補程式，現在本來就想還原它，只是忘了指定 -R，則可在此回答
+[**y**]es，讓 patch 為您還原。
+
+若修補程式建立者在產生修補程式時顛倒了來源目錄和目的地目錄，也會出現這項訊息；
+在這種情況下，還原修補程式實際上才是在套用它。
+
+``patch: **** unexpected end of file in patch`` 或 ``patch unexpectedly
+ends in middle of line`` 之類的訊息，表示 patch 無法理解收到的檔案。可能是檔案
+下載不完整，可能是您沒有先解壓縮便把壓縮的修補程式交給 patch，也可能是修補程式
+檔案在途經某個郵件用戶端或郵件傳輸代理程式時遭到破壞，例如一行過長的內容被拆成
+兩行。這類警告通常很容易處理，只需將被拆開的兩行重新連接（串接）起來即可。
+
+如前所述，若將 kernel.org 提供的修補程式套用至版本正確、未經修改的原始碼樹，
+這些錯誤絕不應出現。因此，若套用 kernel.org 的修補程式時遇到這些錯誤，應認為
+修補程式檔案或原始碼樹已經損壞；建議重新下載完整的核心原始碼樹和要套用的修補
+程式，從頭開始。
+
+
+除了 ``patch``，還有其他選擇嗎？
+====================================
+
+有。
+
+您可使用 ``interdiff`` 程式（http://cyberelk.net/tim/patchutils/），為兩個
+修補程式之間的差異產生一個修補程式，再套用產生的修補程式。
+
+這樣便能一步從 5.7.2 更新至 5.7.3。interdiff 的 -z 旗標甚至允許直接傳入以
+gzip 或 bzip2 格式壓縮的修補程式，無需使用 zcat、bzcat，也不必手動解壓縮。
+
+以下是一步從 5.7.2 更新至 5.7.3 的方法::
+
+	interdiff -z ../patch-5.7.2.gz ../patch-5.7.3.gz | patch -p1
+
+儘管 interdiff 能省去一兩個步驟，一般仍建議依慣例多執行這些步驟，因為 interdiff
+在某些情況下可能產生錯誤結果。
+
+另一個選擇是 ``ketchup``。它是一個可自動下載及套用修補程式的 Python 指令稿
+（https://www.selenic.com/ketchup/）。
+
+其他實用工具還有：diffstat，用於顯示修補程式變更的摘要；lsdiff，用於簡要列出
+修補程式檔案影響的檔案，也可選擇同時顯示各段修補程式的起始行號；grepdiff，用於
+在修補程式中尋找與指定正規表示式相符的內容，並列出這些內容所在的檔案。
+
+
+可以從哪裡下載修補程式？
+==========================
+
+可從 https://kernel.org/ 取得修補程式。網站首頁提供最新修補程式的連結，
+各類修補程式也有各自固定的存放位置。
+
+5.x.y（-stable）修補程式和 5.x 修補程式位於
+
+	https://www.kernel.org/pub/linux/kernel/v5.x/
+
+5.x.y 遞增修補程式位於
+
+	https://www.kernel.org/pub/linux/kernel/v5.x/incr/
+
+-rc 修補程式並不存放於網頁伺服器，而是依下列 git 標籤按需產生
+
+	https://git.kernel.org/torvalds/p/v5.1-rc1/v5.0
+
+穩定版的 -rc 修補程式位於
+
+	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/
+
+
+5.x 核心
+========
+
+這些是 Linus 發布的基礎穩定版本，其中版本號最大者最新。
+
+若發現回歸或其他嚴重缺陷，便會在這個基礎版本之上發布 -stable 修正修補程式
+（見下文）。每當新的 5.x 基礎核心發布時，也會提供一個修補程式，表示上一個
+5.x 核心與新核心之間的差異。
+
+若要套用從 5.6 更新至 5.7 的修補程式，可依下列步驟操作。請注意，這類修補程式
+**不能**套用至 5.x.y 核心之上，只能套用至基礎 5.x 核心之上；若要從 5.x.y
+更新至 5.x+1，必須先還原 5.x.y 修補程式。
+
+以下是兩個範例::
+
+	# 從 5.6 更新至 5.7
+
+	$ cd ~/linux-5.6		# 進入核心原始碼目錄
+	$ patch -p1 < ../patch-5.7	# 套用 5.7 修補程式
+	$ cd ..
+	$ mv linux-5.6 linux-5.7	# 重新命名原始碼目錄
+
+	# 從 5.6.1 更新至 5.7
+
+	$ cd ~/linux-5.6.1		# 進入核心原始碼目錄
+	$ patch -p1 -R < ../patch-5.6.1	# 還原 5.6.1 修補程式
+					# 原始碼目錄現在是 5.6
+	$ patch -p1 < ../patch-5.7	# 套用新的 5.7 修補程式
+	$ cd ..
+	$ mv linux-5.6.1 linux-5.7	# 重新命名原始碼目錄
+
+
+5.x.y 核心
+==========
+
+版本號由三段數字組成的是 -stable 核心。它們包含規模較小但至關重要的修正，
+用於解決某個 5.x 核心中發現的安全性問題或嚴重回歸。
+
+對於想使用最新穩定核心，又無意協助測試開發版或實驗版的使用者，建議選擇這個分支。
+
+若沒有 5.x.y 核心可用，則版本號最大的 5.x 核心就是目前的穩定核心。
+
+-stable 團隊同時提供一般修補程式及遞增修補程式。以下說明如何套用這兩類修補程式。
+
+一般修補程式
+~~~~~~~~~~~~~~
+
+這類修補程式不是遞增修補程式。例如，5.7.3 修補程式不能套用至 5.7.2 核心原始碼，
+而應套用至基礎 5.7 核心原始碼。
+
+因此，若要將 5.7.3 修補程式套用至現有的 5.7.2 核心原始碼，必須先還原 5.7.2
+修補程式（回到基礎 5.7 核心原始碼），再套用新的 5.7.3 修補程式。
+
+以下是一個簡單範例::
+
+	$ cd ~/linux-5.7.2		# 進入核心原始碼目錄
+	$ patch -p1 -R < ../patch-5.7.2	# 還原 5.7.2 修補程式
+	$ patch -p1 < ../patch-5.7.3	# 套用新的 5.7.3 修補程式
+	$ cd ..
+	$ mv linux-5.7.2 linux-5.7.3	# 重新命名核心原始碼目錄
+
+遞增修補程式
+~~~~~~~~~~~~
+
+遞增修補程式則不同：它們不套用於基礎 5.x 核心，而套用於前一個穩定版核心
+（5.x.y-1）。
+
+以下是套用遞增修補程式的範例::
+
+	$ cd ~/linux-5.7.2		# 進入核心原始碼目錄
+	$ patch -p1 < ../patch-5.7.2-3	# 套用新的 5.7.3 修補程式
+	$ cd ..
+	$ mv linux-5.7.2 linux-5.7.3	# 重新命名核心原始碼目錄
+
+
+-rc 核心
+========
+
+這些是發行候選版核心。每當 Linus 認為目前的 git 樹（git 是核心的原始碼管理工具）
+處於相當合理且足以測試的狀態時，就會發布這樣的開發版核心。
+
+這些核心並不穩定；若打算執行，就要預期它們偶爾會發生問題。不過，在幾個主要開發
+分支中，這是最穩定的一個，而且它最終會成為下一個穩定核心，所以讓盡可能多的人
+參與測試十分重要。
+
+若您想協助測試開發版核心，但不想執行真正具有實驗性的內容，這個分支很合適
+（有關真正實驗性的內容，請參閱下文介紹 -next 和 -mm 核心的章節）。
+
+-rc 修補程式不是遞增修補程式；與上文介紹的 5.x.y 修補程式一樣，它們套用於
+基礎 5.x 核心。-rcN 後綴前的核心版本號，表示這個 -rc 核心最終會成為哪個版本。
+
+因此，5.8-rc5 表示它是 5.8 核心的第五個發行候選版，這個修補程式應套用至
+5.7 核心原始碼。
+
+以下是三個套用此類修補程式的範例::
+
+	# 第一個範例：從 5.7 更新至 5.8-rc3
+
+	$ cd ~/linux-5.7			# 進入 5.7 原始碼目錄
+	$ patch -p1 < ../patch-5.8-rc3		# 套用 5.8-rc3 修補程式
+	$ cd ..
+	$ mv linux-5.7 linux-5.8-rc3		# 重新命名原始碼目錄
+
+	# 接著從 5.8-rc3 更新至 5.8-rc5
+
+	$ cd ~/linux-5.8-rc3			# 進入 5.8-rc3 目錄
+	$ patch -p1 -R < ../patch-5.8-rc3	# 還原 5.8-rc3 修補程式
+	$ patch -p1 < ../patch-5.8-rc5		# 套用新的 5.8-rc5 修補程式
+	$ cd ..
+	$ mv linux-5.8-rc3 linux-5.8-rc5	# 重新命名原始碼目錄
+
+	# 最後嘗試從 5.7.3 更新至 5.8-rc5
+
+	$ cd ~/linux-5.7.3			# 進入核心原始碼目錄
+	$ patch -p1 -R < ../patch-5.7.3		# 還原 5.7.3 修補程式
+	$ patch -p1 < ../patch-5.8-rc5		# 套用新的 5.8-rc5 修補程式
+	$ cd ..
+	$ mv linux-5.7.3 linux-5.8-rc5	# 重新命名原始碼目錄
+
+
+-mm 修補程式與 linux-next 樹
+==============================
+
+-mm 修補程式是 Andrew Morton 發布的實驗性修補程式。
+
+過去，-mm 樹也用於測試子系統修補程式；現在這項工作由
+`linux-next` （https://www.kernel.org/doc/man-pages/linux-next.html）
+樹承擔。子系統維護者先將修補程式推送至 linux-next，再於合併視窗期間直接
+傳送給 Linus。
+
+-mm 修補程式是新功能和其他實驗性修補程式的試驗場，這些修補程式未透過子系統樹
+合併。一旦這類修補程式在 -mm 中經過一段時間的驗證並證明自身價值，Andrew 就會
+將其推送給 Linus，以納入主線。
+
+linux-next 樹每日更新，其中包括 -mm 修補程式。兩者始終處於變動之中，包含許多
+實驗性功能、大量不適合主線的除錯修補程式等，是本文所述各分支中實驗性最高的。
+
+這些修補程式不適合用於必須保持穩定的系統，執行它們的風險高於其他任何分支
+（務必備有最新備份；執行任何實驗性核心都應如此，執行 -mm 修補程式或 linux-next
+樹中的核心時尤其如此）。
+
+我們非常歡迎大家測試 -mm 修補程式和 linux-next，因為測試的目的就是在變更併入
+較穩定的 Linus 主線樹之前，找出並消除回歸、當機、資料損壞錯誤、建置失敗及其他
+各類錯誤。
+
+不過，-mm 和 linux-next 的測試者必須明白，這些樹發生問題的頻率高於其他任何
+核心樹。
+
+
+至此，各種核心樹已經介紹完畢。希望您現在已清楚瞭解如何套用各類修補程式，
+並能協助測試核心。
+
+感謝 Randy Dunlap、Rolf Eike Beer、Linus Torvalds、Bodo Eggert、
+Johannes Stezenbach、Grant Coady、Pavel Machek，以及其他可能被我遺漏的人，
+感謝他們對本文的審閱和貢獻。
diff --git a/Documentation/translations/zh_TW/process/index.rst b/Documentation/translations/zh_TW/process/index.rst
index 3f84437a2ca9..1642fcf92b26 100644
--- a/Documentation/translations/zh_TW/process/index.rst
+++ b/Documentation/translations/zh_TW/process/index.rst
@@ -120,6 +120,7 @@ TODOList:
    :maxdepth: 1
 
    magic-number
+   applying-patches
 
 TODOList:
 

-- 
2.55.0.717.g61afef3e37

[PATCH 2/2] docs/zh_TW: link to Traditional Chinese applying-patches translation

[Weijie Yuan]

Now that process/applying-patches.rst has been translated into
Traditional Chinese, update the references in zh_TW howto.rst and
admin-guide/README.rst to point to the Traditional Chinese
translation instead of the English original.

Signed-off-by: Weijie Yuan <wy@wyuan.org>
---
 Documentation/translations/zh_TW/admin-guide/README.rst | 3 +--
 Documentation/translations/zh_TW/process/howto.rst      | 5 ++---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/Documentation/translations/zh_TW/admin-guide/README.rst b/Documentation/translations/zh_TW/admin-guide/README.rst
index 9be4915ae420..d32964f2c307 100644
--- a/Documentation/translations/zh_TW/admin-guide/README.rst
+++ b/Documentation/translations/zh_TW/admin-guide/README.rst
@@ -86,7 +86,7 @@ Linux內核6.x版本 <http://kernel.org/>
    補丁，則不應先應用6.0.1和6.0.2的補丁。類似地，如果您運行的是6.0.2內核，
    並且希望跳轉到6.0.3，那麼在應用6.0.3補丁之前，必須首先撤銷6.0.2補丁
    （即patch -R）。更多關於這方面的內容，請閱讀
-   :ref:`Documentation/process/applying-patches.rst <applying_patches>` 。
+   Documentation/translations/zh_TW/process/applying-patches.rst 。
 
    或者，腳本 patch-kernel 可以用來自動化這個過程。它能確定當前內核版本並
    應用找到的所有補丁::
@@ -292,4 +292,3 @@ Documentation/translations/zh_CN/admin-guide/bug-hunting.rst 。
 更多用GDB調試內核的信息，請參閱：
 Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst
 和 Documentation/process/debugging/kgdb.rst 。
-
diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
index 8466f6af96cc..176506c52402 100644
--- a/Documentation/translations/zh_TW/process/howto.rst
+++ b/Documentation/translations/zh_TW/process/howto.rst
@@ -146,8 +146,8 @@ Linux核心程式碼中包含有大量的文件。這些文件對於學習如何
     有助於核心開發的外部文件列表。如果你在核心自帶的文件中沒有找到你想找
     的內容，可以查看這些文件。
 
-  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
-    關於補丁是什麼以及如何將它打在不同核心開發分支上的好介紹
+  :doc:`Documentation/translations/zh_TW/process/applying-patches.rst <applying-patches>`
+    說明何謂修補程式，以及如何將它套用至不同核心開發分支的實用介紹
 
 核心還擁有大量從程式碼自動產生或者從 ReStructuredText(ReST) 標記產生的文件，
 比如這個文件，它包含核心內部API的全面介紹以及如何妥善處理加鎖的規則。所有
@@ -498,4 +498,3 @@ Kerrisk和Alex Shepard的評審、建議和貢獻。沒有他們的幫助，這
 
 
 英文版維護者： Greg Kroah-Hartman <greg@kroah.com>
-

-- 
2.55.0.717.g61afef3e37

Re: [PATCH 1/2] docs/zh_TW: add process/applying-patches Traditional Chinese translation

[葉宸佑]

Thanks for taking this on -- and for picking a document that actually
matters rather than an easy one. A few things below; the first three
produce real breakage, the rest are suggestions.

## Must fix

1. Section levels are flattened (applying-patches.rst:12)

The English original uses ++++ for the document title (level 1) and
==== for each section (level 2). The translation uses ==== for both, so
the file ends up with eleven parallel h1 headings and no document title.
zh_TW/process/code-of-conduct.rst:12 keeps the ++++ form; the same here
would fix it.

2. The bold marker at :233 will not render

    **不能**套用

docutils requires the closing strong marker to be followed by
whitespace or punctuation; a CJK character does not count. As written
this emits "Inline strong start-string without end-string" and prints
the asterisks literally. The existing practice in the tree is to escape
with a backslash -- see zh_CN/doc-guide/parse-headers.rst.

I checked the other **...**, ``...`` and *...* in the file; this is the
only instance that trips the rule (（**fuzz**） and [**y**]es are both
fine).

3. index.rst: wrong section, and the TODO entry is still there

The entry was added to 「其他材料」 at :123, but the English original
lists applying-patches under tools and technical guides
(Documentation/process/index.rst:46, after email-clients). More
importantly, the 「* applying-patches」 TODOList item at :55 is still
present, so the document is listed as both translated and not
translated.

Moving it into the toctree at :46-49 after email-clients and dropping
:55 fixes both.

4. Please drop the :譯者: block

    +:譯者:
    +
    + Weijie Yuan <wy@wyuan.org>

We are in the middle of removing exactly these blocks from the zh_TW
tree [1] -- adding a new one now would just mean removing it again.

[1] https://lore.kernel.org/linux-doc/20260819145808.291567-1-chenyou910331@gmail.com/

## Suggestions

5. Missing .. _tw_applying_patches: label

Every other .rst under zh_TW/process/ carries a .. _tw_*: label, and
the English original has .. _applying_patches:. Adding it would let
2/2 use :ref: in howto.rst, matching the eight neighbouring entries in
that list instead of standing out as a :doc:.

6. Comment alignment at :340

One tab puts the comment at column 40; the surrounding lines are at 48,
and the English original uses two tabs.

## Terminology

The significant decision here is patch -> 修補程式, used 98 times. I
think the direction is right -- 修補程式 is the standard Taiwanese
rendering -- but it needs to be handled explicitly, because the
existing zh_TW tree has 630 instances of 補丁, including in the two
files 2/2 touches. Right now the two terms would sit on either side of
the same cross-reference.

Could you:

  - add patch -> 修補程式 / 补丁 to glossary.rst, and
  - say in the commit message that this is a deliberate localisation

Migrating the existing 630 instances is a separate question and I do
not think it should ride along with this series; I would rather discuss
it on its own once this lands.

A few smaller ones, measured against what the tree already uses:

  :192  指令稿      -> 腳本      (17 files use 腳本; 指令稿 is not
                                  used in Taiwan)
  :165  郵件用戶端  -> 郵件客戶端 (8 files, including email-clients.rst)
  :228  回歸        -> 迴歸      (regression; 10 files use 迴歸, 4 use
  :259                            回歸 -- 迴歸測試 is the usual form)
  :365

On the other side: 中繼資料, 旗標, 模糊比對, 發行候選版, 當機,
正規表示式 are all good Taiwanese renderings. Would you mind adding
those to the glossary too while you are there? It would save the next
translation from having to guess.

## On the CJK/ASCII spacing

This file puts a space between CJK and Latin throughout, which is the
opposite of what the v3 glossary currently says. That is on me: I wrote
that entry before you raised the question, and we never actually
settled it.

Since we both prefer spaces, changing the glossary is the right fix
rather than asking you to strip 218 of them. Please leave this file as
it is.

Would you send that glossary change yourself once v3 lands? You are the
one who spotted the problem, and you are a maintainer here, so it seems
more natural coming from you than from me correcting my own entry. What
I had in mind:

  - new translations: a space between CJK and Latin/digits
  - existing files: left alone, no tree-wide normalisation

The second half matters -- normalising the 2581 existing instances
would be exactly the kind of churn Jon objected to in the MAINTAINERS
thread.

Thanks.

Chen-Yu

Weijie Yuan <wy@wyuan.org> 於 2026年8月17日週一 下午10:10寫道：
>
> Translate process/applying-patches.rst into Traditional Chinese and add
> it to the process toctree.
>
> Update the translation through commit fa04150b8ef7
> ("Documentation: describe how to apply incremental stable patches")
>
> Assisted-by: ChatGPT:Codex-5.6Terra
> Signed-off-by: Weijie Yuan <wy@wyuan.org>
> ---
>  .../zh_TW/process/applying-patches.rst             | 377 +++++++++++++++++++++
>  Documentation/translations/zh_TW/process/index.rst |   1 +
>  2 files changed, 378 insertions(+)
>
> diff --git a/Documentation/translations/zh_TW/process/applying-patches.rst b/Documentation/translations/zh_TW/process/applying-patches.rst
> new file mode 100644
> index 000000000000..225fb7715156
> --- /dev/null
> +++ b/Documentation/translations/zh_TW/process/applying-patches.rst
> @@ -0,0 +1,377 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +.. include:: ../disclaimer-zh_TW.rst
> +
> +:Original: Documentation/process/applying-patches.rst
> +
> +:譯者:
> +
> + Weijie Yuan <wy@wyuan.org>
> +
> +將修補程式套用至 Linux 核心
> +============================
> +
> +原文作者：
> +       Jesper Juhl，2005 年 8 月
> +
> +.. note::
> +
> +   本文件已經過時。絕大多數情況下，您幾乎一定應該考慮使用 Git，
> +   而不是手動執行 ``patch``。
> +
> +Linux 核心郵件列表經常有人詢問如何將修補程式套用至核心；更精確地說，
> +為眾多樹或分支其中之一建立的修補程式，應以哪個版本的核心為基礎來套用。
> +希望本文能夠解答這些問題。
> +
> +除了說明如何套用和還原修補程式，本文也會簡要介紹不同的核心樹，並舉例
> +說明如何套用各核心樹特有的修補程式。
> +
> +
> +什麼是修補程式？
> +==================
> +
> +修補程式是一份簡短的文字文件，其中記錄了原始碼樹兩個不同版本之間的
> +差異。修補程式由 ``diff`` 程式產生。
> +
> +若要正確套用修補程式，您必須知道它是以哪個版本為基礎產生，又會將原始碼樹
> +更新成哪個版本。這兩項資訊應記錄在修補程式檔案的中繼資料中，或可從檔名
> +推得。
> +
> +
> +如何套用或還原修補程式？
> +========================
> +
> +使用 ``patch`` 程式套用修補程式。patch 程式會讀取 diff 檔案（也稱為
> +修補程式檔案），再依照檔案中的描述修改原始碼樹。
> +
> +Linux 核心的修補程式是相對於存放核心原始碼目錄的父目錄產生。
> +
> +因此，修補程式檔案中的路徑會帶有產生修補程式時所用的核心原始碼目錄名稱
> +（也可能是「a/」和「b/」之類的其他目錄名稱）。
> +
> +這個目錄名稱通常不會恰好和本機的核心原始碼目錄名稱相同（不過，它往往有助於
> +判斷未註明版本的修補程式是以哪個版本為基礎產生）。套用修補程式時，應先進入
> +核心原始碼目錄，再移除修補程式檔案所列路徑中的第一個組成部分（``patch`` 的
> +``-p1`` 參數正是用於此目的）。
> +
> +若要還原先前已套用的修補程式，請為 patch 加上 -R 參數。也就是說，若套用
> +修補程式時執行的是::
> +
> +       patch -p1 < ../patch-x.y.z
> +
> +那麼可這樣還原它::
> +
> +       patch -R -p1 < ../patch-x.y.z
> +
> +
> +如何將修補程式或 diff 檔案交給 ``patch``？
> +=============================================
> +
> +和 Linux 及其他類 UNIX 作業系統中的許多操作一樣，這件事也有好幾種做法。
> +
> +下文所有範例都使用以下語法，透過標準輸入（stdin）將未壓縮的檔案交給 patch::
> +
> +       patch -p1 < path/to/patch-x.y.z
> +
> +如果您只想依照下文範例操作，無意瞭解 patch 的其他用法，那麼讀到這裡即可跳過
> +本節剩下的內容。
> +
> +patch 也可以透過 -i 參數取得要處理檔案的名稱，例如::
> +
> +       patch -p1 -i path/to/patch-x.y.z
> +
> +如果修補程式檔案以 gzip 或 xz 格式壓縮，而您不想先解壓縮再套用，可改為這樣
> +交給 patch::
> +
> +       xzcat path/to/patch-x.y.z.xz | patch -p1
> +       bzcat path/to/patch-x.y.z.gz | patch -p1
> +
> +若想在套用前先手動解壓縮修補程式檔案（下文範例均假設您已如此操作），只要對
> +檔案執行 gunzip 或 xz，例如::
> +
> +       gunzip patch-x.y.z.gz
> +       xz -d patch-x.y.z.xz
> +
> +執行後會留下純文字的 patch-x.y.z 檔案。您可依喜好，透過標準輸入或 ``-i``
> +參數將它交給 patch。
> +
> +patch 還有幾個實用的參數：``-s`` 會使 patch 除了錯誤以外不輸出任何資訊，以免
> +錯誤訊息很快捲出畫面；``--dry-run`` 只會列出將發生的情況，不會實際修改檔案；
> +最後，``--verbose`` 會讓 patch 輸出更詳細的處理資訊。
> +
> +
> +套用修補程式時的常見錯誤
> +==========================
> +
> +套用修補程式檔案時，patch 會用不同方式確認檔案是否合理。
> +
> +例如，patch 會檢查檔案是否像是有效的修補程式檔案，也會檢查待修改程式碼周圍的
> +內容是否與修補程式提供的上下文相符。這只是它所做的兩項基本檢查。
> +
> +如果遇到不太對勁的地方，patch 有兩種選擇：拒絕套用變更並中止，或稍作調整，
> +設法套用修補程式。
> +
> +patch 會嘗試調整的一種情況是：上下文和待修改的行全都相符，只有行號不同。
> +例如，修補程式要修改檔案中段的內容，但檔案開頭附近因故增刪了幾行，就會出現
> +這種情況。此時所有內容其實都相符，只是整體向前或向後移動了一些，patch 通常
> +會相應調整行號並套用修補程式。
> +
> +每當 patch 必須略作調整才能相符時，它會提示修補程式是在經過模糊比對
> +（**fuzz**）後套用。您應謹慎看待這類變更：patch 很可能處理正確，但並不保證
> +每次都能正確處理，有時會得到錯誤結果。
> +
> +若某項變更無法透過模糊比對調整，patch 會直接拒絕這項變更，並留下副檔名為
> +``.rej`` 的檔案（拒絕檔）。您可閱讀此檔案，確切瞭解哪項變更未能套用，再視需要
> +手動處理。
> +
> +假如核心原始碼中沒有第三方修補程式，只有來自 kernel.org 的修補程式，且修補
> +程式套用順序正確，原始碼檔案也未自行修改，那麼 patch 絕不應回報模糊比對或拒絕
> +套用。若仍看到這類訊息，您的本機原始碼樹或修補程式檔案很可能已經損壞。此時應先
> +嘗試重新下載修補程式；若問題依舊，建議從 kernel.org 重新下載完整的全新原始碼樹，
> +從頭開始。
> +
> +以下進一步看看 patch 可能輸出的幾種訊息。
> +
> +若 patch 停下來並顯示 ``File to patch:`` 提示，表示它找不到待修補的檔案。
> +最可能的原因是您忘記指定 -p1，或目前目錄不正確。偶爾也會遇到必須以 ``-p0``
> +而非 ``-p1`` 套用的修補程式（查看修補程式檔案便可判斷是否如此；若確實如此，
> +是修補程式建立者犯了錯，但並不致命）。
> +
> +若看到 ``Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines).`` 或類似訊息，
> +表示 patch 必須調整變更的位置才能套用；在這個例子中，實際變更位置必須與預期
> +位置相差 7 行才能相符。
> +
> +最終得到的檔案可能正確，也可能不正確，取決於檔案為何與預期不符。
> +
> +嘗試套用以其他核心版本為基礎產生的修補程式時，經常會出現這種情況。
> +
> +若看到 ``Hunk #3 FAILED at 2387.`` 之類的訊息，表示修補程式未能正確套用，
> +patch 程式也無法透過模糊比對完成套用。此時會產生一個 ``.rej`` 檔案，其中包含
> +造成修補程式失敗的變更；還會產生一個 ``.orig`` 檔案，其中是未能修改的原始內容。
> +
> +若看到 ``Reversed (or previously applied) patch detected!  Assume
> +-R? [n]``，表示 patch 偵測到修補程式中的變更似乎已經存在。
> +
> +若您確實已套用過此修補程式，只是不慎又套用一次，請回答 [n]o 並中止這次套用。
> +若先前套用過修補程式，現在本來就想還原它，只是忘了指定 -R，則可在此回答
> +[**y**]es，讓 patch 為您還原。
> +
> +若修補程式建立者在產生修補程式時顛倒了來源目錄和目的地目錄，也會出現這項訊息；
> +在這種情況下，還原修補程式實際上才是在套用它。
> +
> +``patch: **** unexpected end of file in patch`` 或 ``patch unexpectedly
> +ends in middle of line`` 之類的訊息，表示 patch 無法理解收到的檔案。可能是檔案
> +下載不完整，可能是您沒有先解壓縮便把壓縮的修補程式交給 patch，也可能是修補程式
> +檔案在途經某個郵件用戶端或郵件傳輸代理程式時遭到破壞，例如一行過長的內容被拆成
> +兩行。這類警告通常很容易處理，只需將被拆開的兩行重新連接（串接）起來即可。
> +
> +如前所述，若將 kernel.org 提供的修補程式套用至版本正確、未經修改的原始碼樹，
> +這些錯誤絕不應出現。因此，若套用 kernel.org 的修補程式時遇到這些錯誤，應認為
> +修補程式檔案或原始碼樹已經損壞；建議重新下載完整的核心原始碼樹和要套用的修補
> +程式，從頭開始。
> +
> +
> +除了 ``patch``，還有其他選擇嗎？
> +====================================
> +
> +有。
> +
> +您可使用 ``interdiff`` 程式（http://cyberelk.net/tim/patchutils/），為兩個
> +修補程式之間的差異產生一個修補程式，再套用產生的修補程式。
> +
> +這樣便能一步從 5.7.2 更新至 5.7.3。interdiff 的 -z 旗標甚至允許直接傳入以
> +gzip 或 bzip2 格式壓縮的修補程式，無需使用 zcat、bzcat，也不必手動解壓縮。
> +
> +以下是一步從 5.7.2 更新至 5.7.3 的方法::
> +
> +       interdiff -z ../patch-5.7.2.gz ../patch-5.7.3.gz | patch -p1
> +
> +儘管 interdiff 能省去一兩個步驟，一般仍建議依慣例多執行這些步驟，因為 interdiff
> +在某些情況下可能產生錯誤結果。
> +
> +另一個選擇是 ``ketchup``。它是一個可自動下載及套用修補程式的 Python 指令稿
> +（https://www.selenic.com/ketchup/）。
> +
> +其他實用工具還有：diffstat，用於顯示修補程式變更的摘要；lsdiff，用於簡要列出
> +修補程式檔案影響的檔案，也可選擇同時顯示各段修補程式的起始行號；grepdiff，用於
> +在修補程式中尋找與指定正規表示式相符的內容，並列出這些內容所在的檔案。
> +
> +
> +可以從哪裡下載修補程式？
> +==========================
> +
> +可從 https://kernel.org/ 取得修補程式。網站首頁提供最新修補程式的連結，
> +各類修補程式也有各自固定的存放位置。
> +
> +5.x.y（-stable）修補程式和 5.x 修補程式位於
> +
> +       https://www.kernel.org/pub/linux/kernel/v5.x/
> +
> +5.x.y 遞增修補程式位於
> +
> +       https://www.kernel.org/pub/linux/kernel/v5.x/incr/
> +
> +-rc 修補程式並不存放於網頁伺服器，而是依下列 git 標籤按需產生
> +
> +       https://git.kernel.org/torvalds/p/v5.1-rc1/v5.0
> +
> +穩定版的 -rc 修補程式位於
> +
> +       https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/
> +
> +
> +5.x 核心
> +========
> +
> +這些是 Linus 發布的基礎穩定版本，其中版本號最大者最新。
> +
> +若發現回歸或其他嚴重缺陷，便會在這個基礎版本之上發布 -stable 修正修補程式
> +（見下文）。每當新的 5.x 基礎核心發布時，也會提供一個修補程式，表示上一個
> +5.x 核心與新核心之間的差異。
> +
> +若要套用從 5.6 更新至 5.7 的修補程式，可依下列步驟操作。請注意，這類修補程式
> +**不能**套用至 5.x.y 核心之上，只能套用至基礎 5.x 核心之上；若要從 5.x.y
> +更新至 5.x+1，必須先還原 5.x.y 修補程式。
> +
> +以下是兩個範例::
> +
> +       # 從 5.6 更新至 5.7
> +
> +       $ cd ~/linux-5.6                # 進入核心原始碼目錄
> +       $ patch -p1 < ../patch-5.7      # 套用 5.7 修補程式
> +       $ cd ..
> +       $ mv linux-5.6 linux-5.7        # 重新命名原始碼目錄
> +
> +       # 從 5.6.1 更新至 5.7
> +
> +       $ cd ~/linux-5.6.1              # 進入核心原始碼目錄
> +       $ patch -p1 -R < ../patch-5.6.1 # 還原 5.6.1 修補程式
> +                                       # 原始碼目錄現在是 5.6
> +       $ patch -p1 < ../patch-5.7      # 套用新的 5.7 修補程式
> +       $ cd ..
> +       $ mv linux-5.6.1 linux-5.7      # 重新命名原始碼目錄
> +
> +
> +5.x.y 核心
> +==========
> +
> +版本號由三段數字組成的是 -stable 核心。它們包含規模較小但至關重要的修正，
> +用於解決某個 5.x 核心中發現的安全性問題或嚴重回歸。
> +
> +對於想使用最新穩定核心，又無意協助測試開發版或實驗版的使用者，建議選擇這個分支。
> +
> +若沒有 5.x.y 核心可用，則版本號最大的 5.x 核心就是目前的穩定核心。
> +
> +-stable 團隊同時提供一般修補程式及遞增修補程式。以下說明如何套用這兩類修補程式。
> +
> +一般修補程式
> +~~~~~~~~~~~~~~
> +
> +這類修補程式不是遞增修補程式。例如，5.7.3 修補程式不能套用至 5.7.2 核心原始碼，
> +而應套用至基礎 5.7 核心原始碼。
> +
> +因此，若要將 5.7.3 修補程式套用至現有的 5.7.2 核心原始碼，必須先還原 5.7.2
> +修補程式（回到基礎 5.7 核心原始碼），再套用新的 5.7.3 修補程式。
> +
> +以下是一個簡單範例::
> +
> +       $ cd ~/linux-5.7.2              # 進入核心原始碼目錄
> +       $ patch -p1 -R < ../patch-5.7.2 # 還原 5.7.2 修補程式
> +       $ patch -p1 < ../patch-5.7.3    # 套用新的 5.7.3 修補程式
> +       $ cd ..
> +       $ mv linux-5.7.2 linux-5.7.3    # 重新命名核心原始碼目錄
> +
> +遞增修補程式
> +~~~~~~~~~~~~
> +
> +遞增修補程式則不同：它們不套用於基礎 5.x 核心，而套用於前一個穩定版核心
> +（5.x.y-1）。
> +
> +以下是套用遞增修補程式的範例::
> +
> +       $ cd ~/linux-5.7.2              # 進入核心原始碼目錄
> +       $ patch -p1 < ../patch-5.7.2-3  # 套用新的 5.7.3 修補程式
> +       $ cd ..
> +       $ mv linux-5.7.2 linux-5.7.3    # 重新命名核心原始碼目錄
> +
> +
> +-rc 核心
> +========
> +
> +這些是發行候選版核心。每當 Linus 認為目前的 git 樹（git 是核心的原始碼管理工具）
> +處於相當合理且足以測試的狀態時，就會發布這樣的開發版核心。
> +
> +這些核心並不穩定；若打算執行，就要預期它們偶爾會發生問題。不過，在幾個主要開發
> +分支中，這是最穩定的一個，而且它最終會成為下一個穩定核心，所以讓盡可能多的人
> +參與測試十分重要。
> +
> +若您想協助測試開發版核心，但不想執行真正具有實驗性的內容，這個分支很合適
> +（有關真正實驗性的內容，請參閱下文介紹 -next 和 -mm 核心的章節）。
> +
> +-rc 修補程式不是遞增修補程式；與上文介紹的 5.x.y 修補程式一樣，它們套用於
> +基礎 5.x 核心。-rcN 後綴前的核心版本號，表示這個 -rc 核心最終會成為哪個版本。
> +
> +因此，5.8-rc5 表示它是 5.8 核心的第五個發行候選版，這個修補程式應套用至
> +5.7 核心原始碼。
> +
> +以下是三個套用此類修補程式的範例::
> +
> +       # 第一個範例：從 5.7 更新至 5.8-rc3
> +
> +       $ cd ~/linux-5.7                        # 進入 5.7 原始碼目錄
> +       $ patch -p1 < ../patch-5.8-rc3          # 套用 5.8-rc3 修補程式
> +       $ cd ..
> +       $ mv linux-5.7 linux-5.8-rc3            # 重新命名原始碼目錄
> +
> +       # 接著從 5.8-rc3 更新至 5.8-rc5
> +
> +       $ cd ~/linux-5.8-rc3                    # 進入 5.8-rc3 目錄
> +       $ patch -p1 -R < ../patch-5.8-rc3       # 還原 5.8-rc3 修補程式
> +       $ patch -p1 < ../patch-5.8-rc5          # 套用新的 5.8-rc5 修補程式
> +       $ cd ..
> +       $ mv linux-5.8-rc3 linux-5.8-rc5        # 重新命名原始碼目錄
> +
> +       # 最後嘗試從 5.7.3 更新至 5.8-rc5
> +
> +       $ cd ~/linux-5.7.3                      # 進入核心原始碼目錄
> +       $ patch -p1 -R < ../patch-5.7.3         # 還原 5.7.3 修補程式
> +       $ patch -p1 < ../patch-5.8-rc5          # 套用新的 5.8-rc5 修補程式
> +       $ cd ..
> +       $ mv linux-5.7.3 linux-5.8-rc5  # 重新命名原始碼目錄
> +
> +
> +-mm 修補程式與 linux-next 樹
> +==============================
> +
> +-mm 修補程式是 Andrew Morton 發布的實驗性修補程式。
> +
> +過去，-mm 樹也用於測試子系統修補程式；現在這項工作由
> +`linux-next` （https://www.kernel.org/doc/man-pages/linux-next.html）
> +樹承擔。子系統維護者先將修補程式推送至 linux-next，再於合併視窗期間直接
> +傳送給 Linus。
> +
> +-mm 修補程式是新功能和其他實驗性修補程式的試驗場，這些修補程式未透過子系統樹
> +合併。一旦這類修補程式在 -mm 中經過一段時間的驗證並證明自身價值，Andrew 就會
> +將其推送給 Linus，以納入主線。
> +
> +linux-next 樹每日更新，其中包括 -mm 修補程式。兩者始終處於變動之中，包含許多
> +實驗性功能、大量不適合主線的除錯修補程式等，是本文所述各分支中實驗性最高的。
> +
> +這些修補程式不適合用於必須保持穩定的系統，執行它們的風險高於其他任何分支
> +（務必備有最新備份；執行任何實驗性核心都應如此，執行 -mm 修補程式或 linux-next
> +樹中的核心時尤其如此）。
> +
> +我們非常歡迎大家測試 -mm 修補程式和 linux-next，因為測試的目的就是在變更併入
> +較穩定的 Linus 主線樹之前，找出並消除回歸、當機、資料損壞錯誤、建置失敗及其他
> +各類錯誤。
> +
> +不過，-mm 和 linux-next 的測試者必須明白，這些樹發生問題的頻率高於其他任何
> +核心樹。
> +
> +
> +至此，各種核心樹已經介紹完畢。希望您現在已清楚瞭解如何套用各類修補程式，
> +並能協助測試核心。
> +
> +感謝 Randy Dunlap、Rolf Eike Beer、Linus Torvalds、Bodo Eggert、
> +Johannes Stezenbach、Grant Coady、Pavel Machek，以及其他可能被我遺漏的人，
> +感謝他們對本文的審閱和貢獻。
> diff --git a/Documentation/translations/zh_TW/process/index.rst b/Documentation/translations/zh_TW/process/index.rst
> index 3f84437a2ca9..1642fcf92b26 100644
> --- a/Documentation/translations/zh_TW/process/index.rst
> +++ b/Documentation/translations/zh_TW/process/index.rst
> @@ -120,6 +120,7 @@ TODOList:
>     :maxdepth: 1
>
>     magic-number
> +   applying-patches
>
>  TODOList:
>
>
> --
> 2.55.0.717.g61afef3e37
>

Re: [PATCH 2/2] docs/zh_TW: link to Traditional Chinese applying-patches translation

[葉宸佑]

Two small things here.

1. The two files use different link styles

README.rst:89 uses a bare path, which automarkup turns into a link and
which doc-guide/sphinx.rst recommends. howto.rst:149 uses :doc: with
the full path as the display text, which is effectively doing
automarkup's job by hand.

Either is fine, but they should match. If you add the
.. _tw_applying_patches: label I suggested on 1/2, howto.rst could use
:ref: and look like the eight entries around it.

2. Unrelated whitespace changes

Both files lose a trailing blank line, which the commit message does
not mention. Best dropped, or split out if it is deliberate.

Thanks.

Chen-Yu

Re: [PATCH 1/2] docs/zh_TW: add process/applying-patches Traditional Chinese translation

[Weijie Yuan]

On Fri, Aug 21, 2026 at 11:54:02PM +0800, 葉宸佑 wrote:
> Thanks for taking this on -- and for picking a document that actually
> matters rather than an easy one. A few things below; the first three
> produce real breakage, the rest are suggestions.
> 
> ## Must fix
> 
> 1. Section levels are flattened (applying-patches.rst:12)
> 
> The English original uses ++++ for the document title (level 1) and
> ==== for each section (level 2). The translation uses ==== for both, so
> the file ends up with eleven parallel h1 headings and no document title.
> zh_TW/process/code-of-conduct.rst:12 keeps the ++++ form; the same here
> would fix it.
> 
> 2. The bold marker at :233 will not render
> 
>     **不能**套用
> 
> docutils requires the closing strong marker to be followed by
> whitespace or punctuation; a CJK character does not count. As written
> this emits "Inline strong start-string without end-string" and prints
> the asterisks literally. The existing practice in the tree is to escape
> with a backslash -- see zh_CN/doc-guide/parse-headers.rst.
> 
> I checked the other **...**, ``...`` and *...* in the file; this is the
> only instance that trips the rule (（**fuzz**） and [**y**]es are both
> fine).
> 
> 3. index.rst: wrong section, and the TODO entry is still there
> 
> The entry was added to 「其他材料」 at :123, but the English original
> lists applying-patches under tools and technical guides
> (Documentation/process/index.rst:46, after email-clients). More
> importantly, the 「* applying-patches」 TODOList item at :55 is still
> present, so the document is listed as both translated and not
> translated.
> 
> Moving it into the toctree at :46-49 after email-clients and dropping
> :55 fixes both.
> 
> 4. Please drop the :譯者: block
> 
>     +:譯者:
>     +
>     + Weijie Yuan <wy@wyuan.org>
> 
> We are in the middle of removing exactly these blocks from the zh_TW
> tree [1] -- adding a new one now would just mean removing it again.
> 
> [1] https://lore.kernel.org/linux-doc/20260819145808.291567-1-chenyou910331@gmail.com/

Sure!

Points above copied. My negligence. Will check again.

> ## Suggestions
> 
> 5. Missing .. _tw_applying_patches: label
> 
> Every other .rst under zh_TW/process/ carries a .. _tw_*: label, and
> the English original has .. _applying_patches:. Adding it would let
> 2/2 use :ref: in howto.rst, matching the eight neighbouring entries in
> that list instead of standing out as a :doc:.

This kind of top-level label is not recommended/allowed right now ;-)

> 
> 6. Comment alignment at :340
> 
> One tab puts the comment at column 40; the surrounding lines are at 48,
> and the English original uses two tabs.

Got it.

> ## Terminology
> 
> The significant decision here is patch -> 修補程式, used 98 times. I
> think the direction is right -- 修補程式 is the standard Taiwanese
> rendering -- but it needs to be handled explicitly, because the
> existing zh_TW tree has 630 instances of 補丁, including in the two
> files 2/2 touches. Right now the two terms would sit on either side of
> the same cross-reference.
> 
> Could you:
> 
>   - add patch -> 修補程式 / 补丁 to glossary.rst, and
>   - say in the commit message that this is a deliberate localisation

Yes, makes sense. I'll do both.

> Migrating the existing 630 instances is a separate question and I do
> not think it should ride along with this series; I would rather discuss
> it on its own once this lands.
> 
> A few smaller ones, measured against what the tree already uses:
> 
>   :192  指令稿      -> 腳本      (17 files use 腳本; 指令稿 is not
>                                   used in Taiwan)

Hem, I don't know and use 指令稿 either. So will check later.

>   :165  郵件用戶端  -> 郵件客戶端 (8 files, including email-clients.rst)
>   :228  回歸        -> 迴歸      (regression; 10 files use 迴歸, 4 use
>   :259                            回歸 -- 迴歸測試 is the usual form)

Copied.

>   :365
> 
> On the other side: 中繼資料, 旗標, 模糊比對, 發行候選版, 當機,
> 正規表示式 are all good Taiwanese renderings. Would you mind adding
> those to the glossary too while you are there? It would save the next
> translation from having to guess.

Yes!

> ## On the CJK/ASCII spacing
> 
> This file puts a space between CJK and Latin throughout, which is the
> opposite of what the v3 glossary currently says. That is on me: I wrote
> that entry before you raised the question, and we never actually
> settled it.
> 
> Since we both prefer spaces, changing the glossary is the right fix
> rather than asking you to strip 218 of them. Please leave this file as
> it is.
> 
> Would you send that glossary change yourself once v3 lands? You are the


> one who spotted the problem, and you are a maintainer here, so it seems
> more natural coming from you than from me correcting my own entry. What
> I had in mind:
> 
>   - new translations: a space between CJK and Latin/digits
>   - existing files: left alone, no tree-wide normalisation

I'd like to do that. If you have time, you can do it in person as well.
;-)

> The second half matters -- normalising the 2581 existing instances
> would be exactly the kind of churn Jon objected to in the MAINTAINERS
> thread.

Yes.


It's kind of weird that this series cannot be applied cleanly with
Linus' current master tip commit 50d05c7c76c9 (Merge tag
'landlock-7.3-rc3' of
git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux)

Did I did something stupid? Confused.. But I'll figure it out.

However, since adding new translations is not our current main goal, I
will put this series on the to-do list for now.

Thanks for your careful review!

Re: [PATCH 1/2] docs/zh_TW: add process/applying-patches Traditional Chinese translation

[葉宸佑]

On Thu, Sep 10, 2026 at 08:18:46PM +0800, Weijie Yuan wrote:
> > 5. Missing .. _tw_applying_patches: label
>
> This kind of top-level label is not recommended/allowed right now ;-)

You are right, and I checked: doc-guide/sphinx.rst says cross-references
between documents need no special syntax, just the path. Withdrawn --
sorry for sending you the wrong way.

Reading that section also makes my point 6 land differently. The same
text says:

  For most use cases, the former is preferred, as it is cleaner and more
  suited for people reading the source files.  If you come across a
  :doc: usage that isn't adding any value, please feel free to convert
  it to just the document path.

So the two files in 2/2 should converge on README.rst's bare-path form
rather than howto.rst's :doc:, which is the opposite of what I suggested.

> It's kind of weird that this series cannot be applied cleanly with
> Linus' current master tip commit 50d05c7c76c9
>
> Did I did something stupid? Confused..

Nothing stupid -- I hit the same thing trying to apply your series for
review. Your base includes my process/ series, which Alex picked up on
18 August but which has not reached Linus yet, so process/index.rst
differs between the two trees. It applies on Alex's docs-next.

> However, since adding new translations is not our current main goal, I
> will put this series on the to-do list for now.

Makes sense -- it will apply cleanly once Alex's pull request lands, so
there is little to do until then.

> > Would you send that glossary change yourself once v3 lands?
>
> I'd like to do that. If you have time, you can do it in person as well.
> ;-)

If possible, please make the changes while you're at it; I need to
prepare the subsequent patch series.

Thanks,
Chen-Yu

Weijie Yuan <wy@wyuan.org> 於 2026年9月10日週四 下午8:18寫道：
>
> On Fri, Aug 21, 2026 at 11:54:02PM +0800, 葉宸佑 wrote:
> > Thanks for taking this on -- and for picking a document that actually
> > matters rather than an easy one. A few things below; the first three
> > produce real breakage, the rest are suggestions.
> >
> > ## Must fix
> >
> > 1. Section levels are flattened (applying-patches.rst:12)
> >
> > The English original uses ++++ for the document title (level 1) and
> > ==== for each section (level 2). The translation uses ==== for both, so
> > the file ends up with eleven parallel h1 headings and no document title.
> > zh_TW/process/code-of-conduct.rst:12 keeps the ++++ form; the same here
> > would fix it.
> >
> > 2. The bold marker at :233 will not render
> >
> >     **不能**套用
> >
> > docutils requires the closing strong marker to be followed by
> > whitespace or punctuation; a CJK character does not count. As written
> > this emits "Inline strong start-string without end-string" and prints
> > the asterisks literally. The existing practice in the tree is to escape
> > with a backslash -- see zh_CN/doc-guide/parse-headers.rst.
> >
> > I checked the other **...**, ``...`` and *...* in the file; this is the
> > only instance that trips the rule (（**fuzz**） and [**y**]es are both
> > fine).
> >
> > 3. index.rst: wrong section, and the TODO entry is still there
> >
> > The entry was added to 「其他材料」 at :123, but the English original
> > lists applying-patches under tools and technical guides
> > (Documentation/process/index.rst:46, after email-clients). More
> > importantly, the 「* applying-patches」 TODOList item at :55 is still
> > present, so the document is listed as both translated and not
> > translated.
> >
> > Moving it into the toctree at :46-49 after email-clients and dropping
> > :55 fixes both.
> >
> > 4. Please drop the :譯者: block
> >
> >     +:譯者:
> >     +
> >     + Weijie Yuan <wy@wyuan.org>
> >
> > We are in the middle of removing exactly these blocks from the zh_TW
> > tree [1] -- adding a new one now would just mean removing it again.
> >
> > [1] https://lore.kernel.org/linux-doc/20260819145808.291567-1-chenyou910331@gmail.com/
>
> Sure!
>
> Points above copied. My negligence. Will check again.
>
> > ## Suggestions
> >
> > 5. Missing .. _tw_applying_patches: label
> >
> > Every other .rst under zh_TW/process/ carries a .. _tw_*: label, and
> > the English original has .. _applying_patches:. Adding it would let
> > 2/2 use :ref: in howto.rst, matching the eight neighbouring entries in
> > that list instead of standing out as a :doc:.
>
> This kind of top-level label is not recommended/allowed right now ;-)
>
> >
> > 6. Comment alignment at :340
> >
> > One tab puts the comment at column 40; the surrounding lines are at 48,
> > and the English original uses two tabs.
>
> Got it.
>
> > ## Terminology
> >
> > The significant decision here is patch -> 修補程式, used 98 times. I
> > think the direction is right -- 修補程式 is the standard Taiwanese
> > rendering -- but it needs to be handled explicitly, because the
> > existing zh_TW tree has 630 instances of 補丁, including in the two
> > files 2/2 touches. Right now the two terms would sit on either side of
> > the same cross-reference.
> >
> > Could you:
> >
> >   - add patch -> 修補程式 / 补丁 to glossary.rst, and
> >   - say in the commit message that this is a deliberate localisation
>
> Yes, makes sense. I'll do both.
>
> > Migrating the existing 630 instances is a separate question and I do
> > not think it should ride along with this series; I would rather discuss
> > it on its own once this lands.
> >
> > A few smaller ones, measured against what the tree already uses:
> >
> >   :192  指令稿      -> 腳本      (17 files use 腳本; 指令稿 is not
> >                                   used in Taiwan)
>
> Hem, I don't know and use 指令稿 either. So will check later.
>
> >   :165  郵件用戶端  -> 郵件客戶端 (8 files, including email-clients.rst)
> >   :228  回歸        -> 迴歸      (regression; 10 files use 迴歸, 4 use
> >   :259                            回歸 -- 迴歸測試 is the usual form)
>
> Copied.
>
> >   :365
> >
> > On the other side: 中繼資料, 旗標, 模糊比對, 發行候選版, 當機,
> > 正規表示式 are all good Taiwanese renderings. Would you mind adding
> > those to the glossary too while you are there? It would save the next
> > translation from having to guess.
>
> Yes!
>
> > ## On the CJK/ASCII spacing
> >
> > This file puts a space between CJK and Latin throughout, which is the
> > opposite of what the v3 glossary currently says. That is on me: I wrote
> > that entry before you raised the question, and we never actually
> > settled it.
> >
> > Since we both prefer spaces, changing the glossary is the right fix
> > rather than asking you to strip 218 of them. Please leave this file as
> > it is.
> >
> > Would you send that glossary change yourself once v3 lands? You are the
>
>
> > one who spotted the problem, and you are a maintainer here, so it seems
> > more natural coming from you than from me correcting my own entry. What
> > I had in mind:
> >
> >   - new translations: a space between CJK and Latin/digits
> >   - existing files: left alone, no tree-wide normalisation
>
> I'd like to do that. If you have time, you can do it in person as well.
> ;-)
>
> > The second half matters -- normalising the 2581 existing instances
> > would be exactly the kind of churn Jon objected to in the MAINTAINERS
> > thread.
>
> Yes.
>
>
> It's kind of weird that this series cannot be applied cleanly with
> Linus' current master tip commit 50d05c7c76c9 (Merge tag
> 'landlock-7.3-rc3' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux)
>
> Did I did something stupid? Confused.. But I'll figure it out.
>
> However, since adding new translations is not our current main goal, I
> will put this series on the to-do list for now.
>
> Thanks for your careful review!

Re: [PATCH 1/2] docs/zh_TW: add process/applying-patches Traditional Chinese translation

[Weijie Yuan]

On Fri, Sep 11, 2026 at 04:50:39PM +0800, 葉宸佑 wrote:
> On Thu, Sep 10, 2026 at 08:18:46PM +0800, Weijie Yuan wrote:
> > > 5. Missing .. _tw_applying_patches: label
> >
> > This kind of top-level label is not recommended/allowed right now ;-)
> 
> You are right, and I checked: doc-guide/sphinx.rst says cross-references
> between documents need no special syntax, just the path. Withdrawn --
> sorry for sending you the wrong way.
> 
> Reading that section also makes my point 6 land differently. The same
> text says:
> 
>   For most use cases, the former is preferred, as it is cleaner and more
>   suited for people reading the source files.  If you come across a
>   :doc: usage that isn't adding any value, please feel free to convert
>   it to just the document path.
> 
> So the two files in 2/2 should converge on README.rst's bare-path form
> rather than howto.rst's :doc:, which is the opposite of what I suggested.

Sure, but I didn't directly carry the concern from the CN side when
sending this series, so now paste it here now (again) for reference. :)

<20260817-apply-patches-v3-0-45e3bd2b1ccc@wyuan.org>:

--- >8 ---

The second patch updates existing zh_CN references to point to the new
translation.  In ordinary paragraphs, the absolute Documentation/...rst
path is used and is handled by automarkup.  The entry in process/howto.rst
is a definition-list term, which automarkup does not process.  It therefore
uses the named :doc: form as the minimal explicit-link exception, without
reintroducing a cn_applying_patches label and using :ref:.

RFC:

I considered the two competing preferences for cross-references. Jon
recommends using a plain absolute Documentation/...rst path, while
another view (I found the discussion in 2021, so I added your email
addresses, thanks.) is to avoid :doc: markup where automarkup can create
the link automatically.  I follow both rules where they apply: the plain
path is used in normal paragraphs.  However, this particular entry is a
definition-list term, which automarkup does not process, so the plain
path is rendered as text rather than a link.  The named :doc: form is
therefore used only for this narrow exception, without adding a
translation-specific label. (Seems to be a workaround)

I would welcome guidance on one stylistic point.  (Since I missed
previous discussions)  The surrounding entries in this definition list
use :ref:, while this new entry uses the named :doc: form because it
links to a whole document without a translation-specific label. Does
this look out of place here?  If so, I am happy to follow the preferred
cross-reference style.

--- >8 ---

And, I think this might be the best way to avoid changing the rendering
method? Although it may seem a bit ugly in terms of the writing style.

(It's been almost a month now. I might need to review my statement to
see if there are any mistakes.) Sorry ;-)

> > It's kind of weird that this series cannot be applied cleanly with
> > Linus' current master tip commit 50d05c7c76c9
> >
> > Did I did something stupid? Confused..
> 
> Nothing stupid -- I hit the same thing trying to apply your series for
> review. Your base includes my process/ series, which Alex picked up on
> 18 August but which has not reached Linus yet, so process/index.rst
> differs between the two trees. It applies on Alex's docs-next.

Oh, that makes sense. It turns out that process/index.rst has been
updated. However, I really should have double-checked instead of posting
it on the list to ask.

> > However, since adding new translations is not our current main goal, I
> > will put this series on the to-do list for now.
> 
> Makes sense -- it will apply cleanly once Alex's pull request lands, so
> there is little to do until then.

Okay.

> > > Would you send that glossary change yourself once v3 lands?
> >
> > I'd like to do that. If you have time, you can do it in person as well.
> > ;-)
> 
> If possible, please make the changes while you're at it; I need to
> prepare the subsequent patch series.

Sure! Appreciate it. ;-)

Thanks!