Непрерывный перевод¶
Weblate строит такую инфраструктуру, чтобы ваш перевод непрерывно следовал за разработкой. Таким образом, переводчики могут работать над переводами всё время разработки, вместо того, чтобы работать с огромным количеством нового текста непосредственно перед выпуском.
См. также
В разделе «Интеграция с Weblate» на базовом уровне описывается, как интегрировать ваш процесс разработки с Weblate.
Процесс следующий:
Разработчики вносят изменения и отправляют их в репозиторий системы контроля версий.
При необходимости файлы перевода обновляются, см. Представляем новые строки.
Weblate извлекает изменения из репозитория VCS, разбирает файлы перевода и обновляет свою базу данных, см. Обновление репозиториев.
Переводчики присылают переводы через веб-интерфейс Weblate, или загружают файлы, изменённые ими в автономном режиме.
После завершения работы переводчиков Weblate фиксирует изменения в локальном репозитории (см. Отложенные коммиты).
Изменения отправляются обратно в вышестоящий репозиторий (см. Отправка изменений из Weblate).
Подсказка
Хостинг вышестоящего кода не обязателен, можно использовать Weblate с Локальные файлы, где есть только репозиторий внутри Weblate.
Обновление репозиториев¶
Вы должны каким-то образом настроить обновления репозиториев из их источников.
Используйте Обработчики уведомлений для интеграции с большинством распространённых сервисов хостинга исходного кода:
You must also Включить обработчики for this to work.
Вручную запускайте обновление либо в разделе управления репозиторием, либо с помощью REST API Weblate или клиента Weblate
Включите параметр
AUTO_UPDATEдля автоматического обновления всех компонентов на вашем экземпляре WeblateВыполните
updategit(с выбором проекта или--allдля обновления всех)
Всякий раз, когда Weblate обновляет репозиторий, будут срабатывать надстройки «после обновления», смотрите раздел Надстройки.
Предотвращение конфликтов слияния¶
The merge conflicts from Weblate arise when same file was changed both in Weblate and outside it. Depending on the situation, there are several approaches that might help here:
Avoiding merge conflicts by changing translation files in Weblate only
Avoiding merge conflicts by locking Weblate while doing outside changes
Avoiding merge conflicts by changing translation files in Weblate only¶
Avoiding edits outside Weblate 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:
The extraction generates template (for example gettext POT is generated using xgettext).
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 before this operation.
Avoiding merge conflicts by locking Weblate while doing outside changes¶
Integrating Weblate into your updating process so that it flushes changes before updating the files outside Weblate can be achieved by using REST API Weblate to force Weblate to push all pending changes and lock the translation while you are doing changes on your side.
Скрипт для выполнения обновлений может выглядеть следующим образом:
# 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
If you have multiple components sharing the same repository, you need to lock them all separately:
wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj
Примечание
The example uses Клиент Weblate, which needs configuration (API keys) to be able to control Weblate remotely. You can also achieve this using any HTTP client instead of Клиент Weblate, for example curl, see REST API Weblate.
Avoiding merge conflicts by focusing on Git operations¶
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.
To approach this, you either need to minimize the amount of pending changes in Weblate when you merge a pull request, or avoid the conflicts completely by not squashing changes.
Вот несколько вариантов, как этого избежать:
Не используйте ни Уплотнение Git-коммитов, ни уплотнение во время слияния. Это основная причина того, что git не распознает изменения после объединения.
Let Weblate commit pending changes before merging. This will update the pull request with all its changes, and both repositories will be in sync.
Use the review features in Weblate (see Рабочие процессы перевода) so that you can automatically merge GitHub pull requests after CI passes.
Использование блокировки в Weblate позволяет избежать изменений во время рассмотрения запроса на GitHub.
См. также
Автоматическое получение изменений из GitHub¶
Weblate поставляется со встроенной поддержкой GitHub.
Если вы используете Hosted Weblate, рекомендуемый подход заключается в установке приложения Weblate, таким образом вы получите правильную настройку без необходимости в дополнительной настройке. Также оно может быть использовано для отправки изменений обратно в GitHub.
Для получения уведомлений о каждой отправке в репозиторий GitHub, добавьте в настройки репозитория (Webhooks) веб-обработчик Weblate, как показано на изображении ниже:
The Payload URL consists of your Weblate URL appended by
/hooks/github/, for example for the Hosted Weblate service, this is
https://hosted.weblate.org/hooks/github/.
Остальные поля вы можете оставить с настройками по умолчанию (Weblate умеет обрабатывать оба типа содержимого и потребляет только событие push).
Автоматическое получение изменений из Bitbucket¶
Weblate поддерживает веб-обработчики Bitbucket, добавьте веб-обработчик, который срабатывает при отправке изменений в репозиторий, указав в качестве URL адрес вашей установки Weblate с суффиксом /hooks/bitbucket/ (например, https://hosted.weblate.org/hooks/bitbucket/).
Автоматическое получение изменений из GitLab¶
Weblate поддерживает обработчики GitLab, добавьте веб-обработчик проекта с адресом назначения /hooks/gitlab/ в вашей установке Weblate (например, https://hosted.weblate.org/hooks/gitlab/).
Автоматическое получение изменений из Pagure¶
Weblate поддерживает обработчики Pagure, добавьте веб-обработчик проекта с адресом назначения, равным адресу вашей установки Weblate с суффиксом /hooks/pagure/ (например, https://hosted.weblate.org/hooks/pagure/). Добавлять этот адрес нужно в поле Activate Web-hooks, расположенное в блоке Project options:
Автоматическое получение изменений из 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.
Автоматическое получение изменений из репозиториев Gitea¶
Weblate поддерживает веб-обработчики Gitea, добавьте веб-обработчик Gitea Webhook для события Push events с адресом назначения, равным адресу вашей установки Weblate с суффиксом /hooks/gitea/ (например, https://hosted.weblate.org/hooks/gitea/). Добавлять этот адрес нужно в поле Webhooks, расположенное в блоке Settings.
Автоматическое получение изменений из репозиториев Gitee¶
Weblate поддерживает веб-обработчики Gitee, добавьте веб-обработчик WebHook для события Push с адресом назначения, равным адресу вашей установки Weblate с суффиксом /hooks/gitee/ (например, https://hosted.weblate.org/hooks/gitee/). Добавлять этот адрес нужно в поле WebHooks, расположенное в блоке Management.
Автоматическое ночное обновление репозиториев¶
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 в качестве Система контроля версий в Настройки компонента.
Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center and Bitbucket Cloud:
Желаемая настройка |
|||
|---|---|---|---|
Без отправки |
пусто |
пусто |
|
Отправка напрямую |
URL-адрес SSH |
пусто |
|
Отправка в отдельную ветку |
URL-адрес SSH |
Имя ветки |
|
Без отправки |
пусто |
пусто |
|
Отправка напрямую |
URL-адрес SSH |
пусто |
|
Отправка в отдельную ветку |
URL-адрес SSH |
Имя ветки |
|
Запрос на извлечение в GitHub из форка |
пусто |
пусто |
|
Запрос на извлечение в GitHub из ветки |
URL-адрес SSH [1] |
Имя ветки |
|
Запрос на слияние в GitLab из форка |
пусто |
пусто |
|
Запрос на слияние в GitLab из ветки |
URL-адрес SSH [1] |
Имя ветки |
|
Запрос на слияние в Gitea из форка |
пусто |
пусто |
|
Запрос на слияние в Gitea из ветки |
URL-адрес SSH [1] |
Имя ветки |
|
Pagure’вский запрос на слияние из форка |
пусто |
пусто |
|
Pagure ’вский запрос на слияние из ветки |
URL-адрес SSH [1] |
Имя ветки |
|
Запрос на извлечение Azure DevOps из форка |
пусто |
пусто |
|
Запрос на извлечение Azure DevOps из ветви |
URL-адрес SSH [1] |
Имя ветки |
|
Bitbucket Data Center pull request from fork |
пусто |
пусто |
|
Bitbucket Data Center pull request from branch |
URL-адрес SSH [1] |
Имя ветки |
|
Bitbucket Cloud pull request from fork |
пусто |
пусто |
|
Bitbucket Cloud pull request from branch |
URL-адрес SSH [1] |
Имя ветки |
Примечание
Также вы можете включить автоматическую отправку изменений после коммитов Weblate, это можно сделать в параметре Отправлять при коммите.
См. также
Для настройки ключей SSH смотрите раздел Доступ к репозиториям, а для получения информации о том, когда Weblate решает закоммитить изменения — раздел Отложенные коммиты.
Защищённые ветки¶
Если вы используете Weblate на защищённой ветке, вы можете настроить его на использование запросов на извлечение и выполнение рецензирования переводов (что может быть проблематично для языков, которых вы не знаете). Альтернативный подход заключается в отмене этого ограничения для пользователя Weblate.
Например, на GitHub’е это можно сделать в настройках репозитория:
Взаимодействие с другими пользователями¶
Weblate облегчает взаимодействие с другими пользователями с помощью своего API.
См. также
Отложенные коммиты¶
Weblate группирует коммиты одного и того же автора в один коммит, если это возможно. Такая группировка значительно сокращает количество коммитов, однако вам может понадобиться явно указать ему сделать коммиты в случае, если вы хотите синхронизировать репозиторий, например, для выполнения слияния (по умолчанию это действие разрешено для группы Управляющие, смотрите раздел Список привилегий).
Изменения в этом режиме коммитятся при выполнении любого из следующих условий:
Кто-то другой изменяет уже изменённую строку.
Происходит слияние с вышестоящим репозиторием.
Запрошен явный коммит изменений.
Запрошена загрузка файла.
Изменения старше периода, определённого возрастом изменений для коммита в конфигурации компонента.
Подсказка
Коммиты создаются для каждого компонента. Так что в случае, если у вас много компонентов, у вас всё равно будет множество коммитов. В этом случае вы можете использовать надстройку Уплотнение Git-коммитов.
Если вы хотите фиксировать изменения чаще и без проверки возраста, вы можете запланировать регулярную задачу для выполнения фиксации. Это можно сделать с помощью периодических задач в Интерфейс администратора Django. Сначала создайте желаемый интервал (например, 120 секунд). Затем добавьте новую периодическую задачу и выберите weblate.trans.tasks.commit_pending в качестве задачи с {"hours": 0} в качестве ключевых аргументов и желаемого интервала.
Обработка репозитория скриптами¶
Настройка взаимодействия Weblate с репозиторием заключается в использовании надстроек. Для получения информации о том, как через надстройки выполнять внешние скрипты, обратитесь к разделу Выполнение скриптов из надстройки.
Поддержание единого перевода в разных компонентах¶
Если у вас несколько компонентов перевода, вы возможно захотите убедиться, что одни и те же строки имеют один и тот же перевод. Этого можно достичь на нескольких уровнях.
Распространение перевода¶
При включённой функции Разрешить распространение перевода (которая включена по умолчанию, смотрите раздел Настройки компонента), все новые переводы автоматически копируются во все компоненты с совпадающими строками. Такие переводы должным образом засчитываются текущему пользователю-переводчику во всех компонентах.
Примечание
Распространение перевода требует, чтобы в одноязычных форматах файлов перевода ключи строк совпадали, так что об этом следует помнить при создании ключей перевода.
Проверка согласованности¶
Проверка Противоречия срабатывает всякий раз, когда строки отличаются друг от друга. Вы можете использовать это, чтобы отрецензировать такие различия вручную и выбрать правильный перевод.
Автоматический перевод¶
Автоматический перевод одних компонентов на основе переводов в других может быть способом синхронизации переводов между компонентами. Вы можете либо запустить его вручную (смотрите раздел Автоматический перевод), либо заставить его автоматически запускаться при обновлении репозитория с помощью надстройки Автоматический перевод.