導入方法

Weblate のインストール

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

ソフトウェア要件

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

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

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

その他のサービス

Weblate は他のサービスを利用しています。実行が必要なサービス:

PostgreSQL データベースサーバー。参照: Weblate のデータベース設定。
キャッシュとタスクキューの Redis サーバー。参照: Celery を使用するバックグラウンドタスク。
メール送信用の SMTP サーバー。参照: メール送信の設定。

Python の依存関係

Weblateは、Python で書かれており、Python 3.6 以降に対応しています。依存関係は、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/

オプションの依存関係

一部の Weblate の機能には、以下のモジュールが必要です。requirements-optional.txt ですべてを確認できます。

Mercurial （Mercurial リポジトリ対応用のオプション）: https://www.mercurial-scm.org/
phply （PHP 文字列対応用のオプション）: https://github.com/viraptor/phply
tesserocr （文字列の視覚情報の OCR 用のオプション）: https://github.com/sirfz/tesserocr
python-akismet （スパム対策のスパム保護用のオプション）: https://github.com/Nekmo/python-akismet
ruamel.yaml （YAML ファイル用のオプション）: https://pypi.org/project/ruamel.yaml/
Zeep （Microsoft 用語集用のオプション）: https://docs.python-zeep.org/
aeidon （字幕ファイル用のオプション）: https://pypi.org/project/aeidon/
fluent.syntax （Fluent 形式用のオプション）: https://projectfluent.org/

ヒント

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

pip install "Weblate[PHP,Fluent]"

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

pip install "Weblate[all]"

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

pip install Weblate

バックエンドのデータベースの依存関係

Weblate は、PostgreSQL、MySQL および MariaDB に対応しています。詳細は、Weblate のデータベース設定およびバックエンドのドキュメントを確認してください。

その他のシステム要件

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

Git: https://git-scm.com/
Pango、Cairo および関連するヘッダーファイルと GObject イントロスペクションデータ: https://cairographics.org/、https://pango.gnome.org/。参照: Pango と Cairo
git-review （Gerrit 対応用のオプション）: https://pypi.org/project/git-review/
git-svn （Subversion 対応用のオプション）: https://git-scm.com/docs/git-svn
tesseract とそのデータ（スクリーンショットの OCR 用のオプション）: https://github.com/tesseract-ocr/tesseract
licensee （コンポーネント作成時にライセンス確認するためのオプション）: https://github.com/licensee/licensee

ビルド時の依存関係

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

Pango と Cairo

バージョン 3.7 で変更.

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

リリース署名の検証

Weblate のリリースは、リリースした開発者により署名は暗号化されています。現在は、Michal Čihař です。彼の PGP 鍵の指紋:

63CB 1DF1 EF12 CF2A C0EE 5A32 9C27 B313 42B7 511D

さらに、<https://keybase.io/nijel> から、より多くの身元情報を得られます。

署名が、ダウンロードしたアーカイブと一致するかどうかの確認をしてください。これにより、リリースされたものと同じコードを使用していることを確認できます。また、署名の日付を確認して、最新バージョンをダウンロードしたかどうかの確認も必要です。

各アーカイブには、PGP 署名を含む .asc ファイルが付属しています。両方とも同じフォルダに入れてから署名を確認します。確認方法:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Can't check signature: public key not found

ご覧のとおり、公開鍵が見つからないと GPG が文句を言ってきてます。この時点で、必要となる操作を、次から一つ選択:

wkd を使用して鍵をダウンロードする:

$ gpg --auto-key-locate wkd --locate-keys michal@cihar.com
pub   rsa4096 2009-06-17 [SC]
      63CB1DF1EF12CF2AC0EE5A329C27B31342B7511D
uid           [ultimate] Michal Čihař <michal@cihar.com>
uid           [ultimate] Michal Čihař <nijel@debian.org>
uid           [ultimate] [jpeg image of size 8848]
uid           [ultimate] Michal Čihař (Braiins) <michal.cihar@braiins.cz>
sub   rsa4096 2009-06-17 [E]
sub   rsa4096 2015-09-09 [S]

Michal のサーバーから鍵束をダウンロードし、次のコマンドでインポートする:

$ gpg --import wmxth3chu9jfxdxywj1skpmhsj311mzm

鍵サーバーの 1 つから、鍵をダウンロードしてインポートする:

$ gpg --keyserver hkp://pgp.mit.edu --recv-keys 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: key 9C27B31342B7511D: "Michal Čihař <michal@cihar.com>" imported
gpg: Total number processed: 1
gpg:              unchanged: 1

実行すると状況を少し改善できる操作（この時点で、指定した鍵からの署名が正しいことを確認できるが、鍵で使用されている名前は信頼できない）:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 63CB 1DF1 EF12 CF2A C0EE  5A32 9C27 B313 42B7 511D

