導入方法¶

Weblate のインストール¶

セットアップと経験に応じて、適切なインストール方法を選択する:

アーキテクチャの概要¶

Web サーバー

受信 HTTP リクエストの処理、静的ファイルの提供。

Celery ワーカー

Celery を使用するバックグラウンドタスクは、ここで実行されます。

作業負荷に応じて、ワーカー数を変更してください。

Weblate を水平方向にスケーリングする場合は、専用ノードを使用してください。

WSGI サーバー

ユーザーに Web ページを提供する WSGI サーバー。

Weblate を水平方向にスケーリングする場合は、専用ノードを使用してください。

データベース

すべてのコンテンツを保存するための PostgreSQL データベースサーバー。参照: Weblate のデータベース設定。

数百億の単語をホストするサイトの場合、専用のデータベースノードを使用してください。

データストア

キャッシュとタスクキュー用の Valkey または Redis のようなキー・バリュー型データストア。参照: Celery を使用するバックグラウンドタスク。

Weblate を水平方向にスケーリングする場合は、専用ノードを使用してください。

ファイルシステム

ファイルシステムストレージは、VCS リポジトリとアップロードされたユーザーデータを保存するための領域です。これは、すべてのプロセスで共有されます。

Weblate を水平方向にスケーリングする場合は、ネットワークストレージを使用してください。

メールサーバー

メール送信用の SMTP サーバー。参照: メール送信の設定。外部から提供できます。

ヒント

Docker を使用したインストールには PostgreSQL と Valkey が含まれているため、インストールが簡単になります。

ソフトウェア要件¶

オペレーティングシステム¶

Weblate は、Linux、FreeBSD、macOS で動作することが判明しています。他の Unix のようなシステムでも動作する可能性は高いでしょう。

Weblate は Windows には対応していません。しかし、動作するかもしれないのでパッチは歓迎します。

参考

アーキテクチャの概要では、Weblate の全体的なアーキテクチャと必要なサービスについて解説しています。

Python の依存関係¶

Weblateは、Python で書かれており、Python 3.12 以降に対応しています。依存関係は、pip を使ってのインストールすることも、ディストリビューションのパッケージからもインストールできます。requirements.txt は、依存関係の完全なリストです。

最も注目すべき依存関係:

Django: https://www.djangoproject.com/
Celery: https://docs.celeryq.dev/
Translate Toolkit: https://toolkit.translatehouse.org/
translation-finder: https://github.com/WeblateOrg/translation-finder
Python Social Auth: https://python-social-auth.readthedocs.io/
Django REST フレームワーク: https://www.django-rest-framework.org/

オプションの依存関係¶
オプションの依存関係指定子	Python パッケージ	Weblate の機能
`amazon`	boto3	Amazon Translate
`gelf`	logging-gelf	Graylog によるログ管理
`gerrit`	git-review	Gerrit review requests
`google`	google-cloud-storage google-cloud-translate	用語集対応の Google Cloud Translation Advanced
`ldap`	django-auth-ldap	LDAP 認証
`mercurial`	mercurial	Mercurial
`postgres`	psycopg	PostgreSQL（参照: Weblate のデータベース設定）
`rollbar`	rollbar	エラーレポートの収集とパフォーマンスの監視
`saml`	python3-saml	SAML 認証
`saml2idp`	djangosaml2idp2	SAML 2 IDP を Weblate に統合
`sphinx`	Sphinx	POT ファイルの更新（Sphinx）が必要
`wllegal`	wllegal	Hosted Weblate との統合
`wsgi`	granian	Weblate 用の WSGI サーバー
`zxcvbn`	django-zxcvbn-password-validator	パスワード認証

pip を使用してインストールする場合には、特定の機能を選択してインストールできます。インストール時の指定方法:

uv pip install "weblate[Postgres,Amazon,SAML]"

または、すべてのオプション機能を追加して Weblate をインストールする方法:

uv pip install "weblate[all]"

もしくは、どのようなオプション機能も追加せずに Weblate をインストールする方法:

uv pip install weblate

pip install のトラブルシューティング¶

ERROR: Dependency 'gobject-introspection-2.0' is required but not found.

インストールされている PyGobject パッケージは、対応する GObject Introspection ライブラリ - gobject-introspection-2.0 を見つけることができません。

古いバージョンは Weblate でサポートしなくなりました。

ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)

これは、PyPI を介して配布されるバイナリパッケージとディストリビューションとの互換性がないことが原因です。これに対処するために必要な、システムでのパッケージの再構築方法:

uv pip install --force-reinstall --no-binary :all: cffi

error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?

これは xmlsec パッケージの既知の問題です。参照: https://github.com/xmlsec/python-xmlsec/issues/314。

lxml & xmlsec libxml2 library version mismatch

lxml および xmlsec パッケージは、単一の libxml2 に対してビルドされる必要があります。この問題を回避するには、それらをローカルでビルドしてください:

uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec

その他のシステム要件¶

システムにインストールされていることが必要な依存関係:

Git: https://git-scm.com/
Pango、Cairo および関連するヘッダーファイルと GObject イントロスペクションデータ: https://cairographics.org/、https://www.gtk.org/docs/architecture/pango。参照: Pango と Cairo
git-review （Gerrit 対応用のオプション）: https://pypi.org/project/git-review/
git-svn （Subversion 対応用のオプション）: https://git-scm.com/docs/git-svn
tesseract （システムで tesserocr バイナリホイールが利用できない場合にのみ必要）: https://github.com/tesseract-ocr/tesseract

ビルド時の依存関係¶

Python の依存関係の一部をビルドするには、依存関係のインストールが必要となることがあります。これは、インストールの方法により異るので、個別のパッケージについてのドキュメントを確認してください。しかし、pip を使用してインストールする場合、ビルド済みの Wheels を使用する場合、または配布パッケージを使用する場合には必要ありません。

Pango と Cairo¶

