chore(i18n): refresh uk translations

2026-04-13 13:01:26 +00:00 · 2026-04-13 13:01:26 +00:00 · dafa5b539f
commit dafa5b539f
parent 1f7631f688
1 changed files with 117 additions and 105 deletions
--- a/docs/uk/reference/RELEASING.md
+++ b/docs/uk/reference/RELEASING.md
@ -1,170 +1,182 @@
 ---
 read_when:
-    - Шукаю визначення публічних каналів релізів
-    - Шукаю назви версій і періодичність
-summary: Публічні канали релізів, назви версій і періодичність
-title: Політика релізів
+    - Шукаю визначення публічних каналів випусків
+    - Шукаю іменування версій та частоту випусків
+summary: Публічні канали випусків, іменування версій та частота випусків
+title: Політика випусків
 x-i18n:
-    generated_at: "2026-04-12T22:00:22Z"
+    generated_at: "2026-04-13T13:00:50Z"
    model: gpt-5.4
    provider: openai
-    source_hash: dffc1ee5fdbb20bd1bf4b3f817d497fc0d87f70ed6c669d324fea66dc01d0b0b
+    source_hash: 402c7f8c38323f735df79611ae3272ffc3816dfd39dd73048b9cab2715fdc334
    source_path: reference/RELEASING.md
    workflow: 15
 ---

-# Політика релізів
+# Політика випусків

-OpenClaw має три публічні канали релізів:
+OpenClaw має три публічні канали випусків:

- stable: релізи з тегами, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запитано
+- stable: позначені тегами випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запитано
 - beta: prerelease-теги, які публікуються в npm `beta`
- dev: поточна рухома вершина `main`
+- dev: рухома вершина `main`

-## Назви версій
+## Іменування версій

- Версія stable-релізу: `YYYY.M.D`
+- Версія stable-випуску: `YYYY.M.D`
  - Git-тег: `vYYYY.M.D`
- Версія stable-виправлення: `YYYY.M.D-N`
+- Версія stable-коригувального випуску: `YYYY.M.D-N`
  - Git-тег: `vYYYY.M.D-N`
- Версія beta prerelease: `YYYY.M.D-beta.N`
+- Версія beta-prerelease: `YYYY.M.D-beta.N`
  - Git-тег: `vYYYY.M.D-beta.N`
 - Не додавайте провідні нулі до місяця або дня
- `latest` означає поточний підвищений stable-реліз у npm
+- `latest` означає поточний просунутий stable-випуск npm
 - `beta` означає поточну ціль встановлення beta
- Stable-релізи та stable-виправлення за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно націлити публікацію на `latest` або пізніше підвищити перевірену beta-збірку
- Кожен реліз OpenClaw постачається разом із npm-пакетом і застосунком для macOS
+- Stable і stable-коригувальні випуски за замовчуванням публікуються в npm `beta`; оператори випусків можуть явно націлити їх на `latest` або просунути перевірену beta-збірку пізніше
+- Кожен випуск OpenClaw постачається разом як npm-пакет і програма для macOS

-## Періодичність релізів
+## Частота випусків

- Релізи спочатку проходять через beta
- Stable виходить лише після перевірки останньої beta
- Детальна процедура релізу, затвердження, облікові дані та примітки щодо відновлення
-  доступні лише для maintainer-ів
+- Випуски спочатку проходять через beta
+- Stable іде лише після перевірки останньої beta
+- Детальна процедура випуску, схвалення, облікові дані та нотатки щодо відновлення доступні
+  лише для maintainers

 ## Передрелізна перевірка

 - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
-  артефакти релізу `dist/*` і бандл Control UI існували для кроку
+  артефакти випуску `dist/*` і бандл Control UI існували для кроку
  перевірки pack
- Запускайте `pnpm release:check` перед кожним релізом із тегом
- Перевірки релізу тепер виконуються в окремому ручному workflow:
+- Запускайте `pnpm release:check` перед кожним позначеним тегом випуском
+- Перевірки випуску тепер виконуються в окремому ручному workflow:
  `OpenClaw Release Checks`
- Цей поділ є навмисним: він зберігає реальний шлях npm-релізу коротким,
-  детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються
+- Цей поділ навмисний: він зберігає реальний шлях npm-випуску коротким,
+  детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки йдуть
  у власному каналі, щоб не затримувати і не блокувати публікацію
