en to uk translation catalogue (93 entries)

en: 16bit ASN: ``64496 - 64511``
uk: 16-розрядний номер ASN: ``64496 - 64511``

en: 32bit ASN: ``65536 - 65551``
uk: 32-розрядний номер ASN: ``65536 - 65551``

en: A plugin will be used to generate a reference label for each headline. To reference a page or a section in the documentation use the ``:ref:`` command.
uk: Плагін використовуватиметься для створення мітки посилання для кожного заголовка. Щоб посилатися на сторінку або розділ у документації, використовуйте команду ``:ref:``.

en: Add modified files to Git index ``$ git add path/to/filename`` or add all unstaged files ``$ git add .``. All files added to the Git index will be part of you following Git commit.
uk: Додайте змінені файли до індексу Git ``$ git add path/to/filename`` або додайте всі файли без етапів ``$ git add .``. Усі файли, додані до індексу Git, будуть частиною вас після фіксації Git.

en: Address space
uk: Адресний простір

en: All RST files must follow the same TOC Level syntax and have to start with
uk: Усі файли RST мають відповідати тому самому синтаксису рівня змісту та починати з них

en: An optional section follows. Some commands have requirements like compatible hardware (e.g. Wifi) or some commands you have to set before. For example, it is recommended to set a route-map before configuring BGP.
uk: Далі йде необов’язковий розділ. Деякі команди мають вимоги, як-от сумісне обладнання (наприклад, Wi-Fi), або деякі команди, які ви повинні встановити раніше. Наприклад, перед налаштуванням BGP рекомендується встановити карту маршруту.

en: And finally, remember that the reStructuredText files aren't exclusively for generating HTML and PDF. They should be human-readable and easily perused from a console.
uk: І, нарешті, пам’ятайте, що файли reStructuredText призначені не виключно для створення HTML і PDF. Вони мають бути зрозумілими для людини та легко переглядатися з консолі.

en: Anything else
uk: Будь-що інше

en: Anything else that is not a configuration or an operation command has no predefined structure.
uk: Усе інше, що не є конфігурацією чи командою операції, не має попередньо визначеної структури.

en: Autolinter
uk: Автолінтер

en: Check your changes by locally building the documentation ``$ make livehtml``. Sphinx will build the html files in the ``docs/_build`` folder. We provide you with a Docker container for an easy-to-use user experience. Check the README.md_ file of this repository.
uk: Перевірте свої зміни, створивши локально документацію ``$ make livehtml``. Sphinx створить файли html у папці ``docs/_build``. Ми пропонуємо вам контейнер Docker для зручного використання. Перевірте файл README.md_ цього репозиторію.

en: Check your configured remote repositories:
uk: Перевірте налаштовані віддалені сховища:

en: Clone fork to local machine, then change to that directory ``$ cd vyos-documentation``
uk: Клонуйте розгалуження на локальну машину, а потім перейдіть до цього каталогу ``$ cd vyos-documentation``

en: Commit your changes with the message, ``$ git commit -m "<commit message>"`` or  use ``$ git commit -v`` to have your configured editor launched. You can type in a commit message. Again please make yourself comfortable without rules (:ref:`prepare_commit`).
uk: Зафіксуйте свої зміни за допомогою повідомлення ``$ git commit -m &quot;<commit message> &quot;`` або скористайтеся ``$ git commit -v``, щоб запустити ваш налаштований редактор. Ви можете ввести повідомлення про фіксацію. Знову ж таки, будь ласка, розслабтеся без правил (:ref:`prepare_commit`).

en: Configuration mode pages
uk: Сторінки режиму конфігурації

en: Create a new branch for your work, use a descriptive name of your work: ``$ git checkout -b <branch-name>``
uk: Створіть нову гілку для своєї роботи, використовуйте описову назву вашої роботи: ``$ git checkout -b<branch-name> ``

en: Cross-References
uk: Перехресні посилання

en: Custom Sphinx-doc Markup
uk: Спеціальна розмітка Sphinx-doc

en: Custom commands have been developed for writing the documentation. Please make yourself comfortable with those commands as this eases the way we render the documentation.
uk: Розроблено власні команди для написання документації. Будь ласка, влаштуйтеся з цими командами, оскільки це полегшить процес обробки документації.