Weblate は、ビットマップウィジェットの表示（参照: 翻訳者コミュニティの構築）と、検査結果の表示（参照: フォントの管理）に、Pango と Cairo を使用します。この Python バインディングを適切にインストールするには、先にシステムライブラリのインストールをしてください。Cairo と Pango の両方が必要であり、次に GLib が必要です。これはすべて、開発ファイルと GObject イントロスペクションデータとともにインストールしてください。

参考

ハードウェア要件¶

Weblate は、最新のハードウェアであれば問題なく動作します。以下は、Weblate を単一のホスト（Weblate、データベース、Web サーバー）で動作させるために必要な最小限の構成:

3 GB の RAM
2 CPU コア
1 GB の記憶容量（HDD or SSD）

注釈

実際に必要な Weblate のインストールの要件は、Weblate で管理する翻訳のサイズによって大きく変化します。

メモリ使用量¶

メモリは多ければ多いほど良い - すべてのレベル（ファイルシステム、データベース、Weblate）でキャッシュとして使用します。数百の翻訳コンポーネントの場合は、少なくとも 4 GB の RAM を推奨します。

ヒント

メモリが推奨よりも少ないシステムの場合は、シングルプロセス Celery の設定を推奨します。

CPU 使用率¶

同時使用者が多い場合、必要な CPU コアの数が増えます。

ストレージ使用量¶

一般的なデータベースストレージの使用量は、ホストサーバーで管理する 100 万語の単語につき約 300 MB 必要です。

リポジトリのクローンに必要なストレージスペースはさまざまですが、Weblate は、シャロークローンを実行してサイズを最小限に抑える努力をします。

ノード数¶

小規模から中規模のサイト（ホストされた単語数が数百万）の場合、Weblate のすべてのコンポーネント（参照: アーキテクチャの概要）を単一ノードで実行できます。

数億件の翻訳対象語を扱う規模に成長する場合は、専用のデータベースノードを用意することを推奨します（参照: Weblate のデータベース設定）。

リリース署名の検証¶

Weblate リリースは、Sigstore 署名を使用して暗号的に署名されます。署名は GitHub リリースに添付されています。

検証は、sigstore パッケージを使用して実行できます。5.4 リリースの署名の検証例:

sigstore verify github \
   --cert-identity https://github.com/WeblateOrg/weblate/.github/workflows/setup.yml@refs/tags/weblate-5.4 \
   --bundle Weblate-5.4-py3-none-any.whl.sigstore \
   Weblate-5.4-py3-none-any.whl

ファイルシステムのアクセス権¶

Weblate プロセスは、データを保持するディレクトリ (DATA_DIR ) に対して、読み書き権限が必要です。このディレクトリ内のすべてのファイルは、すべての Weblat プロセス（通常は WSGI と Celery、参照: 実行サーバーおよび Celery を使用するバックグラウンドタスク）を実行しているユーザーが所有し、書き込み権限が必要です。

デフォルトの設定では、これらは Weblate のソースと同じ階層に配置されますが、/var/lib/weblate などへの、より適切な場所に移動させてください。

Weblate は、これらのディレクトリを自動的に作成しようとします。しかし、アクセス権がなければ作成できません。

The configured CACHE_DIR also has to be writable by the Weblate process and has to allow executing generated helper files. Do not mount CACHE_DIR with the noexec option.

また、管理コマンドの実行には注意が必要です。これは、Weblate 自体の実行と同じユーザーで実行することが必要なためです。実行できなければ、アクセス権の設定を間違えたファイルがあるということです。

Docker コンテナでは、/app/data ボリューム内のすべてのファイルは、コンテナ内の weblate ユーザーは所有者でなければなりません（UID 1000）。

参考

静的ファイルの提供

Weblate のデータベース設定¶

PostgreSQL データベースサーバーで Weblate を実行することを推奨します。

PostgreSQL 13 以降に対応しています。PostgreSQL 15 以降を推奨します。

参考

データベース接続¶

デフォルトの設定では、各 Weblate プロセスはデータベースへの永続的な接続を維持します。永続的な接続により、データベースサーバーに対するリソース使用量が増えることがあります。詳細については、CONN_MAX_AGE と持続的 (persistent) な接続を確認してください。

Weblate に必要な最小接続数:

$(4 \times \mathit{nCPUs}) + 2$ （Celery プロセスの場合）
$\mathit{nCPUs} + 1$ （WSGI ワーカーの場合）

これは、このドキュメントで提供されている Docker コンテナのデフォルトと設定例に当てはまりますが、WSGI ワーカーの量を変更したり、Celery の並列処理を調整したりすると、数値の変更が必要になります。

データベース接続数の実際の制限は、次の状況を考慮してさらに大きくすることが必要:

管理コマンドにも接続が必要です。
プロセスが強制終了された場合（OOM キラーによって強制終了された場合など）、タイムアウトするまで既存の接続がブロックされることがあります。

参考

Celery を使用するバックグラウンドタスク、NGINX および uWSGI の設定例、WEBLATE_WORKERS

PostgreSQL¶

通常、Django ベースのサイトには PostgreSQL が最適です。これは、Django データベース層の実装に使用する参照データベースです。

注釈

Weblate では、場合によっては個別にインストールすることが必要なトライグラム拡張機能を使用します。postgresql-contrib または同様の名前のパッケージを探してください。

参考

PostgreSQL に関するノート

PostgreSQL でデータベースの作成¶

通常は、Weblate を専用のデータベースと、専用のユーザーアカウントで実行してください。設定例:

# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"

# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate

# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -E UTF8 -O weblate weblate

ヒント

Weblate ユーザーを、PostgreSQL のスーパーユーザーにしたくない場合は、省略できます。その場合、Weblate が使用するスキーマの PostgreSQL スーパーユーザーとして、移行手順の一部を手動で実行することになります。実行する移行コマンド:

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;

Weblate で PostgreSQL を使用するための設定¶

settings.py に必要な PostgreSQL 用の設定:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Configures name of the PostgreSQL role to alter during the database migration
        # "ALTER_ROLE": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
        # Persistent connections
        "CONN_MAX_AGE": None,
        "CONN_HEALTH_CHECKS": True,
    }
}

