Застарілість контенту: аудит багатомовної документації Kubernetes

Kubernetes (також відомий як K8s) — це відкрита платформа для розгортання, масштабування та керування контейнеризованими застосунками. Спроєктований у Google, а нині під опікою Cloud Native Computing Foundation, він став стандартом оркестрування контейнерів — його використовують організації всіх розмірів, від стартапів до найбільших корпорацій. Як і будь-яка технологія, що стрімко розвивається, Kubernetes потребує точної й актуальної документації для своїх користувачів по всьому світу.

Офіційний сайт документації проєкту Kubernetes знаходиться за адресою kubernetes.io. Він охоплює все: від базових понять (“Що таке Pod?”) до складних операційних завдань (“Шифрування конфіденційних даних у стані спокою”). Оскільки аудиторія Kubernetes глобальна, документацію перекладено 16 мовами — але підтримувати ці переклади в актуальному стані непросто.

Коли англійські першоджерела змінюються з виходом нових версій, перекладені сторінки потрібно оновлювати. Коли переклад відстає, читачі можуть натрапити на інформацію, яка вже не відображає поточного стану проєкту. Це виклик, який тією чи іншою мірою торкається більшості мов.

Нижче наведено систематичний крос-мовний аудит теки content/ — теки в репозиторії, яка містить усі сторінки документації. Було перевірено кожен .md файл усіма мовами та виміряно два параметри:

• Покриття: яка частка з англомовних сторінок перекладена
• Застарілість: для перекладених сторінок, чи локалізована версія була оновлена після внесення змін до джерела (англійської версії)

Усі дані відображають часові мітки git log станом на 15 липня 2026 року.

Загальні цифри #

Покриття: яка частка англійського контенту перекладена? #

Розрив між найбільш і найменш перекладеними мовами величезний:

[*] Примітка щодо українських даних: Показники української мови вище враховують вміст, запропонований у PR #48551 — масштабний переклад, який наразі відкрито й ще не злито в main. Без цього ПР поточне покриття української у гілці main становить 4% (69 файлів в docs/) із 29% застарілості (22 із 75 спільних файлів застарілі). Див. підсумок за мовами нижче для повного порівняння.

Ключові висновки:

