[`i18n/en/en.toml`](https://github.com/kubernetes/website/blob/main/i18n/en/en.toml)
in a new language-specific file. Using German as an example:
`i18n/de/de.toml`.
Add a new localization directory and file to `i18n/`. For example, with
German (`de`):
```bash
mkdir -p i18n/de
cp i18n/en/en.toml i18n/de/de.toml
```
Revise the comments at the top of the file to suit your localization, then
translate the value of each string. For example, this is the German-language
placeholder text for the search form:
```toml
[ui_search]
other = "Suchen"
```
Localizing site strings lets you customize site-wide text and features: for
example, the legal copyright text in the footer on each page.
### Language-specific localization guide
As a localization team, you can formalize the best practices your team follows
by creating a language-specific localization guide.
For example, see the
[Korean Localization Guide](/ko/docs/contribute/localization_ko/), which
includes content on the following subjects:
- Sprint cadence and releases
- Branch strategy
- Pull request workflow
- Style guide
- Glossary of localized and non-localized terms
- Markdown conventions
- Kubernetes API object terminology
### 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 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.
## Branch 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
[@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers)
opens a localization branch from a source branch on
https://github.com/kubernetes/website.
Your team approvers joined the `@kubernetes/website-maintainers` team when
you [added your localization team](#add-your-localization-team-in-github) to
the [`kubernetes/org`](https://github.com/kubernetes/org) repository.
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 `kubernetes/website` repository,