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

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

См.также

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

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

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

Подсказка

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

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

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

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

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

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

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

Первый подход прост с одноязычными файлами — вы можете добавлять новые строки, не выходя из Weblate’а, и возложить на него любое редактирование файлов. Для двуязычных файлов, как правило, существует некий процесс извлечения сообщений из исходного кода для генерации файлов перевода. В некоторых случаях он может быть разбит на две части — одна, извлекающая, часть генерирует шаблон (например, файл POT gettext’а генерируется с помощью программы xgettext), а дальнейший процесс объединяет его с фактическими переводами (файлы PO gettext’а, обновляемые с помощью программы msgmerge). Второй шаг вы можете выполнить в Weblate’е, и он удостоверится, что до выполнения этой операции все отложенные изменения были зафиксированы.

Второй подход может быть достигнут путём использования 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#

Даже если Weblate является единственным источником изменений в файлах перевода, могут возникать конфликты, когда используется дополнение Уплотнение Git-коммитов, Стиль слияния настроен на Rebase, или вы сминаете коммиты вне Weblate (например, при слиянии pull request).

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

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

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

Не используйте ни Уплотнение Git-коммитов, ни сквоширование во время слияния. Это основная причина того, что git не распознает изменения после слияния.
Позвольте Weblate зафиксировать оставшиеся изменения перед слиянием. Это обновит pull request со всеми его изменениями, и оба репозитория будут синхронизированы.
Используйте функции рецензирования в 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 поддерживает веб-обработчики Azure Repos, добавьте веб-обработчик для события Code pushed с адресом назначения, равным адресу вашей установки Weblate с суффиксом /hooks/azure/ (например, https://hosted.weblate.org/hooks/azure/). Добавлять этот адрес нужно в поле Service hooks, расположенное в блоке 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.

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

В случае, если вы не хотите использовать прямые push’ы Weblate, существует поддержка Запрос на извлечение в GitHub, Запросы на слияние в GitLab, Запрос на извлечение в Gitea, Запросы на слияние в Pagure, Запросы на поставку Azure DevOps pull requests или 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-коммитов.

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

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

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

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

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

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

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

Примечание

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

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

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

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

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