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@xxxxxxxxx>

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@xxxxxxxxx/

## 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@xxxxxxxxx> 於 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@xxxxxxxxx>
> ---
>  .../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@xxxxxxxxx>
> +
> +將修補程式套用至 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
>