データベースの移行時には、Weblate が使用するデータベースのロールに対して ALTER ROLE を実行します。ほとんどの場合、ロールの名前は username と一致します。より複雑な設定では、ロール名がユーザー名と異なり、データベース移行中に存在しないロールについてのエラーが発生します（psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist）。これは Azure Database for PostgreSQL で発生することは判明していますが、この環境に限定されていません。データベース移行時に、Weblate が変更することが必要なロール名を ALTER_ROLE に設定してください。

参考

データベース接続

その他の設定¶

メール送信の設定¶

Weblate は、さまざまなタイミングでメールを送信します。ーアカウントの有効化やユーザーが設定した通知など。そのためには、SMTP サーバーへの接続が必要となります。

メールサーバーの初期設定に使用する設定項目: EMAIL_HOST、EMAIL_HOST_PASSWORD、EMAIL_USE_TLS、EMAIL_USE_SSL、EMAIL_HOST_USER および EMAIL_PORT。名前は明確ですが、詳細については Django の資料を確認してください。

ヒント

対応していない認証方法でエラーが発生した場合（例: SMTP AUTH extension not supported by server）は、安全でない接続が原因でサーバーが認証を拒否している可能性が高いです。その場合は、EMAIL_USE_TLS を有効にしてみてください。

参考

リバースプロキシの背後で実行¶

Weblate のいくつかの機能は、正しい HTTP ヘッダーが Weblate に渡されることに依存します。リバースプロキシを使用する場合は、必要な情報が正しく渡されていることを確認してください。

この設定のデバッグには、性能レポート内の HTTP environment を確認してください。

クライアント IP アドレス

これは接続制限または監査ログのために必要です。

Weblate は、WSGI ハンドラによって設定される REMOTE_ADDR から IP アドレスを解析します。これは、空の場合（WSGI にソケットを使用時）や、リバースプロキシのアドレスを含む場合があるため、Weblate にはクライアント IP アドレスを含む追加の HTTP ヘッダーが必要です。

IP_BEHIND_REVERSE_PROXY を有効にするだけで、ほとんどの一般的な構成では十分なはずですが、IP_PROXY_HEADER および IP_PROXY_OFFSET も調整する必要があるかもしれません（Docker コンテナでは WEBLATE_IP_PROXY_HEADER と WEBLATE_IP_PROXY_OFFSET を使用します）。

ヒント

この設定をデフォルトでオンにすることはできません。適切に設定されていないリバースプロキシ環境では、IP アドレスのスプーフィングを許してしまうためです。

サーバーのホスト名

Host ヘッダーは、SITE_DOMAIN の設定と一致させてください。リバースプロキシに追加の設定が必要となることがあります（たとえば、Apache では ProxyPreserveHost On を、nginxでは proxy_set_header Host $host; が必要です）。

ヒント

CSRF 検証失敗エラーは、Host ヘッダーと設定された SITE_DOMAIN の間の不一致によって引き起こされることが良くあります。

クライアントプロトコル

正しいプロトコル情報が渡されないと、Weblate がクライアントを HTTPS にアップグレードしようとしてリダイレクトループに陥る可能性があります。リバースプロキシによって X-Forwarded-Proto として正しく公開されていることを確認してください。

このヘッダーは、SECURE_PROXY_SSL_HEADER （settings.py）または WEBLATE_SECURE_PROXY_SSL_HEADER として設定される必要があります。

重要

設定におけるヘッダー値は大文字/小文字を区別するため、WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,https と WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPS は置き換えられません。

ヒント

ブラウザで "Too many redirects" エラーが出る場合、これは実際のプロトコル（HTTPS）と Weblate が認識するプロトコルとの不一致が原因である可能性が高いです。

バージョン 5.13 で変更: デフォルト設定では、プロトコルプロキシヘッダーは gunicorn によって自動的に処理されますが、他の WSGI サーバーはより安全な設定を採用しており、この明示的な設定が必要です。

Weblate 5.13 以降、Docker コンテナは granian を使用しており、現在は WEBLATE_SECURE_PROXY_SSL_HEADER の明示的な設定が必要です。

参考

HTTP プロキシ¶

Weblate は VCS コマンドを実行しますが、これは環境変数のプロキシ設定を取り込んでいます。settings.py にプロキシを設定してください。設定内容:

import os

os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"

参考

プロキシ環境変数

詳細設定¶

参考

設定例

weblate/settings_example.py を weblate/settings.py にコピーし、設定に合わせて変更します。詳細設定すべきオプション:

ADMINS

マージの失敗や Django エラーなど、問題が発生したときに通知を受け取るサイト管理者一覧。

ADMINS_CONTACT が設定されていない限り、お問い合わせフォームもこれらのメールアドレスへ送信します。

参考

ADMINS

ADMINS_CONTACT

適切な管理者の設定

ALLOWED_HOSTS

サイトでサービスを提供する予定のホスト一覧を設定してください。設定例:
ALLOWED_HOSTS = ["demo.weblate.org"]
ワイルドカードの使用例:
ALLOWED_HOSTS = ["*"]
参考

ALLOWED_HOSTS

WEBLATE_ALLOWED_HOSTS

許可するホストの登録

SESSION_ENGINE

セッションの保存方法を設定します。デフォルトのデータベースバックエンドエンジンを使用している場合に必要なスケジュール:　weblate clearsessions を使用して、古いセッションデータをデータベースから削除します。

Valkey または Redis をキャッシュとして使用している場合（参照: キャッシュの設定）、セッションにも使用してください。設定方法:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
参考

セッションエンジンを設定する

SESSION_ENGINE

DATABASES

データベースサーバーへの接続設定。詳細については、Django のドキュメントを確認してください。

参考

Weblate のデータベース設定

DATABASES

データベース

DEBUG

本番サーバーでは無効にしてください。デバッグモードを有効にすると、Django はエラーが発生したときユーザーにバックトレースを表示します。無効にすると、エラーはメールで ADMINS （上記参照）に送信されます。

この場合、Django はより多くの情報を内部に格納するので、デバッグモードは Weblate の速度を低下させます。

