Непрерывный перевод¶

Weblate строит такую инфраструктуру, чтобы ваш перевод непрерывно следовал за разработкой. Таким образом, переводчики могут работать над переводами всё время разработки, вместо того, чтобы работать с огромным количеством нового текста непосредственно перед выпуском.

См.также

В разделе «Интеграция с Weblate» на базовом уровне описывается, как интегрировать ваш процесс разработки с Weblate.

Процесс следующий:

Разработчики вносят изменения и отправляют их в репозиторий системы контроля версий.
При необходимости файлы перевода обновляются, см. Представляем новые строки.
Weblate извлекает изменения из репозитория VCS, разбирает файлы перевода и обновляет свою базу данных, см. Обновление репозиториев.
Переводчики присылают переводы через веб-интерфейс Weblate, или загружают файлы, изменённые ими в автономном режиме.
После завершения работы переводчиков Weblate фиксирует изменения в локальном репозитории (см. Отложенные коммиты).
Изменения отправляются обратно в вышестоящий репозиторий (см. Отправка изменений из Weblate).

Подсказка

Хостинг вышестоящего кода не обязателен, можно использовать Weblate с Локальные файлы, где есть только репозиторий внутри Weblate.

Обновление репозиториев¶

Вы должны каким-то образом настроить обновления репозиториев из их источников.

Используйте Обработчики уведомлений для интеграции с большинством распространённых сервисов хостинга исходного кода:
Вручную запускайте обновление либо в разделе управления репозиторием, либо с помощью REST API Weblate или клиента Weblate
Включите параметр AUTO_UPDATE для автоматического обновления всех компонентов на вашем экземпляре Weblate
Выполните updategit (с выбором проекта или --all для обновления всех)

Всякий раз, когда Weblate обновляет репозиторий, будут срабатывать надстройки «после обновления», смотрите раздел Надстройки.

Предотвращение конфликтов слияния¶

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

The first approach is easy with monolingual files — you can add new strings within Weblate and leave whole editing of the files there. For bilingual files, there is usually some kind of message extraction process to generate translatable files from the source code. In some cases this can be split into two parts - one for the extraction generates template (for example gettext POT is generated using xgettext) and then further process merges it into actual translations (the gettext PO files are updated using msgmerge). You can perform the second step within Weblate and it will ensure that all pending changes are included prior to this operation.

Второй подход может быть достигнут путём использования REST API Weblate, заставляющего Weblate отправить на все отложенные изменения и заблокировать перевод, пока вы на своей стороне проводите изменения.

Скрипт для выполнения обновлений может выглядеть следующим образом:

# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock

Если у вас есть несколько компонентов, совместно использующих один и тот же репозиторий, вам необходимо заблокировать их все по отдельности:

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

Примечание

В примере используется Клиент Weblate, которому требуется настройка (ключи API) для удаленного управления Weblate. Также вы можете решить задачу с помощью любого HTTP-клиента вместо wlc, к примеру, curl, смотрите раздел REST API Weblate.

Избежание конфликтов слияния изменений, созданных Weblate¶

Even when Weblate is the single source of the changes in the translation files, conflicts can appear when using Уплотнение Git-коммитов add-on, Стиль слияния is configured to Rebase, or you are squashing commits outside of Weblate (for example when merging a pull request).

The reason for merge conflicts is different in this case - there are changes in Weblate which happened after you merged Weblate commits. This typically happens if merging is not automated and waits for days or weeks for a human to review them. Git is then sometimes no longer able to identify upstream changes as matching the Weblate ones and refuses to perform a rebase.

Чтобы решить эту проблему, необходимо либо минимизировать количество ожидающих изменений в Weblate при слиянии запроса на извлечение, либо полностью избежать конфликтов, не уплотняя изменения.

Вот несколько вариантов, как этого избежать:

Не используйте ни Уплотнение Git-коммитов, ни уплотнение во время слияния. Это основная причина того, что git не распознает изменения после объединения.
Позвольте Weblate зафиксировать оставшиеся изменения перед слиянием. Это обновит запрос на извлечение со всеми его изменениями, и оба репозитория будут синхронизированы.
Используйте функции рецензирования в Weblate (см. Рабочие процессы перевода), чтобы автоматически объединять запросы на GitHub после прохождения CI.
Использование блокировки в Weblate позволяет избежать изменений во время рассмотрения запроса на GitHub.

См.также

Клиент Weblate

Автоматическое получение изменений из GitHub¶

Weblate поставляется со встроенной поддержкой GitHub.

Если вы используете Hosted Weblate, рекомендуемый подход заключается в установке приложения Weblate, таким образом вы получите правильную настройку без необходимости в дополнительной настройке. Также оно может быть использовано для отправки изменений обратно в GitHub.

Для получения уведомлений о каждой отправке в репозиторий GitHub, добавьте в настройки репозитория (Webhooks) веб-обработчик Weblate, как показано на изображении ниже:

