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

В настоящее время Weblate в качестве систем контроля версий поддерживает Git (с расширенной поддержкой GitHub, Gerrit и Subversion) и Mercurial.

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

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

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

Для Hosted Weblate существует выделенный пользователь для отправки изменений, зарегистрированный на GitHub, Bitbucket, Codeberg и GitLab (с именем пользователя weblate, электронной почтой hosted@weblate.org и полным именем Weblate push user). Вам необходимо добавить этого пользователя в качестве сотрудника и дать ему в вашем репозитории соответствующее права (для клонирования будет достаточно только чтения, а отправка изменений потребует права на запись). В зависимости от конкретного сервиса и настроек вашей организации, это произойдёт или сразу, или потребует подтверждения со стороны Weblate.

Приглашения GitHub пользователя weblate принимаются автоматически в течение пяти минут. На других сервисах может потребоваться ручная обработка, поэтому, наберитесь терпения.

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

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

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

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

На GitHub каждый ключ может быть использован только один раз, смотрите разделы Репозитории GitHub и Доступ к репозиториям из 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

Совместное использование одной установки репозитория различными компонентами, можно ссылаясь на его размещение как weblate://проект/компонент в других (связанных) компонентах. В таком случае, ссылающиеся компоненты используют конфигурацию репозитория VCS главного (ссылочного) компонента.

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

Удаление главного компонента также удаляет связанные компоненты.

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

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

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

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

  • Существует только один экспортируемый репозиторий с переводами 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: До этого поддерживались только хранилища, использующие стандартный макет.

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

Weblate ожидает, что вы заранее приняли сертификат (и ваши учётные данные, если необходимо). Он будет искать возможность поместить их в каталог, указанный в DATA_DIR. Один раз примите сертификат, используя команду svn с переменной окружения $HOME, установленной в значение 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, на основе которого можно будет создать свой собственный.