- Перевірки релізу потрібно запускати з workflow ref для `main`, щоб
-  логіка workflow і секрети залишалися канонічними
- Цей workflow приймає або наявний тег релізу, або поточний повний
-  40-символьний SHA коміту `main`
- У режимі SHA коміту він приймає лише поточний HEAD `origin/main`; для
-  старіших комітів релізу використовуйте тег релізу
+- Перевірки випуску мають запускатися з workflow ref `main`, щоб логіка
+  workflow і секрети залишалися канонічними
+- Цей workflow приймає або наявний тег випуску, або поточний повний
+  40-символьний commit SHA `main`
+- У режимі commit-SHA він приймає лише поточний HEAD `origin/main`; використовуйте
+  тег випуску для старіших commit випуску
 - Передрелізна перевірка лише для валідації `OpenClaw NPM Release` також приймає поточний
-  повний 40-символьний SHA коміту `main` без вимоги наявності запушеного тега
- Цей шлях SHA є лише для валідації і не може бути підвищений до реальної публікації
- У режимі SHA workflow синтезує `v<package.json version>` лише для
-  перевірки метаданих пакета; реальна публікація все одно потребує справжнього тега релізу
- Обидва workflows залишають реальний шлях публікації та підвищення на GitHub-hosted
+  повний 40-символьний commit SHA `main` без вимоги наявності запушеного тегу
+- Шлях із SHA є лише валідаційним і не може бути просунутий до реальної публікації
+- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки
+  метаданих пакета; реальна публікація все одно потребує реального тегу випуску
+- Обидва workflow зберігають реальний шлях публікації та просування на GitHub-hosted
  runners, тоді як шлях валідації без змін стану може використовувати більші
  Blacksmith Linux runners
 - Цей workflow запускає
  `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
-  використовуючи обидва workflow secrets: `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
- Передрелізна перевірка npm-релізу більше не чекає окремий канал перевірок релізу
- Перед затвердженням запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
-  (або відповідний тег beta/виправлення)
- Після публікації в npm запустіть
+  з використанням обох workflow secrets: `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
+- Передрелізна перевірка npm-випуску більше не очікує на окремий канал перевірок випуску
+- Перед схваленням запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
+  (або відповідний тег beta/коригувального випуску)
+- Після npm publish запустіть
  `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (або відповідну beta/версію виправлення), щоб перевірити опублікований шлях
-  встановлення з реєстру в новому тимчасовому префіксі
- Автоматизація релізів maintainer-ів тепер використовує схему preflight-then-promote:
-  - реальна публікація в npm має пройти успішний npm `preflight_run_id`
-  - stable npm-релізи за замовчуванням націлюються на `beta`
-  - stable npm-публікація може явно націлюватися на `latest` через вхід workflow
-  - підвищення stable npm з `beta` до `latest` усе ще доступне як явний ручний режим у довіреному workflow `OpenClaw NPM Release`
-  - цей режим підвищення все ще потребує дійсного `NPM_TOKEN` у середовищі `npm-release`, оскільки керування npm `dist-tag` виконується окремо від trusted publishing
-  - публічний `macOS Release` призначений лише для валідації
+  (або відповідну beta/коригувальну версію), щоб перевірити шлях встановлення
+  опублікованого реєстру в новому тимчасовому prefix
+- Автоматизація випусків для maintainers тепер використовує модель preflight-then-promote:
+  - реальний npm publish має пройти успішний npm `preflight_run_id`
+  - stable npm-випуски за замовчуванням спрямовуються в `beta`
+  - stable npm publish може явно націлюватися на `latest` через вхід workflow
+  - stable npm-просування з `beta` до `latest` усе ще доступне як явний ручний режим у довіреному workflow `OpenClaw NPM Release`
+  - прямі stable-публікації також можуть запускати явний режим синхронізації dist-tag, який
+    вказує і `latest`, і `beta` на вже опубліковану stable-версію
+  - ці режими dist-tag усе ще потребують дійсного `NPM_TOKEN` у середовищі `npm-release`, оскільки керування npm `dist-tag` є окремим від trusted publishing
+  - публічний `macOS Release` є лише валідаційним
  - реальна приватна mac-публікація має пройти успішні приватні mac
    `preflight_run_id` і `validate_run_id`
