Налаштування інтеграції із керуванням версіями

У поточній версії Weblate передбачено підтримку модулів керування версіями Git (із розширеною підтримкою Запити щодо злиття GitHub, Запити щодо об’єднання GitLab, Запити щодо злиття Gitea, Gerrit, Subversion і Запит щодо злиття для сервера Bitbucket) та Mercurial.

Доступ до репозиторіїв

Репозиторій системи керування версіями, яким ви хочете користуватися, має бути доступним для Weblate. Якщо репозиторій загальнодоступний, вам достатньо ввести правильну адресу (наприклад https://github.com/WeblateOrg/weblate.git), але для приватних репозиторіїв або адрес для запису налаштовування є складнішим і вимагає розпізнавання користувача.

Доступ до репозиторіїв з Hosted Weblate

Для Hosted Weblate на GitHub, Bitbucket, Codeberg і GitLab зареєстровано особливого користувача для запису внесків (назва облікового запису — weblate, адреса електронної пошти — hosted@weblate.org, ім’я користувача Weblate push user). Вам слід додати цього користувача як учасника розробки і надати йому відповідні права доступу до вашого репозиторію (для клонування достатньо прав на читання, для запису потрібні права запису). Залежно від служби і параметрів вашої організації надання прав буде здійснено негайно або потребуватиме підтвердження з боку Weblate.

Запрошення для користувача :guilabel:`weblate`на GitHub приймаються автоматично протягом п’яти хвилин. У інших службах може знадобитися обробка вручну, тому, будь ласка, майте терпіння.

Щойно користувача weblate буде додано, ви можете налаштувати репозиторій початкового коду і адресу запису до репозиторію з використання протоколу SSH (наприклад, git@github.com:WeblateOrg/weblate.git).

Репозиторії із доступом за SSH

Найпоширенішим способом доступу до приватних репозиторіїв є спосіб, який засновано на SSH. Уповноважте відкритий ключ SSH Weblate (див. Ключ SSH Weblate) на доступ до основного репозиторію у цей спосіб.

Попередження

На GitHub кожен ключ може бути використано лише один раз, див. Репозиторії GitHub і Доступ до репозиторіїв з Hosted Weblate.

Крім того, Weblate зберігає відбиток ключа вузла при першому з’єднанні і не може з’єднатися із вузлом, якщо ключ буде пізніше змінено (див. Перевірка ключів SSH вузла).

Якщо потрібні якісь коригування, виконайте їх за допомогою адміністративного інтерфейсу Weblate:

_images/ssh-keys.png

Ключ SSH Weblate

Відкритий ключ Weblate доступний до перегляду усіма користувачами на сторінці Про програму.

Адміністратори можуть створити або переглянути відкритий ключ, який використовується Weblate для з’єднання (з розділу Ключі SSH) на основній сторінці адміністративного інтерфейсу.

Примітка

У поточній версії відповідний закритий ключ SSH не захищено паролем, тому вам слід переконатися, що його добре захищено.

Підказка

Створіть резервну копію створено закритого ключа SSH Weblate.

Перевірка ключів SSH вузла

Weblate автоматично зберігає ключі SSH вузла за першого доступу та використовує їх у подальшому.

Якщо вам захочеться перевірити відбиток ключа до встановлення з’єднання з репозиторієм, додайте ключі SSH вузлів серверів, до яких ви збираєтеся отримати доступ у пункті Додати ключ вузла того самого розділу адміністративного інтерфейсу. Введіть назву вузла, до якого ви маєте намір отримати доступ (наприклад, gitlab.com) і натисніть кнопку Надіслати. Перевірте, чи відбиток збігається з доданим вами сервером.

Додані ключі із відбитками буде показано у повідомленні підтвердження:

_images/ssh-keys-added.png

Репозиторії GitHub

Можливий доступ з використанням SSH (див. Репозиторії із доступом за SSH), але якщо вам потрібен доступ до кількох репозиторіїв, ви зіткнетеся з обмеженням GitHub на використання ключів SSH (оскільки кожен ключ можна використати лише один раз).

Якщо гілку запису не встановлено, буде створено відгалуження проєкту, і зміни буде записано до відгалуження. Якщо гілку запису встановлено, зміни буде записано до основного репозиторію і вибраної гілки.

Для варіантів із малою кількістю проєктів скористайтеся розпізнаванням HTTPS із особистим жетоном доступу та вашим обліковим записом GitHub, див. Creating an access token for command-line use.

Для варіантів із великою кількістю проєктів зазвичай краще створити окремого користувача для Weblate, пов’язати його із відкритим ключем SSH, який створено на Weblate (див. Ключ SSH Weblate) і надати йому доступ до усіх репозиторіїв, які ви хочете перекладати. Цей підхід використано і на Hosted Weblate — маємо особливого користувача weblate.

Внутрішні адреси Weblate

Щоб скористатися одним спільним репозиторієм для різних складників ви можете використати особливу адресу, weblate://проєкт/складник в інших (пов’язаних) складниках. Тоді, складник матиме спільні налаштування репозиторію системи керування версіями з еталонним складником.

Попередження

Вилучення основного складника призводить до вилучення пов’язаних складників.

Weblate автоматично коригує адресу репозиторію при створенні складника, якщо виявляє складник із відповідними налаштуваннями репозиторію. Ви можете перевизначити цю поведінку на останньому кроці налаштовування складника.

Причини для використання внутрішніх адрес:

  • Заощаджує місце на диску сервера — репозиторій зберігається лише один раз.

  • Пришвидшує оновлення — оновлюється лише один репозиторій.

  • Наявність лише одного експортованого репозиторію із перекладами Weblate (див. Засіб експортування Git).

  • Деякі додатки можуть працювати із декількома складниками, які мають єдине спільний репозиторій, наприклад Сполучити Git подання.

Репозиторії HTTPS

Щоб отримати доступ до захищених репозиторіїв HTTPS, включіть до адреси ім’я користувача і пароль. Не слід хвилюватися — Weblate вилучить ці дані при показі адреси користувачам (якщо взагалі показуватиме їм адресу репозиторію).

Наприклад, адреса GitHub із доданими даними розпізнавання може виглядати так: https://користувач:ваш_жетон_доступу@github.com/WeblateOrg/weblate.git.

Примітка

Якщо ваше ім’я користувача і пароль містять спеціальні символи, їх слід записувати у URL-кодуванні, наприклад https://user%40example.com:%24password%23@bitbucket.org/….

Використання проксі-сервера

Якщо вам потрібен доступ HTTP/HTTPS до репозиторіїв системи керування версіями з використанням проксі-сервера, налаштуйте систему керування версіями на його використання.

Зробити це можна за допомогою змінних середовища http_proxy, https_proxy і all_proxy (як це описано у документації до cURL) або примусовим визначенням у налаштуваннях системи керування версіями. Приклад:

git config --global http.proxy http://user:password@proxy.example.com:80

Примітка

Налаштовування проксі слід виконати для користувача, від імені якого запущено Weblate (див. також Права доступу у файловій системі) і з HOME=$DATA_DIR/home (див. DATA_DIR), інакше Git, який запускатиме Weblate, не використовуватиме ці налаштування.

Git

Підказка

Для роботи Weblate потрібен Git 2.12 або новіша версія.

Дивись також

Див. розділ Доступ до репозиторіїв, щоб дізнатися більше про доступ до репозиторіїв різних типів.

Git з примусовим «push»

Це працює як і сам Git. Єдиною відмінністю є те, що запис завжди виконується примусово. Такий режим призначено лише для випадку використання окремого репозиторію для перекладів.

Попередження

Будьте обережні із використанням, оскільки так можна дуже просто втратити внески до вашого основного репозиторію.

Налаштовування Git

Weblate викликає усі команди VCS з використанням HOME=$DATA_DIR/home (див. DATA_DIR), тому редагування налаштувань користувача слід виконувати у DATA_DIR/home/.git.

Віддалені допоміжні засоби Git

Ви можете скористатися remote helpers Git для додаткової підтримки інших систем керування версіями, але вам слід бути готовими до діагностики проблем, до яких може призвести використання цих засобів.

У поточній версії доступні допоміжні засоби для Bazaar і Mercurial у окремих репозиторіях на GitHub: git-remote-hg і git-remote-bzr. Отримайте їх вміст вручну і запишіть до ваших шляхів пошуку (наприклад, до ~/bin). Переконайтеся, що у вашій системі встановлено відповідні засоби систем керування версіями.

Щойно ці засоби буде встановлено, такими віддаленими засобами можна скористатися для визначення репозиторію у Weblate.

Клонування проєкту gnuhello з Launchpad за допомогою Bazaar:

bzr::lp:gnuhello

Для репозиторію hello з selenic.com з використанням Mercurial:

hg::http://selenic.com/repo/hello

Попередження

Незручності використання віддалених допоміжних засобів Git виникають, наприклад, з Mercurial, віддалений допоміжний засіб іноді створює новий пункт при записі змін до основної репозиторію.

Запити щодо злиття GitHub

Нове в версії 2.3.

Це додає тонкий шар над Git з використанням інструмента GitHub API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до репозиторію.

Git записує зміни безпосередньо до репозиторію, а Запити щодо злиття GitHub створює запити щодо об’єднання. Останній не потрібен для простого доступу до репозиторіїв Git.

Щоб це спрацювало, вам слід налаштувати реєстраційні дані для програмного інтерфейсу (GITHUB_CREDENTIALS) у параметрах Weblate. Після налаштовування ви побачите пункт GitHub при виборі системи керування версіями складника.

Запити щодо об’єднання GitLab

Нове в версії 3.9.

Це просто додає тонкий шар над Git з використанням інструмента GitLab API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до репозиторію.

Потреби у використання цього інструмента для доступу до репозиторіїв Git, звичайний Git працює так само. Єдиною відмінністю є спосіб обробки запису до репозиторію. З Git зміни записуються безпосередньо до репозиторію, а Запити щодо об’єднання GitLab створює запит щодо об’єднання.

Щоб це спрацювало, вам слід налаштувати реєстраційні дані для програмного інтерфейсу (GITLAB_CREDENTIALS) у параметрах Weblate. Після налаштовування ви побачите пункт GitLab при виборі системи керування версіями складника.

Запити щодо злиття Gitea

Нове в версії 4.12.

Це додає тонкий шар над Git з використанням інструмента Gitea API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до репозиторію.

Потреби у використання цього інструмента для доступу до репозиторіїв Git, звичайний Git працює так само. Єдиною відмінністю є спосіб обробки запису до репозиторію. З Git зміни записуються безпосередньо до репозиторію, а Запити щодо злиття Gitea створює запит щодо об’єднання.

Щоб це спрацювало, вам слід налаштувати реєстраційні дані для програмного інтерфейсу (GITEA_CREDENTIALS) у параметрах Weblate. Після налаштовування ви побачите пункт Gitea при виборі системи керування версіями складника.

Запит щодо злиття для сервера Bitbucket

Нове в версії 4.16.

Це додає тонкий шар над Git з використанням інструмента програмного інтерфейсу Bitbucket, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до репозиторію.

Попередження

Тут не передбачено підтримки хмарного програмного інтерфейсу Bitbucket.

Потреби у використання цього інструмента для доступу до репозиторіїв Git, звичайний Git працює так само. Єдиною відмінністю є спосіб обробки запису до репозиторію. З Git зміни записуються безпосередньо до репозиторію, а Запит щодо злиття для сервера Bitbucket створює запит щодо об’єднання.

Щоб це спрацювало, вам слід налаштувати реєстраційні дані для програмного інтерфейсу (BITBUCKETSERVER_CREDENTIALS) у параметрах Weblate. Після налаштовування ви побачите пункт сервер Bitbucket при виборі системи керування версіями складника.

Запити щодо об’єднання Pagure

Нове в версії 4.3.2.

Це просто додає тонкий шар над Git з використанням інструмента Pagure API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до репозиторію.

Потреби у використання цього інструмента для доступу до репозиторіїв Git, звичайний Git працює так само. Єдиною відмінністю є спосіб обробки запису до репозиторію. З Git зміни записуються безпосередньо до репозиторію, а Запити щодо об’єднання Pagure створює запит щодо об’єднання.

Щоб це спрацювало, вам слід налаштувати реєстраційні дані для програмного інтерфейсу (PAGURE_CREDENTIALS) у параметрах Weblate. Після налаштовування ви побачите пункт Pagure при виборі системи керування версіями складника.

Gerrit

Нове в версії 2.2.

Це додає тонкий шар над Git з використанням інструмента git-review, щоб уможливити запис змін у перекладах як запитів щодо рецензування Gerrit, замість безпосереднього запису до репозиторію.

У документації до Gerrit наведено подробиці щодо налаштувань, потрібних для таких репозиторіїв.

Mercurial

Нове в версії 2.1.

Ще однією системою керування версіями, якою ви можете користуватися безпосередньо у Weblate є Mercurial.

Примітка

Це має працювати із будь-якою версією Mercurial, але іноді можна зіткнутися із несумісними змінами у інтерфейсі командного рядка, які шкодять інтеграції із Weblate.

Дивись також

Див. розділ Доступ до репозиторіїв, щоб дізнатися більше про доступ до репозиторіїв різних типів.

Subversion

Нове в версії 2.8.

Weblate використовує для взаємодії з репозиторіями subversion git-svn. Це скрипт мовою Perl, який надає змогу користуватися subversion за допомогою клієнта Git, уможливлюючи для користувачів супровід повного клону внутрішнього репозиторію і локальні внески.

Примітка

Weblate намагається виявити компонування репозиторію Subversion автоматично — передбачено підтримку як безпосередніх адрес для гілок, так і репозиторію зі стандартним компонуванням (branches/, tags/ і trunk/). Докладніше про це можна дізнатися з документації до git-svn. Якщо компонування вашого репозиторію не є стандартним і ви стикаєтеся з помилками, спробуйте включити назву гілки у адресу репозиторію і лишити гілку порожньою.

Змінено в версії 2.19: До цього було передбачено лише підтримку репозиторіїв зі стандартним компонуванням.

Реєстраційні дані Subversion

Weblate очікує, що ви прийняли сертифікат і, якщо потрібно, вказали ваші реєстраційні дані. Weblate вставить їх до каталогу DATA_DIR. Прийміть сертифікат за допомогою одноразового запуску svn зі змінною середовища $HOME, яка збігається за значенням з DATA_DIR:

# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example

Дивись також

DATA_DIR

Локальні файли

Git

Підказка

Нижче використано Git. Для роботи слід встановити Git. Уможливлює перехід на безпосереднє використання Git із повним журналом перекладів.

Нове в версії 3.8.

Крім того, Weblate може працювати без віддаленої системи керування версіями. Початкові переклади імпортуються безпосереднім вивантаженням. Пізніше ви можете замінити окремі файли вивантаженням нових версій або додати рядки перекладу безпосередньо з Weblate (у поточній версії цю можливість реалізовано лише для одномовних перекладів).

За лаштунками, Weblate створює репозиторій Git і стежить за усіма змінами за його допомогою. Якщо ви згодом вирішите скористатися системою керування версіями для зберігання ваших перекладів,у вас вже буде репозиторію у Weblate, на основі якого ви зможете побудувати інтеграцію.