Chinese content moves from content/cn/ to content/zh/ to conform with the ISO 639-1 naming scheme.

Language-specific subproject repositories will be archived.

Context

In Q3 2017, Kubernetes SIG Docs invited an independent Chinese localization project to house their project in k/website. SIG Docs was unprepared for the introduction of Chinese-language content, due to both the amount of PRs and the lack of Chinese fluency on the part of k/website's maintainers.

To enable translation work to continue while SIG Docs solved for infrastructure support and a scalable l10n workflow, SIG Docs proposed the creation of a language-specific subproject for Chinese content (kubernetes-docs-zh). The goal was for translation work to continue without creating an undue burden on either the Chinese l10n (via a backlog of unapproved PRs) or on SIG Docs maintainers (unable to provide meaningful review of Chinese content).

In Q3 2018, while solving for how to pass source content and translated output between repos, @zparnold proposed and implemented a language label bot. The bot automatically assigns labels to PRs based on the content/* filepaths of pull requests, allowing reviewers to filter pull requests by language. For example, see this list of PRs with Korean content.

UPDATE: Per @cblecker in #10485 (comment), Prow natively supports automatic label assignment by language. I've updated this PR accordingly. The implementation differs from the original proposal, but the strategic effect remains the same.

The combination of native multilingual support and automated language labeling allows SIG Docs to consolidate l10n workflows in a single repository: k/website. This strategy scales appropriately with increasing numbers of localizations. The alternative requires SIG Docs to enforce common standards for synchronizing source and output across multiple, non-forked repos with disparate branching structures and non-identical milestones. These strategies are unnecessarily complex and do not scale well.

Consolidating workflows is a good idea. Let's do it.

There is one notable downside of archiving language-specific repos: absent some finely-tuned git commands, l10n teams could lose their commit histories by moving files from one repo to another. This is avoidable, but it does require git expertise. (👈@mistyhacks) It's also not the end of the world, but it is kind of a bummer.

Each l10n repository must have branches for the different Kubernetes documentation release versions, matching the branches in the main [kubernetes/website](https://github.com/kubernetes/website) documentation repository. For example, the kubernetes/website `release-1.10` branch (https://github.com/kubernetes/website/tree/release-1.10) has a corresponding branch in the kubernetes/kubernetes-docs-zh repository (https://github.com/kubernetes/kubernetes-docs-zh/tree/release-1.10). These version branches keep track of the differences in the documentation between Kubernetes versions.

Teams are free to use any branching strategy for work in progress. For example, a German localization team might use source files from `{{< release-branch >}}`, but work in `dev-{{< release-branch >}}-de-1.0` before squashing commits in a single PR against `{{< release-branch >}}`.

This comment has been minimized.

edited

It's probably best to treat a development branch for translation the same as any other long-running collaborative branch (for example, the release branches for 1.11 and 1.10: #9171, #7818).

Normally we require folks to open PRs on a fork of k/website, but for collaborative projects like localizations I think it's better to treat them like release branches and open directly against k/website.

A development branch for 1.12 source would require an open PR against https://github.com/kubernetes/website/tree/release-1.12, which Individual contributors would then use as the base for their own PRs. A team needs to agree on who opens and maintains the PR--by keeping it current with its parent branch, resolving merge conflicts, and setting expectations for when to merge it--but that can be anyone, with no special permissions required.

We should absolutely specify this in the docs. 👍 I'll update this PR accordingly. Great question! ✨

* [ ] Archive the [`kubernetes/kubernetes-docs-ja`](https://github.com/kubernetes/kubernetes-docs-ko) repository using admin permissions
* [ ] Make one final commit of `kubernetes-docs-ko:content/ja/` to `k/website`
* [ ] Archive the [`kubernetes/kubernetes-docs-zh`](https://github.com/kubernetes/kubernetes-docs-ko) repository using admin permissions
* [ ] Make one final commit of `kubernetes-docs-ko:content/zh/` to `k/website`

* [ ] Archive the [`kubernetes/kubernetes-docs-ja`](https://github.com/kubernetes/kubernetes-docs-ja) repository using admin permissions
* [ ] Make one final commit of `kubernetes-docs-ja:content/ja/` to `k/website`
* [ ] Archive the [`kubernetes/kubernetes-docs-zh`](https://github.com/kubernetes/kubernetes-docs-zh) repository using admin permissions
* [ ] Make one final commit of `kubernetes-docs-zh:content/zh/` to `k/website`

For the sake of efficiency, limit upstream contributions to a single pull request per week, containing a single [squashed commit](https://github.com/todotxt/todo.txt-android/wiki/Squash-All-Commits-Related-to-a-Single-Issue-into-a-Single-Commit).

SIG Docs welcomes ustream contributions and corrections to the English source! For the sake of efficiency, limit upstream contributions to a single pull request per week, containing a single [squashed commit](https://github.com/todotxt/todo.txt-android/wiki/Squash-All-Commits-Related-to-a-Single-Issue-into-a-Single-Commit).

PUSH is designed to update the latest code base, and managing documents is sometimes necessary.

The impact of this issue：Although it has been successfully switched from cn to zh directory here, kubernetes-docs-zh does not push update permissions, and submitting PR operations to merge documents is not particularly convenient.

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.