From 389349faca9d1e6f8754b2f5a1fc8093a16fc19a Mon Sep 17 00:00:00 2001 From: Yura <122832929+Yurtsia@users.noreply.github.com> Date: Mon, 3 Nov 2025 19:39:52 +0200 Subject: [PATCH] Create README.uk.md --- docs/README.uk.md | 93 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 docs/README.uk.md diff --git a/docs/README.uk.md b/docs/README.uk.md new file mode 100644 index 00000000..48a62434 --- /dev/null +++ b/docs/README.uk.md @@ -0,0 +1,93 @@ + + +Документація 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 (###). +- Використовуйте огороджені блоки коду з мовою та, за потреби, назвою файлу. +- Обгортайте зображення в і додавайте alt текст. +- Використовуйте callouts для акцентів: , , , , . +- Для процедур використовуйте / . +- Для альтернатив — / . +- Для API-доків — , та приклади запитів/відповідей. +Приклади коду +- Надавайте повні, робочі приклади з реалістичними даними. +- Включайте обробку помилок та крайові випадки. +- Вказуйте мову та назву файлу, якщо це корисно. +- Показуйте очікуваний результат або кроки перевірки. +Політика сторонніх гайдів +Попередження: Ми зазвичай не приймаємо гайди, які в основному документують сторонній продукт. Винятки можливі лише за наявності чіткого кейсу використання, орієнтованого на Base, та тісної інтеграції з продуктами Base. Просте розгортання на Base або підключення до Base Account/Base App недостатнє. + +Якщо ваша мета — підвищити видимість продукту, будь ласка, подайте запит на включення до сторінки екосистеми Base. Див. інструкції щодо оновлення сторінки екосистеми Base. +Чекліст перед поданням PR +- [ ] Вписується в існуючу структуру (без нових розділів верхнього рівня) +- [ ] Мінімальні, необхідні підрозділи +- [ ] Послідовна термінологія; скорочення введені при першому використанні +- [ ] Приклади коду повні, робочі та перевірені +- [ ] Додані перехресні посилання на пов’язані гайди/приклади/референси +- [ ] Використано компоненти Mintlify та правильну ієрархію заголовків +- [ ] Доступні зображення з описовим alt текстом і обгорткою +- [ ] Дружній до AI: явний, насичений посиланнями, легкий для сприйняття +Процес подання +- Створіть PR до https://github.com/base/docs з вашими змінами. +- Додайте чіткий опис змін і сторінок, на які вони впливають. +- Запросіть перегляд від команди документації. +- Внесіть правки за фідбеком. +- Після схвалення зміни буде об’єднано та опубліковано. +Публікація змін +Основна команда переглядає відкриті PR. SLA — +