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

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

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

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

Предоставьте Weblate доступ к репозиторию.
- For GitHub repositories on Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow. The App gives Hosted Weblate repository access without inviting the hosted weblate user.
- For other Hosted Weblate repositories, and for direct SSH pushes outside the GitHub App workflow, add the hosted weblate user where it is available, see Доступ к репозиториям из 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¶

Hosted Weblate GitHub App¶

On Hosted Weblate, the recommended setup is to connect the Hosted Weblate app from the Weblate workspace where your project lives. Use the Connect GitHub account flow, install the App on the GitHub user or organization that owns your repositories, grant it access to the repositories you want to translate, and import components from the connected GitHub account.

The App-backed workflow uses GitHub installation access tokens for cloning, pushing translation branches, creating pull requests, and receiving incoming notifications. You do not need to invite the Hosted Weblate weblate GitHub user or configure a separate repository webhook for components imported this way.

Use the Hosted Weblate weblate GitHub user only when you intentionally configure direct SSH pushes outside the GitHub App workflow, see Доступ к репозиториям из 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-репозитория.

On Hosted Weblate, use provider integrations where available. For GitHub, the recommended setup is the Hosted Weblate app. For direct SSH access on supported code hosting sites, use the hosted weblate user, see Доступ к репозиториям из Hosted Weblate.

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

On Hosted Weblate, use this SSH-user workflow only for direct SSH pushes outside the recommended Hosted Weblate app workflow.

Примечание

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

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

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

If you are using Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow. It uses GitHub App webhooks, so you do not need to configure a separate Webhook in GitHub. Components imported from the connected GitHub account also use the App for repository access and pull requests, without inviting the Hosted Weblate weblate GitHub user.

The Hosted Weblate legacy app is kept for existing webhook-only setups. Use it only when you need the legacy app to deliver GitHub notifications to Hosted Weblate.

For self-hosted Weblate, register the GitHub App using the in-app registration flow described below. Weblate generates the App manifest, GitHub returns the credentials, and they are stored in the database - there is no settings-based configuration.

Registering the GitHub App from Weblate¶

The fastest way to add the GitHub App is to let Weblate generate a GitHub App manifest with the correct permissions, events, and webhook URL pre-filled:

Sign in to Weblate with an account that has management access.
Open Manage → VCS Installations → Register Weblate GitHub App.
Fill in the form. The GitHub host defaults to github.com; change it to your GitHub Enterprise hostname if needed. Leave Organization blank to register the App under your personal account, or enter an organization slug to register it under that org.
Click Continue to GitHub and confirm on GitHub’s Create GitHub App page (you can still rename the App there).
GitHub redirects back to Weblate, which exchanges the temporary code for the App ID, private key, webhook secret, and slug and stores them in the database. The Connect GitHub account button is available immediately afterwards.

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-integration 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 only offers accounts where the signed-in GitHub user can install or request the app. If an organization is not shown during the install flow, check the user’s organization role and the organization’s GitHub App installation restrictions. On GitHub.com, public apps can be installed on other accounts; private apps can only be installed on the account that owns the app.

Connecting a workspace¶

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 app installation has access to. For organization installations, Weblate verifies that the install-time GitHub user can administer the organization installation.

Projects that are not in a workspace cannot connect a GitHub App installation.

Components imported through the GitHub App flow use the dedicated GitHub (via Weblate GitHub app) VCS backend. The component settings UI keeps the repository URL read-only to prevent the App-issued credentials from being redirected to an unrelated repository.

App webhook URL¶

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

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

If you are not using a GitHub App, add the Weblate webhook in the repository settings (Webhooks) to receive notifications on every push to a GitHub repository, as shown on the image below:

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 support adds a thin layer atop Git using the git-review tool to allow pushing translation changes as Gerrit review requests, instead of pushing them directly to the repository.

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