参考

DEBUG

デバッグモードの無効化

DEFAULT_FROM_EMAIL

メール送信時の送信者のメールアドレス。例: 登録済みのメールアドレス。

参考

DEFAULT_FROM_EMAIL

SECRET_KEY

Django が Cookie の情報に署名するために使用するキー。詳細については、Django の秘密鍵を確認してください。

参考

SECRET_KEY

SERVER_EMAIL

管理者にメール送信する場合の送信者のメールアドレス。例: マージを失敗した時の通知など。

参考

SERVER_EMAIL

データベースの準備¶

設定の準備ができたら、migrate を実行してデータベース構造を作成します。これで、管理画面を使用して翻訳プロジェクトを作成できます。

設定が完了したら、管理画面の性能レポートも確認してください。これにより、サイトの不適切な設定に気づくかもしれません。

参考

運用環境の設定¶

運用環境の初期設定では、次のセクションで説明する設定の調整が必要です。最重要の設定時に、スーパーユーザーとしてサインインしている場合、上部バーに感嘆符で警告が表示されます。警告表示例:

また、Django により実行された検査項目の確認も推奨します（すべての修正は必要はないかもしれない）。検査を確認するコマンド:

weblate check --deploy

また、管理画面の性能レポートからも、同一の検査項目を確認できます。

参考

デプロイチェックリスト

デバッグモードの無効化¶

Django のデバッグモード（ DEBUG）を無効する方法:

DEBUG = False

デバッグモードを有効にすると、Django は実行したすべてのクエリーを保存し、ユーザーにエラーのバックトレースを表示しますが、これは運用環境では望ましくありません。

参考

詳細設定

適切な管理者の設定¶

適切な管理者のメールアドレスを ADMINS に設定します。サーバーで問題が発生した場合に誰がメールを受信するかを設定します。設定例:

ADMINS = ("Your Name <your_email@example.com>",)

参考

詳細設定

サイトの正確なドメイン設定¶

管理画面からサイト名とドメインを設定してください。設定がされていなければ、RSS のリンクまたはアカウント登録メールは機能しません。設定は、 SITE_DOMAIN にサイトのドメイン名を指定して行います。

バージョン 4.2 で変更: 4.2 以前のリリースでは、代わりに Django sites フレームワークが使用されていました。参照: "sites" フレームワーク。

参考

HTTPS の正しい設定¶

暗号化された HTTPS プロトコルを使用して Weblate を実行することを強く推奨します。有効にしたら、設定画面から ENABLE_HTTPS を設定してください。設定例:

ENABLE_HTTPS = True

ヒント

HSTS も設定してください。詳細については、SSL/HTTPS を確認してください。

参考

ENABLE_HTTPS
許可するホストの登録
サイトの正確なドメイン設定

SECURE_HSTS_SECONDS の適切な設定¶

サイトを SSL で提供している場合、HTTP Strict Transport Security を有効にするには、settings.py 内の SECURE_HSTS_SECONDS の値を設定してください。デフォルトでは以下のように、 0 に設定されています。

SECURE_HSTS_SECONDS = 0

ゼロ以外の整数値に設定すると、django.middleware.security.SecurityMiddleware は、HTTP Strict Transport Security ヘッダーがまだないすべてのレスポンスに設定します。

警告

これを誤って設定すると、元に戻せないほど（しばらくの間）サイトが壊れることがあります。はじめに HTTP Strict Transport Security のドキュメントを読んでください。

強力なデータベースエンジンの使用¶

運用環境では PostgreSQL を使用してください。詳細については、Weblate のデータベース設定を確認してください。
データベースサーバーは、近くのロケーションに設置してください。そうしなければ、ネットワークのパフォーマンスや信頼性が原因で、Weblate が使用できなくなることがあります。
例えば PGTune を使用して、データベースサーバーの性能の検査をしたり、設定を調整してください。

参考

キャッシュの設定¶

できれば、設定変数 CACHES を変更して Django から Valkey または Redis を使用します。設定の変更例:

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/0",
        # If redis is running on same host as Weblate, you might
        # want to use unix sockets instead:
        # 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    }
}

ヒント

キャッシュの設定を変更する場合は、Celery 用の設定も調整することが必要です。参照: Celery を使用するバックグラウンドタスク。

参考

アバターのキャッシュ¶

Django のキャッシュに加えて、Weblate はアバターのキャッシュも行います。そちらは、独立したファイルベースのキャッシュにすることをおすすめします:

CACHES = {
    "default": {
        # Default caching backend setup, see above
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "unix:///var/run/redis/redis.sock?db=0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    },
    "avatar": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
        "TIMEOUT": 604800,
        "OPTIONS": {
            "MAX_ENTRIES": 1000,
        },
    },
}

参考

メールの送信設定¶

Weblate は、たびたびメールを送信します。そのため、送信者のメールアドレスは正確に設定してください。環境に合わせて SERVER_EMAIL および DEFAULT_FROM_EMAIL の設定が必要です。メール送信の設定例:

SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"

注釈

Weblate からのメール送信を無効にするには、EMAIL_BACKEND を django.core.mail.backends.dummy.EmailBackend に設定します。

これにより、登録やパスワードリセットを含む すべての メール配信が無効となります。

参考

許可するホストの登録¶

Django では、サイトの使用を許可するドメイン名のリストは、ALLOWED_HOSTS への登録が必要です。空のままだと、リクエストはブロックされて接続できません。

HTTP サーバーと一致するように設定されていない場合、以下のようなエラーが発生します。Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.

ヒント

Docker コンテナでは、WEBLATE_ALLOWED_HOSTS を使用します。

参考

ALLOWED_HOSTS
WEBLATE_ALLOWED_HOSTS
サイトの正確なドメイン設定

Django の秘密鍵¶

SECRET_KEY 設定は、Django が cookie に署名するために使用します。サンプルの設定値を使用せず、独自の値を実際に生成してください。

新しい秘密鍵の生成には、Weblate 付属の weblate-generate-secret-key を使用できます。

参考

SECRET_KEY

