fly316/PX4-Autopilot
7
0
Fork 0
mirror of https://gitee.com/mirrors_PX4/PX4-Autopilot.git synced 2026-10-27 02:33:34 +08:00
Code Issues Packages Projects Releases Wiki Activity

Move PX4 Guide source into /docs (#24490)

Browse Source 
* Add vitepress tree

* Update existing workflows so they dont trigger on changes in the docs path

* Add nojekyll, package.json, LICENCE etc

* Add crowdin docs upload/download scripts

* Add docs flaw checker workflows

* Used docs prefix for docs workflows

* Crowdin obvious fixes

* ci: docs move to self hosted runner

runs on a beefy server for faster builds

Signed-off-by: Ramon Roche <mrpollo@gmail.com>

* ci: don't run build action for docs or ci changes

Signed-off-by: Ramon Roche <mrpollo@gmail.com>

* ci: update runners

Signed-off-by: Ramon Roche <mrpollo@gmail.com>

* Add docs/en

* Add docs assets and scripts

* Fix up editlinks to point to PX4 sources

* Download just the translations that are supported

* Add translation sources for zh, uk, ko

* Update latest tranlsation and uorb graphs

* update vitepress to latest

---------

Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Ramon Roche <mrpollo@gmail.com>
This commit is contained in:
Hamish Willee
2025-03-13 16:08:27 +11:00
committed by GitHub
co-authored by Ramon Roche
parent 8e6d2ebe4a
commit 88d623bedb
5176 changed files with 558771 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/uk/contribute/code.md
+196
View File
@@ -0,0 +1,196 @@
# Керування вихідним кодом
##
Проект PX4 використовує модель розгалуження Git із трьома гілками:
- [main](https://github.com/PX4/PX4-Autopilot/tree/main) is by default unstable and sees rapid development.
- [beta](https://github.com/PX4/PX4-Autopilot/tree/beta) has been thoroughly tested. Він призначений для тестерів на польоти.
- [stable](https://github.com/PX4/PX4-Autopilot/tree/stable) points to the last release.
We try to retain a [linear history through rebases](https://www.atlassian.com/git/tutorials/rewriting-history) and avoid the [Github flow](https://docs.github.com/en/get-started/quickstart/github-flow).
Однак через глобальну команду і швидкий розвиток ми можемо одночасно вдаватися до збоїв.
To contribute new functionality, [sign up for Github](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account), then [fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) the repository, [create a new branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository), add your [changes as commits](#commits-and-commit-messages), and finally [send a pull request](#pull-requests).
Changes will be merged when they pass our [continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) tests.
All code contributions have to be under the permissive [BSD 3-clause license](https://opensource.org/licenses/BSD-3-Clause) and all code must not impose any further constraints on the use.
## Стиль Коду
PX4 uses the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html), with the following (minimal) modifications:
::: info
Not all PX4 source code matches the style guide, but any _new code_ that you write should do so — in both new and existing files.
Якщо ви оновлюєте існуючий файл, від вас не вимагається, щоб весь файл відповідав інструкції зі стилю, а лише код, який ви змінили.
:::
### Вкладки
- Вкладки використовуються для відступу (еквівалентно 8 пробілу).
- Пробіли використовуються для вирівнювання.
### Довжина рядка
- Максимальна довжина рядка становить 120 символів.
### Розширення файлів
- Source files use extension `*.cpp` instead of `*.cc`.
### Іменування функцій та методів
- `lowerCamelCase()` is used for functions and methods to _visually_ distinguish them from `ClassConstructors()` and `ClassNames`.
### Імена змінних членів приватного класу
- `_underscore_prefixed_snake_case` is used for private class member variable names, as oppose to `underscore_postfixed_`.
### Ключові слова класу
- _zero_ spaces before `public:`, `private:`, or `protected:` keywords.
### Приклад сніпета коду
```cpp
class MyClass {
public:
/**
* @brief Description of what this function does.
*
* @param[in] input_param Clear description of the input [units]
* @return Whatever we are returning [units]
*/
float doSomething(const float input_param) const {
const float in_scope_variable = input_param + kConstantFloat;
return in_scope_variable * _private_member_variable;
}
void setPrivateMember(const float private_member_variable) { _private_member_variable = private_member_variable; }
/**
* @return Whatever we are "getting" [units]
*/
float getPrivateMember() const { return _private_member_variable; }
private:
// Clear description of the constant if not completely obvious from the name [units]
static constexpr float kConstantFloat = ...;
// Clear description of the variable if not completely obvious from the name [units]
float _private_member_variable{...};
};
```
## Вбудована документація
PX4 розробників заохочують до створення відповідної документації через джерело.
::: info
Стандарти документації вихідного коду не застосовуються, і код в даний час непослідовно документований.
Ми б хотіли зробити краще!
:::
В даний час у нас є два типи базової документації:
- `PRINT_MODULE_*` methods are used for both module run time usage instructions and for the [Modules & Commands Reference](../modules/modules_main.md) in this guide.
- The API is documented [in the source code here](https://github.com/PX4/PX4-Autopilot/blob/v1.8.0/src/platforms/px4_module.h#L381).
- Good examples of usage include the [Application/Module Template](../modules/module_template.md) and the files linked from the modules reference.
- We encourage other in-source documentation _where it adds value/is not redundant_.
:::tip
Developers should name C++ entities (classes, functions, variables etc.) such that their purpose can be inferred - reducing the need for explicit documentation.
:::
- Не додавати документацію, яку тривіально можна вивести з імен об'єктів С++.
- ЗАВЖДИ вказуйте одиниці змінних, констант і параметрів введення/повернення там, де вони визначені.
- ЗАВЖДИ вказуйте одиниці змінних, постійних і параметрів введення/повернення там, де вони визначені.
- [Doxgyen](http://www.doxygen.nl/) tags should be used if documentation is needed: `@class`, `@file`, `@param`, `@return`, `@brief`, `@var`, `@see`, `@note`.
A good example of usage is [src/modules/events/send_event.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/events/send_event.h).
Будь ласка, уникайте "магічних чисел", наприклад, звідки прийшло це число? А як щодо множника при введенні ручки повороту?
```cpp
if (fabsf(yaw_stick_normalized_input) < 0.1f) {
yaw_rate_setpoint = 0.0f;
}
else {
yaw_rate_setpoint = 0.52f * yaw_stick_normalized_input;
}
```
Натомість визначте цифри як константи з відповідним контекстом у заголовку:
```cpp
// Порогове значення мертвої зони для нормалізованого введення повороту
static constexpr float kYawStickDeadzone = 0.1f;
// [рад/с] Порогове значення мертвої зони для нормалізованого введення повороту
static constexpr float kMaxYawRate = math::radians(30.0f);
```
і оновіть реалізацію вихідного коду.
```cpp
if (fabsf(yaw_stick_normalized_input) < kYawStickDeadzone) {
yaw_rate_setpoint = 0.0f;
}
else {
yaw_rate_setpoint = kMaxYawRate * yaw_stick_normalized_input;
}
```
## Коміти та повідомлення комітів
Використовуйте описові повідомлення з кількома абзацами для всіх нетривіальних змін.
Добре структуруйте їх, щоб вони мали сенс у підсумку в один рядок, але також надавали повну деталізацію.
```plain
Component: Explain the change in one sentence. Fixes #1234
Prepend the software component to the start of the summary
line, either by the module name or a description of it.
(e.g. "mc_att_ctrl" or "multicopter attitude controller").
If the issue number is appended as <Fixes #1234>, Github
will automatically close the issue when the commit is
merged to the master branch.
The body of the message can contain several paragraphs.
Describe in detail what you changed. Link issues and flight
logs either related to this fix or to the testing results
of this commit.
Describe the change and why you changed it, avoid to
paraphrase the code change (Good: "Adds an additional
safety check for vehicles with low quality GPS reception".
Bad: "Add gps_reception_check() function").
Reported-by: Name <email@px4.io>
```
**Use **`git commit -s`** to sign off on all of your commits.** This will add `signed-off-by:` with your name and email as the last line.
This commit guide is based on best practices for the Linux Kernel and other [projects maintained](https://github.com/torvalds/subsurface-for-dirk/blob/a48494d2fbed58c751e9b7e8fbff88582f9b2d02/README#L88-L115) by Linus Torvalds.
## Запити на злиття
Github [Pull Requests (PRs)](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) are the primary mechanism used to submit new functionality and bug fixes to PX4.
They include the new set of [commits](#commits-and-commit-messages) in your branch (relative the main branch), and a description of the changes.
Опис повинен включати:
- Огляд того, що доставляють дані зміни; достатньо для розуміння широкої мети коду
- Посилання на пов'язані з питаннями або підтримка інформації.
- Інформація про те як було виконано тестування PR функціональності з посиланнями на журнали польотів.
- Where possible, the results from general [Test Flights](../test_and_ci/test_flights.md) both before and after the change.
docs/uk/contribute/dev_call.md
+39
View File
@@ -0,0 +1,39 @@
# Weekly Community Q&A Call (Previously "Dev Call")
<script setup>
import { useData } from 'vitepress'
const { site } = useData();
</script>
<div v-if="site.title !== 'PX4 Guide (main)'">
<div class="custom-block danger">
<p class="custom-block-title">Ця сторінка може бути застарілою. <a href="https://docs.px4.io/main/en/contribute/dev_call.html">Подивіться останню версію</a>.</p>
</div>
</div>
Команда розробників PX4 і спільнота збираються разом, щоб обговорити будь-яку тему, яка цікавить спільноту, починаючи від вирішення проблем і закінчуючи задоволенням вашої цікавості.
## Хто повинен відвідувати ці дзвінки?
- Основні розробники проєкту PX4
- Розробники компонентів
- Test team lead
- Учасники Dronecode
- Члени спільноти (ви!)
:::tip
The Community Q&A call is open to all interested community members.
Це чудова можливість зустрітися з командою і зробити свій внесок у розвиток платформи.
:::
## Що буде обговорюватись?
We publish a forum post per meeting a week before the call on [PX4 Discuss - weekly-dev-call](https://discuss.px4.io/c/weekly-dev-call) and track the agenda write down the discussion for the day. Ми будемо раді будь-яким темам, про які ви, як учасник спільноти хочете задати питання чи просто обговорити!
Будь ласка, додайте ваші теми для обговорення до порядку денного перед початком зустрічі, відповівши на нотатку зустрічі. Це допоможе вам сформулювати ваші запитання більш чітко, і дозволить нам подумати про них заздалегідь.
## Розклад
- TIME: Wednesday 17h00 CET ([subscribe to calendar](https://www.dronecode.org/calendar/))
- **Join the call**: [https://discord.gg/BDYmr6FA6Q](https://discord.gg/BDYmr6FA6Q)
docs/uk/contribute/docs.md
+274
View File
@@ -0,0 +1,274 @@
# Доповнення до документації
Внески до Керівництва користувачів PX4 дуже вітаються; від простих виправлень до правопису та граматики, до створення абсолютно нових секцій.
Ця тема пояснює, як зробити та протестувати зміни.
В кінці є посібник з базового стилю.
:::tip
Note
You will need a (free) [GitHub](https://github.com/) account to contribute to the guides.
:::
## Швидкі зміни в Github
Simple changes to _existing content_ can be made by clicking the **Edit on GitHub** link that appears at the bottom of every page (this opens the page on Github for editing).
![Vitepress: Edit Page button](../../assets/vuepress/vuepress_edit_page_on_github_link.png)
Щоб редагувати існуючу сторінку:
1. Відкрийте сторінку
2. Click the **Edit on GitHub** link below the page content.
3. Зробіть необхідні зміни.
4. Below the Github page editor you'll be prompted to create a separate branch and then guided to submit a _pull request_.
Команда документації перегляне запит і або об'єднає його, або працює з вами, щоб оновити його.
## Зміни за допомогою Git (Нові сторінки та зображення)
Більш суттєві зміни, включаючи додавання нових сторінок або додавання/зміну зображень, не такі прості для внесення (або належним чином протестувати) на Github.
For these kinds of changes we suggest using the same approach as for _code_:
1. Use the _git_ toolchain to get the documentation source code onto your local computer.
2. Внесіть потрібні зміни в документацію (додайте, змініть, видаліть).
3. _Test_ that it builds properly using Vitepress.
4. Створіть гілку для ваших змін і створіть запит на витягнення (PR), щоб втягнути їх назад у документацію.
Нижче пояснено, як отримати вихідний код, побудувати локально (для тестування) та внести зміни в код.
### Get/Push документація вихідного коду
Щоб отримати джерела бібліотеки(ів) на свій локальний комп'ютер, вам потрібно використовувати інструментарій git.
Нижче наведено інструкції, як отримати git і використовувати його на своєму локальному комп'ютері.
1. Download git for your computer from [https://git-scm.com/downloads](https://git-scm.com/downloads)
2. [Sign up](https://github.com/join) for Github if you haven't already
3. Create a copy (Fork) of the [PX4 User Guide repo](https://github.com/PX4/PX4-user_guide) on Github ([instructions here](https://docs.github.com/en/get-started/quickstart/fork-a-repo)).
4. Клонуйте ваш форкнутий репозиторій на локальний комп'ютер:
```sh
cd ~/wherever/
git clone https://github.com/<your git name>/PX4-user_guide.git
```
Наприклад, щоб клонувати форк посібника користувача PX4 для користувача з обліковим записом Github "john_citizen":
```sh
git clone https://github.com/john_citizen/PX4-user_guide.git
```
5. Перейдіть до свого локального сховища:
```sh
cd ~/wherever/PX4-user_guide
```
6. Add a _remote_ called "upstream" to point to the PX4 version of the library:
```sh
git remote add upstream https://github.com/PX4/PX4-user_guide.git
```
:::tip
A "remote" is a handle to a particular repository.
The remote named _origin_ is created by default when you clone the repository, and points to _your fork_ of the guide.
Above you create a new remote _upstream_ that points to the PX4 project version of the documents.
:::
7. Створити гілку для ваших змін:
```sh
git checkout -b <your_feature_branch_name>
```
This creates a local branch on your computer named `your_feature_branch_name`.
8. Внести зміни до документації за необхідною (загальний посібник по цьому в наступних розділах)
9. Коли ви будете задоволені своїми змінами, ви можете додати їх до вашої локальної гілки за допомогою "commit":
```sh
git add <file name>
git commit -m "<your commit message>"
```
For a good commit message, please refer to the [Source Code Management](../contribute/code.md#commits-and-commit-messages) section.
10. Натисніть "Push" вашу локальну гілку (включаючи додані до неї коміти) у вашу репозиторію-форк на Github.
```sh
git push origin your_feature_branch_name
```
11. Go to your forked repository on Github in a web browser, e.g.: `https://github.com/<your git name>/PX4-user_guide.git`.
Там ви маєте побачити повідомлення, що нова гілка була відправлена у вашу репозиторію-форк.
12. Створіть запит на витягнення (Pull Request, PR):
- On the right hand side of the "new branch message" (see one step before), you should see a green button saying "Compare & Create Pull Request".
Натисніть на неї.
- Буде створено шаблон запиту на витягнення.
Він буде перераховувати ваші коміти, і ви можете (маєте) додати значущий заголовок (у випадку одного коміту PR, це зазвичай повідомлення про коміт) та повідомлення (<span style="color:orange">поясніть, що ви зробили і для якої причини. </span>.
Check [other pull requests](https://github.com/PX4/PX4-user_guide/pulls) for comparison)
13. Готово!
Редактори PX4 User Guide зараз переглянуть вашу співпрацю і вирішать, чи хочуть вони інтегрувати її.
Періодично перевіряйте, чи є у них питання по вашим змінам.
### Побудова бібліотеки локально
Побудуйте бібліотеку локально, щоб перевірити, що будь-які зміни, які ви внесли, відображені належним чином:
1. Install the [Vitepress prerequisites](https://vitepress.dev/guide/getting-started#prerequisites):
- [Nodejs 18+](https://nodejs.org/en)
- [Yarn classic](https://classic.yarnpkg.com/en/docs/install)
2. Перейдіть до свого локального сховища:
```sh
cd ~/wherever/PX4-user_guide
```
3. Встановити залежності (включаючи Vuepress):
```sh
yarn install
```
4. Попередній перегляд і обслуговування бібліотеки:
```sh
yarn docs:dev
```
- Одного разу, коли сервер розробки / попереднього перегляду побудує бібліотеку (менше хвилини вперше), він покаже вам URL-адресу, за допомогою якої ви можете переглянути сайт.
This will be something like: `http://localhost:5173/px4_user_guide/`.
- Stop serving using **CTRL+C** in the terminal prompt.
5. Open previewed pages in your local editor:
First specify a local text editor file using the `EDITOR` environment variable, before calling `yarn start` to preview the library.
For example, on Windows command line you can enable VSCode as your default editor by entering:
```sh
set EDITOR=code
```
The **Open in your editor** link at the bottom of each page will then open the current page in the editor (this replaces the _Open in GitHub_ link).
6. Побудуйте бібліотеку за допомогою:
```sh
# Ubuntu
yarn docs:build
# Windows
yarn docs:buildwin
```
:::tip
Use `yarn start` to preview changes _as you make them_ (documents are updated and served very quickly).
Before submitting a PR you should also build it using `yarn docs:build`, as this can highlight issues that are not visible when using `yarn start`.
:::
### Структура Вихідного Коду
The guide uses the [Vitepress](https://vitepress.dev/) toolchain.
На огляд:
- Сторінки записуються окремими файлами, використовуючи markdown.
- Синтаксис майже такий самий, як і Github wiki.
- Vitepress also supports some [markdown extensions](https://vitepress.dev/guide/markdown#markdown-extensions).
We try and avoid using these, except for [tips, warning, etc.](https://vitepress.dev/guide/markdown#default-title).
Це можна переглянути – є кілька цікавих варіантів!
- This is a [multilingual](https://vitepress.dev/guide/i18n) book:
- Сторінки для кожної мови зберігаються в папці з назвою для асоційованого мовного коду (наприклад, "zh" для китайської, "ko" для корейської).
- Only edit the ENGLISH (`/en`) version of files.
We use [Crowdin](../contribute/translation.md) to manage the translations.
- All pages must be in an appropriately named sub-folder of `/en` (e.g. this page is in folder `en/contribute/`).
- Це полегшує створення посилань, оскільки інші сторінки і зображення завжди будуть на тому ж рівні
- The _structure_ of the book is defined in `SUMMARY.md`.
- Якщо ви додаєте нову сторінку до посібника, вам також потрібно додати запис до цього файлу!
:::tip
This is not "standard vitepress" way to define the sidebar (the summary file is imported by [.vitepress/get_sidebar.js](https://github.com/PX4/PX4-user_guide/blob/main/.vitepress/get_sidebar.js)).
:::
- Images must be stored in a sub folder of `/assets`.
Це на два рівні нижче від папок з вмістом, тому якщо ви додаєте зображення, ви посилаєтеся на нього так:
```plain
![Image Description](../../assets/path_to_file/filename.jpg)
```
- A file named **package.json** defines any dependencies of the build.
- Веб-хук використовується для відстеження моменту злиття файлів у головну гілку цього репозиторію, що призводить до перебудови книги.
### Додавання нових сторінок
When you add a new page you must also add it to `en/SUMMARY.md`!
## Інструкція зі стилістичного оформлення
1. Назви файлів/файлів
- Put new markdown files in an appropriate sub-folder of `/en/`, such as `/en/contribute/`.
Не створюйте додаткових вкладених папок.
- Put new image files in an appropriate nested sub-folder of `/assets/`.
Deeper nesting is allowed/encouraged.
- Use descriptive names for folders and files.
In particular, image filenames should describe what they contain (don't name as "image1.png")
- Use lower case filenames and separate words using underscores (`_`).
2. Зображення
- Використовуйте найменший розмір і найнижчу роздільну здатність, яка все ще робить зображення корисним (це зменшує вартість завантаження для користувачів із слабким інтернет-з'єднанням).
- New images should be created in a sub-folder of `/assets/` (so they can be shared between translations).
- SVG files are preferred for diagrams.
PNG files are preferred over JPG for screenshots.
3. Контент
- Use "style" (**bold**, _emphasis_, etc.) consistently and sparingly (as little as possible).
- **Bold** for button presses and menu definitions.
- _Emphasis_ for tool names such as _QGroundControl_ or _prettier_.
- `code` for file paths, and code, parameter names that aren't linked, using tools in a command line, such as `prettier`.
- Headings and page titles should use "First Letter Capitalisation".
- The page title should be a first level heading (`#`).
All other headings should be h2 (`##`) or lower.
- Не додавати ніяких стилів до заголовків.
- Don't translate the text indicating the name of an `info`, `tip` or `warning` declaration (e.g. `::: tip`) as this precise text is required to render the aside properly.
- Break lines on sentences by preference.
Don't break lines based on some arbitrary line length.
- Format using _prettier_ (_VSCode_ is a has extensions can be used for this).
4. Videos:
- Youtube videos can be added using the format `<lite-youtube videoid="<youtube-video-id>" title="your title"/>` (supported via the [https://www.npmjs.com/package/lite-youtube-embed](https://www.npmjs.com/package/lite-youtube-embed) custom element, which has other parameters you can pass).
- Use instructional videos sparingly as they date badly, and are hard to maintain.
- Cool videos of airframes in flight are always welcome.
## Де я можу додати зміни?
Add new files in folders that cover similar topics.
Then reference them in the sidebar (`/en/SUMMARY.md`) in line with the existing structure!
## Переклади
For information about translation see: [Translation](../contribute/translation.md).
## Ліцензія
All PX4/Dronecode documentation is free to use and modify under terms of the permissive [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) license.
docs/uk/contribute/git_examples.md
+305
View File
@@ -0,0 +1,305 @@
# Приклад GIT
<a id="contributing_code"></a>
## Внесок коду у PX4
Додавання функції до PX4 слідує за визначеним робочим процесом. Щоб поділитися своїми внесками в PX4, ви можете слідувати цьому прикладу.
- [Sign up](https://github.com/join) for github if you haven't already
- Fork the PX4-Autopilot repo (see [here](https://docs.github.com/en/get-started/quickstart/fork-a-repo))
- Клонуйте ваш форкнутий репозиторій на локальний комп'ютер
```sh
cd ~/wherever/
git clone https://github.com/<your git name>/PX4-Autopilot.git
```
- Зайдіть в новий каталог, ініціалізуйте та оновіть підмодулі, і додайте оригінальні upstream PX4-Autopilot
```sh
cd PX4-Autopilot
git submodule update --init --recursive
git remote add upstream https://github.com/PX4/PX4-Autopilot.git
```
- You should have now two remote repositories: One repository is called `upstream` that points to PX4/PX4-Autopilot, and one repository `origin` that points to your forked copy of the PX4 repository.
- Це може бути відмічено наступною командою:
```sh
git remote -v
```
- Внесіть зміни, які ви хочете додати до основного.
- Створіть нову гілку з значущим ім'ям, яке репрезентує вашу функцію
```sh
git checkout -b <your feature branch name>
```
you can use the command `git branch` to make sure you're on the right branch.
- Додайте зміни, які ви хочете бути частиною коміту, додавши відповідні файли
```sh
git add <file name>
```
If you prefer having a GUI to add your files see [Gitk](https://git-scm.com/book/en/v2/Git-in-Other-Environments-Graphical-Interfaces) or [`git add -p`](http://nuclearsquid.com/writings/git-add/).
-
```sh
git commit -m "<your commit message>"
```
For a good commit message, please refer to the [Source Code Management](../contribute/code.md#commits-and-commit-messages) section.
- Some time might have passed and the [upstream main](https://github.com/PX4/PX4-Autopilot.git) has changed.
PX4 prefers a linear commit history and uses [git rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing).
Щоб включити найновіші зміни з початкової версії до локальної гілки, перейдіть до головної гілки
```sh
git checkout main
```
Потім зтягнути найновіші коміти з upstream main
```sh
git pull upstream main
```
Тепер ваш локальний головний репозиторій оновлений.
Поверніться до своєї функціональної гілки та перебазуйте свою оновлену основну
```sh
git checkout <your feature branch name>
git rebase main
```
- Тепер ви можете відправляти свої локальні коміти у свій форкований репозиторій
```sh
git push origin <your feature branch name>
```
- You can verify that the push was successful by going to your forked repository in your browser: `https://github.com/<your git name>/PX4-Autopilot.git`
Там ви маєте побачити повідомлення, що нова гілка була відправлена у вашу репозиторію-форк.
- Тепер настав час створити запит на злиття (PR).
On the right hand side of the "new branch message" (see one step before), you should see a green button saying "Compare & Create Pull Request".
Потім у ньому має бути перелік ваших змін, і ви можете (обов’язково) додати змістовний заголовок (у випадку PR з одним комітом, зазвичай це повідомлення коміту) і повідомлення (<span style="color:orange">пояснити, що ви зробили, з якої причини</span>.
Check [other pull requests](https://github.com/PX4/PX4-Autopilot/pulls) for comparison)
- Готово!
Відповідальні учасники PX4 тепер побачать ваш внесок і вирішать, чи хочуть вони інтегрувати його.
Періодично перевіряйте, чи є у них питання по вашим змінам.
##
We recommend using PX4 `make` commands to switch between source code branches.
Це позбавить вас від необхідності запам’ятовувати команди для оновлення підмодулів і очищення артефактів збірки (файли збірки, які не видалено, призведуть до помилок «невідстежуваних файлів» після перемикання).
Переключитися між гілками:
1. Очистити поточну гілку, деініціалізувати підмодуль та видалити всі артефакти збірки:
```sh
make clean
make distclean
```
2. Switch to a new branch or tag (here we first fetch the fictional branch "PR_test_branch" from the `upstream` remote):
```sh
git fetch upstream PR_test_branch
git checkout PR_test_branch
```
3. Отримати підмодулі для нової гілки:
```sh
make submodulesclean
```
<!-- FYI: Cleaning commands in https://github.com/PX4/PX4-Autopilot/blob/main/Makefile#L494 -->
## Отримання конкретного релізу
Specific PX4 point releases are made as tags of the [release branches](#get-a-release-branch), and are named using the format `v<release>`.
These are [listed on Github here](https://github.com/PX4/PX4-Autopilot/releases?q=release\&expanded=true) (or you can query all tags using `git tag -l`).
To get the source code for a _specific older release_ (tag):
1. Clone the PX4-Autopilot repo and navigate into _PX4-Autopilot_ directory:
```sh
git clone https://github.com/PX4/PX4-Autopilot.git
cd PX4-Autopilot
```
:::info
Ви можете повторно використовувати існуючий репозиторій, а не клонувати новий.
In this case clean the build environment (see [changing source trees](#changing-source-trees)):
```sh
make clean
make distclean
```
:::
2. Код оформлення замовлення для конкретного тегу (наприклад, для мітки v1.13.0-beta2)
```sh
git checkout v1.13.0-beta2
```
3. Оновити підмодулі:
```sh
make submodulesclean
```
## Щоб отримати гілку релізу
Releases branches are branched of `main`, and used to backport necessary changes from main into a release.
The branches are named using the format `release/<release_number>` (e.g. `release/v1.13`).
The are [listed here](https://github.com/PX4/PX4-Autopilot/branches/all?query=release).
Щоб отримати гілку релізу:
- Clone the PX4-Autopilot repo and navigate into _PX4-Autopilot_ directory:
```sh
git clone https://github.com/PX4/PX4-Autopilot.git
cd PX4-Autopilot
```
:::info
Ви можете повторно використовувати існуючий репозиторій, а не клонувати новий.
In this case clean the build environment (see [changing source trees](#changing-source-trees)):
```sh
make clean
make distclean
```
:::
- Отримати бажану гілку релізу.
Наприклад, припустимо, що ви хочете джерело для PX4 v1.14:
```sh
git fetch origin release/1.14
```
- Перевірте код гілки
```sh
git checkout release/1.14
```
- Оновити підмодулі:
```sh
make submodulesclean
```
## Оновити підмодулі
Існує кілька способів оновлення підмодуля.
Either you clone the repository or you go in the submodule directory and follow the same procedure as in [Contributing code to PX4](#contributing_code).
## Робити PR для оновлення підмодуля
Це необхідно після того, як ви зробили PR для репозиторію підмодуля X і виправлення помилки/додавання функції є в поточному основному основному підмодулю X. Оскільки прошивка все ще вказує на твердження до вашого оновлення, підмодуль запит на злиття обов'язковий таким чином, щоб підмодуль використовувався точками прошивки до найновішого коміту.
```sh
cd Firmware
```
- Створити нову гілку, яка описує виправлення / функцію оновлення підмодулів:
```sh
git checkout -b pr-some-fix
```
- Перейти до підкаталогу підмодулів
```sh
cd <path to submodule>
```
- Підмодуль PX4 не обов'язково вказує на найновіший коміт. Тому для того, для того, щоб оформити замовлення основного і витягнути найновіший код першоджерела.
```sh
git checkout main
git pull upstream main
```
- Поверніться до каталогу прошивки та, як зазвичай, додайте, зафіксуйте та надішліть зміни.
```sh
cd -
git add <path to submodule>
git commit -m "Update submodule to include ..."
git push upstream pr-some-fix
```
## Checkout pull requests
Ви можете перевірити чийсь запит на злиття (зміни ще не злиті), навіть якщо гілка зливання існує лише на форку з цієї людини. Зробіть наступне:
```sh
git fetch upstream pull/<PR ID>/head:<branch name>
```
`PR ID` is the number right next to the PR's title (without the #) and the `<branch name>` can also be found right below the `PR ID`, e.g. `<the other persons git name>:<branch name>`. Після цього ви зможете побачити новостворену гілку локально за допомогою
```sh
git branch
```
Потім перейдіть на цю гілку
```sh
git checkout <branch name>
```
## Common pitfalls
### Force push to forked repository
Після завершення першого PR, люди зі спільноти PX4 переглянуть ваші зміни. У більшості випадків це означає, що ви повинні виправити свою місцеву гілку відповідно до розгляду. Після локальної зміни файлів гілку функцій потрібно знову базувати з останньою версією upstream/main. Однак після перебазування більше неможливо надіслати гілку функцій у ваш розгалужений репозиторій напряму, замість цього вам потрібно використати force push:
```sh
git push --force-with-lease origin <your feature branch name>
```
### Rebase merge conflicts
If a conflict occurs during a `git rebase`, please refer to [this guide](https://docs.github.com/en/get-started/using-git/resolving-merge-conflicts-after-a-git-rebase).
### Pull merge conflicts
If a conflict occurs during a `git pull`, please refer to [this guide](https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/#competing-line-change-merge-conflicts).
### Помилка збірки через застарілі git теги
The build error `Error: PX4 version too low, expected at least vx.x.x` occurs if git tags are out of date.
Це можна вирішити шляхом отримання тегів репозиторію upstream :
```sh
git fetch upstream --tags
```
docs/uk/contribute/index.md
+29
View File
@@ -0,0 +1,29 @@
# Спільнота
<script setup>
import { useData } from 'vitepress'
const { site } = useData();
</script>
<div v-if="site.title !== 'PX4 Guide (main)'">
<div class="custom-block danger">
<p class="custom-block-title">Ця сторінка може бути застарілою. <a href="https://docs.px4.io/main/en/contribute/">Переглянути останню версію</a>.</p>
</div>
</div>
Ласкаво просимо до Спільноти PX4!
:::tip
We pledge to adhere to the [PX4 code of conduct](https://github.com/PX4/PX4-Autopilot/blob/main/CODE_OF_CONDUCT.md), which aims to foster an open and welcoming environment.
:::
Цей розділ містить інформацію про те, як ви можете зустрітися зі спільнотою та зробити внесок до PX4:
- [Dev Call](../contribute/dev_call.md) - Discuss architecture, pull requests, impacting issues with the dev team
- [Maintainers](./maintainers.md) - Maintainers of PX4 Subsystems and Ecosystem
- [Support](../contribute/support.md) - Get help and raise issues
- [Source Code Management](../contribute/code.md) - Work with PX4 code
- [Documentation](../contribute/docs.md) - Improve the docs
- [Translation](../contribute/translation.md) - Translate using Crowdin
- [Terminology/Notation](../contribute/notation.md) - Terms and symbols used in the docs
- [Licenses](../contribute/licenses.md) - PX4 and Pixhawk licensing
docs/uk/contribute/licenses.md
+12
View File
@@ -0,0 +1,12 @@
# Ліцензії
:::info
All code contributions must be made under the permissive [BSD 3-clause license](https://opensource.org/licenses/BSD-3-Clause) and must not impose any further constraints on its use.
:::
На цій сторінці документуються ліцензії різних компонентів в системі.
- [PX4 Flight Stack](https://github.com/PX4/PX4-Autopilot) &mdash; BSD
- [PX4 Middleware](https://github.com/PX4/PX4-Autopilot) &mdash; BSD
- [Pixhawk Hardware](https://github.com/PX4/Hardware) &mdash; CC-BY-SA 3.0
- [PX4 User Guide](https://github.com/PX4/PX4-user_guide) (Documentation) &mdash; [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).
docs/uk/contribute/maintainers.md
+76
View File
@@ -0,0 +1,76 @@
# Maintainer Role
Dronecode maintainers have technical leadership and responsibility for specific areas of PX4, and for other ecosystem components such as MAVLink, MAVSDK, QGroundControl, and others.
The maintainer role is defined by the community with help and supervision from the [Dronecode Foundation](https://www.dronecode.org/).
To find the most up-to-date maintainers list, visit [PX4-Autopilot README](https://github.com/PX4/PX4-Autopilot#maintenance-team).
## Recruitment Process
If you would like to join the PX4 maintainers team or if you want to nominate someone else follow the steps below:
1. Read the [role description](#dronecode-maintainer-role-description), and make sure you understand the responsibilities of the role.
2. To nominate yourself, reach out to one of the maintainers (see the complete list in the [PX4-Autopilot README](https://github.com/PX4/PX4-Autopilot#maintenance-team)), and seek their sponsorship.
3. Express your interest in becoming a maintainer, and specify which area you would like to maintain.
4. The sponsoring maintainer needs to bring this up for discussion in one of the [weekly developer calls](dev_call.md).
The maintainer team will vote on the call to determine whether to accept you as a maintainer.
## Onboarding Process
Once accepted every maintainers will go through the following process:
1. **Discord** server admin will grant you the `dev team` role, which gives you:
1. Basic admin privileges on discord.
2. Access to the `#maintainers` channel.
2. You will be given access to the GitHub team: "[`Dev Team`](https://github.com/orgs/PX4/teams/dev-team)" which grants you:
1. Permission to merge the PR of any of PX4 workspace repositories after it's approved
2. Permission to trigger GitHub actions when a new contributor opens a PR.
3. Permission to edit Issue/PR contents.
3. **Add your info to official PX4 channels**:
1. Include your information on the PX4 [README](https://github.com/PX4/PX4-Autopilot/blob/main/README.md) next to the rest of the team
2. Listed on the [Maintainers section](https://px4.io/community/maintainers/) of the PX4 website.
3. Add your information to the internal Dronecode database of maintainers to keep you in sync.
4. Community introduction to the new maintainer in the form of a forum post, which is promoted through ever growing official channels
## Dronecode Maintainer Role Description
### Опис
Maintainers lead/manage the development of a **specific category (referred to as category below)** of any Open Source Projects hosted within the Dronecode Foundation, such as the PX4 Autopilot.
### Responsibilities
1. Take charge of overseeing the development in their category.
2. Provide guidance/advice on community members in their category.
3. Review relevant pull requests and issues from the community on GitHub.
4. Coordinate with the maintainer group.
5. Keep regular attendance on [weekly meetings ](dev_call.md).
6. Help create and maintain a roadmap for the project your represent.
7. Uphold the [Code of Conduct](https://github.com/Dronecode/foundation/blob/main/CODE-OF-CONDUCT.md) of our community.
### Qualifications
1. Proven track record of valuable contributions.
2. Domain expertise in the category field.
3. Good overview of the project you are applying to.
4. You need to manage approval from your employer when relevant.
### Perks
1. **Official recognition** as the maintainer in Dronecode/PX4 website, documentation, community and social media.
2. **Github & Discord privileges** (described in the [onboarding process](#onboarding-process)).
3. Priority placement to the yearly **PX4 Developer Summit** scholarship which helps you with travel reimbursement.
### Tools we Provide to Assist You
Dronecode will provide the following tools to help you:
1. **Community survey**: If you need any insight into the community's opinion, we will send out social media posts, mailing lists, announcements in Discord server to get that answer for you.
2. **Workflow automation**: We will provide workflow for PR/Issue review & tagging process to help you.
And as always, don't hesitate to reach out if you need help with anything.
We are here for you!
### Point of Contact
Regarding questions about the maintainer role, please contact the maintainer team.
docs/uk/contribute/notation.md
+97
View File
@@ -0,0 +1,97 @@
# Термінологія
Наступні терміни, символи та декоратори використовуються в тексті та діаграмах протягом цього керівництва.
## Записка
- Жирним шрифтом позначаються вектори або матриці, а нежирним - скаляри.
- Стандартна система координат для кожної змінної - місцева система координат: $\ell{}$.
Right [superscripts](#superscripts) represent the coordinate frame.Якщо правий верхній індекс відсутній, то припускається, що використовується стандартна система координат $\ell{}$.
Виняток становлять матриці обертання, де нижні праві індекси вказують поточну систему координат, а верхні праві індекси - цільову систему координат.
- Змінні та нижні символи можуть використовувати однакові літери, але вони завжди мають різне значення.
## Акроніми
| Акронім | Розшифровка |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AOA | Кут атаки. Also named _alpha_. |
| AOS | Кут бокового зсуву Also named _beta_. |
| FRD | Система координат, де вісь X вказує напрямок до передньої частини транспортного засобу, вісь Y вказує напрямок праворуч, а вісь Z вказує напрямок вниз, завершуючи правило правої руки. |
| FW | Закріплені крила (літаки). |
| MC | Мультикоптери. |
| MPC або MCPC | Контролер позиції багатокоптера&#xA;MPC також використовується для Model Predictive Control (Модельно-прогностичне управління). |
| NED | Система координат, де вісь X вказує напрямок до справжнього Північного полюса, вісь Y вказує напрямок східної сторони, а вісь Z вказує напрямок вниз, завершуючи правило правої руки. |
| PID | Контролер з пропорційною, інтегральною та диференціальною діями. |
## Символи
| Змінні | Опис |
| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| $x,y,z$ | Переміщення вздовж координатних осей x, y та z відповідно. |
| $\boldsymbol{\mathrm{r}}$ | Вектор позиції: $\boldsymbol{\mathrm{r}} = [x \quad y \quad z]^T$ |
| $\boldsymbol{\mathrm{v}}$ | Вектор швидкості: $\boldsymbol{\mathrm{v}} = \boldsymbol{\mathrm{\dot{r}}}$ |
| $\boldsymbol{\mathrm{a}}$ | Прискорення vector: $\boldsymbol{\mathrm{a}} = \boldsymbol{\mathrm{\dot{v}}} = \boldsymbol{\mathrm{\ddot{r}}}$ |
| $\alpha$ | Кут атаки (AOA). |
| $b$ | Розмах крила (від кінчика до кінчика). |
| $S$ | Площа крила |
| $AR$ | Аспектне відношення: $AR = \frac{b^2}{S}$ |
| $\beta$ | Кут бокового зсуву (AOS) |
| $c$ | Довжина хорди крила |
| $\delta$ | Кутове відхилення аеродинамічної керуючої поверхні Позитивне відхилення породжує негативний момент. |
| $\phi,\theta,\psi$ | Euler angles roll (=Bank), pitch and yaw (=Heading). |
| $\Psi$ | Attitude vector: $\Psi = [\phi \quad \theta \quad \psi]^T$ |
| $X,Y,Z$ | Сили вздовж координатних осей x, y та z. |
| $\boldsymbol{\mathrm{F}}$ | Вектор сили: $\boldsymbol{\mathrm{F}} = [X \quad Y \quad Z]^T$ |
| $D$ | Сила опору |
| $C$ | Сила бічного вітру |
| $L$ | Сила підйому |
| $g$ | Гравітація |
| $l,m,n$ | Моменти навколо координатних осей x, y та z. |
| $\boldsymbol{\mathrm{M}}$ | Вектор моменту: $\boldsymbol{\mathrm{M}} = [l \quad m \quad n]^T$v |
| $M$ | Mach number. Може бути ігноровано для масштабних літаків. |
| $\boldsymbol{\mathrm{q}}$ | Векторна частина кватерніону |
| $\boldsymbol{\mathrm{\tilde{q}}}$ | Hamiltonian attitude quaternion (see `1` below) |
| $\boldsymbol{\mathrm{R}}_\ell^b$ | Матриця повороту. Повертає вектор із системи координат $\ell{}$ в систему координат $b{}$. $\boldsymbol{\mathrm{v}}^b = \boldsymbol{\mathrm{R}}_\ell^b \boldsymbol{\mathrm{v}}^\ell$ |
| $\Lambda$ | Кут нахилу переднього краю |
| $\lambda$ | Відношення залишкової хорди: $\lambda = \frac{c_{tip}}{c_{root}}$ |
| $w$ | Швидкість вітру. |
| $p,q,r$ | Кутові швидкості навколо тілесних осей x, y та z. |
| $\boldsymbol{\omega}^b$ | Вектор кутової швидкості в тілесній системі координат: $\boldsymbol{\omega}^b = [p \quad q \quad r]^T$ |
| $\boldsymbol{\mathrm{x}}$ | Загальний вектор стану |
- `1` Hamiltonian attitude quaternion. $\boldsymbol{\mathrm{\tilde{q}}} = (q_0, q_1, q_2, q_3) = (q_0, \boldsymbol{\mathrm{q}})$.<br> $\boldsymbol{\mathrm{\tilde{q}}}{}$ describes the attitude relative to the local frame $\ell{}$. To represent a vector in local frame given a vector in body frame, the following operation can be used: $\boldsymbol{\mathrm{\tilde{v}}}^\ell = \boldsymbol{\mathrm{\tilde{q}}} \, \boldsymbol{\mathrm{\tilde{v}}}^b \, \boldsymbol{\mathrm{\tilde{q}}}^_{}$ (or $\boldsymbol{\mathrm{\tilde{q}}}^{-1}{}$ instead of $\boldsymbol{\mathrm{\tilde{q}}}^_{}$ if $\boldsymbol{\mathrm{\tilde{q}}}{}$ is not unitary). $\boldsymbol{\mathrm{\tilde{v}}}{}$ represents a _quaternionized_ vector: $\boldsymbol{\mathrm{\tilde{v}}} = (0,\boldsymbol{\mathrm{v}})$
### Нижні індекси / Показники
| Нижні індекси / Показники | Опис |
| ------------------------- | ----------------------------------------------------------------------------------------------------- |
| $a$ | Aileron. |
| $e$ | Elevator. |
| $r$ | Руль |
| $Aero$ | Аеродинаміка |
| $T$ | Сила тяги |
| $w$ | Відносна швидкість повітря |
| $x,y,z$ | Компонент вектора вздовж осі x, y та z. |
| $N,E,D$ | Компонент вектора вздовж глобального північного, східного та вертикального напрямків. |
<a id="superscripts"></a>
### Верхні індекси / Показники
| Верхні індекси / Показники | Опис |
| -------------------------- | --------------------------------------------------------------------------------- |
| $\ell$ | Місцева система координат Стандарт для змінних, пов'язаних з PX4. |
| $b$ | Тілесна система координат |
| $w$ | Вітрова система координат |
## Декоратори:
| Декоратор | Опис |
| ------------------------------- | -------------------------------------- |
| $()^\*$ | Комплексне відмінювання |
| $\dot{()}$ | Часова похідна |
| $\hat{()}$ | Оцінки |
| $\bar{()}$ | Середнє |
| $()^{-1}$ | Обернена матриця |
| $()^T$ | Матрична транспозиція. |
| $\tilde{()}$ | Quaternion. |
docs/uk/contribute/support.md
+49
View File
@@ -0,0 +1,49 @@
# Підтримка
<script setup>
import { useData } from 'vitepress'
const { site } = useData();
</script>
<div v-if="site.title !== 'PX4 Guide (main)'">
<div class="custom-block danger">
<p class="custom-block-title">Ця сторінка може бути застарілою. <a href="https://docs.px4.io/main/en/contribute/support.html">Переглянути останню версію</a>.</p>
</div>
</div>
Цей розділ показує, як ви можете отримати допомогу від основної команди розробників і широкої спільноти.
## Форум та чат
Основна команда розробників і спільнота активні на наступних каналах:
- [PX4 Discuss Forum](https://discuss.px4.io/) - Post here first!
- [PX4 Discord](https://discord.gg/dronecode) - Post here if you don't get a response in discuss within a few days (include a link to your forum topic).
:::tip
The Discuss Forum is much preferred because it is indexed by search engines and serves as a common knowledge base.
:::
## Діагностування проблем
Якщо ви не впевнені в тому, що є ця проблема, і вам потрібна допомога для діагностики
- Upload logs to [Flight Log Review](https://logs.px4.io/)
- Open a discussion on [PX4 Discuss](https://discuss.px4.io/c/flight-testing/) with a flight report and links to logs.
- The dev team may prompt you to [raise an issue](#issue-bug-reporting) if the problem is caused by a bug.
## Issue & Bug Reporting
- Upload logs to [Flight Log Review](https://logs.px4.io/)
- [Open a Github Issue](https://github.com/PX4/PX4-Autopilot/issues).
Включити звіт про польоти з якомога більшою кількістю деталей (достатньо для того, щоб проблема була відтворена) і посилання на ваші журнали на Flight review.
## Щотижневий дзвінок розробників
:::tip
Developers are most welcome to attend the [weekly dev call](../contribute/dev_call.md) (and other [developer events](../index.md#calendar-events)) to engage more deeply with the project.
:::
The [Dev Call](../contribute/dev_call.md) is a weekly meeting attended by the PX4 dev team to discuss platform technical details, coordinate activities and perform in-depth analysis.
There is also space in the agenda to discuss pull requests, major impacting issues and Q&A.
docs/uk/contribute/translation.md
+72
View File
@@ -0,0 +1,72 @@
# Переклади
We'd love your help to translate _QGroundControl_, PX4 Metadata (in QGC), and our guides for PX4, _QGroundControl_ and MAVLink!
Our docs (and _QGroundControl_) use the [Crowdin](https://crowdin.com) online tool for translation.
Crowdin автоматично імпортує вихідні теми з Github і представляє нові і змінені рядки для перекладу та/або перегляду (фінального затвердження).
Crowdin експортує перекладені документи назад на Github як "Pull Request" (яку команда розробників періодично переглядає та приймає).
Експортований вивід містить вихідний документ з будь-яким перекладом і затвердженим текстом замінено перекладеними рядками (i. . Якщо рядок не перекладений/змінений, то він буде відображатися англійською).
:::tip
You will need a (free) [Crowdin account](https://crowdin.com/join) account to join the translation team!
:::
:::info
The benefit of this system is that the translation closely tracks the source documents.
Читачі не будуть введені в оману через застарілі і неоновлені переклади.
:::
## Початок роботи
Кроки з приєднання до нашої команди з перекладу такі:
1. Join Crowdin: [https://crowdin.com/join](https://crowdin.com/join)
2. Відкрийте проект, до якого хочете приєднатися:
- [QGroundControl](https://crowdin.com/project/qgroundcontrol) — QGroundControl UI and hard coded strings.
- [PX4-Metadata-Translations](https://crowdin.com/project/px4-metadata-translations) — PX4 parameter and event descriptions in QGroundControl.
- [PX4 User Guide](https://crowdin.com/project/px4-user-guide)
- [QGroundControl Developer Guide](https://crowdin.com/project/qgroundcontrol-developer-guide)
- [QGroundControl User Guide](https://crowdin.com/project/qgroundcontrol-user-guide)
- [MAVLink Guide](https://crowdin.com/project/mavlink)
3. Виберіть мову, якою ви хочете перекладати
4. Click the **Join** button (next to the text _You must join the translators team to be able to participate in this project_)
::: info
You will be notified once your application to join is accepted.
:::
5. Починайте перекладати!
## Особливі примітки
### Не змінюйте текст префікса!
Vuepress uses `:::` to mark the beginning of notes, tips and warning:
```html
:::tip
The text for the tip.
:::
```
The text for `:::tip` or `:::warning` etc. should not be modified as it defines the colour of the notebox.
## Додавання нової мови
Якщо мова, яку ви хочете перекласти, не доступна тоді вам потрібно буде запросити його звернутися до власника проекту (на головній сторінці проекту є посилання на кожен проект).
:::warning
Підтримка перекладу дуже тяжка!
Перш ніж ви попросите нас створити нову мову, знайдіть кількох інших людей, щоб допомогти вам перекласти!
:::
## Отримання допомоги
The _Crowdin_ interface is self explanatory, but there is plenty of additional information on the [knowledgeable](https://support.crowdin.com/).
You can also ask for help from translators and developers in the Dronecode community using [our support channels](../contribute/support.md).