本地化 Kubernetes 文件

本頁面介紹如何本地化文件以適應不同的語言。

為現有本地化貢獻內容

您可以幫助新增或改進現有本地化內容。在Kubernetes Slack中,您可以找到每個本地化的頻道。還有一個通用的SIG Docs 本地化 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/<兩位字母程式碼> 目錄下。

建議更改

根據英文原文建立或更新您選擇的本地化頁面。有關更多詳細資訊,請參閱本地化內容

如果您注意到上游(英文)文件存在技術不準確或其他問題,應先修復上游文件,然後透過更新您正在進行的本地化來重複進行等效的修復。

將一個拉取請求中的更改限制在單個本地化。審查更改多個本地化內容的拉取請求是存在問題的。

請遵循建議內容改進來提出對該本地化的更改。此過程與對上游(英文)內容提出更改類似。

開始新的本地化

如果您希望將 Kubernetes 文件本地化為一種新語言,您需要執行以下操作。

由於貢獻者無法批准自己的拉取請求,因此您需要至少兩名貢獻者才能開始一項本地化工作。

所有本地化團隊都必須自給自足。Kubernetes 網站很樂意託管您的工作,但翻譯和保持現有本地化內容最新則取決於您。

您需要了解您語言的兩位字母語言程式碼。查閱ISO 639-1 標準以查詢您本地化的兩位字母語言程式碼。例如,韓語的兩字母程式碼是 ko

如果您要開始本地化的語言在不同地區有顯著差異,那麼將 ISO-3166 國家程式碼的小寫版本與兩位字母語言程式碼結合使用可能更合適。例如,巴西葡萄牙語的本地化程式碼是 pt-br

當您開始一項新的本地化時,必須本地化所有最低要求的內容,然後 Kubernetes 專案才能將您的更改釋出到即時網站。

SIG Docs 可以幫助您在一個單獨的分支上工作,以便您能夠逐步實現此目標。

尋找社群

讓 Kubernetes SIG Docs 知道您對建立本地化感興趣!加入SIG Docs Slack 頻道SIG Docs 本地化 Slack 頻道。其他本地化團隊很樂意幫助您入門並回答您的問題。

另請考慮參加SIG Docs 本地化子組會議。SIG Docs 本地化子組的使命是與 SIG Docs 各本地化團隊合作,共同定義和記錄建立本地化貢獻指南的流程。此外,SIG Docs 本地化子組還尋求機會跨本地化團隊建立和共享通用工具,並識別 SIG Docs 領導團隊的新需求。如果您對本次會議有任何疑問,請在SIG Docs 本地化 Slack 頻道諮詢。

您還可以在 kubernetes/community 倉庫中為您的本地化建立一個 Slack 頻道。有關新增 Slack 頻道的示例,請參閱新增波斯語頻道的 PR。

加入 Kubernetes GitHub 組織

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

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

接下來,將您的 Kubernetes 本地化團隊新增到sig-docs/teams.yaml。有關新增本地化團隊的示例,請參閱新增西班牙語本地化團隊的 PR。

@kubernetes/sig-docs-**-owners 的成員可以批准更改您的本地化目錄(/content/**/)中內容的 PR。對於每個本地化,@kubernetes/sig-docs-**-reviews 團隊會自動分配新 PR 的評審員。@kubernetes/website-maintainers 的成員可以建立新的本地化分支來協調翻譯工作。@kubernetes/website-milestone-maintainers 的成員可以使用Prow 命令 /milestone 為問題或 PR 分配里程碑。

配置工作流

接下來,在 kubernetes/test-infra 倉庫中為您的本地化新增一個 GitHub 標籤。標籤可讓您按語言過濾問題和拉取請求。

有關新增標籤的示例,請參閱新增義大利語標籤的 PR。

修改站點配置

Kubernetes 網站使用 Hugo 作為其 Web 框架。網站的 Hugo 配置位於hugo.toml 檔案中。您需要修改 hugo.toml 來支援新的本地化。

在現有的 [languages] 塊下,為 hugo.toml 中的新語言新增一個配置塊。例如,德語塊如下所示:

