Интеграция с системой контроля версий¶
В настоящее время 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 exporter).
Некоторые надстройки могут работать с несколькими компонентами, совместно использующими один репозиторий, например, надстройка Склеивать Git-коммиты.
Репозитории по HTTPS¶
Для доступа к защищённым HTTPS репозиториям включите в URL-адрес имя пользователя и пароль. Не волнуйтесь, Weblate обрежет эту информацию, когда адрес будет показываться пользователям (даже если им разрешено видеть адрес репозитория).
Например, URL-адрес GitHub с добавленной аутентификацией может выглядеть следующим образом: https://пользователь:ваш_токен_доступа@github.com/WeblateOrg/weblate.git.
Примечание
If you username or password contains special characters, those have to be
URL encoded, for example
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 для дополнительной поддержки других систем управления версиями, но будьте готовы к отладке проблем, которые могут за этим последовать.
В настоящее время помощники для 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.
Он добавляет с помощью инструмента hub тонкий слой логики поверх Git, который позволяет отправлять изменения перевода в виде запросов на извлечение, вместо того, чтобы отправлять их непосредственно в репозиторий.
Git отправляет изменения непосредственно в репозиторий, в то время как GitHub создаёт запросы на извлечение. Для простого доступа к Git-репозиториям последние не нужны.
См.также
Отправка изменений в GitHub в виде запросов на извлечение¶
Если вы не хотите отправлять переводы непосредственно в репозиторий GitHub, их можно отправить в виде одного или нескольких запросов на извлечение.
См.также
GITHUB_USERNAME, Установка hub для инструкций по настройке
Установка hub¶
Отправка изменений в GitHub в виде запросов на извлечение требует на вашем сервере настроенной установки hub. Следуйте инструкциям по установке, расположенным по адресу https://hub.github.com/, используя для завершения конфигурации hub, например:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home hub clone octocat/Spoon-Knife
hub спросит у вас ваши учётные данные от GitHub’а, извлечёт токен и сохранит его в файле ~/.config/hub. Этот файл должен быть доступен для чтения пользователю, запустившему Weblate.
Примечание
Установите имя пользователя, которое вы использовали при настройке hub переменной GITHUB_USERNAME (переменной окружения WEBLATE_GITHUB_USERNAME для образа Docker).
GitLab¶
Добавлено в версии 3.9.
Просто добавляет с помощью инструмента lab тонкий слой логики поверх Git, который позволяет отправлять изменения перевода в виде запросов на слияние вместо того, чтобы отправлять их непосредственно в репозиторий.
Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как GitLab создаёт запрос на слияние.
См.также
Отправка изменений в GitLab в виде запросов на слияние¶
Если вы не хотите отправлять переводы непосредственно в репозиторий GitLab, их можно отправить в виде одного или нескольких запросов на слияние.
Настройте инструмент командной строки lab и установите переменную GITLAB_USERNAME, чтобы он заработал.
См.также
GITLAB_USERNAME, Установка Lab для инструкций по настройке
Установка Lab¶
Отправка изменений в GitLab в виде запросов на слияние требует на вашем сервере настроенной установки lab. Следуйте инструкциям по установке, расположенным по адресу lab и запустите его без аргументов для завершения конфигурации, например:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
$ HOME=${DATA_DIR}/home lab
Enter GitLab host (default: https://gitlab.com):
Create a token here: https://gitlab.com/profile/personal_access_tokens
Enter default GitLab token (scope: api):
(Config is saved to ~/.config/lab.hcl)
lab спросит у вас ваш токен доступа к GitLab’у, извлечёт его и сохранит в файле ~/.config/lab.hcl. Этот файл должен быть доступен для чтения пользователю, запустившему Weblate.
Примечание
Установите имя пользователя, которое вы использовали при настройке lab переменной GITLAB_USERNAME (переменной окружения WEBLATE_GITLAB_USERNAME для образа Docker).
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, на основе которого вы сможете настроить свою интеграцию.