Code-hosting integrations¶

Weblate integrates with code-hosting sites in several separate places: repository access, incoming notifications, and pushing translations back. The exact setup depends on whether you use Hosted Weblate or run your own Weblate instance, and on whether Weblate should push directly or create pull or merge requests.

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

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

Предоставьте Weblate доступ к репозиторию.
- Для репозиториев GitHub на Hosted Weblate используйте приложение Hosted Weblate из потока Подключить учётную запись GitHub в Weblate. Приложение предоставляет Hosted Weblate доступ к репозиторию без необходимости приглашать пользователя хостинга weblate.
- Для других репозиториев Hosted Weblate и для прямых SSH-отправок вне рабочего процесса приложения GitHub добавьте пользователя хостинга weblate там, где это доступно, см. Доступ к репозиториям из Hosted Weblate.
- For self-hosted Weblate, create a dedicated code-hosting user and grant access using Weblate’s SSH key or an HTTPS token, see Accessing repositories on code-hosting sites (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¶

Приложение Hosted Weblate для GitHub¶

На Hosted Weblate рекомендуется подключать приложение Hosted Weblate из рабочего пространства Weblate, где находится ваш проект. Используйте поток Подключить учётную запись GitHub, установите приложение на пользователя или организацию GitHub, владеющую вашими репозиториями, предоставьте ему доступ к репозиториям, которые вы хотите переводить, и импортируйте компоненты из подключённой учётной записи GitHub.

Рабочий процесс с приложением использует токены доступа установки GitHub для клонирования, отправки веток перевода, создания запросов на извлечение и получения входящих уведомлений. Вам не нужно приглашать пользователя GitHub Hosted Weblate weblate или настраивать отдельный веб-обработчик репозитория для компонентов, импортированных таким образом.

Используйте пользователя GitHub Hosted Weblate weblate только когда вы намеренно настраиваете прямые SSH-отправки вне рабочего процесса приложения GitHub, см. Доступ к репозиториям из Hosted Weblate.

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-репозитория.

Для GitHub создайте выделенного пользователя, например weblate-bot, и используйте SSH-URL-адреса GitHub для ваших репозиториев, например git@github.com:owner/repo.git.

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

Примечание

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

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

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

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

Устаревшее приложение Hosted Weblate сохранено для существующих установок, использующих только веб-обработчики. Используйте его только тогда, когда вам нужно, чтобы устаревшее приложение доставляло уведомления GitHub в Hosted Weblate.

Для самостоятельного хостинга Weblate зарегистрируйте приложение GitHub, используя описанный ниже поток регистрации в приложении. Weblate генерирует манифест приложения, GitHub возвращает учётные данные, и они сохраняются в базе данных — никакой настройки через параметры не требуется.

Регистрация приложения GitHub из Weblate¶

Самый быстрый способ добавить приложение GitHub — позволить Weblate создать манифест приложения GitHub с предварительно заполненными правильными разрешениями, событиями и URL-адресом веб-обработчика:

Войдите в Weblate с учётной записью, имеющей доступ к управлению.
Open Manage → Code-hosting connections → Register Weblate GitHub App.
Заполните форму. Хост GitHub по умолчанию — github.com; при необходимости измените его на имя хоста вашего GitHub Enterprise. Оставьте Организация пустым, чтобы зарегистрировать приложение в личной учётной записи, или введите плашку организации, чтобы зарегистрировать его в этой организации.
Нажмите Продолжить в GitHub и подтвердите на странице GitHub Создать приложение GitHub (вы всё ещё можете переименовать приложение там).
GitHub перенаправляет обратно в Weblate, который обменивает временный код на идентификатор приложения, закрытый ключ, секрет веб-обработчика и плашку, и сохраняет их в базе данных. Кнопка Подключить учётную запись GitHub становится доступной сразу после этого.

The manifest requests the permissions and event subscriptions Weblate needs (Contents and Pull requests read/write, Metadata read-only, Organization administration read-only, Workflows read/write, and the Installation, Meta and Push events), and sets the callback, setup and per-app webhook URLs automatically, so no manual GitHub App configuration is required. GitHub delivers the Installation and Installation repositories events to all GitHub Apps by default.

GitHub предлагает только те учётные записи, где вошедший в систему пользователь GitHub может установить или запросить приложение. Если организация не отображается во время установки, проверьте роль пользователя в организации и ограничения на установку приложений GitHub в организации. На GitHub.com публичные приложения могут быть установлены на другие учётные записи; приватные приложения могут быть установлены только на учётную запись, которая владеет приложением.

Подключение рабочего пространства¶

Connected GitHub accounts are bound to a Weblate workspace. A user with project administration rights for any project in a workspace can connect a GitHub account on that workspace. After connecting, every project in the workspace can import components from repositories the GitHub App installation has access to. For organization accounts, Weblate verifies that the install-time GitHub user can administer the organization installation.

Projects that are not in a workspace cannot connect a GitHub account through the GitHub App.

Компоненты, импортированные через поток приложения GitHub, используют специализированный бэкенд СКВ GitHub (через приложение Weblate GitHub). Интерфейс настроек компонента оставляет URL-адрес репозитория только для чтения, чтобы предотвратить перенаправление учётных данных, выданных приложением, на посторонний репозиторий.

URL-адрес веб-обработчика приложения¶

Each registered Weblate GitHub App has its own webhook URL containing an opaque token that uniquely identifies a single registered App:

https://weblate.example.com/hooks/integrations/<webhook_token>/

Если вы не используете приложение GitHub, добавьте веб-обработчик Weblate в настройках репозитория (Веб-обработчики), чтобы получать уведомления о каждой отправке в репозиторий 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.

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

Уведомления 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 на Bitbucket добавьте пользователя хостинга weblate с необходимыми разрешениями на репозиторий, см. Доступ к репозиториям из 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 вместо прямой отправки в репозиторий.

Необязательный параметр Ветка для отправки выбирает целевую ветку для рецензии Gerrit. Оставьте его пустым, чтобы использовать Ветка репозитория. Используйте короткое имя ветки, например main; Weblate и git-review автоматически отправляют рецензию в refs/for/<branch>. Параметры отправки Gerrit можно добавлять после % в любой настройке, например main%topic=l10n. Gerrit интерпретирует эти параметры как настроенную учётную запись Weblate Gerrit и применяет свои собственные разрешения.

The Gerrit documentation has the details on the configuration necessary to set up such repositories. There is no separate code-hosting credential setting for this backend.

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

For Docker installations, code-hosting API credentials can also be provided through environment variables, see Code-hosting sites credentials.