Інтеграція з системою керування версіями¶
У поточній версії Weblate передбачено підтримку модулів керування версіями Git (із розширеною підтримкою Запити щодо злиття GitHub, Запити щодо об’єднання GitLab, Запити щодо злиття Gitea, Gerrit, Subversion, Запити щодо об’єднання Bitbucket Cloud, Запити на вилучення Bitbucket Data Center і Запити щодо об’єднання Azure DevOps) та Mercurial.
Доступ до сховищ¶
Сховище системи керування версіями, яким ви хочете користуватися, має бути доступним для Weblate. Якщо сховище загальнодоступний, вам достатньо ввести правильну адресу (наприклад https://github.com/WeblateOrg/weblate.git), але для приватних сховищ або адрес для запису налаштовування є складнішим і вимагає розпізнавання користувача.
Доступ до сховищ з Hosted Weblate¶
Примітка
Цей розділ стосується лише розміщеного Weblate (hosted.weblate.org). Якщо ви використовуєте власний екземпляр Weblate, розміщений окремо, будь ласка, дивіться the next section.
Для Hosted Weblate існує спеціалізований зареєстрований користувач для внесення змін на GitHub, Bitbucket, Codeberg і GitLab (його іменем користувача є weblate, а адресою електронної пошти — hosted@weblate.org, назву або опис профілю наведено у розділі Користувач-записувач Weblate).
Підказка
На платформах можуть бути додаткові користувачі Weblate, які призначено для використання у інших екземплярах Weblate. Рекомендуємо скористатися пошуком за адресою електронної пошти hosted@weblate.org для виявлення належного користувача для Hosted Weblate.
Вам слід додати цього користувача як учасника розробки і надати йому відповідні права доступу до вашого сховища (для клонування достатньо прав на читання, для запису потрібні права запису). Залежно від служби і параметрів вашої організації надання прав буде здійснено негайно або потребуватиме підтвердження з боку Weblate.
Запрошення для користувача weblate на GitHub приймаються автоматично протягом п’яти хвилин. У інших службах може знадобитися обробка вручну, тому, будь ласка, майте терпіння.
Після додавання користувача weblate до вашого репозиторію, ви можете налаштувати Сховище з джерелами та Адреса для записування до сховища за допомогою протоколу SSH (наприклад git@github.com:WeblateOrg/weblate.git).
Доступ до сховищ на сайтах зберігання коду (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Примітка
Цей розділ стосується власно розміщених екземплярів Weblate. Якщо ви використовуєте Hosted Weblate (hosted.weblate.org), див. Доступ до сховищ з Hosted Weblate.
Для самостійно розміщеного Weblate доступ до репозиторіїв на сайтах розміщення коду зазвичай здійснюється шляхом створення спеціального користувача, який пов’язаний з SSH-ключем Weblate (див. Ключ SSH Weblate). Таким чином, ви пов’язуєте SSH-ключ Weblate з одним користувачем (платформи часто вимагають одноразового використання SSH-ключа) та надаєте цьому користувачеві доступ до репозиторію. Потім ви можете використовувати SSH-URL для доступу до репозиторію (див. Сховища із доступом за SSH).
Сховища із доступом за SSH¶
Найпоширенішим способом доступу до приватних сховищ є спосіб, який засновано на SSH. Уповноважте відкритий ключ SSH Weblate (див. Ключ SSH Weblate) на доступ до основного сховища у цей спосіб.
Попередження
На GitHub кожен ключ може бути використано лише один раз, див. Сховища GitHub і Доступ до сховищ з Hosted Weblate.
Крім того, Weblate зберігає відбиток ключа вузла при першому з’єднанні і не може з’єднатися із вузлом, якщо ключ буде пізніше змінено (див. Перевірка ключів SSH вузла).
Якщо потрібні якісь коригування, виконайте їх за допомогою адміністративного інтерфейсу Weblate:
Ключ SSH Weblate¶
Змінено в версії 4.17: Нова версія Weblate створює одразу ключі SSH RSA і Ed25519. Для нововстановлених версій рекомендуємо користуватися Ed25519.
Відкритий ключ Weblate доступний до перегляду усіма користувачами на сторінці Про програму.
Адміністратори можуть створити або переглянути відкритий ключ, який використовується Weblate для з’єднання (з розділу Ключі SSH) на основній сторінці адміністративного інтерфейсу.
Примітка
У поточній версії відповідний закритий ключ SSH не захищено паролем, тому вам слід переконатися, що його добре захищено.
Підказка
Створіть резервну копію створено закритого ключа SSH Weblate.
Перевірка ключів SSH вузла¶
Weblate автоматично зберігає ключі SSH вузла за першого доступу та використовує їх у подальшому.
Якщо вам захочеться перевірити відбиток ключа до встановлення з’єднання з сховищем, додайте ключі SSH вузлів серверів, до яких ви збираєтеся отримати доступ у пункті Додати ключ вузла того самого розділу адміністративного інтерфейсу. Введіть назву вузла, до якого ви маєте намір отримати доступ (наприклад, gitlab.com) і натисніть кнопку Надіслати. Перевірте, чи відбиток збігається з доданим вами сервером.
Додані ключі із відбитками буде показано у повідомленні підтвердження:
Встановлення з’єднання із застарілими серверами SSH¶
У свіжих випусках OpenSSH (наприклад, у тому який використано у контейнері Docker Weblate) підписи RSA із використанням алгоритму хешування SHA-1 типово вимкнено. Цю зміну було внесено, оскільки алгоритм хешування SHA-1 криптографічно зламано, можна створити колізії із вибраним префіксом хешування за <USD$50K.
Для більшості користувачів ця зміна лишиться невидимою і потреби у заміні ключів ssh-rsa не виникне. У OpenSSH передбачено підтримку підписів RFC8332 RSA/SHA-256/512 з випуску 7.2, а у сучасних ключах ssh-rsa автоматично використано складніші алгоритми там, де це можливо.
Ймовірнішою є несумісність при встановленні з’єднання із застарілими реалізаціями SSH, які не було осучаснено, і яких не реалізовано удосконалень протоколу SSH. Спроба з’єднатися за допомогою SSH з таким сервером завершиться повідомленням:
no matching host key type found. Their offer: ssh-rsa
Для таких випадків може виникнути потреба у вибірковому вмиканні RSA/SHA1 з метою уможливлення з’єднання та/або розпізнавання користувачів за допомогою параметрів HostkeyAlgorithms і PubkeyAcceptedAlgorithms. Наприклад, такі інструкції у DATA_DIR/ssh/config увімкнуть RSA/SHA1 для розпізнавання вузлів та користувачів для одного вузла призначення:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Ми рекомендуємо вмикати RSA/SHA1 лише у виключних випадках до оновлення або переналаштовування застарілих реалізації на інший тип ключа (зокрема ECDSA або Ed25519).
Сховища GitHub¶
Існує два основних підходи до доступу до репозиторіїв GitHub за допомогою Weblate:
Варіант 1: HTTPS з персональним токеном доступу (простіше для початку)
Використовуйте HTTPS-автентифікацію з персональним токеном доступу та вашим обліковим записом GitHub. Це працює як для доступу лише для читання (клонування), так і для доступу для читання та запису (надсилання змін або створення запитів на зняття).
Щоб скористатися цим підходом:
Створіть персональний токен доступу, як описано в розділі Створення токена доступу для використання в командному рядку.
Включіть токен до URL-адреси вашого репозиторію:
https://username:token@github.com/owner/repo.git
Це зручно, якщо ви тільки починаєте роботу з Weblate або працюєте з одним репозиторієм.
Варіант 2: SSH з виділеним користувачем (рекомендовано для кількох репозиторіїв)
Для налаштувань з кількома репозиторіями рекомендується створити окремого користувача для Weblate. Це дозволить уникнути обмеження GitHub, яке полягає в тому, що кожен SSH-ключ можна використовувати лише один раз на одній платформі.
Щоб скористатися цим підходом:
Створіть окремий обліковий запис користувача GitHub (наприклад,
weblate-bot)Додати публічний SSH-ключ Weblate до цього користувача (див. Ключ SSH Weblate)
Надайте цьому користувачеві доступ до всіх репозиторіїв, які ви хочете перекласти
Використовуйте SSH-URL-адреси для своїх репозиторіїв:
git@github.com:owner/repo.git
Цей підхід також використовується для Hosted Weblate, який має спеціального користувача weblate для цієї мети.
Примітка
Під час використання Запити щодо злиття GitHub для пул-реквестів, конфігурація Гілка для запису впливає на поведінку: якщо не встановлено, проєкт розгалужується, а зміни надсилаються через розгалуження. Якщо встановлено, зміни надсилаються до основного репозиторію та вибраної гілки.
Репозиторії GitLab¶
Доступ через SSH можливий (див. Сховища із доступом за SSH), але якщо вам потрібно отримати доступ до більш ніж одного репозиторію, ви зіткнетеся з обмеженням GitLab щодо дозволеного використання SSH-ключів (оскільки кожен ключ можна використовувати тільки один раз).
Якщо Гілка для запису не встановлено, проєкт розгалужується, а зміни надсилаються через розгалуження. Якщо ж встановлено, зміни надсилаються до основного репозиторію та вибраної гілки.
Також можна використовувати особисті або проектні токени доступу. Токен потребує права доступу write_repository, щоб мати можливість відправляти зміни до репозиторію. Проектний токен доступу потребує ролі Developer для відправлення.
URL-адреса повинна містити ім’я користувача. Для особистого токена доступу це фактичне ім’я користувача (https://user:personal_access_token@gitlab.com/example/example.git), для токенів доступу до проєкту це може бути будь-яке значення, крім порожнього (https://example:project_access_token@gitlab.com/example/example.git).
Примітка
Правила використання токенів доступу до проектів змінилися між версіями GitLab. Зараз обов’язковим є вказання значення, яке не є порожнім, але в старих версіях були інші вимоги (назва проекту, ім’я користувача бота). Якщо ви не впевнені, перевірте документацію GitLab, що відповідає вашій версії.
Внутрішні адреси Weblate¶
Щоб скористатися одним спільним сховищем для різних складників ви можете використати особливу адресу, weblate://проєкт/складник в інших (пов’язаних) складниках. Тоді, складник матиме спільні налаштування сховища системи керування версіями з еталонним складником.
Попередження
Вилучення основного складника призводить до вилучення пов’язаних складників.
Weblate автоматично коригує адресу сховища при створенні складника, якщо виявляє складник із відповідними налаштуваннями сховища. Ви можете перевизначити цю поведінку на останньому кроці налаштовування складника.
Причини для використання внутрішніх адрес:
Заощаджує місце на диску сервера — сховище зберігається лише один раз.
Пришвидшує оновлення — оновлюється лише один сховище.
Наявність лише одного експортованого сховища із перекладами Weblate (див. Засіб експортування Git).
Деякі додатки можуть працювати із декількома складниками, які мають єдине спільне сховище, наприклад Сполучити Git подання.
Сховища HTTPS¶
Дивись також
Щоб отримати доступ до захищених сховищ HTTPS, включіть до адреси ім’я користувача і пароль. Не слід хвилюватися — Weblate вилучить ці дані при показі адреси користувачам (якщо взагалі показуватиме їм адресу сховища).
Наприклад, адреса GitHub із доданими даними розпізнавання може виглядати так: https://користувач:ваш_жетон_доступу@github.com/WeblateOrg/weblate.git.
Якщо ви не вкажете облікові дані в URL-адресі, а репозиторій їх вимагає, Git повернеться з помилкою:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Змінено в версії 5.10.2: Weblate використовує проактивну автентифікацію з Git 2.46.0 і новіших версій, якщо надаються облікові дані HTTP.
Це дає змогу отримати доступ до сховищ Azure DevOps і пришвидшує доступ до автентифікованих сховищ.
Примітка
Якщо ваше ім’я користувача і пароль містять спеціальні символи, їх слід записувати у 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.28 або новішої версії.
Дивись також
Див. розділ Доступ до сховищ, щоб дізнатися більше про доступ до сховищ різних типів.
Git з примусовим «push»¶
Це працює як і сам Git. Єдиною відмінністю є те, що запис завжди виконується примусово. Такий режим призначено лише для випадку використання окремого сховища для перекладів.
Попередження
Будьте обережні із використанням, оскільки так можна дуже просто втратити внески до вашого основного сховища.
Налаштовування Git¶
Weblate викликає усі команди VCS з використанням HOME=$DATA_DIR/home (див. DATA_DIR), тому редагування налаштувань користувача слід виконувати у DATA_DIR/home/.git.
Запити щодо злиття GitHub¶
Це додає тонкий шар над Git з використанням інструмента GitHub API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до сховища.
Git записує зміни безпосередньо до сховища, а Запити щодо злиття GitHub створює запити щодо об’єднання. Останній не потрібен для простого доступу до сховищ Git.
Щоб це запрацювало, вам потрібно налаштувати облікові дані API (GITHUB_CREDENTIALS) у налаштуваннях Weblate. Після налаштування ви побачите опцію GitHub під час вибору Система керування версіями.
Дивись також
Запити щодо об’єднання GitLab¶
Це просто додає тонкий шар над Git з використанням інструмента GitLab API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до сховища.
Потреби у використання цього інструмента для доступу до сховищ Git, звичайний Git працює так само. Єдиною відмінністю є спосіб обробки запису до сховища. З Git зміни записуються безпосередньо до сховища, а Запити щодо об’єднання GitLab створює запит щодо об’єднання.
Щоб це запрацювало, вам потрібно налаштувати облікові дані API (GITLAB_CREDENTIALS) у налаштуваннях Weblate. Після налаштування ви побачите опцію GitLab під час вибору Система керування версіями.
Дивись також
Запити щодо злиття Gitea¶
Added in version 4.12.
Це додає тонкий шар над Git з використанням інструмента Gitea API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до сховища.
Потреби у використання цього інструмента для доступу до сховищ Git, звичайний Git працює так само. Єдиною відмінністю є спосіб обробки запису до сховища. З Git зміни записуються безпосередньо до сховища, а Запити щодо злиття Gitea створює запит щодо об’єднання.
Щоб це запрацювало, вам потрібно налаштувати облікові дані API (GITEA_CREDENTIALS) у налаштуваннях Weblate. Після налаштування ви побачите опцію Gitea при виборі Система керування версіями.
Дивись також
Запити на вилучення Bitbucket Data Center¶
Added in version 4.16.
Це лише додає тонкий шар поверх Git за допомогою Bitbucket Data Center API, щоб дозволити надсилати зміни перекладу як запити на витягування замість надсилання безпосередньо до репозиторію.
Попередження
Тут не передбачено підтримки хмарного програмного інтерфейсу Bitbucket.
Потреби у використання цього інструмента для доступу до сховищ Git, звичайний Git працює так само. Єдиною відмінністю є спосіб обробки запису до сховища. З Git зміни записуються безпосередньо до сховища, а Запити на вилучення Bitbucket Data Center створює запит щодо об’єднання.
Вам потрібно налаштувати облікові дані API (BITBUCKETSERVER_CREDENTIALS) у налаштуваннях Weblate, щоб це працювало. Після налаштування ви побачите опцію Центр даних Bitbucket, вибравши Система керування версіями.
Дивись також
Запити щодо об’єднання Bitbucket Cloud¶
Added in version 5.8.
Це додає тонкий шар над Git з використанням інструмента програмного інтерфейсу Bitbucket Cloud, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до сховища.
Попередження
Це відрізняється від Bitbucket Data Center API.
Потреби у використання цього інструмента для доступу до сховищ Git, звичайний Git працює так само. Єдиною відмінністю є спосіб обробки запису до сховища. З Git зміни записуються безпосередньо до сховища, а Запити щодо об’єднання Bitbucket Cloud створює запит щодо об’єднання.
Щоб це запрацювало, вам потрібно налаштувати облікові дані API (BITBUCKETCLOUD_CREDENTIALS) у налаштуваннях Weblate. Після налаштування ви побачите опцію Bitbucket Cloud під час вибору Система керування версіями.
Дивись також
Запити щодо об’єднання Pagure¶
Added in version 4.3.2.
Це просто додає тонкий шар над Git з використанням інструмента Pagure API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до сховища.
Потреби у використання цього інструмента для доступу до сховищ Git, звичайний Git працює так само. Єдиною відмінністю є спосіб обробки запису до сховища. З Git зміни записуються безпосередньо до сховища, а Запити щодо об’єднання Pagure створює запит щодо об’єднання.
Щоб це запрацювало, вам потрібно налаштувати облікові дані API (PAGURE_CREDENTIALS) у налаштуваннях Weblate. Після налаштування ви побачите опцію Pagure під час вибору Система керування версіями.
Дивись також
Gerrit¶
Це додає тонкий шар над Git з використанням інструмента git-review, щоб уможливити запис змін у перекладах як запитів щодо рецензування Gerrit, замість безпосереднього запису до сховища.
У документації до Gerrit наведено подробиці щодо налаштувань, потрібних для таких сховищ.
Запити щодо об’єднання Azure DevOps¶
Це додає тонкий шар над Git з використанням інструмента Azure DevOps API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до сховища.
Git записує зміни безпосередньо до сховища, а Запити щодо об’єднання Azure DevOps створює запити щодо об’єднання. Останній не потрібен для простого доступу до сховищ Git.
Щоб це запрацювало, вам потрібно налаштувати облікові дані API (AZURE_DEVOPS_CREDENTIALS) у налаштуваннях Weblate. Після налаштування ви побачите опцію Azure DevOps під час вибору Система керування версіями.
Дивись також
Mercurial¶
Ще однією системою керування версіями, якою ви можете користуватися безпосередньо у Weblate є Mercurial.
Примітка
Це має працювати із будь-якою версією Mercurial, але іноді можна зіткнутися із несумісними змінами у інтерфейсі командного рядка, які шкодять інтеграції із Weblate.
Дивись також
Див. розділ Доступ до сховищ, щоб дізнатися більше про доступ до сховищ різних типів.
Subversion¶
Weblate використовує для взаємодії з сховищами subversion git-svn. Це скрипт мовою Perl, який надає змогу користуватися subversion за допомогою клієнта Git, уможливлюючи для користувачів супровід повного клону внутрішнього сховища і локальні внески.
Примітка
Weblate намагається виявити компонування сховища Subversion автоматично — передбачено підтримку як безпосередніх адрес для гілок, так і сховища зі стандартним компонуванням (branches/, tags/ і trunk/). Докладніше про це можна дізнатися з документації до git-svn. Якщо компонування вашого сховища не є стандартним і ви стикаєтеся з помилками, спробуйте включити назву гілки у адресу сховища і лишити гілку порожньою.
Реєстраційні дані 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
Дивись також
Локальні файли¶
Підказка
Нижче використано Git. Для роботи слід встановити Git. Уможливлює перехід на безпосереднє використання Git із повним журналом перекладів.
Крім того, Weblate може працювати без віддаленої системи керування версіями. Початкові переклади імпортуються безпосереднім вивантаженням. Пізніше ви можете замінити окремі файли вивантаженням нових версій або додати рядки перекладу безпосередньо з Weblate (у поточній версії цю можливість реалізовано лише для одномовних перекладів).
За лаштунками, Weblate створює сховище Git і стежить за усіма змінами за його допомогою. Якщо ви згодом вирішите скористатися системою керування версіями для зберігання ваших перекладів,у вас вже буде сховища у Weblate, на основі якого ви зможете побудувати інтеграцію.