導入方法#

Weblate のインストール#

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

ソフトウェア要件#

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

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

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

その他のサービス#

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

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]

$ 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 12 and higher is supported.

参考

強力なデータベース エンジンの使用、データベース、他のデータベースから 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;
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": "",
    }
}

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

MySQL と MariaDB#

警告

While MySQL and MariaDB support is still maintained in Weblate, our primary focus is PostgreSQL. It is recommended to use PostgreSQL for new installs, and to migrate existing installs to PostgreSQL, see 他のデータベースから PostgreSQL に移行.

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

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

Weblate requires MySQL at least 8 or MariaDB at least 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"

参考

プロキシ環境変数

詳細設定#

参考

設定例

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

データベースの準備#

After your configuration is ready, you can run weblate migrate to create the database structure. Now you should be able to create translation projects using the admin interface.

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

参考

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

運用環境の設定#

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

../_images/admin-wrench.png

また、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 プロトコルを使用して 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'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 が実行するタスク:

バージョン 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 の実行に必要なサービスと推奨設定:

注釈

サービス間には、依存関係があります。例えば、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 の設定例、および 静的ファイルの提供 の設定を確認してください。

静的ファイルの提供#

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

    # 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 のように、別のパッケージとして提供されています。

Use matching Python version to install 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 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 の実行#

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

    # 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 で動作する処理の例（このリストは完全ではありません）:

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

You can find current length of the Celery task queues in the 管理画面 or you can use weblate celery_queues on the command-line. In case the queue will get too long, you will also get configuration error in the admin interface.

警告

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

参考

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

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

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 が使用していた可能性のある他のサービスの移動を忘れないでください。