Weblate の内部構造

注釈

この章では、Weblate 内部の基本的な概要を説明します。

Weblate のコード構造の大部分は Django を基に作成しました。

ディレクトリ構造

Weblate メイン リポジトリのディレクトリ構造の概要:

docs

このドキュメントのソースコードは、Sphinx を使用して作成しています。

dev-docker

開発サーバーを実行する Docker コード。参照: Docker上でローカルに Weblate の実行。

weblate

Django アプリケーションとしての Weblate のソースコード。参照: Weblate の内部構造。

weblate/static

クライアント ファイル（CSS、Javascript および画像）。参照: Weblate フロントエンド。

モジュール

Weblate は、複数の Django アプリケーションで構成されています（複数のオプション。参照: オプションの Weblate モジュール）。

accounts

ユーザー アカウント、プロファイル、および通知。

addons

Weblate の動作の詳細設定用のアドオン。参照: アドオン。

api

Django REST framework をベースにした API。

auth

認証とアクセス権。

billing

オプションの 課金 モジュール。

checks

翻訳文字列の 品質検査 モジュール。

fonts

フォント表示検査モジュール。

formats

translate-toolkit をベースにしたファイル形式抽象化レイヤー。

gitexport

オプションの Git エクスポーター モジュール。

lang

言語と複数形のモデルを定義するモジュール。

legal

オプションの 法務モジュール モジュール。

machinery

機械翻訳サービスとの連携。

memory

組み込みの翻訳メモリ。参照: 翻訳メモリ。

screenshots

スクリーンショット管理と OCR モジュール。

trans

翻訳を処理するメイン モジュール。

utils

複数のヘルパー ユーティリティ。

vcs

バージョン管理システムの抽象化。

wladmin

カスタマイズした Django 管理画面。

Translation sources

A unit has a canonical file source and may have a translation from another language as its effective source. Keep Unit.source and Unit.source_unit canonical: repository synchronization and file formats depend on this. Use effective_source and its language and plural accessors for content shown to translators. Do not replace source on a copied unit to simulate an effective source; other fields and related objects still describe the canonical source.

Use Unit.source_snapshot when an operation needs to preserve the source text, language, plural rules, and terminology metadata together. Its identity defines source changes for dependency reconciliation, editor conflict detection, and AI diagnostics. For historical rendering and reports, read the snapshot recorded on the change, rather than reconstructing it from the current unit.

A missing configured parent remains a custom source: its text is empty, its language is retained, and its child is blocked. effective_source_unit is then None. Only removing the workflow or selecting the canonical language restores the canonical source.

Text-only accessors do not load language or plural metadata. For batch consumers that need the complete effective source, use UnitQuerySet.prefetch_translation_parent() alongside their existing unit prefetches. prefetch_source() already includes this. Ordinary searches keep the canonical query path and ordinary units retain their existing content hashes.

Source-dependent writes enter source_operation() before locking unit rows. The outer operation takes a shared project gate and reads its workflow mapping in one database round trip, including for projects without custom workflows. Workflow changes take source_project_gate(..., exclusive=True) before validation or persistence. Configuration changes affecting several projects acquire their gates in ascending project ID order. Never upgrade a shared gate to an exclusive one inside an operation.

The database gate function locks first and reads workflows in a separate statement, so a waiter sees configuration committed while it waited. Write paths use this transaction-scoped view rather than cached model settings. Nested operations reuse it; rolled-back savepoints discard their dependency work. Queued dependencies are reconciled before commit and external memory updates are scheduled after commit. Source-change history is written in bulk, preserving individual records while batching their notification dispatch.

Acquire any required repository locks before project gates, then component and unit row locks. Reconciliation itself only changes database state and does not acquire repository locks. Apply this boundary to bulk imports, automatic translation, file-save failures, deletion, and restoration as well as editor writes. Language and plural-rule changes require exclusive gates before their updates. Historical migrations use historical models without these runtime helpers.

Machinery source selection happens before mapping language codes to a provider. Use get_unit_source_language() for translation and uses_custom_source() for workflow-specific glossary handling. Provider codes can merge distinct language variants, so code equality cannot determine whether a workflow source was selected. Explicit component or secondary source selection takes precedence over the workflow source.

バックグラウンド タスクの内部構造

ヒント

このセクションでは、Celery タスクの内部構造について説明します。Celery の設定方法については Celery を使用するバックグラウンド タスク を確認してください。

Weblate はCeleryを使用してバックグラウンドでタスクを実行します。タスクには、イベントによって実行されるものと、スケジュールによって実行されるものがあります。

タスクのスケジューリングには Celery Beat が使用され、定期タスクのスケジュールは django-celery-beat によってデータベースに保存されます。タスクのスケジュールは、各 Django アプリの tasks.py に設定されています。

タスクは複数のキューを使用して処理され、ルーティングは settings.py に設定されています。以下は、異なる種類のワークロードを分離するために設計されているキュー：

celery

バックグラウンド タスクが処理されるデフォルトのキュー。

notify

Weblate 内のイベントや、認証、登録のための通知メールを送信するキュー。他のタスクが滞留していても、メール配信がスムーズに行われるように分離されたキューです。

memory

翻訳メモリのエントリを更新するキュー。新しい文字列をインポートすると更新キューが長くなることがありますが、処理時間が長くてもここではそれほど問題にならないため、他のタスクをブロックしないように分離されています。

backup

バックアップ タスクは並列実行できないため、専用のワーカーを 1 つ用意することで管理しやすくしています。

translate

自動翻訳タスクは外部サービスを利用するため、時間がかかることが知られています。