ここで問題なのは、誰もがこの名前で鍵を発行できてしまうことです。その鍵が、その人物が実際に所有しているかどうかの確認が必要となります。GNU プライバシーハンドブックでは、Validating other keys on your public keyring の章でこの話題を扱っています。最も信頼できる方法は、開発者と直接会って鍵の指紋を交換することですが、信頼できる WEB に頼ることもできます。これにより、開発者に直接会った他の人の署名を使用して、鍵を関節的に信頼できます。

鍵が信頼されると、警告は発生しません。鍵が信頼された場合:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]

署名が無効な場合（アーカイブ改ざん時）、鍵の信頼にかかわらず、明確なエラーが発生します。署名が無効な場合:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: BAD signature from "Michal Čihař <michal@cihar.com>" [ultimate]

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

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

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

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

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

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

参考

静的ファイルの提供

Weblate のデータベース設定

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

参考

強力なデータベースエンジンの使用、データベース、他のデータベースから PostgreSQL に移行

PostgreSQL

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

注釈

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

参考

PostgreSQL notes

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 WITH SCHEMA weblate;
CREATE EXTENSION IF NOT EXISTS btree_gin WITH SCHEMA weblate;

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

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

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Name of role to alter to set parameters in PostgreSQL,
        # use in case role name is different than user used for authentication.
        # "ALTER_ROLE": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
    }
}

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

MySQL と MariaDB

ヒント

Weblate の機能の中には、PostgreSQL を使用するとパフォーマンスが向上するものがあります。これには、検索と翻訳メモリが含まれます。どちらもデータベースの全文機能を利用しており、PostgreSQL を実装する方が優れています。

Weblate は、MySQL や MariaDB でも使用できます。Django を使用する際の注意事項については、MySQL notes および MariaDB notes を確認してください。制限があるため、新規インストールには PostgreSQL の使用を推奨します。

Weblate には、MySQL 5.7.8 以上または MariaDB 10.2.7 以上が必要です。

Weblate で推奨する設定:

utf8mb4 文字セットを使用して、より高い Unicode プレーン（絵文字など）の表現を可能にする。
テキストフィールドでより長いインデックスを使用できるように、innodb_large_prefix をサーバーに設定する。
分離レベルを READ COMMITTED に設定する。
SQL モードを STRICT_TRANS_TABLES に必ず設定すること。

MySQL 8.x、MariaDB 10.5.x 以降では、適切なデフォルト設定があり、そのためサーバーの調整は必要なく、必要なものはすべてクライアント側から設定できます。

以下の設定ファイル /etc/my.cnf.d/server.cnf は、8 GB の RAM を搭載したサーバーの例です。ほとんどのインストールは、この設定で十分です。MySQL と MariaDB には、サーバーの性能を向上させる調整機能がありますが、システムに多数のユーザーが同時接続することを計画していない限り、不要です。詳細については、さまざまなベンダーのドキュメントを確認してください。

Weblate のインストール時の問題を減らすため、事前に innodb_file_per_table を適切に設定して、そのあと MySQL/MariaDB を再起動したのちに、Weblate をインストールすることが非常に重要です。

[mysqld]
character-set-server = utf8mb4
character-set-client = utf8mb4
collation-server = utf8mb4_unicode_ci

datadir=/var/lib/mysql

log-error=/var/log/mariadb/mariadb.log

innodb_large_prefix=1
innodb_file_format=Barracuda
innodb_file_per_table=1
innodb_buffer_pool_size=2G
sql_mode=STRICT_TRANS_TABLES

ヒント

#1071 - Specified key was too long; max key length is 767 bytes というメッセージが表示された場合、上記の innodb の設定を含むように設定ファイルを上書きし、インストールを再開してください。

ヒント

#2006 - MySQL server has gone away というエラーが発生する場合は、CONN_MAX_AGE と設定してみてください。

Weblate で MySQL または MariaDB を使用するための設定

settings.py に必要な MySQL と MariaDB 用の設定:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.mysql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "127.0.0.1",
        # Set to empty string for default
        "PORT": "3306",
        # In case you wish to use additional
        # connection options
        "OPTIONS": {},
    }
}

インストールを開始する前に、MySQL または MariaDB で weblate ユーザーアカウントを作成してください。アカウント作成コマンド例:

GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

その他の設定

メール送信の設定

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 からメールが届かない、Configuring outgoing e-mail in Docker container

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

Weblate の複数の機能は、クライアントの IP アドレスを取得できることを前提にしています。これには、接続制限、スパム対策または監査ログが含まれます。

デフォルト構成では、Weblate は WSGI ハンドラーが設定した REMOTE_ADDR から IP アドレスを解析します。

