將內容本地化為給定的語言區域
一項將內容本地化為給定語言區域的技能。
運作方式
此技能會接收輸入的內容以及一份目標語言區域清單，接著將內容翻譯成每個指定的語言區域，並提供各語言區域的本地化版本。
內容結構
.
└── docs/ ← 工作坊內容（來源 + 語言區域輸出）
├── README.md ← 登陸頁面（來源；slug: index）
├── <category>/ ← 英文工作坊分類
│ ├── README.md ← 分類登陸頁面（來源；slug: <category>）
│ └── <workshop>/
│ ├── README.md ← 工作坊登陸頁面（來源；slug: <category>/<workshop>）
│ └── *.md
├── _images/ ← 共享資源（不進行本地化）
└── <locale>/ ← 本地化輸出，為 docs/ 的直接子目錄
├── README.md ← 語言區域登陸頁面（slug: <locale>）
└── <category>/
├── README.md ← 本地化的分類登陸頁面（slug: <locale>/<category>）
└── <workshop>/
├── README.md ← 本地化的工作坊登陸頁面（slug: <locale>/<category>/<workshop>）
└── *.md
輸入內容
以下是在本地化範圍內的內容：
docs/及其子目錄下的所有英文 Markdown 檔案 — 網站登陸頁面（docs/README.md）、分類登陸頁面以及工作坊課程（docs/<category>/<workshop>/**/*.md）。
不要將 _images/（共享資源）或任何已設定的語言區域根目錄視為來源輸入。
已存在於 docs/<locale>/ 下的檔案是輸出結果，而非輸入內容——永遠不要將已設定的語言區域根目錄視為需要再次本地化的來源內容。
目標語言區域
目標語言區域定義在此技能的 rules 目錄中，以 Markdown 檔案形式存在（例如 rules/ko-kr.md）。要確定需要處理哪些語言區域，請列出 rules/ 中的檔案：每個 <locale>.md 檔案都對應一個支援的目標語言區域。 每個語言區域都有一組自己的翻譯規則與指南，以確保本地化內容適合目標受眾。
語言區域識別碼使用小寫字母與連字號（例如 ko-kr）。這是此技能中規則檔案名稱與輸出目錄的標準大小寫格式；請保持一致性。
輸出內容
所有本地化的工作坊內容都直接存放在儲存庫根目錄的 docs/ 內容目錄下，每個語言區域都有自己的子目錄。例如，韓文內容存放在 docs/ko-kr/ 中。
語言區域目錄必須是 docs/ 的直接子目錄，以便 Starlight（在 website/astro.config.mjs 中設定）能夠識別它們並顯示語言選擇器。請勿添加中間的 localizations/ 目錄。
本地化流程
本地化有三種情況。要判斷適用哪種情況，請比較來源目錄樹與現有的 docs/<locale>/ 目錄樹，並使用來源檔案的 git 歷史來偵測變更：
- 原始檔案存在，但該語言區域沒有本地化版本： 建立一個新的本地化文件。
- 原始檔案與本地化版本皆存在： 將來源目錄樹與
docs/<locale>/進行比較，然後在來源檔案上執行git diff（或git log）以找出自上次產生本地化版本以來的變更。僅更新本地化文件中受影響的部分；請勿不必要地重新翻譯未變更的章節。 - 本地化版本存在，但原始檔案已被刪除： 刪除孤立無援的本地化文件（並清除現在為空的語言區域子目錄）。
此流程分兩輪執行。首先，分析內容以識別關鍵短語與上下文。接著，translator（翻譯者）代理程式執行初步本地化，然後由 evaluator（評估者）代理程式進行審查與優化，以確保品質與一致性。
translator與evaluator「代理程式」是角色／人物形象，而非外部工具。如果沒有專門的子代理程式可用，請將其視為連續的角色來執行：首先採用翻譯者角色來產出草稿，然後採用評估者角色來針對該語言區域的規則審查並優化草稿。重複優化循環，直到滿足評估者的標準為止。
Markdown 與格式保留
無論語言區域為何，以下內容必須精確保留且不要翻譯：
- YAML frontmatter 的鍵（僅在適當情況下翻譯值，例如
title）。例外情況——登陸頁面（README.md）上的slug鍵： 網站透過其slug路由每個資料夾的登陸頁面，因此本地化的登陸頁面必須攜帶帶語言區域前綴的 slug，而非使用英文 slug。請重新編寫它：語言區域根目錄（docs/<locale>/README.md）使用slug: <locale>，本地化的分類登陸頁面使用slug: <locale>/<category>，而本地化的工作坊登陸頁面則使用slug: <locale>/<category>/<workshop>。切勿將英文登陸頁面的 slug 逐字複製到本地化檔案中，因為這會與英文路由發生衝突。 - 圍欄式與行內程式碼，包括變數、函式與指令名稱。
- URL 與外部連結目標。
- HTML 標籤、Markdown 結構、表格與警示標記。
請翻譯人類語言的文章部分，包括程式碼區塊內具有說明性的註解（根據語言區域規則而定）。保持標題順序與文件結構穩定。
標題錨點會跟隨本地化後的文字。 當標題被翻譯時，其自動產生的錨點／slug 也會隨之改變——這是預期的行為。要求是同文件內的錨點連結必須保持可解析：每當你翻譯一個標題時，請更新所有指向該標題的頁面內連結（](#...)）為本地化後標題的新 slug。一旦標題被翻譯，請不要留下指向原始英文 slug 的連結，也不要保留一個與其標題不符的英文錨點。指向非本地化檔案（或外部 URL）的錨點則保留其原始目標。
圖片與資源路徑指向原始資源，除非存在本地化的資源。 由於本地化檔案位於 docs/<locale>/ 下，請視需要重新編寫相對於來源的路徑，使其仍能解析到共享資源（例如，位於 docs/<locale>/real-world-development/app/2-foo.md 的課程使用 ../../../_images/x.png 來指向 docs/_images/）。僅在對應的翻譯圖片確實存在於語言區域目錄樹下時，才指向本地化的資源。無論哪種方式，連結都必須解析到一個真實的檔案。
翻譯者代理程式
使用 translator 代理程式來執行本地化。它應遵循 rules 目錄中為每個目標語言區域文件定義的規則與指南。
評估者代理程式
使用 evaluator 代理程式來評估本地化內容的品質。評估者會根據 rules 目錄中為目標語言區域定義的規則與指南，檢查準確性、文化相關性與整體品質。
評估者會根據該語言區域的評估者評分標準（定義在語言區域的 rules/<locale>.md 中）對本地化文件進行評分。該評分標準使用兩個層級：Tier A 硬性失敗標準，必須獲得 5 分；以及 Tier B 分級標準（1–5 分），必須獲得 4 或 5 分。只有當每個適用的 Tier A 標準都獲得 5 分且每個適用的 Tier B 標準都獲得 ≥ 4 分時，文件才算通過。如果任何項目未達標，請將文件連同具體說明退回給翻譯者，並重新執行翻譯 → 評估循環，直到通過為止；若超出評分標準規定的迭代次數上限，則升級給人工處理。
注意事項
- 務必僅針對
rules目錄中定義的目標語言區域執行本地化（每個支援的語言區域一個<locale>.md）。請勿本地化到不支援的語言區域。 - 務必精確保留 Markdown 結構、程式碼、外部連結／URL 目標以及 frontmatter 的鍵（參閱 Markdown 與格式保留）。
- 務必讓標題錨點跟隨本地化後的標題文字，並更新同文件內的錨點連結以匹配新的 slug，使其保持可解析（參閱 Markdown 與格式保留）。
- 務必將圖片與資源路徑指向原始資源（視需要重新編寫相對於
docs/<locale>/的相對路徑，使其能正確解析），除非存在對應的本地化資源（參閱 Markdown 與格式保留）。 - 務必在
docs/<locale>/下鏡像來源目錄的佈局。 - 請勿將已設定的語言區域根目錄視為來源輸入。
- 請勿重新排序或重組內容；保持標題及其順序穩定。
- 請勿翻譯程式碼、指令或識別碼；僅翻譯說明性文章與程式碼註解。