メンテナンスタスクの実行¶

パフォーマンスを最適化するには、メンテナンスタスクをバックグラウンドで実行させることが望ましいです。これは、Celery を使用するバックグラウンドタスクにより自動的に実行されます。celery が実行するタスク:

設定の健全性診断（毎時）。
保留中の変更のコミット（毎時）。参照: 遅延コミットおよび commit_pending。
コンポーネントの警告の更新（毎日）。
リモートブランチの（毎晩）更新。参照: AUTO_UPDATE。
JSON への翻訳メモリのバックアップ（毎日）。参照: dump_memory。
全文およびデータベースの保守タスク（毎日および毎週のタスク）。参照: cleanuptrans。

システム言語とエンコーディング¶

システム言語は、UTF-8 対応の言語に設定してください。ほとんどの Linux ディストリビューションでは、UTF-8 がデフォルトの設定です。使用するシステムが該当しない場合は、言語を UTF-8 形式に変更してください。

例えば、/etc/default/locale を編集して、 LANG="C.UTF-8" を設定します。

場合によっては、個々のサービスには言語ごとに個別の設定があります。これはディストリビューションと Web サーバーによって異なるため、Web サーバーパッケージのドキュメントを確認してください。

Ubuntu の Apache で使用する /etc/apache2/envvars の設定例:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

CentOS の Apache で使用する /etc/sysconfig/httpd （または /opt/rh/httpd24/root/etc/sysconfig/httpd）の設定例:

LANG='en_US.UTF-8'

カスタム認証局の使用¶

Weblate は、HTTP リクエスト中に SSL 証明書を検証します。デフォルトで同梱されている信頼性がないカスタム認証局を使用している場合は、その証明書を信頼できるものとして追加してください。

追加は、システム権限で設定してください。詳細はディストリビューションのドキュメントを参照してください（例えば Debian では、CA 証明書を /usr/local/share/ca-certificates/ に配置して、 update-ca-certificates を実行します）。

ヒント

Weblate コンテナはそれを検索パスに含んでいないため、実行するにはフルパスを指定する必要があります。例:

docker compose exec -u root weblate /usr/sbin/update-ca-certificates

追加すると、システムツールは証明書を信頼します。これは Git も含まれます。

Python コードの場合は、同梱しているシステム CA バンドルではなく、システム CA バンドルを使用するようにリクエストを設定してください。これは、次のコードを settings.py （Debian 固有のパス）にコピーします。設定するコード:

import os

os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

クライアントアセットの圧縮¶

Weblate には、JavaScript と CSS ファイルが多く含まれます。パフォーマンス上の理由から、クライアントに送信する前に圧縮することが望ましいです。デフォルトの設定では、少ないオーバーヘッドで送信時に実行されます。大規模なインストールでは、オフライン圧縮モードの有効化を推奨します。これは、設定で行うことが必要であり、圧縮は、すべての Weblate をアップグレードするたびに必要です。

設定の切り替えは簡単で、django.conf.settings.COMPRESS_OFFLINE を有効にして、django.conf.settings.COMPRESS_OFFLINE_CONTEXT を設定するだけです（後者は設定例にすでに含まれている）。オフライン圧縮の設定例:

COMPRESS_OFFLINE = True

デプロイごとに、現在のバージョンと一致するようにファイルを圧縮することが必要です。圧縮コマンド:

weblate compress

ヒント

公式の Docker イメージでは、すでにこの機能は有効です。

参考

実行サーバー¶

ヒント

下記で説明しているサービスの設定に慣れていない場合は、Docker を使用したインストールを試してください。

Weblate の実行に必要なサービスと推奨設定:

データベースサーバー（参照: Weblate のデータベース設定）
キャッシュサーバー（参照: キャッシュの設定）
静的ファイルと SSL ターミネーション用のフロントエンド Web サーバー（参照: 静的ファイルの提供）
動的コンテンツ用の WSGI サーバー（参照: NGINX および uWSGI の設定例）
バックグラウンドタスク実行用の Celery（参照: Celery を使用するバックグラウンドタスク）

注釈

サービス間には、依存関係があります。例えば、Celery または uwsgi プロセスの起動時には、キャッシュとデータベースサーバーが実行されていることが必要です。

多くの場合、すべてのサービスを単一の（仮想）サーバー上で実行しますが、インストールの負荷が高い場合は、サービスを分割できます。唯一の制限は、Celery サーバーと Wsgi サーバーは DATA_DIR へのアクセス権が必要なことです。

注釈

WSGI プロセスは、Celery プロセスと同じユーザーとして実行させてください。もし異なる場合は、DATA_DIR 内のファイルの所有権が混在した状態で保存され、実行時に問題が発生します。

ファイルシステムのアクセス権および Celery を使用するバックグラウンドタスクも確認してください。

Web サーバーの実行¶

Weblate の実行は、他の Django ベースのプログラムの実行と同じです。通常 Django は WSGI または fcgi として実行されます（下記の異なる webservers の例を参照）。

注釈

The sample configuration files shown below are maintained in the Weblate source tree under weblate/examples/. They are included in source distributions and in this documentation, but Python wheels only install runtime files. When installing Weblate from PyPI, get the matching source distribution or source checkout before copying these examples.

テスト目的のために、Django の内蔵 Web サーバーを使用できます。Web サーバー実行コマンド:

weblate runserver

警告

Django の内蔵 Web サーバーは、運用環境では使用しないでください。セキュリティ監査や性能試験を受けていません。 runserver の Django ドキュメントも確認してください。

ヒント

Django に内蔵された Web サーバーは、開発専用であるため、DEBUG が有効な場合にのみ静的ファイルが提供されます。運用環境で使用するには、WSGI 設定を確認してください。

NGINX および Granian のためのサンプル設定
NGINX と Gunicorn の設定例
NGINX および uWSGI の設定例
Apache の設定例
Apache と Gunicorn の設定例
静的ファイルの提供

静的ファイルの提供¶

バージョン 5.15.2 で変更: /media/ はスクリーンショットの提供には使用されなくなりました。

