Update localization documentation

[xirehat]

The current localization documentation is outdated and no longer reflects how new localization teams are actually onboarded and operate. Following it leads teams to perform steps that are unnecessary today, while missing steps that are required creating confusion and extra work. Guidance in the docs does not match the current process we’re experiencing in Persian localization team.

[lmktfy]

Can you explain the gap between the documented process and what the docs should explain?

[lmktfy]

/area localization
/sig contributor-experience

/language en
(sic)

[xirehat]

Can you explain the gap between the documented process and what the docs should explain?

The current docs describe a “one PR plus and org-team creation” path, but what works in practice is a staged, public process. Opening a series of small, reviewable PRs (instead of a single all-in-one PR) reduces reviewer load and lets us validate Netlify builds incrementally. Org-level teams in kubernetes/org (e.g., sig-docs--owners/reviews) are best created after the localization dev branch is stable and close to merging into main, not at the outset. The docs should also encourage starting openly in Slack announcing intent in #sig-docs-localizations, forming a visible language team, and seeking guidance from SIG Docs leads and experienced contributors rather than working in the background. Updating the docs to reflect this staged, public flow will help new teams avoid unnecessary steps and focus on what’s actually required at the right time.

[lmktfy]

Right now, the explanation of using multiple PRs is very short; just

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

What I think would work well: a case study blog article, that the localization guide links to.
We can have more than one case study, even.

[lmktfy]

/triage accepted
/priority backlog