リバースプロキシーを実行している場合、通常このフィールドにはアドレスが含まれます。追加の HTTP ヘッダーを信頼し、そこから IP アドレスを解析するように Webrate を設定してください。リバースプロキシを使用しないインストールでは、 IP アドレスのスプーフィングが可能になるため、デフォルトでは有効にできません。通常は、IP_BEHIND_REVERSE_PROXY を有効化する設定だけで十分ですが、IP_PROXY_HEADER および IP_PROXY_OFFSET の設定も調整が必要です。

もう一つ注意すべきは、Host ヘッダーです。これは、SITE_DOMAIN の設定と一致させてください。リバースプロキシに追加の設定が必要となるかもしれません（例えば、Apache では ProxyPreserveHost On を、nginxでは proxy_set_header Host $host; が必要です）。

参考

スパム対策、接続制限、監査ログ、IP_BEHIND_REVERSE_PROXY、IP_PROXY_HEADER、IP_PROXY_OFFSET、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、適切な管理者の設定

ALLOWED_HOSTS

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

ALLOWED_HOSTS、WEBLATE_ALLOWED_HOSTS、許可するホストの登録

SESSION_ENGINE

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

Redis をキャッシュとして使用している場合（参照: キャッシュの有効化）、セッションにも 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

データベースの準備

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

コマンドでインストールをするには、weblate migrate --noinput を使用してから、createadmin コマンドを使用して admin ユーザーを作成します。

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

参考

設定, アクセス権および組込みロールの一覧

運用環境の設定

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

また、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 フレームワークが使用されていました。参照: The "sites" framework。

参考

許可するホストの登録、HTTPS の正しい設定、SITE_DOMAIN、WEBLATE_SITE_DOMAIN、ENABLE_HTTPS

HTTPS の正しい設定

暗号化された HTTPS プロトコルを使用して Webrate を実行することを強く推奨します。有効にしたら、設定画面から 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 を使用して、データベースサーバーの性能の検査をしたり、設定を調整してください。

参考

Weblate のデータベース設定、他のデータベースから PostgreSQL に移行、詳細設定, データベース

キャッシュの有効化

できれば、設定変数 CACHES を変更して Django の 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",
        },
    }
}

ヒント

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

参考

アバターのキャッシュ、Django's cache framework

アバターのキャッシュ

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,
        },
    },
}

参考

ENABLE_AVATARS、AVATAR_URL_PREFIX、アバター、キャッシュの有効化、Django's cache framework

メールの送信設定

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 に設定します。

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

参考

詳細設定、メール送信の設定、EMAIL_BACKEND、DEFAULT_FROM_EMAIL、SERVER_EMAIL

許可するホストの登録

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/examples/generate-secret-key を使用します。

参考

SECRET_KEY

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

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

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

バージョン 3.2 で変更: バージョン 3.2 以降、このタスクを実行はデフォルトで Celery を使用しており、Weblate はすでに適切な設定に変更して提供されています。参照: Celery を使用するバックグラウンドタスク。

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

