Localize your open source documentation: a Kubernetes case study
summary
Kubernetes documentation scales localization from zero to eleven localizations in six months by using concrete tools and rules: Hugo + Netlify + Python scripts for preview builds and diff tracking, canonical source = English on main, reviewers must have native fluency, and authors cannot self-approve. Permissions use long‑running repo branches and language labels via GitHub actions. Outcome: six Korean contributors sustain a one‑to‑many support ratio serving 30,123 Korean visitors (2.1% of traffic) in March 2022, showing the approach works.
AI-written summary · about
chapters (10)
- 0:00Intro
- 4:07Localization requires maintenance. Choose your maintenance wisely.
- 8:05Establish a canonical source language and branch.
- 9:25Establish an MVD: minimum viable documentation
- 10:17Script away common functions.
- 11:45Use tools that support internationalization.
- 14:40Who can approve root-level changes to configuration files?
- 17:35Treat localization with the same trust as any release branch.
- 18:14Document everything
- 22:26Is localization worth it?
related talks
22mCreating a Micro Open-Source Community with Helm
01h 01mClosing the documentation gap with Backstage.io
34mKubernetes from Dev to Prod at GoEuro
39mSoftware Rollout at Scale: Using GitOps to Scale Kubernetes Rollouts
44mMigrating a Monolith to Kubernetes
16mMovingFromGitHubWikiToOwnDocsServer
45mLearning How to Pronounce Kubernetes to Production in 3 Months!
40mHow we replicate and localize 100,000 repositories nearly every day 🕺🏼