en: Don't forget to update ``index.rst`` when adding a new node.
uk: Не забудьте оновити ``index.rst`` під час додавання нового вузла.

en: Each GitHub pull request is automatically linted to check the address space and line length.
uk: Кожен запит на отримання GitHub автоматично розміщується для перевірки адресного простору та довжини рядка.

en: Except in ``.. code-block::`` because it uses the html tag ``<pre>`` and renders the same line format from the source rst file.
uk: За винятком ``.. code-block::``, оскільки він використовує тег html ``<pre> `` і відображає той самий формат рядка з вихідного першого файлу.

en: For an inline configuration level command, use ``:cfgcmd:``
uk: Для вбудованої команди рівня конфігурації використовуйте ``:cfgcmd:``

en: For an inline operational level command, use ``:opcmd:``
uk: Для вбудованої команди операційного рівня використовуйте ``:opcmd:``

en: For example, you want to reference the headline **VLAN** in the **ethernet.rst** page. The plugin generates the label based on the headline and the file path.
uk: Наприклад, ви хочете посилатися на заголовок **VLAN** на сторінці **ethernet.rst**. Плагін генерує мітку на основі заголовка та шляху до файлу.

en: For example:
uk: Наприклад:

en: Fork this project on GitHub https://github.com/vyos/vyos-documentation/fork
uk: Розгалужте цей проект на GitHub https://github.com/vyos/vyos-documentation/fork

en: Forking Workflow
uk: Робочий процес розгалуження

en: Formating and Sphinxmarkup
uk: Форматування та розмітка Sphinx

en: General concepts for troubleshooting and detailed process descriptions belong here.
uk: Загальні поняття щодо усунення несправностей і детальні описи процесів містяться тут.

en: Guidelines
uk: Настанови

en: If there some troubleshooting guides related to the commands. Explain it in the next optional part.
uk: Якщо є деякі посібники з усунення несправностей, пов’язані з командами. Поясніть це в наступній додатковій частині.

en: If you also want to update your fork on GitHub, use the following: ``$ git push origin master``
uk: Якщо ви також хочете оновити свій форк на GitHub, використовуйте наступне: ``$ git push origin master``

en: If you are willing to contribute to our documentation this is the definite guide how to do so.
uk: Якщо ви бажаєте зробити внесок у нашу документацію, це чіткий посібник, як це зробити.

en: In contrast to submitting code patches, there is no requirement that you open up a Phabricator_ task prior to submitting a Pull-Request to the documentation.
uk: На відміну від надсилання патчів коду, немає вимоги відкривати завдання Phabricator_ перед надсиланням Pull-Request до документації.

en: In the configuration part of the page, all possible configuration options should be documented. Use ``.. cfgcmd::`` described above.
uk: У частині сторінки конфігурації мають бути задокументовані всі можливі параметри конфігурації. Використовуйте ``.. cfgcmd::``, як описано вище.

en: Indent with two spaces.
uk: Відступ з двома пробілами.

en: Install the requirements ``$ pip install -r requirements.txt`` (or something similar)
uk: Встановіть вимоги ``$ pip install -r requirements.txt`` (або щось подібне)

en: Leave a newline before and after a header.
uk: Залиште новий рядок перед і після заголовка.

en: Limit all lines to a maximum of 80 characters.
uk: Обмежте всі рядки максимум 80 символами.

en: Line length
uk: Довжина лінії

en: Make all your changes - please keep our commit rules in mind (:ref:`prepare_commit`). This mainly applies to proper commit messages describing your change (how and why). Please check out the documentation of Sphinx-doc_ or reStructuredText_ if you are not familiar with it. This is used for writing our docs. Additional directives how to write in RST can be obtained from reStructuredTextDirectives_.
uk: Внесіть усі ваші зміни - пам’ятайте про наші правила фіксації (:ref:`prepare_commit`). Це в основному стосується правильних повідомлень комітів, що описують вашу зміну (як і чому). Перегляньте документацію Sphinx-doc_ або reStructuredText_, якщо ви з ними не знайомі. Це використовується для написання наших документів. Додаткові директиви, як писати в RST, можна отримати з reStructuredTextDirectives_.