Для адреса полезной нагрузки (поля Payload URL), добавьте к URL-адресу вашего Weblate /hooks/github/, например, для сервиса Hosted Weblate, это этот адрес будет https://hosted.weblate.org/hooks/github/.

Остальные поля вы можете оставить с настройками по умолчанию (Weblate умеет обрабатывать оба типа содержимого и потребляет только событие push).

См.также

POST /hooks/github/, Доступ к репозиториям из Hosted Weblate

Автоматическое получение изменений из Bitbucket¶

Weblate поддерживает веб-обработчики Bitbucket, добавьте веб-обработчик, который срабатывает при отправке изменений в репозиторий, указав в качестве URL адрес вашей установки Weblate с суффиксом /hooks/bitbucket/ (например, https://hosted.weblate.org/hooks/bitbucket/).

См.также

POST /hooks/bitbucket/, Доступ к репозиториям из Hosted Weblate

Автоматическое получение изменений из GitLab¶

Weblate поддерживает обработчики GitLab, добавьте веб-обработчик проекта с адресом назначения /hooks/gitlab/ в вашей установке Weblate (например, https://hosted.weblate.org/hooks/gitlab/).

См.также

POST /hooks/gitlab/, Доступ к репозиториям из Hosted Weblate

Автоматическое получение изменений из Pagure¶

Weblate поддерживает обработчики Pagure, добавьте веб-обработчик проекта с адресом назначения, равным адресу вашей установки Weblate с суффиксом /hooks/pagure/ (например, https://hosted.weblate.org/hooks/pagure/). Добавлять этот адрес нужно в поле Activate Web-hooks, расположенное в блоке Project options:

См.также

POST /hooks/pagure/, Доступ к репозиториям из Hosted Weblate

Автоматическое получение изменений из Azure Repos¶

Weblate has support for Azure Repos webhooks, add a webhook for Code pushed event with destination to /hooks/azure/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/azure/). This can be done in Service hooks under Project settings.

См.также

Веб-обработчики в руководстве Azure DevOps, POST /hooks/azure/, Доступ к репозиториям из Hosted Weblate

Автоматическое получение изменений из репозиториев Gitea¶

Weblate поддерживает веб-обработчики Gitea, добавьте веб-обработчик Gitea Webhook для события Push events с адресом назначения, равным адресу вашей установки Weblate с суффиксом /hooks/gitea/ (например, https://hosted.weblate.org/hooks/gitea/). Добавлять этот адрес нужно в поле Webhooks, расположенное в блоке Settings.

См.также

Веб-обработчики в руководстве по Gitea, POST /hooks/gitea/, Доступ к репозиториям из Hosted Weblate

Автоматическое получение изменений из репозиториев Gitee¶

Weblate поддерживает веб-обработчики Gitee, добавьте веб-обработчик WebHook для события Push с адресом назначения, равным адресу вашей установки Weblate с суффиксом /hooks/gitee/ (например, https://hosted.weblate.org/hooks/gitee/). Добавлять этот адрес нужно в поле WebHooks, расположенное в блоке Management.

См.также

Веб-обработчики в руководстве по Gitee, POST /hooks/gitee/, Доступ к репозиториям из Hosted Weblate

Автоматическое ночное обновление репозиториев¶

Weblate по ночам автоматически извлекает изменения из удалённых репозиториев для повышения производительности при последующем слиянии изменений. По желанию вы можете превратить его и в ночное слияние, включив параметр AUTO_UPDATE.

Отправка изменений из Weblate¶

Каждый компонент перевода может иметь настроенный URL-адрес для отправки (смотрите описание параметра URL для отправки в репозиторий), в этом случае Weblate будет способен отсылать изменения в удалённый репозиторий. Также Weblate может быть настроен на автоматическую отсылку изменений при каждом коммите (это поведение по умолчанию, смотрите описание параметра Отправлять при коммите). Если вы не хотите, чтобы изменения отправлялись автоматически, вы можете отправлять их вручную в разделе Обслуживание репозитория или через API командой wlc push.

Параметры отправки отличаются в зависимости от используемой системы контроля версий, подробнее об этом читайте в указанной главе.

В случае, если вы не хотите использовать прямые отправки изменений Weblate, существует поддержка запросов на извлечение Запрос на извлечение в GitHub, Запросы на слияние в GitLab, Запрос на извлечение в Gitea, Запросы на слияние в Pagure, Запросы на извлечение Azure DevOps или рецензирований Gerrit, вы можете включить их, выбрав GitHub, GitLab, Gitea, Gerrit, Azure DevOps или Pagure в качестве Система контроля версий в Настройки компонента.

В целом, следующие варианты доступны для Git, Mercurial, GitHub, GitLab, Gitea, Pagure и Azure DevOps:

Желаемая настройка	Система контроля версий	URL для отправки в репозиторий	Ветка для отправки
Без отправки	Git	пусто	пусто
Отправка напрямую	Git	URL-адрес SSH	пусто
Отправка в отдельную ветку	Git	URL-адрес SSH	Имя ветки
Без отправки	Mercurial	пусто	пусто
Отправка напрямую	Mercurial	URL-адрес SSH	пусто
Отправка в отдельную ветку	Mercurial	URL-адрес SSH	Имя ветки
Запрос на извлечение в GitHub из форка	Запрос на извлечение в GitHub	пусто	пусто
Запрос на извлечение в GitHub из ветки	Запрос на извлечение в GitHub	URL-адрес SSH [1]	Имя ветки
Запрос на слияние в GitLab из форка	Запросы на слияние в GitLab	пусто	пусто
Запрос на слияние в GitLab из ветки	Запросы на слияние в GitLab	URL-адрес SSH [1]	Имя ветки
Запрос на слияние в Gitea из форка	Запрос на извлечение в Gitea	пусто	пусто
Запрос на слияние в Gitea из ветки	Запрос на извлечение в Gitea	URL-адрес SSH [1]	Имя ветки
Pagure’вский запрос на слияние из форка	Запросы на слияние в Pagure	пусто	пусто
Pagure ’вский запрос на слияние из ветки	Запросы на слияние в Pagure	URL-адрес SSH [1]	Имя ветки
Запрос на извлечение Azure DevOps из форка	Запросы на извлечение Azure DevOps	пусто	пусто
Запрос на извлечение Azure DevOps из ветви	Запросы на извлечение Azure DevOps	URL-адрес SSH [1]	Имя ветки

Примечание

Также вы можете включить автоматическую отправку изменений после коммитов Weblate, это можно сделать в параметре Отправлять при коммите.

См.также

Для настройки ключей SSH смотрите раздел Доступ к репозиториям, а для получения информации о том, когда Weblate решает закоммитить изменения — раздел Отложенные коммиты.

Защищённые ветки¶

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

Например, на GitHub’е это можно сделать в настройках репозитория:

Взаимодействие с другими пользователями¶

Weblate облегчает взаимодействие с другими пользователями с помощью своего API.

См.также

REST API Weblate

Отложенные коммиты¶

Weblate группирует коммиты одного и того же автора в один коммит, если это возможно. Такая группировка значительно сокращает количество коммитов, однако вам может понадобиться явно указать ему сделать коммиты в случае, если вы хотите синхронизировать репозиторий, например, для выполнения слияния (по умолчанию это действие разрешено для группы Управляющие, смотрите раздел Список привилегий).

Изменения в этом режиме коммитятся при выполнении любого из следующих условий:

Кто-то другой изменяет уже изменённую строку.
Происходит слияние с вышестоящим репозиторием.
Запрошен явный коммит изменений.
Запрошена загрузка файла.
Изменения старше периода, определённого возрастом изменений для коммита в конфигурации компонента.

Подсказка

Коммиты создаются для каждого компонента. Так что в случае, если у вас много компонентов, у вас всё равно будет множество коммитов. В этом случае вы можете использовать надстройку Уплотнение Git-коммитов.

Если вы хотите фиксировать изменения чаще и без проверки возраста, вы можете запланировать регулярную задачу для выполнения фиксации. Это можно сделать с помощью периодических задач в Интерфейс администратора Django. Сначала создайте желаемый интервал (например, 120 секунд). Затем добавьте новую периодическую задачу и выберите weblate.trans.tasks.commit_pending в качестве задачи с {"hours": 0} в качестве ключевых аргументов и желаемого интервала.

Обработка репозитория скриптами¶

Настройка взаимодействия Weblate с репозиторием заключается в использовании надстроек. Для получения информации о том, как через надстройки выполнять внешние скрипты, обратитесь к разделу Выполнение скриптов из надстройки.

Поддержание единого перевода в разных компонентах¶

Если у вас несколько компонентов перевода, вы возможно захотите убедиться, что одни и те же строки имеют один и тот же перевод. Этого можно достичь на нескольких уровнях.

Распространение перевода¶

При включённой функции ref:component-allow_translation_propagation (которая включена по умолчанию, смотрите раздел Настройки компонента), все новые переводы автоматически копируются во все компоненты с совпадающими строками. Такие переводы должным образом засчитываются текущему пользователю-переводчику во всех компонентах.

Примечание

Распространение перевода требует, чтобы в одноязычных форматах файлов перевода ключи строк совпадали, так что об этом следует помнить при создании ключей перевода.

Проверка согласованности¶

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

Автоматический перевод¶

Автоматический перевод одних компонентов на основе переводов в других может быть способом синхронизации переводов между компонентами. Вы можете либо запустить его вручную (смотрите раздел Автоматический перевод), либо заставить его автоматически запускаться при обновлении репозитория с помощью надстройки Автоматический перевод.