導入方法¶

Weblate のインストール¶

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

アーキテクチャの概要¶

Web server

Handling incoming HTTP requests, 静的ファイルの提供.

Celery workers

Celery を使用するバックグラウンドタスク are executed here.

Depending on your workload, you might want to customize the number of workers.

Use dedicated node when scaling Weblate horizontally.

WSGI server

A WSGI server serving web pages to users.

Use dedicated node when scaling Weblate horizontally.

データベース

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

Use dedicated database node for sites with hundreds of millions of hosted words.

Redis

キャッシュとタスクキューの Redis サーバー。参照: Celery を使用するバックグラウンドタスク。

Use dedicated node when scaling Weblate horizontally.

File system

File system storage for storing VCS repositories and uploaded user data. This is shared by all the processes.

Use networked storage when scaling Weblate horizontally.

E-mail server

SMTP server for outgoing e-mail, see メール送信の設定. It can be provided externally.

ヒント

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

ソフトウェア要件¶

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

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

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

参考

アーキテクチャの概要 describes overall Weblate architecture and required services.

Python の依存関係¶

Weblate is written in Python and supports Python 3.10 or newer. You can install dependencies using pip or from your distribution packages, full list is available in 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/

オプションの依存関係¶
pip extra	Python パッケージ	Weblate の機能
`alibaba`	aliyun-python-sdk-alimt	Alibaba
`amazon`	boto3	Amazon Translate
`antispam`	python-akismet	スパム対策
`gerrit`	git-review	Gerrit
`google`	google-cloud-translate	Google Cloud Translation Advanced
`ldap`	django-auth-ldap	LDAP 認証
`mercurial`	mercurial	Mercurial
`mysql`	mysqlclient	MySQL または MariaDB（参照: Weblate のデータベース設定）
`openai`	openai	OpenAI
`postgres`	psycopg	PostgreSQL（参照: Weblate のデータベース設定）
`saml`	python3-saml	SAML 認証
`zxcvbn`	django-zxcvbn-password	パスワード認証

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

pip install "Weblate[Postgres,Amazon,SAML]"

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

pip install "Weblate[all]"

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

pip install 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``（システムで tesserocr バイナリホイールが利用できない場合にのみ必要）: https://github.com/tesseract-ocr/tesseract
licensee （コンポーネント作成時にライセンス確認するためのオプション）: https://github.com/licensee/licensee

ビルド時の依存関係¶

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

Pango と Cairo¶

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

参考

Debian と Ubuntu にインストール、SUSE および openSUSE にインストール、RedHat、Fedora、CentOS にインストール、macOS にインストール

ハードウェア要件¶

Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on a single host (Weblate, database and web server):

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

注釈

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

Memory usage¶

The more memory the better - it is used for caching on all levels (file system, database and Weblate). For hundreds of translation components, at least 4 GB of RAM is recommended.

ヒント

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

CPU usage¶

Many concurrent users increase the amount of needed CPU cores.

Storage usage¶

The typical database storage usage is around 300 MB per 1 million hosted words.

Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.

Nodes¶

For small and medium-sized sites (millions of hosted words), all Weblate components (see アーキテクチャの概要) can be run on a single node.

When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see 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 は、これらのディレクトリを自動的に作成しようとします。しかし、アクセス権がなければ作成できません。

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

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

参考

静的ファイルの提供

Weblate のデータベース設定¶

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

PostgreSQL 12 and higher is supported. PostgreSQL 15 or newer is recommended.

MySQL と MariaDB に対応していますが、新規インストールは推奨しません。

注釈

No other database servers are currently supported, but support for other Django supported databases should be possible to implement.

参考

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

データベース接続¶

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

Weblate に必要な最小接続数:

:math:`(4 times mathit{nCPUs}) + 2`（Celery プロセスの場合）
:math:`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",
        # 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": "",
        # 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 に設定してください。

参考

データベース接続

MySQL と MariaDB¶

警告

Weblate では、MySQL と MariaDB への対応は継続していますが、私たちの次の興味は PostgreSQL です。新しいインストールでは PostgreSQL の使用を推奨しており、既存のインストールを PostgreSQL に移行することも推奨しています。参照: 他のデータベースから PostgreSQL に移行。

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

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

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

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 アドレスを解析するように Weblate を設定してください。リバースプロキシを使用しないインストールでは、 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"

参考

Proxy Environment Variables

詳細設定¶

参考

設定例

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 を使用して、古いセッションデータをデータベースから削除します。

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

データベースの準備¶

設定の準備ができたら、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 の正しい設定、SITE_DOMAIN、WEBLATE_SITE_DOMAIN、ENABLE_HTTPS

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 を使用して、データベースサーバーの性能の検査をしたり、設定を調整してください。

参考

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 のキャッシュフレームワーク

アバターのキャッシュ¶

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 のキャッシュフレームワーク

メールの送信設定¶

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。

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

システム言語は、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 の設定例、および静的ファイルの提供の WSGI 設定を確認してください。

静的ファイルの提供¶

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

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

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

参考

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

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

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 /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 /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.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

# 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 /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>

    # 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.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 をインストールします。

参考

システム言語とエンコーディング、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 /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>

    # 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>

参考

Django を Gunicorn とともに使う

パスの下での Weblate の実行¶

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

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

# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later

#
# 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 /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>

    # 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.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 プロセスから負荷の高い操作をオフロードさせる。
保留中の変更のコミット（参照: 遅延コミット）。

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 を使用してローテーションするための追加設定の記述例:

# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later

/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

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

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

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

警告

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

Weblate の監視¶

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

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

参考

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/"

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

参考

Sentry パフォーマンスモニタリング、Sentry プロファイリング

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¶

ハードウェア要件¶

Memory usage¶

CPU usage¶

Storage usage¶

Nodes¶

リリース署名の検証¶

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

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 の状態の監視¶

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

Weblate の監視¶

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

Sentry¶

Rollbar¶

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

データベースの移行¶

VCS リポジトリの移行¶

その他の注意事項¶

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

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

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

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

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

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

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

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

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

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