[languages.de]
title = "Kubernetes"
languageName = "Deutsch (German)"
weight = 5
contentDir = "content/de"
languagedirection = "ltr"

[languages.de.params]
time_format_blog = "02.01.2006"
language_alternatives = ["en"]
description = "Produktionsreife Container-Orchestrierung"
languageNameLatinScript = "Deutsch"

語言選擇欄列出了 languageName 的值。為 languageName 分配“本地語言(拉丁字母表示的英文名稱)”。例如,languageName = "한국어 (Korean)"languageName = "Deutsch (German)"

languageNameLatinScript 可用於訪問拉丁字母語言名稱並在主題中使用。為 languageNameLatinScript 分配“拉丁字母語言名稱”。例如,languageNameLatinScript ="Korean"languageNameLatinScript = "Deutsch"

weight 引數決定了語言選擇欄中語言的順序。較低的權重具有優先權,導致語言先出現。分配 weight 引數時,重要的是檢查現有的語言塊並調整它們的權重,以確保它們相對於所有語言(包括任何新新增的語言)都已排序。

有關 Hugo 多語言支援的更多資訊,請參閱“多語言模式”。

新增新的本地化目錄

在倉庫的 content 資料夾中新增一個特定於語言的子目錄。例如,德語的兩字母程式碼是 de

mkdir content/de

您還需要在 i18n 中為本地化字串建立一個目錄;請參考現有本地化示例。

例如,對於德語,字串位於 i18n/de.toml

本地化社群行為準則

針對 cncf/foundation 倉庫開啟一個 PR,以新增您語言的行為準則。

設定 OWNERS 檔案

要設定每個貢獻者在本地化中的角色,請在特定語言子目錄中建立一個 OWNERS 檔案,其中包含:

有關 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:
- area/localization
- language/es

新增特定語言的 OWNERS 檔案後,使用新的 Kubernetes 團隊 sig-docs-**-ownerssig-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 將執行以下操作:

本地化內容

本地化所有 Kubernetes 文件是一項巨大的任務。從小處著手,隨著時間的推移逐步擴充套件是可以的。

最低要求內容

最低限度,所有本地化必須包括:

描述URL
主頁所有標題和副標題 URL
設定所有標題和副標題 URL
教程Kubernetes 基礎知識, Hello Minikube
站點字串新本地化 TOML 檔案中的所有站點字串
釋出所有標題和副標題 URL

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

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

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

為確保語法和含義的準確性,您的本地化團隊成員在釋出前應仔細審查所有機器生成的翻譯。

本地化 SVG 影像

Kubernetes 專案建議儘可能使用向量(SVG)影像,因為這些影像對本地化團隊來說更容易編輯。如果您發現一個需要本地化的柵格影像,請首先考慮將其英文版本重繪為向量影像,然後對其進行本地化。

在翻譯 SVG(可縮放向量圖形)影像中的文字時,遵循某些準則至關重要,以確保準確性並在不同語言版本之間保持一致性。SVG 影像通常用於 Kubernetes 文件中,以說明概念、工作流和圖表。

  1. 識別可翻譯文字:首先識別 SVG 影像中需要翻譯的文字元素。這些元素通常包括標籤、說明、註釋或任何傳達資訊的文字。

  2. 編輯 SVG 檔案:SVG 檔案是基於 XML 的,這意味著它們可以使用文字編輯器進行編輯。但是,需要注意的是,Kubernetes 中的大多數文件影像已經將文字轉換為曲線,以避免字型相容性問題。在這種情況下,建議使用專門的 SVG 編輯軟體(如 Inkscape)進行編輯,開啟 SVG 檔案並找到需要翻譯的文字元素。

  3. 翻譯文字:用目標語言的翻譯版本替換原始文字。確保翻譯後的文字準確傳達了預期含義,並且適合影像中的可用空間。在處理使用拉丁字母的語言時,應使用 Open Sans 字體系列。您可以在此處下載 Open Sans 字型:Open Sans 字型

  4. 將文字轉換為曲線:如前所述,為了解決字型相容性問題,建議將翻譯後的文字轉換為曲線或路徑。將文字轉換為曲線可確保最終影像正確顯示翻譯後的文字,即使使用者的系統沒有使用原始 SVG 中的字型。

  5. 審查和測試:在進行必要的翻譯並將文字轉換為曲線後,儲存並審查更新後的 SVG 影像,以確保文字正確顯示和對齊。請檢查本地預覽您的更改