en: Multicast MAC-Addresses: ``90-10-00`` to ``90-10-FF``
uk: Багатоадресні MAC-адреси: від ``90-10-00`` до ``90-10-FF``

en: Note the following RFCs (:rfc:`5737`, :rfc:`3849`, :rfc:`5389` and :rfc:`7042`), which describe the reserved public IP addresses and autonomous system numbers for the documentation:
uk: Зверніть увагу на такі RFC (:rfc:`5737`, :rfc:`3849`, :rfc:`5389` і :rfc:`7042`), які описують зарезервовані публічні IP-адреси та номери автономних систем для документації:

en: Once pull requests have been approved, you may want to locally update your forked repository too. First you'll have to add a second remote called `upstream` which points to our main repository. ``$ git remote add upstream https://github.com/vyos/vyos-documentation.git``
uk: Після схвалення запитів на отримання ви можете також локально оновити свій розгалужений репозиторій. Спочатку вам доведеться додати другий віддалений під назвою `upstream`, який вказує на наше головне сховище. ``$ git віддалене додавання вгору https://github.com/vyos/vyos-documentation.git``

en: Operation mode commands that do not fit in a related configuration mode command must be documented in this part of the documentation.
uk: Команди режиму роботи, які не підходять до відповідної команди режиму конфігурації, повинні бути задокументовані в цій частині документації.

en: Operation mode pages
uk: Сторінки режимів роботи

en: Page content
uk: Вміст сторінки

en: Please do not use other public address space.
uk: Будь ласка, не використовуйте інший публічний адресний простір.

en: Properly quote commands, filenames and brief code snippets with double backticks.
uk: Правильно цитуйте команди, назви файлів і короткі фрагменти коду з подвійними зворотними галочками.

en: Push commits to your GitHub project: ``$ git push -u origin <branch-name>``
uk: Push фіксує ваш проект GitHub: ``$ git push -u origin<branch-name> ``

en: Related operation command must be documented in the next part of the article. Use ``::opcmd..`` for these commands.
uk: Відповідну команду операції необхідно задокументувати в наступній частині статті. Для цих команд використовуйте ``::opcmd..``.

en: Sometimes it is necessary to provide real IP addresses like in the :ref:`examples`. For this, please use the sphinx comment syntax ``.. stop_vyoslinter`` to stop the linter and ``.. start_vyoslinter`` to start.
uk: Іноді необхідно надати справжні IP-адреси, як у :ref:`прикладах`. Для цього використовуйте синтаксис коментаря sphinx ``.. stop_vyoslinter`` для зупинки лінтера та ``.. start_vyoslinter`` для запуску.

en: Style Guide
uk: Керівництво по стилю

en: Submit pull-request. In GitHub visit the main repository and you should see a banner suggesting to make a pull request. Fill out the form and describe what you do.
uk: Надіслати пул-запит. У GitHub відвідайте головне сховище, і ви побачите банер із пропозицією зробити запит на отримання. Заповніть форму та опишіть, що ви робите.

en: TOC Level
uk: Рівень TOC

en: Take a look at the :doc:`/documentation` page for an intricate explanation of the documentation process.
uk: Подивіться на сторінку :doc:`/documentation`, щоб отримати складне пояснення процесу документування.

en: The Forking Workflow is fundamentally different from other popular Git workflows. Instead of using a single server-side repository to act as the "central" codebase, it gives every developer their own server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one.
uk: Робочий процес Forking принципово відрізняється від інших популярних робочих процесів Git. Замість того, щоб використовувати єдине серверне сховище як «центральну» кодову базу, це надає кожному розробнику власне серверне сховище. Це означає, що кожен учасник має не одне, а два сховища Git: приватне локальне та загальнодоступне на стороні сервера.

en: The article starts with a short introduction about the command or the technology. Please include some helpful links or background information.
uk: Стаття починається з короткого вступу про команду або технологію. Додайте корисні посилання або довідкову інформацію.

