Ukrainian translation of README.md

docs/README.uk.md

@@ -0,0 +1,93 @@
+<!-- Ukrainian translation by @Yurtsia -->
+
+Документація Base управляється спільнотою. Ми вітаємо та заохочуємо внески від усіх, щоб ці документи залишались точними, корисними та актуальними.
+Примітка: Цей репозиторій є основою для публічного сайту документації Base. Вміст знаходиться в папці docs/.
+
+Локальна розробка
+Передумова: Node.js v19+.
+- Клонуйте репозиторій.
+- Встановіть Mint CLI для локального перегляду змін у документації:
+- Перегляньте локально (виконуйте з директорії docs/, де знаходиться docs.json):
+Альтернатива без глобальної установки:
+Вирішення проблем
+- Переконайтесь, що встановлено Node.js v19+ і що ви запускаєте mint dev з директорії, яка містить docs.json (зазвичай docs/).
+- Локальний перегляд може відрізнятись від продакшн-версії: запустіть mint update, щоб оновити CLI.
+Як контриб’ютити
+- Форк і гілка: Форкніть base/docs і створіть описову гілку для вашої зміни.
+- Редагуйте вміст у docs/: Дотримуйтесь структури та стилю, описаних нижче. Переглядайте локально за допомогою Mint CLI.
+- Створіть Pull Request: Додайте чітке резюме та посилання на пов’язані сторінки. Команда документації та спільнота переглянуть ваш внесок.
+Порада: надавайте перевагу невеликим, сфокусованим PR. Додавайте прямі посилання на пов’язані гайди та референси.
+
+Структура документації
+Основний принцип: зберігайте існуючу структуру
+Попередження: не створюйте нові розділи верхнього рівня. Розміщуйте весь новий вміст у наявних папках під docs/.
+
+Документація Base організована у встановлені розділи (наприклад: get-started/, learn/, base-account/, base-app/, base-chain/, cookbook/, mini-apps/, onchainkit/). Розміщуйте новий вміст у найбільш релевантному існуючому розділі.
+Політика навігації
+Примітка: Ми зазвичай не змінюємо глобальну навігацію (вкладки верхнього рівня) або бокове меню, якщо немає чіткої, загальнокорисної потреби. Внески мають бути спрямовані на покращення існуючих сторінок та додавання нових у поточні розділи.
+
+Призначення розділів
+- Quickstart: Повна настройка до першого успіху. Має бути стислим і актуальним.
+- Concepts: Пояснення компонентів, архітектури та філософії дизайну.
+- Guides: Покрокові, практичні туторіали для конкретних задач.
+- Examples: Повні, робочі приклади реального використання.
+- Technical Reference: Специфікації API/методів/компонентів з параметрами та типами повернення.
+- Contribute: Інформація для контриб’юторів та оновлення процесу.
+Область cookbook
+- Розділ cookbook/ містить гайди та шаблони, орієнтовані на кейси використання, а не на конкретні продукти.
+- Віддавайте перевагу рішенням, які демонструють, як будувати на Base з використанням різних інструментів та сценаріїв.
+Попередження: Уникайте надмірної деталізації підрозділів:
+- Розміщуйте всі гайди на одному рівні в розділі Guides.
+- Організовуйте Reference за компонентом/функцією, а не за кейсом.
+- Використовуйте перехресні посилання замість створення нових структурних рівнів.
+
+Стиль і форматування
+Стиль написання
+- Будьте стислими та послідовними; використовуйте активний стан і звернення на "ти".
+- Фокусуйтесь на основному сценарії; альтернативи згадуйте коротко.
+- Використовуйте чіткі, описові заголовки та назви файлів.
+- Дотримуйтесь єдиної термінології; вводьте скорочення при першому використанні.
+Контент, дружній до AI
+- Використовуйте чітку, явну мову та додавайте прямі посилання на пов’язані сторінки.
+- Віддавайте перевагу маркованим спискам для варіантів/кроків, якщо вони не є послідовними.
+- Називайте та згадуйте бібліотеки та інструменти явно.
+- Використовуйте семантичні, читабельні URL і уникайте неоднозначних скорочень.
+Чекліст:
+- Чи зможе велика мовна модель зрозуміти та виконати цей контент?
+- Чи зможе інженер скопіювати, вставити та запустити приклади як є?
+
+Форматування Mintlify
+- Основні розділи починайте з H2 (##), підрозділи — з H3 (###).
+- Використовуйте огороджені блоки коду з мовою та, за потреби, назвою файлу.
+- Обгортайте зображення в <Frame> і додавайте alt текст.
+- Використовуйте callouts для акцентів: <Note>, <Tip>, <Warning>, <Info>, <Check>.
+- Для процедур використовуйте <Steps> / <Step>.
+- Для альтернатив — <Tabs> / <Tab>.
+- Для API-доків — <ParamField>, <ResponseField> та приклади запитів/відповідей.
+Приклади коду
+- Надавайте повні, робочі приклади з реалістичними даними.
+- Включайте обробку помилок та крайові випадки.
+- Вказуйте мову та назву файлу, якщо це корисно.
+- Показуйте очікуваний результат або кроки перевірки.
+Політика сторонніх гайдів
+Попередження: Ми зазвичай не приймаємо гайди, які в основному документують сторонній продукт. Винятки можливі лише за наявності чіткого кейсу використання, орієнтованого на Base, та тісної інтеграції з продуктами Base. Просте розгортання на Base або підключення до Base Account/Base App недостатнє.
+
+Якщо ваша мета — підвищити видимість продукту, будь ласка, подайте запит на включення до сторінки екосистеми Base. Див. інструкції щодо оновлення сторінки екосистеми Base.
+Чекліст перед поданням PR
+- [ ] Вписується в існуючу структуру (без нових розділів верхнього рівня)
+- [ ] Мінімальні, необхідні підрозділи
+- [ ] Послідовна термінологія; скорочення введені при першому використанні
+- [ ] Приклади коду повні, робочі та перевірені
+- [ ] Додані перехресні посилання на пов’язані гайди/приклади/референси
+- [ ] Використано компоненти Mintlify та правильну ієрархію заголовків
+- [ ] Доступні зображення з описовим alt текстом і обгорткою
+- [ ] Дружній до AI: явний, насичений посиланнями, легкий для сприйняття
+Процес подання
+- Створіть PR до https://github.com/base/docs з вашими змінами.
+- Додайте чіткий опис змін і сторінок, на які вони впливають.
+- Запросіть перегляд від команди документації.
+- Внесіть правки за фідбеком.
+- Після схвалення зміни буде об’єднано та опубліковано.
+Публікація змін
+Основна команда переглядає відкриті PR. SLA —
+