Интеграция с системой контроля версий

Weblate currently supports Git (with extended support for GitHub, Gerrit and Subversion) and Mercurial as version control back-ends.

Доступ к репозиториям

Репозиторий системы контроля версий, который вы хотите использовать, должен быть доступен для Weblate. При использовании общедоступного репозитория вам просто надо указать правильный URL-адрес (например, https://github.com/WeblateOrg/weblate.git), но для частных репозиториев или для URL-адресов отправки изменений настройка будет более сложной и потребует аутентификации.

Доступ к репозиториям из Hosted Weblate

For Hosted Weblate there is a dedicated push user registered on GitHub, Bitbucket, Codeberg and GitLab (with the username weblate, e-mail hosted@weblate.org and, named Weblate push user). You need to add this user as a collaborator and give it appropriate permission to your repository (read-only is okay for cloning, write is required for pushing). Depending on service and your organization settings, this happens immediately, or requires confirmation on the Weblate side.

The weblate user on GitHub accepts invitations automatically within five minutes. Manual processing might be needed on the other services, so please be patient.

Once the weblate user is added, you can configure Репозиторий исходного кода and URL для отправки в репозиторий using the SSH protocol (for example git@github.com:WeblateOrg/weblate.git).

Репозитории по SSH

Наиболее часто используемый метод доступа к частным репозиториям — доступ по SSH. Чтобы дать Weblate такой доступ к вышестоящему репозиторию, авторизуйте его публичный SSH-ключ (смотрите раздел SSH-ключ Weblate).

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

On GitHub, each key can only be used once, see Репозитории GitHub and Доступ к репозиториям из Hosted Weblate.

Weblate также сохраняет отпечаток ключа сервера при первом подключении и не сможет подключиться к нему, если в дальнейшем ключ будет изменён (смотрите раздел Проверка SSH-ключей сервера).

В случае, если его будет необходимо изменить, это можно сделать из интерфейса администратора Weblate:

_images/ssh-keys.png

SSH-ключ Weblate

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

Администраторы могут сгенерировать или посмотреть публичный ключ, который в настоящее время использует Weblate (из блока SSH-ключи) на странице входа в интерфейс администратора.

Примечание

Соответствующий закрытый SSH-ключ в настоящее время не может быть запаролен, поэтому убедитесь, что он хорошо защищён.

Подсказка

Сделайте резервную копию сгенерированного закрытого SSH-ключа Weblate.

Проверка SSH-ключей сервера

Weblate автоматически сохраняет для дальнейшего использования SSH-ключи серверов при первом обращении к ним.

В случае, если вы хотите, подтвердить подлинность отпечатков ключей до первого подключения к репозиторию, добавьте SSH-ключ тех серверов, к которым вы собираетесь подключаться, через пункт Добавить ключ хоста, в том же разделе интерфейса администратора. Введите имя хоста, к которому вы собираетесь получить доступ (например, gitlab.com), и нажмите Подтвердить. После этого вы сможете убедится, что отпечаток этого ключа соответствует тому серверу, который вы добавляете.

Добавленные ключи и их отпечатки будут отображаться в сообщении о подтверждении:

_images/ssh-keys-added.png

Репозитории GitHub

Доступ по SSH возможен (смотрите раздел. Репозитории по SSH), но в случае, если вам необходимо получить доступ к более чем одному репозиторию, вы столкнётесь с ограничением GitHub’а по разрешённому использованию ключей SSH (поскольку один ключ может быть использован только один раз).

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

Для небольших проектов используйте HTTPS-аутентификацию с персональным токеном доступа и вашей GitHub’овской учётной записью, смотрите подробности в документации GitHub’а: Создание токена доступа для использования из командной строки.

Для более крупных конфигураций обычно лучше создать для Weblate специального пользователя, назначить ему открытый SSH-ключ, сгенерированный Weblate (смотрите раздел SSH-ключ Weblate), и предоставить ему доступ ко всем репозиториям, которые вы собираетесь переводить. Этот подход также используется и наоблачном хостинге Weblate, для него на GitHub есть специальный пользователь weblate.

Внутренние URL-адреса Weblate

Share one repository setup between different components by referring to its placement as weblate://project/component in other(linked) components. This way linked components use the VCS repository configuration of the main(referenced) component.

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

Removing main component also removes linked components.

Weblate automatically adjusts the repository URL when creating a component if it finds a component with a matching repository setup. You can override this in the last step of the component configuration.

Зачем это нужно:

  • Экономия дискового пространства на сервере: хранится только одна копия репозитория.

  • Ускорение обновлений: обновляется только один репозиторий.

  • Существует только один экспортируемый репозиторий с переводами Weblate (смотрите раздел Экспортер Git).

  • Некоторые надстройки могут работать с несколькими компонентами, совместно использующими один репозиторий, например, «Уплотнение Git-коммитов».

Репозитории по HTTPS

Для доступа к защищённым HTTPS-репозиториям включите в URL-адрес имя пользователя и пароль. Не волнуйтесь, Weblate обрежет эту информацию, когда адрес будет показываться пользователям (если им вообще будет разрешено просматривать адрес репозитория).

Например, URL-адрес 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

См.также

Для получения информации о том, как получить доступ к различным типам репозиториев, смотрите раздел Доступ к репозиториям.

Git c принудительной отправкой (force push)

Этот вариант ведёт себя точно так же, как и Git, с той лишь разницей, что он всегда выполняет принудительную отправку. Он предназначен только для тех случаев, когда вы используете отдельный репозиторий для переводов.

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

Используйте с осторожностью, поскольку это может привести к потере коммитов в вашем репозитории.

Настройка конфигурации Git’а

Weblate выполняет все команды системы контроля версий с установкой HOME=$DATA_DIR/home (смотрите DATA_DIR), поэтому изменение пользовательских настроек нужно выполнять в DATA_DIR/home/.git.

Удалённые помощники Git

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

В настоящее время в отдельных GitHub’овских репозиторияхдоступны помощники для Bazaar и Mercurial: 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, в том, что удалённый помощник иногда создаёт новую оконечную фиксацию (tip) при отправке изменений обратно.

GitHub

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

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

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

Отправка изменений в GitHub в виде запросов на извлечение

Если вы не хотите отправлять переводы непосредственно в репозиторий GitHub’а, их можно отправить в виде одного или нескольких запросов на извлечение.

Чтобы это заработало, нужно будет настроить учётные данные API.

GitLab

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

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

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

Отправка изменений в GitLab в виде запросов на слияние

Если вы не хотите отправлять переводы непосредственно в репозиторий GitLab, их можно отправить в виде одного или нескольких запросов на слияние.

Чтобы это заработало, нужно будет настроить учётные данные API.

Pagure

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

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

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

Отправка изменений в Pagure в виде запросов на слияние

Если вы не хотите отправлять переводы непосредственно в репозиторий Pagure, их можно отправить в виде одного или нескольких запросов на слияние.

Чтобы это заработало, нужно будет настроить учётные данные API.

Gerrit

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

Это просто добавляет тонкий слой логики поверх Git с помощью git-review , что позволяет отправлять изменения в переводе в виде запросов на рецензирование Gerrit вместо того, чтобы выполнять push непосредственно в репозиторий.

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

Mercurial

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

Mercurial — это ещё одна система контроля версий, которую вы можете использовать в Weblate напрямую.

Примечание

Weblate должен работать с любой версией Mercurial’а, но иногда в его интерфейсе командной строки происходят несовместимые изменения, которые нарушают его интеграцию с Weblate.

См.также

Для получения информации о том, как получить доступ к различным типам репозиториев, смотрите раздел Доступ к репозиториям.

Subversion

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

Для взаимодействия с хранилищем subversion Weblate использует команду git-svn. Это Perl-скрипт, который позволяет использовать subversion из клиента Git’а, позволяя пользователям поддерживать полный клон внутреннего хранилища и коммитить в него локально.

Примечание

Weblate автоматически пытается определить компоновку хранилища Subversion — он поддерживает как прямые URL-адреса для веток, так и хранилища со стандартной компоновкой (каталоги branches/, tags/ и trunk/). Подробнее об этом можно прочитать в документации к git-svn. Если ваше хранилище не придерживается стандартной компоновки и вы столкнулись с ошибками, попробуйте включить в URL-адрес хранилища имя ветки, а саму ветку оставить пустой.

Изменено в версии 2.19: Before this, only repositories using the standard layout were supported.

Учётные данные Subversion

Weblate expects you to have accepted the certificate up-front (and your credentials if needed). It will look to insert them into the DATA_DIR directory. Accept the certificate by using svn once with the $HOME environment variable set to the 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

См.также

DATA_DIR

Локальные файлы

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

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

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