Kubernetes 文件在地化

本頁說明如何在地化不同語言的文件。

貢獻現有的在地化

你可以協助新增或改進現有在地化的內容。在 Kubernetes Slack 中，你可以找到每個在地化的頻道。還有一個通用的 SIG Docs Localizations Slack 頻道，你可以在其中打招呼。

注意

如需如何貢獻特定在地化的額外詳細資訊，請尋找此頁面的在地化版本。

尋找你的雙字母語言代碼

首先，請查閱 ISO 639-1 標準，以尋找你的在地化的雙字母語言代碼。例如，韓文的雙字母代碼為 ko。

某些語言會使用 ISO-3166 定義的國家代碼的小寫版本及其語言代碼。例如，巴西葡萄牙語語言代碼為 pt-br。

Fork 並複製儲存庫

首先，建立你自己的 fork kubernetes/website 儲存庫。

然後，複製你的 fork 並 cd 進入其中

git clone https://github.com/<username>/website
cd website

網站內容目錄包含每個語言的子目錄。你想要協助的在地化位於 content/<雙字母代碼> 內。

建議變更

根據英文原文，建立或更新您選擇的在地化頁面。請參閱在地化內容以取得更多詳細資訊。

如果您注意到上游（英文）文件中存在技術上的不準確或其他問題，您應該先修正上游文件，然後透過更新您正在處理的在地化版本來重複相同的修正。

限制提取請求 (pull request) 中的變更為單一在地化版本。審查變更多個在地化版本的提取請求會很麻煩。

遵循建議內容改進來提出對該在地化版本的變更建議。此流程與提出對上游（英文）內容的變更建議類似。

開始新的在地化

如果您希望將 Kubernetes 文件在地化為新的語言，以下是您需要做的。

由於貢獻者不能批准自己的提取請求，因此您需要至少兩位貢獻者才能開始在地化。

所有在地化團隊都必須自給自足。Kubernetes 網站很樂意託管您的工作成果，但翻譯並保持現有在地化內容的時效性取決於您自己。

您需要知道您語言的兩個字母語言代碼。請查閱ISO 639-1 標準以尋找您在地化語言的兩個字母語言代碼。例如，韓語的兩個字母代碼是 ko。

如果您要開始在地化的語言在不同地區使用，且變體之間存在顯著差異，則將小寫的 ISO-3166 國家代碼與語言的兩個字母代碼組合可能更有意義。例如，巴西葡萄牙語在地化為 pt-br。

當您開始新的在地化時，您必須在地化所有最低限度所需內容，Kubernetes 專案才能將您的變更發佈到即時網站。

SIG Docs 可以協助您在個別分支上工作，以便您可以逐步朝該目標邁進。

尋找社群

讓 Kubernetes SIG Docs 知道您有興趣建立在地化版本！加入 SIG Docs Slack 頻道和 SIG Docs Localizations Slack 頻道。其他在地化團隊很樂意協助您入門並回答您的問題。

也請考慮參與 SIG Docs Localization Subgroup 會議。SIG Docs 在地化子群組的任務是跨 SIG Docs 在地化團隊合作，共同定義和記錄建立在地化貢獻指南的流程。此外，SIG Docs 在地化子群組尋找機會來建立和分享跨在地化團隊的通用工具，並識別 SIG Docs 領導團隊的新需求。如果您對此會議有疑問，請在 SIG Docs Localizations Slack 頻道中詢問。

您也可以在 kubernetes/community 儲存庫中為您的在地化版本建立 Slack 頻道。如需新增 Slack 頻道的範例，請參閱為波斯語新增頻道的 PR。

加入 Kubernetes GitHub 組織

當您開啟在地化 PR 後，您可以成為 Kubernetes GitHub 組織的成員。團隊中的每個人都需要在 kubernetes/org 儲存庫中建立自己的組織成員資格請求。

在 GitHub 中新增您的在地化團隊

接下來，將您的 Kubernetes 在地化團隊新增至 sig-docs/teams.yaml。如需新增在地化團隊的範例，請參閱新增西班牙語在地化團隊的 PR。

@kubernetes/sig-docs-**-owners 的成員可以批准變更您的在地化目錄內（且僅限於其內）內容的 PR：/content/**/。對於每個在地化版本，@kubernetes/sig-docs-**-reviews 團隊會自動執行新 PR 的審查分配。@kubernetes/website-maintainers 的成員可以建立新的在地化分支，以協調翻譯工作。@kubernetes/website-milestone-maintainers 的成員可以使用 /milestone Prow 指令來為議題或 PR 指派里程碑。