Django では、静的ファイルを 1 つのディレクトリーに必ず集約してください。実現するには、weblate collectstatic --noinput を実行します。これにより、STATIC_ROOT 設定に指定したディレクトリに静的ファイルがコピーされます（デフォルトでは、 CACHE_DIR 内の static ディレクトリ）。

静的ファイルは、Web サーバーから直接提供することが望ましいです。静的ファイルが必要となるパス:

/static/: Weblate および管理画面の静的ファイルの提供（STATIC_ROOT に設定済）。
/favicon.ico: /static/favicon.ico を提供するようにルールを変更してください。

参考

NGINX および Granian のためのサンプル設定
NGINX と Gunicorn の設定例
NGINX および uWSGI の設定例
Apache の設定例
Apache と Gunicorn の設定例
クライアントアセットの圧縮
Djangoをデプロイするには
静的ファイルをデプロイする

コンテンツセキュリティポリシー¶

Weblate のデフォルト設定では、weblate.middleware.SecurityMiddleware ミドルウェアが有効となり、Content-Security-Policy または X-XSS-Protection などのセキュリティ関連の HTTP ヘッダーが設定されます。デフォルトでは、これらは Weblate の設定で動作するように設定されていますが、環境によっては変更が必要です。

参考

NGINX および Granian のためのサンプル設定¶

次の設定では、Granian NGINX WEB サーバーを使用して Weblate を実行する方法:

weblate/examples/weblate.nginx.granian.conf¶

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # CACHE_DIR/static/
        alias /home/weblate/data/cache/static/;
        expires 30d;
    }

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:8888;
        proxy_read_timeout 3600;
    }
}

参考

NGINX と Gunicorn の設定例¶

The following configuration runs Weblate using Gunicorn under the NGINX webserver (weblate/examples/weblate.nginx.gunicorn.conf in the source tree):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # CACHE_DIR/static/
        alias /home/weblate/data/cache/static/;
        expires 30d;
    }

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://unix:/run/gunicorn.sock;
        proxy_read_timeout 3600;
    }
}

参考

NGINX および uWSGI の設定例¶

運用環境の WEB サーバーを実行するには、Weblate とともにインストールされた WSGI ラッパーを使用します（Python 環境を利用している場合は ~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py としてインストールされます）。また、Python の検索パスを使用している Python 環境に設定することも忘れないでください（例: uWSGI で virtualenv = /home/user/weblate-env の指定）。

次の設定では、NGINX WEB サーバーの下で Weblate を uWSGI として実行します。

Configuration for NGINX (weblate/examples/weblate.nginx.conf in the source tree):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # CACHE_DIR/static/
        alias /home/weblate/data/cache/static/;
        expires 30d;
    }

    location / {
        include uwsgi_params;
        # Needed for long running operations in admin interface
        uwsgi_read_timeout 3600;
        # Adjust based to uwsgi configuration:
        uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
        # uwsgi_pass 127.0.0.1:8080;
    }
}

Configuration for uWSGI (weblate/examples/weblate.uwsgi.ini in the source tree):

#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins       = python3
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py

# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path   = /path/to/weblate

# Path to the Python environment
virtualenv = /home/weblate/weblate-env

# Needed for OAuth/OpenID
buffer-size   = 8192

# Reload when consuming too much of memory
reload-on-rss = 250

# Increase number of workers for heavily loaded sites
workers       = 8

# Enable threads for Sentry error submission
enable-threads = true

# Child processes do not need file descriptors
close-on-exec = true

# Avoid default 0000 umask
umask = 0022

# Run as weblate user
uid = weblate
gid = weblate

# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true

# Enable uWSGI stats server
# stats = :1717
# stats-http = true

# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true

参考

Django を uWSGI とともに使うには？

Apache の設定例¶

Weblate で WSGI を使用する場合は、prefork MPM を使用することが望ましいです。

The following configuration runs Weblate as WSGI, you need to have enabled mod_wsgi (weblate/examples/apache.conf in the source tree):

#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico

    # CACHE_DIR/static/
    Alias /static/ /home/weblate/data/cache/static/
    <Directory /home/weblate/data/cache/static/>
        Require all granted
    </Directory>

    # Path to your Weblate Python environment
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

注釈

Weblate には Python 3 が必要なので、Python 3 版の modwsgi が実行されていることを確認してください。通常は、libapache2-mod-wsgi-py3 のように、別のパッケージとして提供されています。

一致する Python バージョンを使用して Weblate をインストールします。

参考

Apache と Gunicorn の設定例¶

The following configuration runs Weblate in Gunicorn and Apache 2.4 (weblate/examples/apache.gunicorn.conf in the source tree):

#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico

    # CACHE_DIR/static/
    Alias /static/ /home/weblate/data/cache/static/
    <Directory /home/weblate/data/cache/static/>
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/https_cert.cert
    SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
    SSLProxyEngine On

    ProxyPass /favicon.ico !
    ProxyPass /static/ !

    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

参考

Granianを起動するための設定例¶

Weblate には wsgi オプションの依存関係（Python の依存関係）があり、これには Granian を実行するために必要なすべてが含まれます。Weblate をインストールする際には、次のように指定できます:

uv pip install Weblate[all,wsgi]

Granian のインストール後、実行可能です。これは通常システムレベルで行われます。systemd を使った起動例を以下に示します:

/etc/systemd/system/granian.service¶

[Unit]
Description=granian daemon
After=network.target