-  - реальні шляхи публікації підвищують уже підготовлені артефакти замість їх повторного збирання
- Для stable-виправлень на кшталт `YYYY.M.D-N` post-publish verifier
-  також перевіряє той самий шлях оновлення в тимчасовому префіксі з `YYYY.M.D` до `YYYY.M.D-N`,
-  щоб виправлення релізу не могли непомітно залишити старі глобальні встановлення на
-  базовому stable-вмісті
- Передрелізна перевірка npm-релізу завершується помилкою за замовчуванням, якщо tarball не містить
-  і `dist/control-ui/index.html`, і непорожній вміст `dist/control-ui/assets/`,
+  - реальні шляхи публікації просувають підготовлені артефакти замість повторного
+    їх збирання
+- Для stable-коригувальних випусків на кшталт `YYYY.M.D-N`, post-publish verifier
+  також перевіряє той самий шлях оновлення в temp-prefix з `YYYY.M.D` до `YYYY.M.D-N`,
+  щоб коригування випуску не могли непомітно залишити старіші глобальні встановлення
+  на базовому stable-навантаженні
+- Передрелізна перевірка npm-випуску завершується fail closed, якщо tarball не містить і
+  `dist/control-ui/index.html`, і непорожнє навантаження `dist/control-ui/assets/`,
  щоб ми знову не випустили порожню панель браузера
- Якщо робота над релізом зачепила планування CI, маніфести часу виконання extensions або
-  матриці тестування extensions, перед затвердженням згенеруйте заново та перегляньте
-  workflow matrix outputs, якими керує planner,
-  `checks-node-extensions` з `.github/workflows/ci.yml`, щоб примітки до релізу не
-  описували застарілу структуру CI
- Готовність stable-релізу для macOS також охоплює поверхні оновлення:
-  - GitHub-реліз зрештою має містити паковані `.zip`, `.dmg` і `.dSYM.zip`
+- Якщо робота над випуском зачіпала планування CI, маніфести часу виконання extensions або
+  матриці тестів extensions, перед схваленням заново згенеруйте й перегляньте
+  виходи матриці workflow `checks-node-extensions`, якими володіє planner, із `.github/workflows/ci.yml`,
+  щоб примітки до випуску не описували застарілу схему CI
+- Готовність stable-випуску macOS також включає поверхні оновлювача:
+  - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
  - `appcast.xml` у `main` після публікації має вказувати на новий stable zip
-  - пакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed
-    URL і `CFBundleVersion` на рівні або вище канонічного мінімального Sparkle build
-    для цієї версії релізу
+  - запакована програма має зберігати non-debug bundle id, непорожній Sparkle feed
+    URL і `CFBundleVersion` на рівні або вище за канонічну нижню межу збірки Sparkle
+    для цієї версії випуску

 ## Вхідні параметри workflow NPM

 `OpenClaw NPM Release` приймає такі керовані оператором вхідні параметри:

- `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або
+- `tag`: обов’язковий тег випуску, наприклад `v2026.4.2`, `v2026.4.2-1` або
  `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
-  повний 40-символьний SHA коміту `main` для передрелізної перевірки лише з валідацією
- `preflight_only`: `true` лише для валідації/збирання/пакування, `false` для
-  реального шляху публікації
- `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав
-  підготовлений tarball з успішного запуску передрелізної перевірки
- `npm_dist_tag`: цільовий npm-тег для шляху публікації; за замовчуванням `beta`
- `promote_beta_to_latest`: `true`, щоб пропустити публікацію й перемістити вже опубліковану
-  stable beta-збірку на `latest`
+  повний 40-символьний commit SHA `main` для передрелізної перевірки лише для валідації
+- `preflight_only`: `true` для лише валідації/збирання/пакування, `false` для
+  шляху реальної публікації
+- `preflight_run_id`: обов’язковий на шляху реальної публікації, щоб workflow повторно використав
+  підготовлений tarball з успішного передрелізного запуску
+- `npm_dist_tag`: цільовий тег npm для шляху публікації; за замовчуванням `beta`
+- `promote_beta_to_latest`: `true`, щоб пропустити публікацію і перемістити вже опубліковану
+  stable-збірку `beta` на `latest`
+- `sync_stable_dist_tags`: `true`, щоб пропустити публікацію і спрямувати і `latest`, і
+  `beta` на вже опубліковану stable-версію

 `OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри:

- `ref`: наявний тег релізу або поточний повний 40-символьний SHA коміту `main`
-  для перевірки
+- `ref`: наявний тег випуску або поточний повний 40-символьний commit
+  SHA для перевірки

 Правила:

- Stable-теги та теги виправлень можуть публікуватися або в `beta`, або в `latest`
+- Stable і correction-теги можуть публікуватися або в `beta`, або в `latest`
 - Beta prerelease-теги можуть публікуватися лише в `beta`