原始檔

本地化必須基於本地化團隊所針對的特定版本的英文檔案。每個本地化團隊都可以決定要定位哪個版本,以下稱為*目標版本*。

查詢目標版本的原始檔

  1. 導航到 Kubernetes 網站倉庫:https://github.com/kubernetes/website

  2. 從下表選擇您的目標版本的分支

目標版本分支
最新版本main
上一個版本release-1.33
下一個版本dev-1.35

main 分支包含當前版本 v1.34 的內容。釋出團隊在下一個版本 v1.35 之前建立一個 release-1.34 分支。

i18n 中的站點字串

本地化必須包含 i18n/en/en.toml 的內容到一個新的特定語言檔案中。以德語為例:i18n/de.toml

i18n/ 新增一個新的特定語言目錄和檔案。例如,對於德語(de

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

修改檔案頂部的註釋以適合您的本地化,然後翻譯每個字串的值。例如,這是搜尋表單的德語佔位符文字:

[ui_search]
other = "Suchen"

本地化站點字串允許您自定義網站範圍內的文字和功能:例如,每頁頁尾的法律版權文字。

特定語言的本地化指南

作為本地化團隊,您可以建立特定語言的本地化指南來正式化您的團隊遵循的最佳實踐。

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

  • 衝刺週期和釋出
  • 分支策略
  • 拉取請求工作流
  • 樣式指南
  • 本地化和非本地化術語詞彙表
  • Markdown 約定
  • Kubernetes API 物件術語

特定語言的 Zoom 會議

如果本地化專案需要單獨的會議時間,請聯絡 SIG Docs 的聯合主席或技術負責人,以建立一個新的定期 Zoom 會議和日曆邀請。僅當團隊規模足夠大,能夠維持並需要單獨會議時才需要這樣做。

根據 CNCF 的政策,本地化團隊必須將他們的會議上傳到 SIG Docs YouTube 播放列表。SIG Docs 的聯合主席或技術負責人可以在自動化之前協助此過程。

分支策略

由於本地化專案是高度協作的努力,我們鼓勵團隊使用共享的本地化分支工作——尤其是在開始階段且本地化尚未上線時。

要協作本地化分支

  1. 來自@kubernetes/website-maintainers 的團隊成員從 https://github.com/kubernetes/website 上的源分支開啟一個本地化分支。

    您的團隊批准者在您將新增您的本地化團隊kubernetes/org 倉庫時,已加入 @kubernetes/website-maintainers 團隊。

    我們推薦以下分支命名方案:

    dev-<源版本>-<語言程式碼>.<團隊里程碑>

    例如,德語本地化團隊的一名批准者直接針對 kubernetes/website 倉庫開啟本地化分支 dev-1.12-de.1,該分支基於 Kubernetes v1.12 的源分支。

  2. 個人貢獻者基於本地化分支開啟功能分支。

    例如,一名德語貢獻者從 username:local-branch-name 開啟一個包含對 kubernetes:dev-1.12-de.1 更改的拉取請求。

  3. 批准者審查併合並功能分支到本地化分支。

  4. 定期,一名批准者會透過開啟和批准一個新的拉取請求,將本地化分支與其源分支合併。請確保在批准拉取請求之前壓縮提交。

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

團隊必須將本地化內容合併到從中獲取內容的同一分支。例如:

  • main 分支建立的本地化分支必須合併到 main
  • release-1.33 分支建立的本地化分支必須合併到 release-1.33

在每個團隊里程碑開始時,最好開啟一個問題,比較上一個本地化分支和當前本地化分支之間的上游更改。有兩個指令碼可用於比較上游更改。

雖然只有批准者可以開啟新的本地化分支和合並拉取請求,但任何人都可以為新的本地化分支開啟拉取請求。不需要特殊許可權。

有關從 fork 工作或直接從倉庫工作的更多資訊,請參閱“Fork 並克隆倉庫”

上游貢獻

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