Внутреннее устройство Weblate

Примечание

Эта глава даст вам базовое представление о внутреннем устройстве Weblate.

Большую часть структуры своего кода Weblate наследует от Django, так как основывается на оном.

Структура каталогов

Быстрый обзор структуры каталогов главного репозитория Weblate:

docs

Исходный код данной документации, который можно собрать с помощью Sphinx.

dev-docker

Код Docker для запуска сервера разработки, смотреть раздел Запуск Weblate локально внутри Doсker.

weblate

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

weblate/static

Клиентские файлы (CSS, Javascript, изображения), смотреть Фронтэнд Weblate.

Модули

Weblate состоит из нескольких Django-приложений (некоторые из них необязательны, смотреть раздел Дополнительные модули Weblate):

accounts

Учётные записи пользователей, профили и уведомления.

addons

Надстройки для изменения поведения Weblate, смотреть раздел Дополнения.

api

API на основе Django REST framework.

auth

Авторизация и разрешения.

billing

Дополнительный модуль Выставление счетов.

checks

Модуль Проверки качества строки перевода.

fonts

Модуль проверки отрисовки шрифтов.

formats

Слой абстракции от форматов файлов на основе translate-toolkit.

gitexport

Дополнительный модуль Экспортер Git.

lang

Модуль определения языка и моделей множественного числа.

legal

Дополнительный модуль Юридический модуль.

machinery

Интеграция сервисов машинного перевода.

memory

Встроенная память переводов, смотрите раздел Память переводов.

screenshots

Модуль управления снимками экрана и распознаванием текста.

trans

Основной модуль обработки переводов.

utils

Различные вспомогательные утилиты.

vcs

Абстракция системы контроля версий.

wladmin

Настройка интерфейса администра Django.

Источники перевода

Единица имеет канонический файловый источник и может иметь перевод с другого языка в качестве своего фактического источника. Сохраняйте Unit.source и Unit.source_unit каноническими: синхронизация репозитория и форматы файлов зависят от этого. Используйте effective_source и его средства доступа к языку и множественному числу для содержимого, показываемого переводчикам. Не заменяйте source в скопированной единице, чтобы имитировать фактический источник; другие поля и связанные объекты всё ещё описывают канонический источник.

Используйте Unit.source_snapshot, когда операции нужно сохранить исходный текст, язык, правила множественного числа и метаданные терминологии вместе. Его identity определяет изменения источника для согласования зависимостей, обнаружения конфликтов в редакторе и диагностики ИИ. Для исторического отображения и отчётов читайте снимок, записанный в изменении, а не восстанавливайте его из текущей единицы.

Отсутствующий настроенный родитель остаётся пользовательским источником: его текст пуст, его язык сохраняется, а его дочерний элемент заблокирован. Тогда effective_source_unit равен None. Только удаление рабочего процесса или выбор канонического языка восстанавливает канонический источник.

Средства доступа только к тексту не загружают метаданные языка или множественного числа. Для пакетных потребителей, которым нужен полный фактический источник, используйте UnitQuerySet.prefetch_translation_parent() вместе с их существующими предварительными выборками единиц. prefetch_source() уже включает это. Обычные поиски сохраняют канонический путь запроса, а обычные единицы сохраняют свои существующие хеши содержимого.

Зависимые от источника записи входят в source_operation() перед блокировкой строк единиц. Внешняя операция захватывает общий шлюз проекта и читает его сопоставление рабочего процесса за один обмен с базой данных, в том числе для проектов без пользовательских рабочих процессов. Изменения рабочего процесса захватывают source_project_gate(..., exclusive=True) перед проверкой или сохранением. Изменения конфигурации, затрагивающие несколько проектов, захватывают свои шлюзы в порядке возрастания идентификаторов проектов. Никогда не повышайте общий шлюз до эксклюзивного внутри операции.

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

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

Выбор источника механизма происходит перед сопоставлением кодов языков с поставщиком. Используйте get_unit_source_language() для перевода и uses_custom_source() для обработки словаря, специфичной для рабочего процесса. Коды поставщиков могут объединять различные варианты языков, поэтому равенство кодов не может определить, был ли выбран источник рабочего процесса. Явный выбор компонента или дополнительного источника имеет приоритет над источником рабочего процесса.

Внутреннее устройство фоновых задач

Подсказка

В этом разделе описываются внутренности задач Celery. Фоновые задачи с использованием Celery описывает, как настроить Celery для выполнения задач.

Weblate использует Celery для выполнения задач в фоновом режиме. Некоторые задачи запускаются по событиям, а некоторые — по расписанию.

Celery Beat используется для планирования задач, а django-celery-beat используется для хранения расписания периодических задач в базе данных. Расписание задач настраивается в tasks.py в каждом из приложений Django.

Задачи обрабатываются с использованием нескольких очередей; маршрутизация настраивается в settings.py. Очереди были спроектированы для разделения различных типов рабочей нагрузки:

celery

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

notify

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

memory

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

backup

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

translate

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