システム言語は、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`（または :file:/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 を実行します）。

追加すると、システムツールは証明書を信頼します。これは 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 イメージでは、すでにこの機能は有効です。

参考

Common Deployment Scenarios、静的ファイルの提供

実行サーバー

ヒント

下記で説明しているサービスの設定に慣れていない場合は、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 は uWSGI または fcgi として実行されます（下記の異なる webservers の例を参照）。

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

weblate runserver

警告

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

ヒント

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

静的ファイルの提供

バージョン 2.4 で変更: バージョン 2.4 以前では、Weblate が Django 静的ファイルフレームワークを適切に使用せず設定が難解でした。

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

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

/static/: Weblate および管理インタフェースの静的ファイルの提供（STATIC_ROOT に設定済）。
/media/: ユーザーメディアのアップロードに使用する（例: スクリーンショット）。
/favicon.ico: /static/favicon.ico を提供するようにルールを変更してください。

参考

NGINX および uWSGI の設定例, Apache の設定例、Apache と Gunicorn の設定例、クライアントアセットの圧縮、How to deploy Django、How to deploy static files

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

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

参考

CSP_SCRIPT_SRC、CSP_IMG_SRC、CSP_CONNECT_SRC、CSP_STYLE_SRC、CSP_FONT_SRC

NGINX および uWSGI の設定例

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

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

NGINX の設定（ weblate/examples/weblate.nginx.conf に設定可能）:

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 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$ {
        # DATA_DIR/static/favicon.ico
        alias /home/weblate/data/static/favicon.ico;
        expires 30d;
    }

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

    location /media/ {
        # DATA_DIR/media/
        alias /home/weblate/data/media/;
        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;
    }
}

uWSGI の設定（ weblate/examples/weblate.uwsgi.ini に設定可能）。

#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 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.9/site-packages/weblate/wsgi.py

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

# In case you're using virtualenv uncomment this:
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 を使用することが望ましいです。

Weblate を WSGI として実行する設定例。mod_wsgi の有効化が必須（weblate/examples/apache.conf にて設定可能）:

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

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

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

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

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

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

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

</VirtualHost>

注釈

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

参考

システム言語とエンコーディング、Django を Apache と mod_wsgi とともに使うには？

Apache と Gunicorn の設定例

Gunicorn および Apache 2.4 で Weblate を実行する設定例（weblate/examples/apache.gunicorn.conf に設定可能）:

#
# 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 virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

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

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        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 /media/ !

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

参考

How to use Django with Gunicorn

パスの下での Weblate の実行

バージョン 1.3 で追加.

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

Weblate を /weblate 配下で実行する Apache の設定例。こちらも mod_wsgi を使用します（weblate/examples/apache-path.conf でも設定可能）:

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

    # DATA_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /home/weblate/data/static/favicon.ico

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

    # DATA_DIR/media/
    Alias /weblate/media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    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.9/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

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

</VirtualHost>

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

URL_PREFIX = "/weblate"

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

バージョン 3.2 で追加.

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

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

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

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

参考

Redis broker configuration in Celery

また、Celery ワーカーを起動してタスクを処理し、スケジュールしたタスクを開始することが必要です。コマンドラインから直接実行する方法（これはデバッグや開発の際に便利です）:

./weblate/examples/celery start
./weblate/examples/celery stop

注釈

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

多くの場合、Celery をデーモンとして実行したいですが、これは Daemonization に含まれます。systemd を使用した最も一般的な Linux の設定では、次に示す examples フォルダに付属にあるサンプルファイルを使用できます。

/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,
# increase concurrency if you get weblate.E019
CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \
    --queues:notify=notify --prefetch-multiplier:notify=10 \
    --queues:memory=memory --prefetch-multiplier:memory=10 \
    --queues:translate=translate --prefetch-multiplier:translate=4 \
    --concurrency:backup=1 --queues:backup=backup  --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 には、スケジュール済みのタスクが初期設定されています。または、settings.py で追加のタスクを設定できます。遅延コミットの例を確認してください。

タスクは Celery beats デーモンによって実行されることになっています。正常に動作していない場合は、実行していないか、データベースが破損していることがあります。このような場合は、Celery の起動ログを調べて、根本的な原因を突き止めます。

Celery の状態の監視

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

警告

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

参考

Weblate の監視、Weblate が正しく設定されているかどうかを確認する方法は？、Configuration and defaults、Workers Guide、Daemonization、Monitoring and Management Guide、celery_queues

Weblate の監視

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

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

参考

Weblate が正しく設定されているかどうかを確認する方法は？、Celery の状態の監視、Munin 用の Weblate プラグイン

エラーレポートの収集

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

Sentry

Weblate には`Sentry <https://sentry.io/>`_ への対応が組み込まれています。使用するには、 settings.py に SENTRY_DSN だけを設定すれば十分です。

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

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",
    "client_token": "POST_CLIENT_ITEM_ACCESS_TOKEN",
    "environment": "development" if DEBUG else "production",
    "branch": "main",
    "root": "/absolute/path/to/code/root",
}

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

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

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

データベースの移行

データベースのバックエンドによっては、データベースを移行するオプションが複数あります。最も簡単な方法は、データベースの正規のツールを使用することです。通常、この方法が最も効果的です（例: mysqldump や pg_dump など）。また、データベースがレプリケーションに対応している場合には、レプリケーションを使用できます。

参考

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

VCS リポジトリの移行

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

その他の注意事項

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

導入方法

Weblate のインストール

ソフトウェア要件

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

その他のサービス

Python の依存関係

オプションの依存関係

バックエンドのデータベースの依存関係

その他のシステム要件

ビルド時の依存関係

Pango と Cairo

リリース署名の検証

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

Weblate のデータベース設定

PostgreSQL

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

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

MySQL と MariaDB

Weblate で MySQL または MariaDB を使用するための設定

その他の設定

メール送信の設定

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

HTTP プロキシ

詳細設定

データベースの準備

運用環境の設定

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

適切な管理者の設定

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

HTTPS の正しい設定

SECURE_HSTS_SECONDS の適切な設定

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

キャッシュの有効化

アバターのキャッシュ

メールの送信設定

許可するホストの登録

Django の秘密鍵

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

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

カスタム認証局の使用

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

実行サーバー

Web サーバーの実行

静的ファイルの提供

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

NGINX および uWSGI の設定例

Apache の設定例

Apache と Gunicorn の設定例

パスの下での Weblate の実行

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

eager モードよる wsgi での Celery タスクの実行

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

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

Celery の状態の監視

Weblate の監視

エラー レポートの収集

Sentry

Rollbar

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

データベースの移行

VCS リポジトリの移行

その他の注意事項

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

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

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

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

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

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

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

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

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

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

エラーレポートの収集