[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
    --no-ws \
    --workers-max-rss 350 \
    --interface wsgi \
    --workers 2 \
    --backpressure 16 \
    --runtime-threads 8 \
    --runtime-mode mt \
    --port 8888 \
    weblate.wsgi:application

[Install]
WantedBy=multi-user.target
~

参考

Gunicorn を起動するための設定例¶

Gunicorn は別途インストールする必要があります:

uv pip install gunicorn

Gunicorn のインストール後、実行可能です。これは通常システムレベルで行われます。systemd を使った起動例を以下に示します:

/etc/systemd/system/gunicorn.socket¶

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

/etc/systemd/system/gunicorn.service¶

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
    --preload \
    --timeout 3600 \
    --graceful-timeout 3600 \
    --worker-class=gthread \
    --workers=2 \
    --threads=16 \
    --bind unix:/run/gunicorn.sock \
    weblate.wsgi:application

[Install]
WantedBy=multi-user.target

参考

Django を Gunicorn とともに使う

パスの下での Weblate の実行¶

Weblate で WSGI を使用する場合は、prefork MPM を使用することが望ましいです。

A sample Apache configuration to serve Weblate under /weblate. Again using mod_wsgi (weblate/examples/apache-path.conf in the source tree):

#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico

    # CACHE_DIR/static/
    Alias /weblate/static/ /home/weblate/data/cache/static/
    <Directory /home/weblate/data/cache/static/>
        Require all granted
    </Directory>

    # Path to your Weblate Python environment
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

さらに、weblate/settings.py の変更が必要です。

URL_PREFIX = "/weblate"

Celery を使用するバックグラウンドタスク¶

Weblate は Celery を使用して、通常のタスクとバックグラウンドタスクを実行します。タスクを実行する Celery サービスを実行してください。 Celery で動作する処理の例（このリストは完全ではありません）:

外部サービスによる Web フックの受信（参照: 通知フック）。
バックアップ、クリーンアップ、毎日動作のアドオン、更新などの定期的なメンテナンスタスクの実行（参照: Weblate のバックアップと移動、BACKGROUND_TASKS、アドオン）。
自動翻訳の実行。
ダイジェスト通知の送信。
WSGI プロセスから負荷の高い操作をオフロードさせる。
保留中の変更のコミット（参照: 遅延コミット）。

Valkey または Redis をバックエンドとして使用する一般的な設定例:

CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL

参考

Redis broker configuration in Celery

You should also start the Celery worker to process the tasks and start scheduled tasks. For debugging or development, this can be done directly on the command-line:

celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup

注釈

Celery プロセスは、WSGI プロセスと同じユーザーとして実行させてください。もし異なると、DATA_DIR 内のファイルの所有権は混在した状態で保存され、実行時に問題が発生します。

ファイルシステムのアクセス権および実行サーバーも確認してください。

eager モードよる WSGI での Celery タスクの実行¶

注釈

これは、Web インタフェースに深刻な性能上の影響を与えます。そして、定期的なトリガーで起動する操作（例えば、保留中の変更のコミット、ダイジェスト通知、またはバックアップなど）が中断されます。

開発時には、すべてのタスクを適切に処理する Eager を設定してください。Eager 設定例:

CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True

システムサービスとして実行する Celery¶

Most likely you will want to run Celery as a daemon and that is covered by Daemonization. For the most common Linux setup using systemd, adapt the example files listed below. These examples are maintained in the Weblate source tree under weblate/examples/; Python wheels do not install these deployment samples.

/etc/systemd/system/celery-weblate.service に記述する Systemd ユニットの設定方法:

[Unit]
Description=Celery Service (Weblate)
After=network.target

[Service]
Type=forking
User=weblate
Group=weblate
EnvironmentFile=/etc/default/celery-weblate
WorkingDirectory=/home/weblate
RuntimeDirectory=celery
RuntimeDirectoryPreserve=restart
LogsDirectory=celery
ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait ${CELERYD_NODES} \
  --pidfile=${CELERYD_PID_FILE}'
ExecReload=/bin/sh -c '${CELERY_BIN} multi restart ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'

[Install]
WantedBy=multi-user.target

/etc/default/celery-weblate に記述する環境設定の記述例:

# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"

# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"

# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"

# Extra command-line arguments to the worker. You might need to customize
# concurrency depending on the available resources and Weblate usage. Increase
# the concurrency if you get weblate.E019 error, decrease it if you are on a
# low-resource system.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=4 \
    --queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=10 \
    --queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=10 \
    --queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=4 \
    --queues:backup=backup  --concurrency:backup=1 --prefetch-multiplier:backup=2"

# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
#   and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"

/etc/logrotate.d/celery にある Celery ログを logrotate を使用してローテーションするための追加設定の記述例:

/var/log/celery/*.log {
        weekly
        missingok
        rotate 12
        compress
        notifempty
}

Celery beat を使用した定期的なタスク¶

Weblate には、スケジュール済みのタスクが初期設定されています。タスクスケジュールはデータベースに保存され、Celery beat デーモンによって実行されます。

ヒント

追加タスクは settings.py で定義できます。たとえば、遅延コミットを参照してください。

Celery の状態の監視¶

Celery タスクキューの現在の長さは、管理画面から確認できますし、コマンドラインを使用して celery_queues からも確認できます。キューが長くなりすぎると、管理画面にも設定エラーが表示されます。

警告

デフォルトでは、Celery エラーは Celery ログにのみ記録され、ユーザーには表示されません。このような障害の概要を知りたいときは、エラーレポートの収集とパフォーマンスの監視の設定をしてください。

参考

シングルプロセス Celery の設定¶

メモリが非常に限られている場合は、Weblate のプロセス数を減らしてみてください。すべての Celery タスクをシングルプロセスで実行する設定:

celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo

Docker を使用したインストールでは、CELERY_SINGLE_PROCESS を設定することで、単一プロセスの Celery セットアップを使用するように設定できます。

警告

これにより、Weblate の性能に顕著な影響が出ます。

Weblate の監視¶

Weblate は、Kubernetes などを使用した簡単に健全性診断ができる /healthz/ URLを提供しています。Docker コンテナには、この URL を使用した健全性診断が付属しています。

Weblate のメトリックスを監視するには、API のエンドポイント GET /api/metrics/ を使用します。

参考

エラーレポートの収集とパフォーマンスの監視¶

Weblate は、他のソフトウェアと同じようにエラーが発生することがあります。有用な障害状態を収集するには、サードパーティのサービスを使用して、そのような情報を収集してください。これは、Celery タスクが失敗した場合にとても便利です。失敗した場合、ログにエラーが報告されるだけで、メールで通知はされません。Weblate が対応するログサービス:

メールアドレス¶

Weblate のデフォルト設定では、django.utils.log.AdminEmailHandler を通じて、サーバーエラー発生時に Django が管理者へメールを送信するよう設定されています。これは最も手軽に導入できる方法ですが、エラー通知メールには機密情報が含まれる可能性があるため、プライバシーの観点から他の手段の利用も検討すべきです。詳細についてはセキュリティへの影響を参照してください。

この動作を無効にするには、Weblate の設定で LOGGING から mail_admins を削除するか、Docker 環境で WEBLATE_ADMIN_NOTIFY_ERROR を無効にしてください。

Sentry¶

Weblate には Sentry への対応が組み込まれています。使用するには、 settings.py に SENTRY_DSN だけを設定すれば十分です。

SENTRY_DSN = "https://id@your.sentry.example.com/"

Sentry は、Weblate のパフォーマンスを監視するためにも使用できます。特定の割合の操作のトレースとプロファイルを収集することで、パフォーマンスの問題を特定できます。これは、SENTRY_TRACES_SAMPLE_RATE および SENTRY_PROFILES_SAMPLE_RATE を使用して設定できます。

参考

Rollbar¶

Weblate は Rollbar に対応しています。使用方法は、 Rollbar notifier for Python の指示に従うだけです。

つまり、settings.py に必要な設定:

# Add rollbar as last middleware:
MIDDLEWARE = [
    # … other middleware classes …
    "rollbar.contrib.django.middleware.RollbarNotifierMiddleware",
]

# Configure client access
ROLLBAR = {
    "access_token": "POST_SERVER_ITEM_ACCESS_TOKEN",
    "environment": "development" if DEBUG else "production",
    "branch": "main",
    "root": "/absolute/path/to/code/root",
}

他のすべてを自動的に連携して、サーバー側とクライアント側の両方のエラーを収集します。

注釈

エラーログには、正常に処理された例外も含まれていますが、アップロードされたファイルの解析失敗などの問題を示唆するものかもしれません。

Graylog によるログ管理¶

Added in version 5.9.

Weblate は GELF TCP プロトコルを使ったログ記録を設定できます。これは Graylog 統合のために開発されましたが、準拠する任意のロギングプラットフォームで利用可能です。

設定のひな形は設定例に含まれています。Docker を使用する場合は WEBLATE_LOG_GELF_HOST を用いて設定します。

Weblate を別のサーバーに移行¶

Weblate を別のサーバーに移行するのは非常に簡単です。しかし、複数の場所にデータを保存しているので、慎重に移行してください。最良の方法は、移行のために Weblate を停止することです。

データベースの移行¶

最も簡単な方法は、データベース純正の管理ツールを使用することです。これは通常もっとも効果的です（例: pg_dump）。また、データベースが対応している場合は、レプリケーションを使用できます。

参考

他のデータベースから PostgreSQL に移行に説明があるデータベース間の移行。

VCS リポジトリの移行¶

DATA_DIR に保存されている VCS リポジトリーも必ず移行してください。単純にコピーすることも、rsync コマンドを使用して、より効率的に移行することもできます。

その他の注意事項¶

Weblate が使用していた可能性のある Valkey、Redis、Cron ジョブ、カスタム認証バックエンドなどの他のサービスも移行することを忘れないでください。

導入方法¶

Weblate のインストール¶

アーキテクチャの概要¶

ソフトウェア要件¶

オペレーティング システム¶

Python の依存関係¶

pip install のトラブルシューティング¶

その他のシステム要件¶

ビルド時の依存関係¶

Pango と Cairo¶

ハードウェア要件¶

メモリ使用量¶

CPU 使用率¶

ストレージ使用量¶

ノード数¶

リリース署名の検証¶

ファイル システムのアクセス権¶

Weblate のデータベース設定¶

データベース接続¶

PostgreSQL¶

PostgreSQL でデータベースの作成¶

Weblate で PostgreSQL を使用するための設定¶

その他の設定¶

メール送信の設定¶

リバース プロキシの背後で実行¶

HTTP プロキシ¶

詳細設定¶

データベースの準備¶

運用環境の設定¶

デバッグ モードの無効化¶

適切な管理者の設定¶

サイトの正確なドメイン設定¶

HTTPS の正しい設定¶

SECURE_HSTS_SECONDS の適切な設定¶

強力なデータベース エンジンの使用¶

キャッシュの設定¶

アバターのキャッシュ¶

メールの送信設定¶

許可するホストの登録¶

Django の秘密鍵¶

メンテナンス タスクの実行¶

システム言語とエンコーディング¶

カスタム認証局の使用¶

クライアント アセットの圧縮¶

実行サーバー¶

Web サーバーの実行¶

静的ファイルの提供¶

コンテンツ セキュリティ ポリシー¶

NGINX および Granian のためのサンプル設定¶

NGINX と Gunicorn の設定例¶

NGINX および uWSGI の設定例¶

Apache の設定例¶

Apache と Gunicorn の設定例¶

Granianを起動するための設定例¶

Gunicorn を起動するための設定例¶

パスの下での Weblate の実行¶

Celery を使用するバックグラウンド タスク¶

eager モードよる WSGI での Celery タスクの実行¶

システム サービスとして実行する Celery¶

Celery beat を使用した定期的なタスク¶

Celery の状態の監視¶

シングルプロセス Celery の設定¶

Weblate の監視¶

エラーレポートの収集とパフォーマンスの監視¶

メールアドレス¶

Sentry¶

Rollbar¶

Graylog によるログ管理¶

Weblate を別のサーバーに移行¶

データベースの移行¶

VCS リポジトリの移行¶

その他の注意事項¶

オペレーティングシステム¶

ファイルシステムのアクセス権¶

リバースプロキシの背後で実行¶

デバッグモードの無効化¶

強力なデータベースエンジンの使用¶

メンテナンスタスクの実行¶

クライアントアセットの圧縮¶

コンテンツセキュリティポリシー¶

Celery を使用するバックグラウンドタスク¶

システムサービスとして実行する Celery¶