設定工作流程

接下來，在 kubernetes/test-infra 儲存庫中為您的在地化版本新增 GitHub 標籤。標籤可讓您篩選特定語言的議題和提取請求。

如需新增標籤的範例，請參閱新增義大利語標籤的 PR。

修改網站設定

Kubernetes 網站使用 Hugo 作為其網站框架。網站的 Hugo 設定位於 hugo.toml 檔案中。您需要修改 hugo.toml 以支援新的在地化版本。

在現有的 [languages] 區塊下，為新語言將設定區塊新增至 hugo.toml。例如，德語區塊看起來像這樣

[languages.de]
title = "Kubernetes"
description = "Produktionsreife Container-Verwaltung"
languageName = "Deutsch (German)"
languageNameLatinScript = "Deutsch"
contentDir = "content/de"
weight = 8

語言選擇列會列出 languageName 的值。將「母語腳本和語言的語言名稱（拉丁文字母的英文語言名稱）」指派給 languageName。例如，languageName = "한국어 (Korean)" 或 languageName = "Deutsch (German)"。

languageNameLatinScript 可用於存取拉丁文字母的語言名稱，並在佈景主題中使用。將「拉丁文字母的語言名稱」指派給 languageNameLatinScript。例如，languageNameLatinScript ="Korean" 或 languageNameLatinScript = "Deutsch"。

weight 參數決定語言在語言選擇列中的順序。較低的權重優先，導致語言首先出現。在指派 weight 參數時，檢查現有的語言區塊並調整其權重非常重要，以確保它們相對於所有語言（包括任何新加入的語言）都以排序順序排列。

有關 Hugo 多語言支援的更多資訊，請參閱「多語言模式」。

新增新的在地化目錄

將特定語言的子目錄新增至儲存庫中的 content 資料夾。例如，德語的兩個字母代碼是 de

mkdir content/de

您還需要在 data/i18n 內建立一個目錄，用於在地化字串；請查看現有的在地化版本作為範例。若要使用這些新字串，您還必須建立從 i18n/<localization>.toml 到 data/i18n/<localization>/<localization>.toml 中實際字串設定的符號連結（記得提交符號連結）。

例如，對於德語，字串位於 data/i18n/de/de.toml 中，而 i18n/de.toml 是 data/i18n/de/de.toml 的符號連結。

在地化社群行為準則

針對 cncf/foundation 儲存庫開啟 PR，以新增您語言的行為準則。

設定 OWNERS 檔案

若要設定每位貢獻於在地化版本的使用者的角色，請在特定語言的子目錄內建立一個 OWNERS 檔案，其中包含

reviewers：具有審查者角色的 Kubernetes 團隊清單，在本例中為
在在 GitHub 中新增您的在地化團隊中建立的 sig-docs-**-reviews 團隊。
approvers：具有批准者角色的 Kubernetes 團隊清單，在本例中為
在在 GitHub 中新增您的在地化團隊中建立的 sig-docs-**-owners 團隊。
labels：要自動套用至 PR 的 GitHub 標籤清單，在本例中為在設定工作流程中建立的語言標籤。

有關 OWNERS 檔案的更多資訊，請參閱 go.k8s.io/owners。

具有語言代碼 es 的西班牙語 OWNERS 檔案看起來像這樣

# See the OWNERS docs at https://go.k8s.io/owners

# This is the localization project for Spanish.
# Teams and members are visible at https://github.com/orgs/kubernetes/teams.

reviewers:
- sig-docs-es-reviews

approvers:
- sig-docs-es-owners

labels:
- language/es

在新增特定語言的 OWNERS 檔案後，使用新的 Kubernetes 在地化團隊 sig-docs-**-owners 和 sig-docs-**-reviews 更新根目錄 OWNERS_ALIASES 檔案。

對於每個團隊，新增在在 GitHub 中新增您的在地化團隊中請求的 GitHub 使用者清單，並依字母順序排列。

--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -48,6 +48,14 @@ aliases:
     - stewart-yu
     - xiangpengzhao
     - zhangxiaoyu-zidif
+  sig-docs-es-owners: # Admins for Spanish content
+    - alexbrand
+    - raelga
+  sig-docs-es-reviews: # PR reviews for Spanish content
+    - alexbrand
+    - electrocucaracha
+    - glo-pena
+    - raelga
   sig-docs-fr-owners: # Admins for French content
     - perriea
     - remyleone

開啟提取請求

接下來，開啟提取請求 (PR) 以將在地化版本新增至 kubernetes/website 儲存庫。PR 必須包含所有最低限度所需內容才能獲得批准。

