This page shows you how to localize the docs for a different language.
Because contributors can’t approve their own pull requests, you need at least two contributors to begin a localization.
All localization teams must be self-sustaining with their own resources. We’re happy to host your work, but we can’t translate it for you.
First, consult the ISO 639-1 standard to find your localization’s two-letter country code. For example, the two-letter code for Korean is
Then, clone your fork and
cd into it:
git clone https://github.com/<username>/website cd website
Next, open a pull request (PR) to add a localization to the
The PR must include all of the minimum required content before it can be approved.
For an example of adding a new localization, see the PR to enable docs in French.
Once you’ve opened a localization PR, you can become members of the Kubernetes GitHub organization. Each person on the team needs to create their own Organization Membership Request in the
sig-docs-**-owners can approve PRs that change content within (and only within) your localization directory:
sig-docs-**-reviews team automates review assignment for new PRs.
sig-docs-l10n-admins can create new development branches to coordinate translation efforts.
website-milestone-maintainers can use the
/milestone Prow command to assign a milestone to issues or PRs.
Next, add a GitHub label for your localization in the
kubernetes/test-infra repository. A label lets you filter issues and pull requests for your specific language.
For an example of adding a label, see the PR for adding the Italian language label.
Let Kubernetes SIG Docs know you’re interested in creating a localization! Join the SIG Docs Slack channel. Other localization teams are happy to help you get started and answer any questions you have.
You can also create a Slack channel for your localization in the
kubernetes/community repository. For an example of adding a Slack channel, see the PR for adding channels for Indonesian and Portuguese.
The Kubernetes website uses Hugo as its web framework. The website’s Hugo configuration resides in the
config.toml file. To support a new localization, you’ll need to modify
Add a configuration block for the new language to
config.toml, under the existing
[languages] block. The German block, for example, looks like:
[languages.de] title = "Kubernetes" description = "Produktionsreife Container-Verwaltung" languageName = "Deutsch" contentDir = "content/de" weight = 3
When assigning a
weight parameter for your block, find the language block with the highest weight and add 1 to that value.
For more information about Hugo’s multilingual support, see “Multilingual Mode”.
Add a language-specific subdirectory to the
content folder in the repository. For example, the two-letter code for German is
Open a PR against the
cncf/foundation repository to add the code of conduct in your language.
To guide other localization contributors, add a new
README-**.md to the top level of k/website, where
** is the two-letter language code. For example, a German README file would be
Provide guidance to localization contributors in the localized
README-**.md file. Include the same information contained in
README.md as well as:
After you create the localized README, add a link to the file from the main English
README.md, and include contact information in English. You can provide a GitHub ID, email address, Slack channel, or other method of contact. You must also provide a link to your localized Community Code of Conduct.
To set the roles of each user contributing to the localization, create an
OWNERS file inside the language-specific subdirectory with:
sig-docs-**-reviewsteam created in Add your localization team in GitHub.
sig-docs-**-ownersteam created in Add your localization team in GitHub.
More information about the
OWNERS file can be found at go.k8s.io/owners.
The Spanish OWNERS file, with language code
es, looks like:
# 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
After adding the language-specific
OWNERS file, update the root
OWNERS_ALIASES file with the new Kubernetes teams for the localization,
For each team, add the list of GitHub users requested in Add your localization team in GitHub, in alphabetical order.
--- 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
Localizing all of the Kubernetes documentation is an enormous task. It’s okay to start small and expand over time.
At a minimum, all localizations must include:
|Home||All heading and subheading URLs|
|Setup||All heading and subheading URLs|
|Tutorials||Kubernetes Basics, Hello Minikube|
|Site strings||All site strings in a new localized TOML file|
Translated documents must reside in their own
content/**/ subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the Kubernetes Basics tutorial for translation into German, create a subfolder under the
content/de/ folder and copy the English source:
mkdir -p content/de/docs/tutorials cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md
Translation tools can speed up the translation process. For example, some editors offers plugins to quickly translate text.
Caution: Machine-generated translation alone does not meet the minimum standard of quality and requires extensive human review to meet that standard.
To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing.
Localizations must be based on the English files from the most recent release, v1.18 .
To find source files for the most recent release:
release-1.Xbranch for the most recent version.
The latest version is v1.18
, so the most recent release branch is
Localizations must include the contents of
i18n/en.toml in a new language-specific file. Using German as an example:
Add a new localization file to
i18n/. For example, with German (
cp i18n/en.toml i18n/de.toml
Then translate the value of each string:
[docs_label_i_am] other = "ICH BIN..."
Localizing site strings lets you customize site-wide text and features: for example, the legal copyright text in the footer on each page.
Some language teams have their own language-specific style guide and glossary. For example, see the Korean Localization Guide.
Because localization projects are highly collaborative efforts, we encourage teams to work in shared development branches.
To collaborate on a development branch:
Your team approvers joined the
sig-docs-l10n-admins team when you added your localization team to the
We recommend the following branch naming scheme:
dev-<source version>-<language code>.<team milestone>
For example, an approver on a German localization team opens the development branch
dev-1.12-de.1 directly against the k/website repository, based on the source branch for Kubernetes v1.12.
Individual contributors open feature branches based on the development branch.
For example, a German contributor opens a pull request with changes to
Approvers review and merge feature branches into the development branch.
Periodically, an approver merges the development branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request.
Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German development branches would be:
Teams must merge localized content into the same release branch from which the content was sourced. For example, a development branch sourced from release-1.18 must be based on release-1.18 .
An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch.
At the beginning of every team milestone, it’s helpful to open an issue comparing upstream changes between the previous development branch and the current development branch.
While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required.
For more information about working from forks or directly from the repository, see “fork and clone the repo”.
SIG Docs welcomes upstream contributions and corrections to the English source.
You can also help add or improve content to an existing localization. Join the Slack channel for the localization, and start opening PRs to help.
Once a localization meets requirements for workflow and minimum output, SIG docs will:
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.