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

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¶

HTTPS с персональным токеном доступа¶

Для одного приватного репозитория HTTPS-доступ с токеном доступа обычно является самой простой настройкой, когда поставщик поддерживает Git через HTTPS. Используйте требуемое поставщиком имя пользователя и токен в Репозиторий исходного кода.

Настраивайте URL для отправки в репозиторий только когда Weblate должен отправлять изменения напрямую или когда выбранный рабочий процесс требует URL-адреса отправки, см. Отправка изменений из Weblate.

Токену требуется доступ на чтение для клонирования и доступ на запись для отправки. Серверные части СКВ специфичные для поставщика, которые создают запросы на извлечение или слияние, могут требовать отдельные учётные данные API.

Чтобы использовать этот подход:

Создайте персональный токен доступа, как описано в Создание токена доступа для использования в командной строке.
Включите токен в URL-адрес вашего репозитория: https://username:token@github.com/owner/repo.git.

Это подходит, когда вы начинаете работать с Weblate или работаете с одним репозиторием.

SSH с выделенным пользователем¶

Для установок с несколькими репозиториями используйте SSH-доступ с выделенным пользователем хостинга кода для Weblate. Добавьте публичный SSH-ключ Weblate этому пользователю, предоставьте пользователю доступ к репозиториям и используйте SSH-URL-адреса в Репозиторий исходного кода, например git@example.com:group/project.git.

Это также позволяет избежать ограничений поставщика на повторное использование SSH-ключей. Некоторые сайты хостинга кода позволяют добавить публичный SSH-ключ только один раз или только одному пользователю или записи ключа развёртывания. Хранение SSH-ключа Weblate у выделенного пользователя позволяет предоставить этому пользователю доступ к нескольким репозиториям без повторного использования ключа в нескольких местах.

Это позволяет не включать персональные, проектные токены или токены доступа API в URL-адреса репозиториев. Учётные данные API поставщика по-прежнему необходимы при использовании серверной части СКВ, специфичной для поставщика, для создания запросов на извлечение или слияние; эти учётные данные настраиваются отдельно от URL-адреса Git-репозитория.

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

Для GitHub создайте выделенного пользователя, например weblate-bot, и используйте SSH-URL-адреса GitHub для ваших репозиториев, например 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¶

HTTPS с персональным или проектным токеном доступа¶

Для GitLab токену требуется область действия 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, соответствующую вашей версии.

SSH с выделенным пользователем¶

Для GitLab создайте выделенного пользователя и используйте SSH-URL-адреса GitLab, например git@gitlab.com:group/project.git.

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

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

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

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

См. также

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

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

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

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

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

Gitea, Forgejo и Codeberg¶

Доступ к репозиториям Gitea, Forgejo и Codeberg¶

HTTPS с токеном доступа¶

SSH с выделенным пользователем¶

Для репозиториев Хостинга 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¶

Доступ к репозиторию Bitbucket¶

HTTPS с токеном доступа¶

SSH с выделенным пользователем¶

Хостинг 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¶

HTTPS с токеном доступа¶

Используйте HTTPS-URL-адрес клонирования, показываемый Azure Repos для репозитория.

SSH с выделенным пользователем¶

Используйте SSH-URL-адрес, показываемый Azure Repos для репозитория.

Уведомления 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¶

HTTPS с токеном доступа¶

SSH с выделенным пользователем¶

Уведомления 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¶

HTTPS с токеном доступа¶

SSH с выделенным пользователем¶

Уведомления 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. Gerrit push options can be appended after % in either setting, for example main%topic=l10n. Gerrit interprets these options as the configured Weblate Gerrit account and applies its own permissions.

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

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

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