Collaborating on Localization Branches: Workflow and Upstream Contributions

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, based on the source branch for Kubernetes v1.12. 1. 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`. 1. Approvers review and merge feature branches into the localization branch. 1. Periodically, an approver merges the localization branch with 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 localization branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. Teams must merge localized content into the same branch from which the content was sourced. For example: - A localization branch sourced from `main` must be merged into `main`. - A localization branch sourced from `release-{{% skew "prevMinorVersion" %}}` must be merged into `release-{{% skew "prevMinorVersion" %}}`. {{< note >}} If your localization branch was created from `main` branch, but it is not merged into `main` before the new release branch `{{< release-branch >}}` created, merge it into both `main` and new release branch `{{< release-branch >}}`. To merge your localization branch into the new release branch `{{< release-branch >}}`, you need to switch the upstream branch of your localization branch to `{{< release-branch >}}`. {{< /note >}} 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. - [`upstream_changes.py`](https://github.com/kubernetes/website/tree/main/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And - [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/main/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch. 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"](#fork-and-clone-the-repo). ## Upstream contributions SIG Docs welcomes upstream contributions and corrections to the English source.

This section details the process of collaborating on localization branches within the Kubernetes website repository. It outlines the steps for creating localization branches, working on feature branches, merging changes, and periodically synchronizing with the source branch. It emphasizes the importance of merging localized content back into the correct source branch (e.g., `main` or `release-*`). The section also mentions the use of scripts for comparing upstream changes between localization branches, and clarifies that while opening a localization branch and merging PRs requires approver status, anyone can submit a pull request to a new branch. Finally, it encourages contributions and corrections to the English source content.