Налаштування інтеграції із керуванням версіями#
Weblate currently supports Git (with extended support for Запити щодо злиття GitHub, Запити щодо об’єднання GitLab, Запити щодо злиття Gitea, Gerrit, Subversion, Запит щодо злиття для сервера Bitbucket, and Azure DevOps pull requests) and Mercurial as version control back-ends.
Доступ до сховищ#
Сховище системи керування версіями, яким ви хочете користуватися, має бути доступним для Weblate. Якщо сховище загальнодоступний, вам достатньо ввести правильну адресу (наприклад https://github.com/WeblateOrg/weblate.git), але для приватних сховищ або адрес для запису налаштовування є складнішим і вимагає розпізнавання користувача.
Доступ до сховищ з Hosted Weblate#
Для Hosted Weblate існує спеціалізований зареєстрований користувач для внесення змін на GitHub, Bitbucket, Codeberg і GitLab (його іменем користувача є weblate, а адресою електронної пошти — hosted@weblate.org, назву або опис профілю наведено у розділі Користувач-записувач Weblate).
Підказка
На платформах можуть бути додаткові користувачі Weblate, які призначено для використання у інших екземплярах Weblate. Рекомендуємо скористатися пошуком за адресою електронної пошти hosted@weblate.org для виявлення належного користувача для Hosted Weblate.
Вам слід додати цього користувача як учасника розробки і надати йому відповідні права доступу до вашого сховища (для клонування достатньо прав на читання, для запису потрібні права запису). Залежно від служби і параметрів вашої організації надання прав буде здійснено негайно або потребуватиме підтвердження з боку Weblate.
Запрошення для користувача :guilabel:`weblate`на GitHub приймаються автоматично протягом п’яти хвилин. У інших службах може знадобитися обробка вручну, тому, будь ласка, майте терпіння.
Щойно користувача weblate буде додано до вашого сховища, ви можете налаштувати сховище початкового коду і адресу запису до сховища з використання протоколу SSH (наприклад, git@github.com:WeblateOrg/weblate.git).
Accessing repositories on code hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)#
Accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Ключ SSH Weblate). This way you associate Weblate SSH key with a single user (this of frequently enforced by the platform) and grant this user access to the repository. You can then use SSH URL to access the repository (see Сховища із доступом за SSH).
Підказка
On a Hosted Weblate, this is pre-cofigured for most of the public sites, please see Доступ до сховищ з Hosted Weblate.
Сховища із доступом за 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) і натисніть кнопку Надіслати. Перевірте, чи відбиток збігається з доданим вами сервером.
Додані ключі із відбитками буде показано у повідомленні підтвердження:
Connecting to legacy SSH servers#
Recent OpenSSH releases (for example the one used in Weblate Docker container) disable RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K.
For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. The SSH connection to such server will fail with:
no matching host key type found. Their offer: ssh-rsa
For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow
connection and/or user authentication via the HostkeyAlgorithms and
PubkeyAcceptedAlgorithms options. For example, the following stanza in
DATA_DIR/ssh/config will enable RSA/SHA1 for host and user
authentication for a single destination host:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).
Сховища 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#
Це додає тонкий шар над Git з використанням інструмента GitHub API, щоб уможливити запис змін у перекладах як запитів щодо об’єднання, замість безпосереднього запису до сховища.
Git записує зміни безпосередньо до сховища, а Запити щодо злиття GitHub створює запити щодо об’єднання. Останній не потрібен для простого доступу до сховищ Git.
Щоб це спрацювало, вам слід налаштувати реєстраційні дані для програмного інтерфейсу (GITHUB_CREDENTIALS) у параметрах Weblate. Після налаштовування ви побачите пункт GitHub при виборі системи керування версіями складника.
Дивись також
Запити щодо об’єднання GitLab#
Це просто додає тонкий шар над 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#
Це додає тонкий шар над Git з використанням інструмента git-review, щоб уможливити запис змін у перекладах як запитів щодо рецензування Gerrit, замість безпосереднього запису до сховища.
У документації до Gerrit наведено подробиці щодо налаштувань, потрібних для таких сховищ.
Azure DevOps pull requests#
This adds a thin layer atop Git using the Azure DevOps API to allow pushing translation changes as pull requests, instead of pushing directly to the repository.
Git pushes changes directly to a repository, while Azure DevOps pull requests creates pull requests. The latter is not needed for merely accessing Git repositories.
You need to configure API credentials (AZURE_DEVOPS_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Azure DevOps option when selecting Система керування версіями.
Дивись також
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, на основі якого ви зможете побудувати інтеграцію.