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

Weblate currently supports Git (with extended support for Запрос на извлечение в GitHub, Запросы на слияние в GitLab, Запрос на извлечение в Gitea, Запросы на рецензирование Gerrit, Subversion, Запросы на извлечение в Bitbucket Cloud, Запросы на извлечение в Bitbucket Data Center, and Запросы на извлечение Azure DevOps) and Mercurial as version control back-ends.

For provider-specific setup steps that combine repository access, incoming notifications, and pushing translations back, see Интеграции с хостингом кода.

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

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

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

Примечание

Этот раздел применим только к Хостингу Weblate (hosted.weblate.org). Если вы запускаете свой собственный самостоятельно размещённый экземпляр 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 с доступом на запись, даже если вы используете приложение Хостинга Weblate для GitHub. Приложение обрабатывает входящие уведомления от GitHub, но отправка изменений обратно по-прежнему использует пользователя Хостинга Weblate weblate.

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

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

Доступ к репозиториям на сайтах хостинга кода (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶

Примечание

Этот раздел применим к самостоятельно размещённым экземплярам Weblate. Если вы используете Хостинг Weblate (hosted.weblate.org), обратитесь к Доступ к репозиториям из Hosted Weblate.

For self-hosted Weblate, 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 an SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see Репозитории по SSH).

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

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

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

On GitHub, each key can only be used once, see Доступ к репозиторию GitHub and Доступ к репозиториям из 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), и нажмите Подтвердить. После этого вы сможете убедится, что отпечаток этого ключа соответствует тому серверу, который вы добавляете.

Добавленные ключи и их отпечатки будут отображаться в сообщении о подтверждении:

Подключение к устаревшим 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¶

Detailed GitHub repository access is covered in Доступ к репозиторию GitHub.

Репозитории GitLab¶

Detailed GitLab repository access is covered in Доступ к репозиторию GitLab.

Внутренние URL-адреса Weblate¶

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

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

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

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

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

Экономия дискового пространства на сервере: хранится только одна копия репозитория.
Ускорение обновлений: обновляется только один репозиторий.
Существует только один экспортируемый репозиторий с переводами Weblate (смотрите раздел Экспортер Git).
Некоторые надстройки могут работать с несколькими компонентами, использующими один репозиторий, например, «Уплотнение Git-коммитов».

Репозитории по HTTPS¶

См. также

Для доступа к защищённым HTTPS-репозиториям включите в URL-адрес имя пользователя и пароль. Не волнуйтесь, Weblate обрежет эту информацию, когда адрес будет показываться пользователям (если им вообще будет разрешено просматривать адрес репозитория).

Например, URL-адрес GitHub с добавленной авторизацией будет выглядеть примерно следующим образом: https://пользователь:ваш_токен_доступа@github.com/WeblateOrg/weblate.git.

Если вы не предоставите учётные данные в URL-адресе, а репозиторий требует их, Git завершится ошибкой:

fatal: could not read Username for 'https://github.com': terminal prompts disabled

Изменено в версии 5.10.2: Weblate использует упреждающую аутентификацию с Git 2.46.0 и новее, когда предоставлены учётные данные HTTP.

Это обеспечивает доступ к репозиториям Azure DevOps и ускоряет доступ к аутентифицированным репозиториям.

Примечание

Если имя вашего пользователя или пароль содержат специальные символы, то они должны быть закодированы для использования в 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.28 или новее.

См. также

Для получения информации о том, как получить доступ к различным типам репозиториев, смотрите раздел Доступ к репозиториям.

Git c принудительной отправкой (force push)¶

Этот вариант ведёт себя точно так же, как и Git, с той лишь разницей, что он всегда выполняет принудительную отправку. Он предназначен только для тех случаев, когда вы используете отдельный репозиторий для переводов.

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

Используйте с осторожностью, поскольку это может привести к потере коммитов в вашем репозитории.

Настройка конфигурации Git’а¶

Weblate выполняет все команды системы контроля версий с установкой HOME=$DATA_DIR/home (смотрите DATA_DIR), поэтому изменение пользовательских настроек нужно выполнять в DATA_DIR/home/.git.

Запрос на извлечение в GitHub¶

Detailed GitHub pull request setup is covered in Запрос на извлечение в GitHub.

Запросы на слияние в GitLab¶

Detailed GitLab merge request setup is covered in Запросы на слияние в GitLab.

Запрос на извлечение в Gitea¶

Detailed Gitea pull request setup is covered in Запрос на извлечение в Gitea.

Запросы на извлечение в Bitbucket Data Center¶

Detailed Bitbucket Data Center pull request setup is covered in Запросы на извлечение в Bitbucket Data Center.

Запросы на извлечение в Bitbucket Cloud¶

Detailed Bitbucket Cloud pull request setup is covered in Запросы на извлечение в Bitbucket Cloud.

Запросы на слияние в Pagure¶

Detailed Pagure merge request setup is covered in Запросы на слияние в Pagure.

Gerrit¶

Detailed Gerrit review request setup is covered in Запросы на рецензирование Gerrit.

Запросы на извлечение Azure DevOps¶

Detailed Azure DevOps pull request setup is covered in Запросы на извлечение 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

См. также

DATA_DIR

Локальные файлы¶

Подсказка

Для них используется Git. Требуется установленный Git и позволяет вам перейти на его использование нативно с полной историей ваших переводов.

Weblate также может работать без удалённой системы контроля версий. Первоначальные переводы импортируются путём их загрузки. Позже вы можете заменить отдельные файлы через загрузку файлов или добавить строки перевода непосредственно из Weblate (в настоящее время этот функционал доступен только для одноязычных переводов).

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