- Повний SHA коміту дозволений лише коли `preflight_only=true`
- Режим SHA коміту для перевірок релізу також вимагає поточний HEAD `origin/main`
- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час передрелізної перевірки;
+- Повний вхід commit SHA дозволено лише коли `preflight_only=true`
+- Режим commit-SHA для перевірок випуску також вимагає поточного HEAD `origin/main`
+- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що й під час передрелізної перевірки;
  workflow перевіряє ці метадані перед продовженням публікації
- Режим підвищення має використовувати stable-тег або тег виправлення, `preflight_only=false`,
+- Режим просування має використовувати stable або correction-тег, `preflight_only=false`,
  порожній `preflight_run_id` і `npm_dist_tag=beta`
- Режим підвищення також вимагає дійсний `NPM_TOKEN` у середовищі `npm-release`,
-  оскільки `npm dist-tag add` усе ще потребує звичайної npm-автентифікації
+- Режим синхронізації dist-tag має використовувати stable або correction-тег,
+  `preflight_only=false`, порожній `preflight_run_id`, `npm_dist_tag=latest`
+  і `promote_beta_to_latest=false`
+- Режими просування та синхронізації dist-tag також потребують дійсного `NPM_TOKEN` у
+  середовищі `npm-release`, оскільки `npm dist-tag add` усе ще потребує звичайної npm
+  автентифікації

-## Послідовність stable npm-релізу
+## Послідовність stable npm-випуску

-Під час випуску stable npm-релізу:
+Під час створення stable npm-випуску:

 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
-   - До появи тега ви можете використовувати поточний повний SHA коміту `main` для
-     dry run передрелізного workflow лише з валідацією
-2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише
-   коли ви навмисно хочете пряму stable-публікацію
-3. Окремо запустіть `OpenClaw Release Checks` з тим самим тегом або
-   повним поточним SHA `main`, якщо вам потрібне live-покриття prompt cache
+   - Поки тег ще не існує, ви можете використовувати поточний повний commit SHA `main` для
+     лише валідаційного dry run workflow передрелізної перевірки
+2. Виберіть `npm_dist_tag=beta` для звичайного beta-first потоку або `latest` лише
+   коли ви свідомо хочете прямої stable-публікації
+3. Запустіть `OpenClaw Release Checks` окремо з тим самим тегом або
+   повним поточним commit SHA `main`, якщо вам потрібне live-покриття prompt cache
   - Це навмисно окремо, щоб live-покриття залишалося доступним без
-     повторного поєднання довготривалих або нестабільних перевірок із workflow публікації
+     повторного зв’язування довгих або нестабільних перевірок з workflow публікації
 4. Збережіть успішний `preflight_run_id`
-5. Знову запустіть `OpenClaw NPM Release` з `preflight_only=false`, тим самим
+5. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим
   `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id`
-6. Якщо реліз потрапив у `beta`, пізніше запустіть `OpenClaw NPM Release` з
+6. Якщо випуск потрапив у `beta`, пізніше запустіть `OpenClaw NPM Release` з
   тим самим stable `tag`, `promote_beta_to_latest=true`, `preflight_only=false`,
-   порожнім `preflight_run_id` і `npm_dist_tag=beta`, коли захочете перемістити цю
-   опубліковану збірку до `latest`
+   порожнім `preflight_run_id` і `npm_dist_tag=beta`, коли ви захочете перемістити цю
+   опубліковану збірку на `latest`
+7. Якщо випуск було свідомо опубліковано безпосередньо в `latest` і `beta`
+   має вказувати на ту саму stable-збірку, запустіть `OpenClaw NPM Release` з тим самим
+   stable `tag`, `sync_stable_dist_tags=true`, `promote_beta_to_latest=false`,
+   `preflight_only=false`, порожнім `preflight_run_id` і `npm_dist_tag=latest`

-Режим підвищення все ще потребує затвердження середовища `npm-release` і
-дійсного `NPM_TOKEN` у цьому середовищі.
+Режими просування та синхронізації dist-tag усе ще потребують схвалення середовища `npm-release`
+і дійсного `NPM_TOKEN` у цьому середовищі.

-Це зберігає як шлях прямої публікації, так і шлях підвищення beta-first
-задокументованими та видимими для оператора.
+Це зберігає і шлях прямої публікації, і beta-first шлях просування
+задокументованими та видимими для операторів.

 ## Публічні посилання

@ -174,6 +186,6 @@ OpenClaw має три публічні канали релізів:
 - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
 - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)

-Maintainer-и використовують приватну документацію релізів у
+Maintainers використовують приватну документацію з випусків у
 [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
 для фактичного runbook.