如需新增新的在地化版本的範例，請參閱啟用法語文件的 PR。

新增在地化的 README 檔案

為了引導其他在地化貢獻者，請在 kubernetes/website 的頂層新增一個新的 README-**.md，其中 ** 是兩個字母的語言代碼。例如，德語 README 檔案將是 README-de.md。

在在地化的 README-**.md 檔案中引導在地化貢獻者。包含與 README.md 中相同的資訊，以及

在地化專案的聯絡人
任何特定於在地化版本的資訊

在您建立在地化的 README 後，從主要的英文 README.md 新增指向該檔案的連結，並以英文包含聯絡資訊。您可以提供 GitHub ID、電子郵件地址、Slack 頻道或其他聯絡方式。您還必須提供指向您在地化的社群行為準則的連結。

啟動您的新在地化版本

當在地化版本符合工作流程和最低輸出要求時，SIG Docs 會執行以下操作

在網站上啟用語言選擇。
透過 Cloud Native Computing Foundation (CNCF) 管道（包括 Kubernetes 部落格）公開在地化版本的可用性。

在地化內容

在地化所有 Kubernetes 文件是一項龐大的任務。從小處著手並隨著時間推移擴展是可以的。

最低限度所需內容

至少，所有在地化版本都必須包含

描述	網址
首頁	所有標題和副標題網址
設定	所有標題和副標題網址
教學課程	Kubernetes 基礎知識、Hello Minikube
網站字串	新的在地化 TOML 檔案中的所有網站字串
發行版本	所有標題和副標題網址

翻譯的文件必須位於其自己的 content/**/ 子目錄中，但在其他方面，應遵循與英文來源相同的網址路徑。例如，若要準備 Kubernetes 基礎知識教學課程以翻譯成德語，請在 content/de/ 目錄下建立一個子目錄，並複製英文來源或目錄

mkdir -p content/de/docs/tutorials
cp -ra content/en/docs/tutorials/kubernetes-basics/ content/de/docs/tutorials/

翻譯工具可以加速翻譯過程。例如，某些編輯器提供外掛程式來快速翻譯文字。

注意

機器產生的翻譯本身是不夠的。在地化需要廣泛的人工審查才能達到最低品質標準。

為了確保文法和意義的準確性，您的在地化團隊成員應在發佈前仔細審查所有機器產生的翻譯。

在地化 SVG 圖片

Kubernetes 專案建議盡可能使用向量 (SVG) 圖片，因為這些圖片對於在地化團隊來說更容易編輯。如果您發現需要在地化的點陣圖，請考慮先將英文版本重新繪製為向量圖，然後在地化該向量圖。

翻譯 SVG (可縮放向量圖形) 圖片中的文字時，務必遵循某些準則，以確保跨不同語言版本的準確性和一致性。SVG 圖片通常用於 Kubernetes 文件中，以說明概念、工作流程和圖表。

識別可翻譯的文字：首先識別 SVG 圖片中需要翻譯的文字元素。這些元素通常包括標籤、標題、註釋或任何傳達資訊的文字。
編輯 SVG 檔案：SVG 檔案是以 XML 為基礎的，這表示可以使用文字編輯器進行編輯。但是，請務必注意，Kubernetes 中的大多數文件圖片已經將文字轉換為曲線，以避免字型相容性問題。在這種情況下，建議使用專門的 SVG 編輯軟體（例如 Inkscape）進行編輯，開啟 SVG 檔案並找到需要翻譯的文字元素。
翻譯文字：將原始文字替換為所需語言的翻譯版本。確保翻譯後的文字準確傳達預期的含義，並符合圖片中的可用空間。在使用拉丁字母的語言時，應使用 Open Sans 字型系列。您可以從此處下載 Open Sans 字型：Open Sans Typeface。
將文字轉換為曲線：如前所述，為了解決字型相容性問題，建議將翻譯後的文字轉換為曲線或路徑。將文字轉換為曲線可確保最終圖片正確顯示翻譯後的文字，即使使用者的系統沒有原始 SVG 中使用的確切字型。
審查和測試：在進行必要的翻譯並將文字轉換為曲線後，儲存並審查更新後的 SVG 圖片，以確保文字正確顯示和對齊。檢查在本機預覽您的變更。

來源檔案

在地化版本必須以在地化團隊針對的特定發行版本的英文檔案為基礎。每個在地化團隊都可以決定要針對哪個發行版本，以下稱為目標版本。

尋找目標版本的來源檔案

導覽至 Kubernetes 網站儲存庫：https://github.com/kubernetes/website。
從下表中選取目標版本的分支