en: The configuration mode folder and the articles cover the specific level of the commands. The exact level depends on the command. This should provide stability for URLs used in the forum or blogpost.
uk: Папка режиму налаштування та статті охоплюють певний рівень команд. Точний рівень залежить від команди. Це має забезпечити стабільність URL-адрес, які використовуються на форумі чи в блозі.

en: The documentation has 3 different types of pages. The same kind of pages must have the same structure to achieve a recognition factor.
uk: Документація має 3 різні типи сторінок. Сторінки одного типу повинні мати однакову структуру, щоб отримати коефіцієнт розпізнавання.

en: The documentation source is kept in the Git repository at https://github.com/vyos/vyos-documentation and you can follow the instructions in the README.md_ to build and test your changes.
uk: Джерело документації зберігається в сховищі Git за адресою https://github.com/vyos/vyos-documentation, і ви можете дотримуватись інструкцій у README.md_, щоб створити та протестувати свої зміни.

en: The following is a quick summary of the rules:
uk: Нижче наведено короткий виклад правил:

en: The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.
uk: Основна перевага робочого процесу розгалуження полягає в тому, що внески можна інтегрувати без необхідності пересилання всіх до єдиного центрального сховища. Розробники надсилають дані у власні репозиторії на стороні сервера, і лише супроводжувач проекту може надсилати дані в офіційне сховище. Це дозволяє супроводжувачу приймати коміти від будь-якого розробника, не надаючи їм доступу для запису до офіційної кодової бази.

en: The plugin will warn on build if a headline has a duplicate name in the same document. To prevent this warning, you have to put a custom link on top of the headline.
uk: Плагін попереджатиме під час створення, якщо заголовок має повторюване ім’я в тому самому документі. Щоб запобігти цьому попередженню, ви повинні розмістити спеціальне посилання вгорі заголовка.

en: There are a few things to keep in mind when contributing to the documentation, for the sake of consistency and readability.
uk: Є кілька речей, про які слід пам’ятати, додаючи внески до документації, для послідовності та зручності читання.

en: To extract a defaultvalue from the XML definitions add a ``:defaultvalue:`` to ``.. cfgcmd::`` directive. To have this feature locally, the vyos-1x submodule must be initialized before. Please be aware to not update the submodule in your PR.
uk: Щоб отримати значення за замовчуванням із визначень XML, додайте ``:defaultvalue:`` до директиви ``.. cfgcmd::``. Щоб мати цю функцію локально, субмодуль vyos-1x має бути ініціалізований раніше. Зверніть увагу: не оновлюйте підмодуль у своєму PR.

en: To minimize redundancy, there is a special include directive. It includes a txt file and replace the ``{{ var0 }}`` - ``{{ var9 }}`` with the correct value.
uk: Для мінімізації надмірності існує спеціальна директива include. Він містить текстовий файл і замінює ``{{ var0 }}`` - ``{{ var9 }}`` на правильне значення.

en: Try not to exceed 80 characters per line, but don't break URLs over this.
uk: Намагайтеся не перевищувати 80 символів у рядку, але не розбивайте URL-адреси через це.

en: Unicast MAC Addresses: ``00-53-00`` to ``00-53-FF``
uk: Одноадресні MAC-адреси: від ``00-53-00`` до ``00-53-FF``

en: Updates to our documentation should be delivered by a GitHub pull-request. This requires you already have a GitHub account.
uk: Оновлення нашої документації мають надсилатися за допомогою запиту на підключення GitHub. Для цього потрібен обліковий запис GitHub.

en: Use American English at all times. It's always a good idea to run your text through a grammar and spell checker, such as `Grammarly`_.
uk: Завжди використовуйте американську англійську мову. Завжди доцільно перевірити текст через інструмент перевірки граматики та орфографії, наприклад `Grammarly`_.

en: Use literal blocks for longer snippets.
uk: Використовуйте літеральні блоки для довших фрагментів.

en: View modified files by calling ``$ git status``. You will get an overview of all files modified by you. You can add individual files to the Git Index in the next step.
uk: Перегляньте змінені файли, викликавши ``$ git status``. Ви отримаєте огляд усіх змінених вами файлів. Ви можете додати окремі файли до Git Index на наступному кроці.

