Интеграции с хостингом кода¶

Weblate интегрируется с сайтами хостинга кода в нескольких отдельных местах: доступ к репозиторию, входящие уведомления и отправка переводов обратно. Точная настройка зависит от того, используете ли вы Хостинг Weblate или запускаете свой собственный экземпляр Weblate, а также от того, должен ли Weblate отправлять напрямую или создавать запросы на извлечение.

Используйте эту страницу как контрольный список, ориентированный на поставщика. Отдельные страницы настроек остаются каноническим справочником по синтаксису настроек.

Обзор настройки¶

Предоставьте Weblate доступ к репозиторию.
- Для Хостинга Weblate добавьте пользователя хостинга weblate там, где он доступен, см. Доступ к репозиториям из Hosted Weblate.
- Для самостоятельно размещённого Weblate создайте выделенного пользователя хостинга кода и предоставьте доступ с использованием SSH-ключа Weblate или HTTPS-токена, см. Доступ к репозиториям на сайтах хостинга кода (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Настройте Репозиторий исходного кода, чтобы Weblate мог клонировать репозиторий.
Настройте входящие уведомления, чтобы Weblate извлекал изменения вскоре после отправки. Веб-обработчик или приложение репозитория должны указывать на соответствующий URL-адрес обработчика Weblate, и в проекте должен быть включён Включить обработчики.
Решите, как Weblate должен отправлять переводы обратно:
- Используйте Git или Mercurial и URL для отправки в репозиторий для прямой отправки.
- Используйте внутренний механизм СКВ, специфичный для поставщика, например GitHub или GitLab, для создания запросов на извлечение или слияние. Этим механизмам требуются учётные данные API в настройках Weblate.
При необходимости установите Ветка для отправки, когда Weblate должен отправлять в ветку в вышестоящем репозитории вместо использования форка, где это поддерживается.

Отправка изменений из Weblate¶

Каждый компонент перевода может иметь настроенный URL-адрес для отправки (см. URL для отправки в репозиторий), и в этом случае Weblate сможет отправлять изменения в удалённый репозиторий. Weblate также можно настроить на автоматическую отправку изменений при каждом коммите; это включено по умолчанию, см. Отправлять при коммите.

Если вы не хотите, чтобы изменения отправлялись автоматически, вы можете отправлять их вручную в разделе Обслуживание репозитория или через API с помощью wlc push.

Если вы не хотите использовать прямые отправки Weblate, существует поддержка Запрос на извлечение в GitHub, Запросы на слияние в GitLab, Запрос на извлечение в Gitea, Запросы на слияние в Pagure, Запросы на извлечение Azure DevOps или Запросы на рецензирование Gerrit рецензий. Вы можете активировать их, выбрав GitHub, GitLab, Gitea, Gerrit, Azure DevOps или Pagure в качестве Система контроля версий в Настройки компонента.

В целом, следующие параметры доступны для Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center и Bitbucket Cloud:

Желаемая настройка	Система контроля версий	URL для отправки в репозиторий	Ветка для отправки
Без отправки	Git	пусто	пусто
Отправка напрямую	Git	URL-адрес SSH	пусто
Отправка в отдельную ветку	Git	URL-адрес SSH	Имя ветки
Без отправки	Mercurial	пусто	пусто
Отправка напрямую	Mercurial	URL-адрес SSH	пусто
Запрос на извлечение в GitHub из форка	Запрос на извлечение в GitHub	пусто	пусто
Запрос на извлечение в GitHub из ветки	Запрос на извлечение в GitHub	URL-адрес SSH [1]	Имя ветки
Запрос на слияние в GitLab из форка	Запросы на слияние в GitLab	пусто	пусто
Запрос на слияние в GitLab из ветки	Запросы на слияние в GitLab	URL-адрес SSH [1]	Имя ветки
Запрос на слияние в Gitea из форка	Запрос на извлечение в Gitea	пусто	пусто
Запрос на слияние в Gitea из ветки	Запрос на извлечение в Gitea	URL-адрес SSH [1]	Имя ветки
Запрос на слияние в Pagure из форка	Запросы на слияние в Pagure	пусто	пусто
Pagure ’вский запрос на слияние из ветки	Запросы на слияние в Pagure	URL-адрес SSH [1]	Имя ветки
Запрос на извлечение в Azure DevOps из форка	Запросы на извлечение Azure DevOps	пусто	пусто
Запрос на извлечение Azure DevOps из ветви	Запросы на извлечение Azure DevOps	URL-адрес SSH [1]	Имя ветки
Рецензия Gerrit	Запросы на рецензирование Gerrit	URL-адрес SSH	Имя целевой ветки (необязательно)
Запрос на извлечение в Bitbucket Data Center из форка	Запросы на извлечение в Bitbucket Data Center	пусто	пусто
Запрос на извлечение в Bitbucket Data Center из форка	Запросы на извлечение в Bitbucket Data Center	URL-адрес SSH [1]	Имя ветки
Запрос на извлечение в Bitbucket Cloud из форка	Запросы на извлечение в Bitbucket Cloud	пусто	пусто
Запрос на извлечение в Bitbucket Cloud из форка	Запросы на извлечение в Bitbucket Cloud	URL-адрес SSH [1]	Имя ветки

GitHub¶

Доступ к репозиторию 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.

Этот подход также используется для Хостинга Weblate, у которого для этой цели есть выделенный пользователь weblate.

Примечание

При использовании GitHub для запросов на извлечение конфигурация Ветка для отправки влияет на поведение: если не задано, проект форкается, и изменения отправляются через форк. Если задано, изменения отправляются в вышестоящий репозиторий и выбранную ветку.

Уведомления GitHub¶

Weblate поставляется со встроенной поддержкой GitHub.

Если вы используете Хостинг Weblate, рекомендуемый подход — установить приложение Weblate. Приложение доставляет уведомления GitHub в Хостинг Weblate, поэтому вам не нужно настраивать отдельный Веб-обработчик в GitHub. Однако само по себе оно не предоставляет Хостингу Weblate доступ на запись к репозиторию. Чтобы отправлять изменения обратно, вам всё равно нужно добавить пользователя GitHub Хостинга Weblate weblate в качестве соавтора с доступом на запись; см. Доступ к репозиториям из Hosted Weblate.

Если вы не используете приложение, добавьте веб-обработчик Weblate в настройках репозитория (Webhooks), чтобы получать уведомления о каждой отправке в репозиторий GitHub, как показано на изображении ниже:

Payload URL состоит из URL-адреса вашего Weblate с добавлением /hooks/github/, например, для службы Hosted Weblate это https://hosted.weblate.org/hooks/github/.

Остальные поля вы можете оставить с настройками по умолчанию. Weblate умеет обрабатывать оба типа содержимого и потребляет только событие push.

См. также

Запрос на извлечение в GitHub¶

Это просто добавляет тонкий слой логики поверх Git с помощью API GitHub, что позволяет отправлять изменения в переводе в виде запросов на извлечение, вместо того, чтобы отправлять их непосредственно в репозиторий.

Git отправляет изменения непосредственно в репозиторий, в то время как внутренний механизм GitHub создаёт запросы на извлечение. Последний не нужен для простого доступа к Git-репозиториям.

Чтобы создавать запросы на извлечение, выберите GitHub в качестве Система контроля версий и настройте GITHUB_CREDENTIALS. Для GitHub.com используйте api.github.com в качестве узла API. Токен должен разрешать Weblate читать и записывать содержимое репозитория и создавать запросы на извлечение. Если Weblate должен форкать частные репозитории, токену также может потребоваться доступ на администрирование.

GitLab¶

Доступ к репозиторию 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, соответствующую вашей версии.

Уведомления GitLab¶

Weblate поддерживает обработчики GitLab. Добавьте веб-обработчик проекта с адресом назначения /hooks/gitlab/ в вашей установке Weblate, например https://hosted.weblate.org/hooks/gitlab/.

Решение проблем

Проверьте историю запросов веб-обработчиков GitLab, если веб-обработчики доставляются.
Тело ответа содержит информацию о сопоставленных компонентах.

См. также

Запросы на слияние в GitLab¶

Это добавляет тонкий слой поверх Git с использованием API GitLab, позволяющий отправлять изменения перевода в виде запросов на слияние вместо прямой отправки в репозиторий.

Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как внутренний механизм GitLab создаёт запрос на слияние.

Чтобы создавать запросы на слияние, выберите GitLab в качестве Система контроля версий и настройте GITLAB_CREDENTIALS.

Gitea, Forgejo и Codeberg¶

Для репозиториев Хостинга Weblate на Codeberg добавьте пользователя хостинга weblate там, где требуется доступ на запись, см. Доступ к репозиториям из Hosted Weblate.

Уведомления Gitea¶

Weblate поддерживает веб-обработчики Gitea. Добавьте Веб-обработчик Gitea для события Push events с адресом назначения, равным URL-адресу /hooks/gitea/ в вашей установке Weblate, например https://hosted.weblate.org/hooks/gitea/. Это можно сделать в разделе Webhooks в Настройках репозитория.

См. также

Уведомления Forgejo¶

Weblate поддерживает веб-обработчики Forgejo. Добавьте Веб-обработчик Forgejo для события Push events с адресом назначения, равным URL-адресу /hooks/forgejo/ в вашей установке Weblate, например https://hosted.weblate.org/hooks/forgejo/. Это можно сделать в разделе Webhooks в Настройках репозитория.

См. также

Запрос на извлечение в Gitea¶

Добавлено в версии 4.12.

Это добавляет тонкий слой поверх Git с использованием API Gitea, позволяющий отправлять изменения перевода в виде запросов на извлечение вместо прямой отправки в репозиторий.

Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как внутренний механизм Gitea создаёт запросы на извлечение.

Чтобы создавать запросы на извлечение, выберите Gitea в качестве Система контроля версий и настройте GITEA_CREDENTIALS.

Bitbucket¶

Хостинг Weblate имеет выделенного пользователя weblate для доступа к Bitbucket, см. Доступ к репозиториям из Hosted Weblate.

Для прямой отправки используйте Git или Mercurial с URL для отправки в репозиторий.

Уведомления Bitbucket¶

Weblate поддерживает веб-обработчики Bitbucket. Добавьте веб-обработчик, который срабатывает при отправке в репозиторий, с адресом назначения /hooks/bitbucket/ в вашей установке Weblate, например https://hosted.weblate.org/hooks/bitbucket/.

См. также

Запросы на извлечение в Bitbucket Data Center¶

Добавлено в версии 4.16.

Это добавляет тонкий слой поверх Git с использованием API Bitbucket Data Center, позволяющий отправлять изменения перевода в виде запросов на извлечение вместо прямой отправки в репозиторий.

Предупреждение

Это не поддерживает Bitbucket Cloud API.

Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как внутренний механизм Bitbucket Data Center создаёт запрос на извлечение.

Чтобы создавать запросы на извлечение, выберите Bitbucket Data Center в качестве Система контроля версий и настройте BITBUCKETSERVER_CREDENTIALS.

Запросы на извлечение в Bitbucket Cloud¶

Добавлено в версии 5.8.

Это добавляет тонкий слой поверх Git с использованием API Bitbucket Cloud, позволяющий отправлять изменения перевода в виде запросов на извлечение вместо прямой отправки в репозиторий.

Предупреждение

Это отличается от API Bitbucket Data Center API.

Нет необходимости использовать это для доступа к Git-репозиториям; обычный Git работает так же, единственное отличие — как обрабатывается отправка в репозиторий. С Git изменения отправляются непосредственно в репозиторий, а внутренний механизм Bitbucket Cloud создаёт запрос на извлечение.

Чтобы создавать запросы на извлечение, выберите Bitbucket Cloud в качестве Система контроля версий и настройте BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

Уведомления Azure Repos¶

Weblate поддерживает веб-обработчики Azure Repos. Добавьте веб-обработчик для события Code pushed с адресом назначения, равным URL-адресу /hooks/azure/ в вашей установке Weblate, например https://hosted.weblate.org/hooks/azure/. Это можно сделать в разделе Service hooks в Project settings.

См. также

Запросы на извлечение Azure DevOps¶

Это добавляет тонкий слой поверх Git, использующий Azure DevOps API, чтобы позволить отправлять изменения перевода в виде запросов на извлечение, вместо того чтобы отправлять их непосредственно в репозиторий.

Git отправляет изменения непосредственно в репозиторий, в то время как внутренний механизм Azure DevOps создаёт запросы на извлечение. Последний не нужен для простого доступа к Git-репозиториям.

Чтобы создавать запросы на извлечение, выберите Azure DevOps в качестве Система контроля версий и настройте AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Уведомления Pagure¶

Weblate поддерживает обработчики Pagure. Добавьте веб-обработчик с адресом назначения, равным URL-адресу /hooks/pagure/ в вашей установке Weblate, например https://hosted.weblate.org/hooks/pagure/. Это можно сделать в разделе Activate Web-hooks в Project options:

См. также

Запросы на слияние в Pagure¶

Добавлено в версии 4.3.2.

Это добавляет тонкий слой поверх Git с использованием API Pagure, позволяющий отправлять изменения перевода в виде запросов на слияние вместо прямой отправки в репозиторий.

Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как внутренний механизм Pagure создаёт запрос на слияние.

Чтобы создавать запросы на слияние, выберите Pagure в качестве Система контроля версий и настройте PAGURE_CREDENTIALS.

Другие рабочие процессы¶

Уведомления Gitee¶

Weblate поддерживает веб-обработчики Gitee. Добавьте WebHook для события Push с адресом назначения, равным URL-адресу /hooks/gitee/ в вашей установке Weblate, например https://hosted.weblate.org/hooks/gitee/. Это можно сделать в разделе WebHooks в Управлении репозитория.

См. также

Запросы на рецензирование Gerrit¶

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

The optional Ветка для отправки setting selects the target branch for the Gerrit review. Leave it empty to use Ветка репозитория. Use the short branch name, such as main; Weblate and git-review push the review to refs/for/<branch> automatically. Do not include Gerrit push options such as %submit or %l=Code-Review+2 in the branch name.

В документации Gerrit подробно описаны настройки, необходимые для использования таких репозиториев. Для этого внутреннего механизма нет отдельного параметра учётных данных хостинга кода.

Учётные данные Docker¶

Для установок Docker учётные данные API хостинга кода также могут быть предоставлены через переменные окружения, см. Учётные данные сайтов хостинга кода.