Localizing Kubernetes documentation

This page shows you how to

Contribute to an existing localization

You can help add or improve content to an existing localization. In

First, consult the ko.

First, create your own fork of the

Then, clone your fork and cd into it:

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

Create or update your chosen localized page based on the English original. See translating content for more details.

If you notice a technical inaccuracy or other problem with the upstream (English) documentation, you should fix the upstream documentation first and then repeat the equivalent fix by updating the localization you're working on.

Please limit pull requests to a single localization, since pull requests that change content in multiple localizations could be difficult to review.

Follow Suggesting Content Improvements to propose changes to that localization. The process is very similar to proposing changes to the upstream (English) content.

Start a new localization

If you want the Kubernetes documentation localized into a new language, here's what you need to do.

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. The Kubernetes website is happy to host your work, but it's up to you to translate it and keep existing localized content current.

You'll need to know the two-letter language code for your language. Consult the ko.

When you start a new localization, you must localize all the minimum required content before the Kubernetes project can publish your changes to the live website.

SIG Docs can help you work on a separate branch so that you can incrementally work towards that goal.

Find community

Let Kubernetes SIG Docs know you're interested in creating a localization! Join the

Please also consider participating in the .

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 .

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

Add your localization team in GitHub

Next, add your Kubernetes localization team to .

Members of @kubernetes/website-milestone-maintainers can use the /milestone

Configure the workflow

For an example of adding a label, see the PR for adding the .

The Kubernetes website uses Hugo as its web framework. The website's Hugo configuration resides in the config.toml.

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

For more information about Hugo's multilingual support, see "".

Add a language-specific subdirectory to the de:

mkdir content/de

You also need to create a directory inside data/i18n for localized strings; look at existing localizations for an example. To use these new strings, you must also create a symbolic link from i18n/<localization>.toml to the actual string configuration in data/i18n/<localization>/<localization>.toml (remember to commit the symbolic link).

For example, for German the strings live in data/i18n/de/de.toml, and i18n/de.toml is a symbolic link to data/i18n/de/de.toml.

Localize the community code of conduct

Open a PR against the

Setting up the OWNERS files

• reviewers: A list of kubernetes teams with reviewer roles, in this case, the sig-docs-**-reviews team created in Add your localization team in GitHub.
• approvers: A list of kubernetes teams with approvers roles, in this case, the sig-docs-**-owners team created in Add your localization team in GitHub.
• labels: A list of GitHub labels to automatically apply to a PR, in this case, the language label created in Configure the workflow.

More information about the OWNERS file can be found at

The

# 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 sig-docs-**-reviews.

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

Open a pull request

Next, open a pull request (PR) to add a localization to the kubernetes/website repository.

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 .

To guide other localization contributors, add a new README-de.md.

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,

Launching your new localization

• Enable language selection on the website
• Publicize the localization's availability through .

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.

To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing.

Source files

Localizations must be based on the English files from a specific release targeted by the localization team. Each localization team can decide which release to target which is referred to as the target version below.

To find source files for your target version:

1. Navigate to the Kubernetes website repository at
2. Select a branch for your target version from the following table:

   Target version	Branch
   Latest version
   Previous version
   Next version

Localizations must include the contents of data/i18n/de/de.toml.

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

[ui_search_placeholder]
other = "Suchen"

Some language teams have their own language-specific style guide and glossary. For example, see the Korean Localization Guide.

Language specific Zoom meetings

If the localization project needs a separate meeting time, contact a SIG Docs Co-Chair or Tech Lead to create a new reoccurring Zoom meeting and calendar invite. This is only needed when the the team is large enough to sustain and require a separate meeting.

Per CNCF policy, the localization teams must upload their meetings to the SIG Docs YouTube playlist. A SIG Docs Co-Chair or Tech Lead can help with the process until SIG Docs automates it.

Branching strategy

Because localization projects are highly collaborative efforts, we encourage teams to work in shared localization branches - especially when starting out and the localization is not yet live.

To collaborate on a localization branch:

1. A team member of

   Your team approvers joined the @kubernetes/website-maintainers 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 localization branch dev-1.12-de.1 directly against the k/website repository, based on the source branch for Kubernetes v1.12.

2. Individual contributors open feature branches based on the localization branch.

   For example, a German contributor opens a pull request with changes to kubernetes:dev-1.12-de.1 from username:local-branch-name.

3. Approvers review and merge feature branches into the localization branch.

4. Periodically, an approver merges the localization branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request.

At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous localization branch and the current localization branch. There are two scripts for comparing upstream changes.

While only approvers can open a new localization branch and merge pull requests, anyone can open a pull request for a new localization branch. No special permissions are required.

For more information about working from forks or directly from the repository, see "fork and clone the repo".

Upstream contributions

SIG Docs welcomes upstream contributions and corrections to the English source.