目標版本	分支
最新版本	`main`
先前版本	`release-1.31`
下一個版本	`dev-1.33`

main 分支包含目前發行版本 v1.32 的內容。發行團隊會在下一個發行版本 v1.33 之前建立 release-1.32 分支。

i18n 中的網站字串

在地化版本必須包含 data/i18n/en/en.toml 的內容在新的特定語言檔案中。以德語為例：data/i18n/de/de.toml。

將新的在地化目錄和檔案新增至 data/i18n/。例如，使用德語 (de)

mkdir -p data/i18n/de
cp data/i18n/en/en.toml data/i18n/de/de.toml

修改檔案頂部的註解以適合您的在地化版本，然後翻譯每個字串的值。例如，這是搜尋表單的德語預留位置文字

[ui_search_placeholder]
other = "Suchen"

在地化網站字串可讓您自訂全網站的文字和功能：例如，每頁頁尾的法律著作權文字。

特定語言的在地化指南

作為在地化團隊，您可以透過建立特定語言的在地化指南來正式化您的團隊遵循的最佳實務。

例如，請參閱韓語在地化指南，其中包含以下主題的內容

衝刺節奏和發行版本
分支策略
提取請求工作流程
樣式指南
在地化和非在地化術語詞彙表
Markdown 慣例
Kubernetes API 物件術語

特定語言的 Zoom 會議

如果在地化專案需要單獨的會議時間，請聯絡 SIG Docs 聯合主席或技術主管以建立新的定期 Zoom 會議和行事曆邀請。只有當團隊規模夠大，需要單獨的會議時，才需要這樣做。

根據 CNCF 政策，在地化團隊必須將其會議上傳到 SIG Docs YouTube 播放清單。SIG Docs 聯合主席或技術主管可以在 SIG Docs 自動化此流程之前協助處理。

分支策略

由於在地化專案是高度協作的努力，我們鼓勵團隊在共用的在地化分支中工作 - 尤其是在剛開始且在地化版本尚未上線時。

協作在地化分支

@kubernetes/website-maintainers 的團隊成員從 https://github.com/kubernetes/website 上的來源分支開啟在地化分支。
當您將在地化團隊新增至 kubernetes/org 儲存庫時，您的團隊批准者加入了 @kubernetes/website-maintainers 團隊。
我們建議以下分支命名方案
dev-<來源版本>-<語言代碼>.<團隊里程碑>
例如，德語在地化團隊的批准者直接針對 kubernetes/website 儲存庫，根據 Kubernetes v1.12 的來源分支開啟在地化分支 dev-1.12-de.1。
個別貢獻者根據在地化分支開啟功能分支。
例如，德語貢獻者從 username:local-branch-name 開啟一個提取請求，其中包含對 kubernetes:dev-1.12-de.1 的變更。
批准者審查功能分支並將其合併到在地化分支中。
批准者定期透過開啟和批准新的提取請求，將在地化分支與其來源分支合併。在批准提取請求之前，請務必壓縮提交。

根據需要重複步驟 1-4，直到在地化完成。例如，後續的德語在地化分支將是：dev-1.12-de.2、dev-1.12-de.3 等。

團隊必須將在地化內容合併到內容來源的同一個分支中。例如

從 main 來源的在地化分支必須合併到 main 中。
從 release-1.31 來源的在地化分支必須合併到 release-1.31 中。

注意

如果您的在地化分支是從 main 分支建立的，但未在新發行分支 release-1.32 建立之前合併到 main 中，則將其合併到 main 和新發行分支 release-1.32 中。若要將您的在地化分支合併到新的發行分支 release-1.32 中，您需要將您的在地化分支的上游分支切換到 release-1.32。

在每個團隊里程碑的開始，開啟一個議題以比較先前在地化分支和目前在地化分支之間的上游變更會很有幫助。有兩個腳本用於比較上游變更。

upstream_changes.py 用於檢查對特定檔案所做的變更非常有用。而
diff_l10n_branches.py 用於為特定的在地化分支建立過時檔案清單非常有用。

雖然只有批准者可以開啟新的在地化分支和合併提取請求，但任何人都可以為新的在地化分支開啟提取請求。不需要特殊權限。

有關從 fork 或直接從儲存庫工作的更多資訊，請參閱「fork 和複製儲存庫」。

上游貢獻

SIG Docs 歡迎對英文來源的上游貢獻和更正。

上次修改時間：2024 年 4 月 17 日下午 4:48 PST：Update content/en/docs/contribute/localization.md (18f0cce616)