Интеграция с системой контроля версий¶
Weblate currently supports Git (with extended support for Запрос на извлечение в GitHub, Запросы на слияние в GitLab, Запрос на извлечение в Gitea, Gerrit, Subversion, Bitbucket Cloud pull requests, Bitbucket Data Center pull requests, and Запросы на извлечение Azure DevOps) and Mercurial as version control back-ends.
Доступ к репозиториям¶
Репозиторий системы контроля версий, который вы хотите использовать, должен быть доступен для 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, назначенных для других экземпляров Weblate. Для поиска нужного пользователя для Hosted Weblate рекомендуется использовать поиск по адресу эл. почты hosted@weblate.org.
Вам необходимо добавить этого пользователя в качестве соавтора и предоставить ему соответствующие права доступа к вашему репозиторию (для клонирования подходит режим «только чтение», для «проталкивания» - «запись»). В зависимости от сервиса и настроек вашей организации это происходит сразу или требует подтверждения со стороны Weblate.
Приглашения GitHub пользователя weblate принимаются автоматически в течение пяти минут. На других сервисах может потребоваться ручная обработка, поэтому, наберитесь терпения.
После того как пользователь weblate добавлен в ваш репозиторий, вы можете настроить Репозиторий исходного кода и URL для отправки в репозиторий, используя протокол SSH (например, git@github.com:WeblateOrg/weblate.git).
Accessing repositories on code hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see SSH-ключ Weblate). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of a SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see Репозитории по SSH).
Подсказка
On a Hosted Weblate, this is pre-configured for most of the public sites, please see Доступ к репозиториям из Hosted Weblate.
Репозитории по SSH¶
Наиболее часто используемый метод доступа к частным репозиториям — доступ по SSH. Чтобы дать Weblate такой доступ к вышестоящему репозиторию, авторизуйте его публичный SSH-ключ (смотрите раздел SSH-ключ Weblate).
Предупреждение
На GitHub каждый ключ может быть использован только один раз, смотрите разделы Репозитории GitHub и Доступ к репозиториям из Hosted Weblate.
Weblate также сохраняет отпечаток ключа сервера при первом подключении и не сможет подключиться к нему, если в дальнейшем ключ будет изменён (смотрите раздел Проверка SSH-ключей сервера).
В случае, если его будет необходимо изменить, это можно сделать из интерфейса администратора Weblate:
SSH-ключ Weblate¶
Изменено в версии 4.17: Weblate теперь создаёт SSH-ключи RSA и Ed25519. Для новых установок рекомендуется использовать Ed25519.
Открытый ключ Weblate виден всем пользователям, просматривающим страницу О Weblate.
Администраторы могут сгенерировать или посмотреть публичный ключ, который в настоящее время использует Weblate (из блока SSH-ключи) на странице входа в интерфейс администратора.
Примечание
The corresponding private SSH key can not currently have a password, so ensure it is well protected.
Подсказка
Сделайте резервную копию сгенерированного закрытого SSH-ключа Weblate.
Проверка SSH-ключей сервера¶
Weblate автоматически сохраняет для дальнейшего использования SSH-ключи серверов при первом обращении к ним.
В случае, если вы хотите, подтвердить подлинность отпечатков ключей до первого подключения к репозиторию, добавьте SSH-ключ тех серверов, к которым вы собираетесь подключаться, через пункт Добавить ключ хоста, в том же разделе интерфейса администратора. Введите имя хоста, к которому вы собираетесь получить доступ (например, gitlab.com), и нажмите Подтвердить. После этого вы сможете убедится, что отпечаток этого ключа соответствует тому серверу, который вы добавляете.
Добавленные ключи и их отпечатки будут отображаться в сообщении о подтверждении:
Подключение к устаревшим SSH-серверам¶
В последних версиях OpenSSH (например, используемой в Docker-контейнере Weblate) по умолчанию отключены RSA-подписи с использованием хэш-алгоритма SHA-1. Это изменение было сделано в связи с тем, что хэш-алгоритм SHA-1 криптографически сломан, и в нём можно создавать противоречия хэшей с выбранным префиксом на сумму <50 тыс. долл.
Для большинства пользователей это изменение должно быть незаметным, и нет необходимости заменять ключи ssh-rsa. OpenSSH поддерживает подписи RFC8332 RSA/SHA-256/512 начиная с версии 7.2, и существующие ключи ssh-rsa будут автоматически использовать более сильный алгоритм, где это возможно.
Несовместимость более вероятна при подключении к старым реализациям SSH, которые не обновлялись или не следили за усовершенствованием протокола SSH. SSH-соединение с таким сервером завершится неудачей:
no matching host key type found. Their offer: ssh-rsa
В этих случаях может потребоваться выборочное повторное включение RSA/SHA1 для разрешения авторизации соединения и/или пользователя с помощью опций HostkeyAlgorithms и PubkeyAcceptedAlgorithms. Например, следующая строфа в DATA_DIR/ssh/config включит RSA/SHA1 для авторизации сервера и пользователя для одного сервера назначения:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Мы рекомендуем включать RSA/SHA1 только в качестве временной меры, пока не будут обновлены или перенастроены на другой тип ключа (например, ECDSA или Ed25519) устаревшие реализации.
Репозитории 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.
Предупреждение
Удаление главного компонента также удаляет связанные компоненты.
При создании компонента, если Weblate находит другой компонент с таким же репозиторием, то он автоматически заменяет его на разделяемый репозиторий с внутренним URL-адресом. Вы можете переопределить это позже, на последнем этапе настройки компонента.
Зачем это нужно:
Экономия дискового пространства на сервере: хранится только одна копия репозитория.
Ускорение обновлений: обновляется только один репозиторий.
Существует только один экспортируемый репозиторий с переводами Weblate (смотрите раздел Экспортер Git).
Некоторые надстройки могут работать с несколькими компонентами, использующими один репозиторий, например, «Уплотнение Git-коммитов».
Репозитории по HTTPS¶
Для доступа к защищённым HTTPS-репозиториям включите в URL-адрес имя пользователя и пароль. Не волнуйтесь, Weblate обрежет эту информацию, когда адрес будет показываться пользователям (если им вообще будет разрешено просматривать адрес репозитория).
Например, URL-адрес GitHub с добавленной авторизацией будет выглядеть примерно следующим образом: https://пользователь:ваш_токен_доступа@github.com/WeblateOrg/weblate.git.
Изменено в версии 5.10.2: Weblate uses proactive authentication with Git 2.46.0 and newer when HTTP credentials are supplied.
This makes it possible to access Azure DevOps repositories and makes access to authenticated repositories faster.
Примечание
Если имя вашего пользователя или пароль содержат специальные символы, то они должны быть закодированы для использования в 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¶
Подсказка
Weblate needs Git 2.28 or newer.
См. также
Для получения информации о том, как получить доступ к различным типам репозиториев, смотрите раздел Доступ к репозиториям.
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::https://selenic.com/repo/hello
Предупреждение
Неудобство использования удалённых помощников Git’а заключается , на примере Mercurial, в том, что удалённый помощник иногда создаёт новую оконечную фиксацию (tip) при отправке изменений обратно.
Запрос на извлечение в GitHub¶
Это просто добавляет тонкий слой логики поверх Git с помощью API GitHub, что позволяет отправлять изменения в переводе в виде запросов на извлечение, вместо того, чтобы отправлять их непосредственно в репозиторий.
Git отправляет изменения непосредственно в репозиторий, в то время как Запрос на извлечение в GitHub создаёт запросы на извлечение. Для простого доступа к Git-репозиториям последние не нужны.
Для того чтобы это работало, необходимо настроить учётные данные API (GITHUB_CREDENTIALS) в настройках Weblate. После настройки вы увидите опцию GitHub при выборе Система контроля версий.
См. также
Запросы на слияние в GitLab¶
Это просто добавляет тонкий слой логики поверх Git с помощью API GitLab, что позволяет отправлять изменения в переводе в виде запросов на слияние вместо того, чтобы отправлять их непосредственно в репозиторий.
Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как Запросы на слияние в GitLab создаёт запрос на слияние.
Для того чтобы это работало, необходимо настроить учётные данные API (GITLAB_CREDENTIALS) в настройках Weblate. После настройки вы увидите опцию GitLab при выборе Система контроля версий.
См. также
Запрос на извлечение в Gitea¶
Добавлено в версии 4.12.
Это просто добавляет тонкий слой поверх Git с помощью API Gitea, что позволяет отправлять изменения в переводе в виде запросов на извлечение, вместо отправки непосредственной в репозиторий.
Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как Запрос на извлечение в Gitea создаёт запросы на извлечение.
Для того чтобы это работало, необходимо настроить учётные данные API (GITEA_CREDENTIALS) в настройках Weblate. После настройки вы увидите опцию Gitea при выборе Система контроля версий.
См. также
Bitbucket Data Center pull requests¶
Добавлено в версии 4.16.
This just adds a thin layer atop Git using the Bitbucket Data Center API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
Предупреждение
Это не поддерживает Bitbucket Cloud API.
Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как Bitbucket Data Center pull requests создаёт запросы на извлечение.
You need to configure API credentials (BITBUCKETSERVER_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Bitbucket Data Center option when selecting Система контроля версий.
Bitbucket Cloud pull requests¶
Добавлено в версии 5.8.
This just adds a thin layer atop Git using the Bitbucket Cloud API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
Предупреждение
This is different from Bitbucket Data Center API.
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 Bitbucket Cloud pull requests creates pull request.
You need to configure API credentials (BITBUCKETCLOUD_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Bitbucket Cloud option when selecting Система контроля версий.
Запросы на слияние в Pagure¶
Добавлено в версии 4.3.2.
Это просто добавляет тонкий слой логики поверх Git с помощью API Pagure, что позволяет отправлять изменения в переводе в виде запросов на слияние вместо того, чтобы выполнять push непосредственно в репозиторий.
Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как Запросы на слияние в Pagure создаёт запрос на слияние.
Для того чтобы это работало, необходимо настроить учётные данные API (PAGURE_CREDENTIALS) в настройках Weblate. После настройки вы увидите опцию Pagure при выборе Система контроля версий.
См. также
Gerrit¶
Это просто добавляет тонкий слой логики поверх Git с помощью git-review , что позволяет отправлять изменения в переводе в виде запросов на рецензирование Gerrit вместо того, чтобы выполнять push непосредственно в репозиторий.
В документации Gerrit подробно описаны те настройки, которые необходимо сделать для использования таких репозиториев.
Запросы на извлечение Azure DevOps¶
Это добавляет тонкий слой поверх Git, использующий Azure DevOps API, чтобы позволить отправлять изменения перевода в виде запросов на извлечение, вместо того чтобы отправлять их непосредственно в репозиторий.
Git осуществляет непосредственное внесение изменений в репозиторий, а Запросы на извлечение Azure DevOps - создание запросов на извлечение. Последний не нужен для простого доступа к Git-репозиториям.
Для того чтобы это работало, необходимо настроить учётные данные API (AZURE_DEVOPS_CREDENTIALS) в настройках Weblate. После настройки вы увидите опцию Azure DevOps при выборе Система контроля версий.
Mercurial¶
Mercurial — это ещё одна система контроля версий, которую вы можете использовать в Weblate напрямую.
Примечание
Weblate должен работать с любой версией Mercurial’а, но иногда в его интерфейсе командной строки происходят несовместимые изменения, которые нарушают его интеграцию с Weblate.
См. также
Для получения информации о том, как получить доступ к различным типам репозиториев, смотрите раздел Доступ к репозиториям.
Subversion¶
Для взаимодействия с репозиторием subversion Weblate использует команду git-svn. Это Perl-скрипт, который позволяет использовать subversion из клиента Git’а, позволяя пользователям поддерживать полный клон внутреннего репозитория и коммитить в него локально.
Примечание
Weblate автоматически пытается определить компоновку репозитория Subversion — он поддерживает как прямые URL-адреса для веток, так и репозитории со стандартной компоновкой (каталоги branches/, tags/ и trunk/). Подробнее об этом можно прочитать в документации к git-svn. Если ваш репозиторий не придерживается стандартной компоновки и вы столкнулись с ошибками, попробуйте включить в URL-адрес репозитория имя ветки, а саму ветку оставить пустой.
Учётные данные 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
См. также
Локальные файлы¶
Подсказка
Для них используется Git. Требуется установленный Git и позволяет вам перейти на его использование нативно с полной историей ваших переводов.
Weblate также может работать без удалённой системы контроля версий. Первоначальные переводы импортируются путём их загрузки. Позже вы можете заменить отдельные файлы через загрузку файлов или добавить строки перевода непосредственно из Weblate (в настоящее время этот функционал доступен только для одноязычных переводов).
Weblate создаст свой внутренний Git-репозиторий, в котором будут отслеживаться все изменения. В случае, если вы позже решите использовать систему контроля версий для хранения переводов, у вас уже будет готовый репозиторий внутри Weblate, на основе которого можно будет создать свой собственный.