en: VyOS documentation is written in reStructuredText and generated to Read the Docs pages with Sphinx, as per the Python tradition, as well as PDF files for offline use through LaTeX. We welcome all sorts of contributions to the documentation. Not just new additions but also corrections to existing documentation.
uk: Документація VyOS написана в reStructuredText і створена для читання сторінок документів за допомогою Sphinx, згідно з традицією Python, а також файлів PDF для використання в автономному режимі через LaTeX. Ми вітаємо будь-які внески в документацію. Не тільки нові доповнення, а й виправлення існуючої документації.

en: We encourage every VyOS user to help us improve our documentation as we have a deficit like most software projects.  This not only helps you when reading but also everyone else.
uk: Ми заохочуємо кожного користувача VyOS допомогти нам покращити нашу документацію, оскільки у нас є дефіцит, як і в більшості програмних проектів. Це допоможе не лише вам під час читання, але й усім іншим.

en: We use the following syntax for Headlines.
uk: Ми використовуємо наступний синтаксис для заголовків.

en: When documenting CLI commands, use the ``.. cfgcmd::`` directive for all configuration mode commands. An explanation of the described command should be added below this statement. Replace all variable contents with <value> or something similar.
uk: Під час документування команд CLI використовуйте директиву ``.. cfgcmd::`` для всіх команд режиму налаштування. Пояснення описаної команди слід додати під цією заявою. Замінити весь вміст змінної на<value> або щось подібне.

en: When documenting operational level commands, use the ``.. opcmd::`` directive. An explanation of the described command should be added below this statement.
uk: Під час документування команд робочого рівня використовуйте директиву ``.. opcmd::``. Пояснення описаної команди слід додати під цією заявою.

en: When in doubt, follow the style of existing documentation.
uk: Якщо сумніваєтеся, дотримуйтеся стилю існуючої документації.

en: When referencing to VyOS Phabricator Tasks, there is a custom Sphinx Markup command called ``vytask`` that automatically renders to a proper Phabricator URL. This is heavily used in the :ref:`release-notes` section.
uk: Коли йдеться про завдання VyOS Phabricator, існує спеціальна команда Sphinx Markup під назвою ``vytask``, яка автоматично відображає правильну URL-адресу Phabricator. Це широко використовується в розділі :ref:`release-notes`.

en: With those custom commands, it is possible to render them in a more descriptive way in the resulting HTML/PDF manual.
uk: За допомогою цих користувацьких команд можна відобразити їх у більш описовий спосіб у кінцевому посібнику HTML/PDF.

en: With those custom commands, it will be possible to render them in a more descriptive way in the resulting HTML/PDF manual.
uk: За допомогою цих користувальницьких команд можна буде відобразити їх у більш описовий спосіб у кінцевому посібнику HTML/PDF.

en: Write Documentation
uk: Напишіть документацію

en: You can either install Sphinx (and TeX Live for PDF output) and build the documentation locally, or use the Dockerfile_ to build it in a container.
uk: Ви можете встановити Sphinx (і TeX Live для виведення PDF) і створити документацію локально, або використати Dockerfile_, щоб створити її в контейнері.

en: Your remote repo on Github is called ``origin``, while the original repo you have forked is called ``upstream``. Now you can locally update your forked repo.
uk: Ваше віддалене репо на Github називається ``origin``, тоді як оригінальне репо, яке ви створили, називається ``upstream``. Тепер ви можете локально оновлювати своє розгалужене репо.

en: ``:ref:`Check out VLAN<configuration/interfaces/ethernet:vlan>``
uk: ``:ref:`Перевірте VLAN<configuration/interfaces/ethernet:vlan> ``

en: ``set firewall zone`` is written in ``firewall/zone.rst``
uk: ``встановити зону брандмауера`` записується в ``firewall/zone.rst``

en: ``set interfaces ethernet`` is written in ``interfaces/ethernet.rst``
uk: ``set interfaces ethernet`` записується в ``interfaces/ethernet.rst``

en: handle build errors
uk: обробляти помилки збірки

en: the content of interface-address.txt looks like this
uk: вміст interface-address.txt виглядає так

en: to use an alternative hyperlink use it this way:
uk: щоб використовувати альтернативне гіперпосилання, використовуйте його таким чином:
