Интеграция с системой контроля версий¶
В настоящее время Weblate в качестве систем контроля версий поддерживает Git (с расширенной поддержкой GitHub, Gerrit и Subversion) и Mercurial.
Доступ к репозиториям¶
Репозиторий системы контроля версий, который вы хотите использовать, должен быть доступен для Weblate. При использовании общедоступного репозитория вам просто надо указать правильный URL-адрес (например, https://github.com/WeblateOrg/weblate.git), но для частных репозиториев или для URL-адресов отправки изменений настройка будет более сложной и требует аутентификации.
Доступ к репозиториям из Hosted Weblate¶
Для Hosted Weblate существует выделенный пользователь для отправки изменений, зарегистрированный на GitHub, Bitbucket, Codeberg и GitLab (с именем пользователя weblate, известный также под именем Weblate push user). Вам необходимо добавить этого пользователя в качестве сотрудника и дать ему в вашем репозитории соответствующее разрешение (для клонирования подойдет только чтение, отправки изменений требуется запись). В зависимости от сервиса и настроек вашей организации, это произойдёт или немедленно, или потребует подтверждения со стороны Weblate.
Приглашения на GitHub принимаются автоматически в течение пяти минут, на другие сервисы может потребоваться ручная обработка, поэтому, пожалуйста, наберитесь терпения.
После того, как пользователь weblate будет добавлен, вы сможете настроить Репозиторий исходного кода и URL для отправки в репозиторий по протоколу SSH (например, git@github.com:WeblateOrg/weblate.git).
Репозитории по SSH¶
Наиболее часто используемый метод доступа к частным репозиториям основан на SSH. Чтобы получить таким образом доступ к вышестоящему репозиторию, авторизуйте публичный SSH-ключ Weblate (смотрите раздел SSH-ключ Weblate).
Предупреждение
На GitHub каждый ключ может быть добавлен только в один репозиторий, смотрите разделы Репозитории GitHub и Доступ к репозиториям из Hosted Weblate.
Weblate также сохраняет при первом подключении отпечаток ключа хоста и не сможет подключиться к хосту, если позже ключ будет изменён (смотрите раздел Проверка SSH-ключей хоста).
В случае необходимости его изменения это можно сделать из интерфейса администратора Weblate:
SSH-ключ Weblate¶
Открытый ключ Weblate виден всем пользователям, просматривающим страницу О Weblate.
Администраторы могут сгенерировать или посмотреть публичный ключ, который в настоящее время использует Weblate (из блока SSH-ключи) на странице входа в интерфейс администратора.
Примечание
Соответствующий закрытый SSH-ключ в настоящее время не может быть запаролен, поэтому убедитесь, что он хорошо защищён.
Подсказка
Сделайте резервную копию сгенерированного закрытого SSH-ключа Weblate.
Проверка SSH-ключей хоста¶
Weblate автоматически запоминает SSH-ключи хостов при первом к ним обращении и запоминает их для дальнейшего использования.
В случае, если вы хотите проверить их перед подключением к репозиторию, проверьте SSH-ключи хостов серверов, к которым вы собираетесь получить доступ через пункт Добавить ключ хоста, в том же разделе административного интерфейса. Введите имя хоста, к которому вы собираетесь получить доступ (например, gitlab.com), и нажмите Подтвердить. Убедитесь, что его отпечаток совпадает с отпечатком добавленного вами сервера. Они отображаются в сообщении о подтверждении:
Репозитории GitHub¶
Доступ по SSH возможен (смотрите раздел. Репозитории по SSH), но в случае, если вам необходимо получить доступ к более чем одному репозиторию, вы столкнётесь с ограничением GitHub’а по разрешённому использованию ключей SSH (поскольку один ключ может быть использован только для одного репозитория).
В случае, если ветка для отправки не задана, проект форкается и изменения отправляются через форк. В случае если она задана, изменения отправляются в вышестоящий репозиторий и выбранную ветку.
Для небольших развёртываний используйте HTTPS-аутентификацию с персональным токеном доступа и вашей GitHub’овской учётной записью, смотрите документ Создание токена доступа для использования из командной строки.
Для более крупных установок обычно лучше создать для Weblate специального пользователя, назначить ему сгенерированный в Weblate открытый SSH ключ (смотрите раздел SSH-ключ Weblate) и предоставить ему доступ ко всем репозиториям, которые вы хотите переводить. Этот подход также используется в Hosted Weblate, для этого есть выделенный пользователь weblate.
Внутренние URL-адреса Weblate¶
Для совместного использования одного репозитория между различными компонентами можно использовать специальный URL-адрес вида weblate://проект/компонент. Таким образом, компонент будет совместно использовать конфигурацию репозитория системы контроля версий с соответствующим компонентом (в примере это проект/компонент).
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 через прокси-сервер, настройте СКВ на его использование.
This can be done using the http_proxy, https_proxy, and all_proxy
environment variables, (as described in the cURL documentation)
or by enforcing it in the VCS configuration, for example:
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 для дополнительной поддержки других систем управления версиями, но будьте готовы к отладке проблем, которые могут за этим последовать.
В настоящее время помощники для Bazaar и Mercurial доступны в отдельных GitHub’овских репозиториях: 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, том, что удалённый помощник иногда создаёт новую оконечную фиксацию при обратном проталкивании изменений.
GitHub¶
Добавлено в версии 2.3.
Он добавляет с помощью API Github’а тонкий слой логики поверх Git, который позволяет отправлять изменения перевода в виде запросов на извлечение, вместо того, чтобы отправлять их непосредственно в репозиторий.
Git отправляет изменения непосредственно в репозиторий, в то время как GitHub создаёт запросы на извлечение. Для простого доступа к Git-репозиториям последние не нужны.
См.также
Отправка изменений в GitHub в виде запросов на извлечение¶
Если вы не хотите отправлять переводы непосредственно в репозиторий GitHub’а, их можно отправить в виде одного или нескольких запросов на извлечение.
You need to configure API credentials to make this work.
См.также
GitLab¶
Добавлено в версии 3.9.
Просто добавляет с помощью API GitLab’а тонкий слой логики поверх Git, который позволяет отправлять изменения перевода в виде запросов на слияние вместо того, чтобы отправлять их непосредственно в репозиторий.
Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как GitLab создаёт запрос на слияние.
См.также
Отправка изменений в GitLab в виде запросов на слияние¶
Если вы не хотите отправлять переводы непосредственно в репозиторий GitLab, их можно отправить в виде одного или нескольких запросов на слияние.
You need to configure API credentials to make this work.
См.также
Pagure¶
Добавлено в версии 4.3.2.
This just adds a thin layer atop Git using the Pagure API to allow pushing translation changes as merge requests instead of pushing directly to the repository.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while Pagure creates merge request.
См.также
Pushing changes to Pagure as merge requests¶
If not wanting to push translations to a Pagure repository, they can be sent as either one or many merge requests instead.
You need to configure API credentials to make this work.
См.также
Gerrit¶
Добавлено в версии 2.2.
Добавляет с помощью инструмента git-review тонкий слой логики поверх Git, который позволяет отправлять изменения перевода в виде запросов на рецензирование Gerrit, вместо того, чтобы отправлять их непосредственно в репозиторий.
В документации 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
См.также
Локальные файлы¶
Добавлено в версии 3.8.
Weblate также может работать без удалённой системы контроля версий. Первоначальные переводы импортируются путём их загрузки. Позже вы можете заменить отдельные файлы через загрузку файлов или добавить строки перевода непосредственно из Weblate (в настоящее время этот функционал доступен только для одноязычных переводов).
В фоне Weblate создаст Git-репозиторий, и будет отслеживать все изменения. В случае, если вы позже решите использовать для хранения переводов систему контроля версий, у вас уже будет репозиторий внутри Weblate, на основе которого вы сможете настроить свою интеграцию.