• Італійська, польська, гінді та бенгальська мають менше ніж 100 сторінок документації — менше 6% від англійської. Основні концептуальні сторінки (architecture, security, storage, workloads) здебільшого відсутні.
• Українська (з урахуванням вмісту PR #48551) — беззаперечний лідер: я як єдиний автор і супроводжувач [**] переклав практично все. Без цього ПР українська має лише 4% покриття — поточний стан у main.
• Китайська майже наздоганяє з 89%, хоча все ще бракує ~180 сторінок.
• Решта 12 мов перебувають у діапазоні 3–31%. Більшості з цих проєктів потрібно більше учасників для зростання.

[**] Я сподіваюсь, що знайдуться інші охочі, щоб приєднатись до цієї роботи і нарешті додати повний переклад до документації Kubernetes.

Покриття за розділами #

Розділ довідки (docs/reference/) є найбільшим — 1 163 англійські файли, здебільшого автоматично згенерована довідка API. Покриття тут загалом низьке за межами української та китайської, оскільки сторінки довідки генеруються механічно і їх важко перекладати вручну.

Проблема блогу #

З 750 англійських блог-постів лише китайська (349 дописів, 46%) та українська (80 дописів, 10%) мають значуще покриття перекладу. Японська має 45, корейська — 10. Інші 10 мов мають 0–3 дописи кожна, а чотири мови — перська, гінді, польська та російська не мають жодного блог-посту.

Блог-пости документують релізи, застарівання та оновлення від спільноти. Коли вони залишаються неперекладеними, читачі, які не володіють англійською, пропускають важливі оголошення про проєкт.

Застарілість: наскільки свіжими є наявні переклади? #

Покриття показує, скільки перекладено. Застарілість показує, наскільки актуальними є ці переклади. Дату останнього коміту кожного перекладеного файлу було порівняно з його англійським оригіналом.

Критично застарілі — файли, яких не торкалися з 2019–2020 #

Найбільш тривожна тенденція: кілька мов мають ключові документи, які не оновлювалися з 2019 або початку 2020 року — тобто вони описують Kubernetes таким, яким він був 6–7 років тому.

Мови з древніми версіями

Це сторінки, які користувачі Kubernetes найімовірніше прочитають першими. Показувати 6-річний вміст означає, що читачі можуть покладатися на інформацію, яка вже не відповідає поточному стану Kubernetes.

Важливі сторінки, застарілі в багатьох мовах #

Сторінка docs/home/_index.md (головна сторінка документації) застаріла в 13 із 16 мов. docs/concepts/overview/_index.md застаріла в 11 мовах.

Підсумок за мовами #

🟢 Добрий стан #

• Українська (uk): із PR #48551 українська сягає 99% покриття з 0% застарілих — кожна англійська сторінка має український відповідник, який я як єдиний автор і супроводжувач підтримую в актуальному стані. Без цього ПР, однак, поточна гілка main має лише 4% покриття (69 файлів docs/) та 29% застарілості: наявні сторінки охоплюють базові концепти, термінологічний глосарій та декілька посібників, тоді як для 1 612 англійських сторінок немає українського відповідника взагалі.
• Китайська (zh-cn): 89% покриття, 3% застарілих. Чудово — активно підтримується, блог значною мірою перекладено.
• Перська (fa): 10% покриття, але 98% наявних сторінок свіжі. Команда підтримує якість навіть із малим корпусом.

🟡 Потребує уваги #

• Японська (ja): Хороше покриття (31%), але 36% файлів застарілі. Concepts і Tasks здебільшого присутні, але старіють.
• Французька (fr): 20% покриття, 39% застарілих. Розділ Setup повний, але концепти застарілі.
• Португальська (pt-br): 17% покриття, 38% застарілих. Стабільна робота, але контент старіє.
• Вʼєтнамська (vi): 12% покриття, 21% застарілих. Невелика команда, прийнятне співвідношення свіжості.
• Німецька (de): 7% покриття, 48% застарілих. Половина перекладених сторінок потребує оновлення.
• Бенгальська (bn): 6% покриття, 28% застарілих. Розділ Releases повністю перекладено — хороша відправна точка.
• Гінді (hi): 6% покриття, 26% застарілих. Мало, але відносно доглянуто.
• Італійська (it): 3% покриття, 43% застарілих. Дуже мало сторінок, і половина потребує оновлення.

🔴 Термінова увага #

• Індонезійська (id): 61% застарілих. Основні сторінки архітектури не оновлювалися з 2019 року. Це найбільш застаріла мова загалом.
• Іспанська (es): 60% застарілих. Розділ концепцій заморожено з 2021 року. Блог відсутній.
• Корейська (ko): 57% застарілих. Незважаючи на 541 сторінку документації (31% покриття), понад половина відстає від англійської.
• Російська (ru): 51% застарілих. Мале покриття (7%), і половина з того, що існує, застаріло.

Рекомендації #

1. Запровадити правила застарівання документації: інші компоненти Kubernetes мають формальну політику застарівання — документація також повинна її мати. Kubernetes випускає нові мінорні версії приблизно кожні 3 місяці, а між ними — патчі, при цьому підтримуються лише три найновіші мінорні релізи (~1 рік підтримки на версію). Пороги застарілості мають узгоджуватись з цим циклом: мінорні релізи задають загальне вікно свіжості, а патчі (особливо з виправленнями безпеки) можуть вимагати швидшого оновлення документації для критичних сторінок. Нижче наведено запропоновану кількарівневу систему:

   Рівень	Відставання від англ. джерела	Позиція в циклі релізів	Статус	Дія
   Fresh (актуально)	< 3 місяців	У межах поточного релізу	🟢 Актуально	—
   Stale (застаріває)	3–12 місяців	1–4 релізи тому (у межах вікна підтримки)	🟡 Погіршується	GitHub Action створює issue з міткою translation/stale
   Dormant (неактивно)	1–2 роки	4–8 релізів тому (поза вікном підтримки)	🟠 Неактивно	На сторінці показується повідомлення: “Цей переклад востаннє оновлено {дата}. Англійська версія була змінена з тих пір.”
   Archived (архівовано)	> 2 років	> 8 релізів тому	🔴 Архівовано	Сторінка прибирається з основної навігації, але зберігається як історичний артефакт і доступна через версії документації відповідного релізу Kubernetes.

   Межа між Stale та Dormant (~1 рік) віддзеркалює вікно підтримки патчів Kubernetes — коли мінорна версія досягає завершення життєвого циклу, її документацію варто вважати неактивною, якщо її не оновлюють. Патчі самі по собі не скидають лічильник застарілості, таймер ведеться за мінорними релізами. Однак сторінки, що описують чутливі до безпеки компоненти (автентифікація, авторизація, мережеві політики), мають переглядатися після кожного патчу, який торкається відповідних компонентів.

2. Архівувати або позначити неактивні мови: мови з покриттям <5% і відсутністю нещодавньої активності (італійська, польська) варто або відродити, або задокументувати їхній статус “режим підтримки”.

3. Пріоритезувати основні концепт-сторінки: architecture, overview, workloads, security та services-networking — найбільш популярні сторінки. Вони мають бути перекладені та актуальні в кожній мові, яка заявляє про покриття.

4. Виправити проблему з блогом: блог-пости — основний канал для повідомлень про застарівання, анонсів релізів і рад безпеки. Мови з покриттям блогу нижче 5% ризикують, що їхні читачі пропустять критичну інформацію.

5. Усунути інструментальні барʼєри для команд локалізації: багато мовних команд досі працюють із git-орієнтованими процесами, що робить відстеження розбіжностей і синхронізацію виснажливими. Як зазначено в PS нижче, спеціалізовані платформи перекладу вже вміють перевіряти свіжість нативно — вони сповіщають перекладачів, які саме рядки змінилися, усуваючи потребу в ручному порівнянні git log чи саморобних скриптів. Впровадження таких інструментів дозволить командам зосередитись на якості перекладу замість ручного пошуку того, що змінилось.

Методологія #

• Обсяг: усі .md файли в content/{lang}/ (де застосовно, без автоматично згенерованих довідкових субмодулів).
• Покриття: для кожної мови файли, що існують у content/{lang}/, порівнюються з content/en/. Блог-пости враховуються окремо.
• Застарілість: для кожного файлу, що присутній в англійській мові та в перекладі, порівнюється дата автора останнього коміту, який торкався цього файлу. Файл вважається “застарілим”, якщо англійський коміт новіший за коміт перекладу.
• Дата: усі дані зібрано 2026-07-15.
• Обмеження: часові мітки git log відображають останній коміт, який торкався файлу, а не те, коли вміст востаннє перевірявся. Файл може бути змістовно застарілим, навіть якщо його нещодавно торкнувся CI- або коміт, що виправляє форматування.

PS. Обговорення інструментів для підтримки перекладів #

Проблема підтримки перекладів в актуальному стані не нова. Ще з лютого 2024 року спільнота обговорює кращі інструменти для локалізації Kubernetes у GitHub Discussion #45209. Ключові моменти:

• Централізовані платформи перекладу (Crowdin, Transifex, Weblate) були запропоновані та оцінені. Вони пропонують автоматичне відстеження змін — коли англійське джерело оновлюється, перекладачі отримують сповіщення про те, які саме рядки потребують оновлення.
• Рівень рецензування — речення/абзац замість цілого PR: кілька перекладачів можуть одночасно працювати над однією сторінкою, а рецензенти можуть затверджувати окремі сегменти.
• Памʼять перекладів (TM) та підказки машинного перекладу (MT) пришвидшують роботу та забезпечують узгодженість термінології.
• Спрощений вступ учасників: CLA можна підписати один раз на платформі.
• Було сформовано тестову ініціативу (issue #45756) з волонтерами з pt-br, ko, uk та ar команд, але вона загальмувалася через брак ресурсів SIG Docs.
• Нещодавно LFX mentorship проєкт (2026) створив прототип bash-скрипту для виявлення розбіжностей між англійськими та локалізованими сторінками — див. допис у блозі.

Консенсус обговорення: git добре підходить для коду, але спеціалізовані інструменти могли б значно зменшити навантаження на команди локалізації. Долучайтеся до обговорення в #45209.

Команди локалізації можуть використовувати ці дані як відправну точку для цілеспрямованих оновлень. Якщо ви зацікавлені в допомозі з будь-якою з цих мов, перегляньте посібник з локалізації Kubernetes.