Интеграция с системой контроля версий#
Weblate currently supports Git (with extended support for Запрос на извлечение в GitHub, Запросы на слияние в GitLab, Запрос на извлечение в Gitea, Gerrit, Подрывная деятельность, Запрос на принятие изменений в сервер Bitbucket, and Azure DevOps pull requests) 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 a name or profile description Weblate push user).
Подсказка
There can be more Weblate users on the platforms, designated for other Weblate instances.
Searching by e-mail hosted@weblate.org is recommended to find the correct
user for Hosted Weblate.
You need to add this user as a collaborator and give it appropriate permissions to your repository (read-only is okay for cloning, write is required for pushing). Depending on the service and your organization’s settings, this happens immediately, or requires confirmation on the Weblate side.
Приглашения GitHub пользователя weblate принимаются автоматически в течение пяти минут. На других сервисах может потребоваться ручная обработка, поэтому, наберитесь терпения.
Once the weblate user is added to your repository, you can configure
Репозиторий исходного кода and URL для отправки в репозиторий using the SSH protocol (for example
git@github.com:WeblateOrg/weblate.git).
Репозитории по 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-ключи) на странице входа в интерфейс администратора.
Примечание
Соответствующий закрытый SSH-ключ в настоящее время не может быть запаролен, поэтому убедитесь, что он хорошо защищён.
Подсказка
Сделайте резервную копию сгенерированного закрытого SSH-ключа Weblate.
Проверка SSH-ключей сервера#
Weblate автоматически сохраняет для дальнейшего использования SSH-ключи серверов при первом обращении к ним.
В случае, если вы хотите, подтвердить подлинность отпечатков ключей до первого подключения к репозиторию, добавьте SSH-ключ тех серверов, к которым вы собираетесь подключаться, через пункт Добавить ключ хоста, в том же разделе интерфейса администратора. Введите имя хоста, к которому вы собираетесь получить доступ (например, gitlab.com), и нажмите Подтвердить. После этого вы сможете убедится, что отпечаток этого ключа соответствует тому серверу, который вы добавляете.
Добавленные ключи и их отпечатки будут отображаться в сообщении о подтверждении:
Connecting to legacy SSH servers#
Recent OpenSSH releases (for example the one used in Weblate Docker container) disable RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K.
For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. The SSH connection to such server will fail with:
no matching host key type found. Their offer: ssh-rsa
For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow
connection and/or user authentication via the HostkeyAlgorithms and
PubkeyAcceptedAlgorithms options. For example, the following stanza in
DATA_DIR/ssh/config will enable RSA/SHA1 for host and user
authentication for a single destination host:
Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).
Репозитории 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#
Подсказка
Weblate необходим Git 2.12 или новее.
См.также
Для получения информации о том, как получить доступ к различным типам репозиториев, смотрите раздел Доступ к репозиториям.
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#
Это просто добавляет тонкий слой логики поверх 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#
Добавлено в версии 4.16.
Это просто добавляет тонкий слой поверх Git с помощью API Gitea, что позволяет отправлять изменения в переводе в виде запросов на извлечение, вместо отправки непосредственной в репозиторий.
Предупреждение
Это не поддерживает Bitbucket Cloud API.
Нет необходимости использовать его для доступа к Git-репозиториям, обычный Git работает так же, единственная разница заключается в том, как выполняется отправка изменений в репозиторий. С помощью Git изменения отправляются непосредственно в репозиторий, в то время как Запрос на извлечение в Gitea создаёт запросы на извлечение.
Для того чтобы это работало, необходимо настроить учетные данные API (BITBUCKETSERVER_CREDENTIALS) в настройках Weblate. После настройки вы увидите опцию Bitbucket Server при выборе Система контроля версий.
Запросы на слияние в 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 pull requests#
This adds a thin layer atop Git using the Azure DevOps API to allow pushing translation changes as pull requests, instead of pushing directly to the repository.
Git pushes changes directly to a repository, while Azure DevOps pull requests creates pull requests. The latter is not needed for merely accessing Git repositories.
You need to configure API credentials (AZURE_DEVOPS_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Azure DevOps option when selecting Система контроля версий.
Mercurial#
Mercurial — это ещё одна система контроля версий, которую вы можете использовать в Weblate напрямую.
Примечание
Weblate должен работать с любой версией Mercurial’а, но иногда в его интерфейсе командной строки происходят несовместимые изменения, которые нарушают его интеграцию с Weblate.
См.также
Для получения информации о том, как получить доступ к различным типам репозиториев, смотрите раздел Доступ к репозиториям.
Подрывная деятельность#
Для взаимодействия с репозиторием 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, на основе которого можно будет создать свой собственный.