設定手順¶

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.celeryproject.org/
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
akismet （提案のスパム保護用のオプション）: https://github.com/ubernostrum/akismet
ruamel.yaml （YAML files 用のオプション）: https://pypi.org/project/ruamel.yaml/
Zeep （Microsoft Terminology Service 用のオプション）: https://docs.python-zeep.org/
aeidon （Subtitle files 用のオプション）: https://pypi.org/project/aeidon/

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

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

その他のシステム要件¶

システムにインストールする必要がある依存関係:

Git: https://git-scm.com/
Pango、Cairo および関連するヘッダファイルと gir イントロスペクションデータ: 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は、ビットマップウィジェットの表示（参照: Promoting the translation）と、検査結果の表示（参照: フォントの管理）に 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 は、これらのディレクトリを自動的に作成を試みます。しかし、アクセス権がない場合は失敗します。

また、Management commands の実行時には注意が必要です。これは、Weblate 自体の実行と同じユーザーで実行することが必要なためです。そうでなければ、アクセス権を間違ったファイルがあります。

Docker コンテナでは、/app/data ボリューム内のすべてのファイルは、コンテナ内の weblate ユーザーが所有者であることが必要です（UID 1000）。

参考

静的ファイルの提供

Weblate のデータベース設定¶

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

参考

強力なデータベースエンジンの使用、Databases、Migrating from other databases to PostgreSQL

PostgreSQL¶

通常、PostgreSQL は Django ベースのサイトに最適です。これは、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 -O weblate weblate

ヒント

Weblate ユーザーを PostgreSQL のスーパーユーザーにしたくない場合は、省略ができます。その場合、いくつかの移行手順をスキーマ Weblate の PostgreSQL スーパーユーザーとして手動で実行することが必要:

CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA weblate;

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

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 に設定が必要。

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

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

[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 設定を含むように構成を更新し、インストールを再開してください。

ヒント

In case you are getting #2006 - MySQL server has gone away error, configuring CONN_MAX_AGE might help.

MySQL/MariaDB を使用するための Weblate の設定¶

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 を有効にしてみてください。

参考

Not receiving e-mails from Weblate、Configuring outgoing e-mail in Docker container

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

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

デフォルト構成では、WEBlate は WSGI ハンドラーによって設定された REMOTE_ADDR から IP アドレスを解析します。

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

参考

Spam protection、接続制限、監査ログ、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

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"
参考

Configuring the session engine、SESSION_ENGINE

DATABASES

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

参考

Weblate のデータベース設定、DATABASES、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 ユーザーを作成します。

設定が完了したら、管理インターフェイスの Performance report も確認してください。これにより、サイトの不適切かもしれない設定のヒントが得られます。

参考

設定, アクセス制御

本番環境の設定¶

本番環境のセットアップでは、以下のセクションで説明する設定が必要です。最重要の設定では警告が発生します。スーパーユーザーとしてサインインしている場合、上部バーに感嘆符で警告:

また、Django によって起動された検査項目を確認することも推奨します（すべてを修正する必要はないかもしれない）:

weblate check --deploy

管理画面からも、ほぼ同じな検査項目を確認できます。

参考

Deployment checklist

デバッグモードの無効¶

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 のデータベース設定、Migrating from other databases to PostgreSQL、詳細設定, Databases

キャッシュの有効化¶

可能であれば、設定変数 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、Avatars、キャッシュの有効化、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

ホームディレクトリ¶

バージョン 2.1 で変更: これは不要になりました。Weblate では、すべてのデータを DATA_DIR に格納します。

Weblate を実行しているユーザーのホームディレクトリが存在し、ユーザーが書き込み可能であることが必要です。これは、特に SSH を使ってプライベートリポジトリに接続したい場合に必要ですが、Git はこのディレクトリにもアクセスが必要かもしれません（使用する Git のバージョンによる）。

Weblate で使用するディレクトリは、 settings.py で変更できます。Weblate 階層の configuration ディレクトリに設定します。

os.environ["HOME"] = os.path.join(BASE_DIR, "configuration")

注釈

Linux および、その他の UNIX などのシステムでは、ユーザーのホームディレクトリへのパスは /etc/passwd に定義します。多くのディストリビューションでは、WEB コンテンツを提供するユーザー（apache、www-data または wwwrun など）のために、書き込み不可のディレクトリをデフォルトにしています。そのため、別のユーザーの配下で Webrate を実行するか、この設定の変更が必要です。

参考

リポジトリへの接続

テンプレートの読み込み¶

Django には、キャッシュしたテンプレートローダーの使用を推奨します。解析したテンプレートをキャッシュして、リクエストごとに解析を行うことが必要なくなります。次のスニペット（ここでは loaders の設定が重要）を使用した設定方法:

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [
            os.path.join(BASE_DIR, "templates"),
        ],
        "OPTIONS": {
            "context_processors": [
                "django.contrib.auth.context_processors.auth",
                "django.template.context_processors.debug",
                "django.template.context_processors.i18n",
                "django.template.context_processors.request",
                "django.template.context_processors.csrf",
                "django.contrib.messages.context_processors.messages",
                "weblate.trans.context_processors.weblate_context",
            ],
            "loaders": [
                (
                    "django.template.loaders.cached.Loader",
                    [
                        "django.template.loaders.filesystem.Loader",
                        "django.template.loaders.app_directories.Loader",
                    ],
                ),
            ],
        },
    },
]

参考

django.template.loaders.cached.Loader

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

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

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

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

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

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

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

場合によっては、個々のサービスが言語に対して個別の設定を持っています。Apache を使用する場合、 /etc/apache2/envvars にする設定:

export LANG='en_US.UTF-8'
export LC_ALL='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、静的ファイルの提供

実行サーバー¶

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

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

注釈

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

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

注釈

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

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

Web サーバーの実行¶

Weblate の実行は、他の Django ベースのプログラムの実行と同じことです。通常 Django は uWSGI または fcgi として実行されます（次の Web サーバー例の確認）。

テスト目的での、Django に標準搭載された Web サーバーの使用方法:

weblate runserver

警告

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

ヒント

Django に標準搭載されたサーバーは開発専用であるため、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 を提供するようにルールを書き直すことが必要。

参考

クライアントアセットの圧縮、Deploying Django、Deploying 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.7/site-packages/weblate/wsgi.py としてインストールされる）。 Python 検索パスも virtualenv に設定することを忘れないでください（例: uWSGI で virtualenv = /home/user/weblate-env の使用）。

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

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

# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
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 に設定可能）。

# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
[uwsgi]
plugins       = python3
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /home/weblate/weblate-env/lib/python3.7/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

参考

How to use Django with uWSGI

Apache の設定例¶

Weblate で WSGI を使用する場合は、prefork MPM の使用を推奨します。

次は、Weblate を WSGI として実行する設定方法。mod_wsgi を有効にすること（weblate/examples/apache.conf にて設定可能）:

#
# VirtualHost for Weblate
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<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
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py process-group=weblate request-timeout=600
    WSGIPassAuthorization On

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

</VirtualHost>

注釈

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

参考

システム言語とエンコーディング、How to use Django with Apache and mod_wsgi

Apache と Gunicorn の設定例¶

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

#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<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
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<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
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py process-group=weblate request-timeout=600
    WSGIPassAuthorization On

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

</VirtualHost>

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

URL_PREFIX = "/weblate"

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

バージョン 3.2 で追加.

Weblate は Celery を使ってバックグラウンドタスクを処理します。Redis をバックエンドとして使用する一般的な設定例:

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

参考

Redis broker configuration in Celery

開発で使用できる、すべてのタスクを適切に処理する Eager の設定例。Weblate の性能に影響を与えます:

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

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

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

注釈

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

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

システムサービスとして実行する 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 concurency 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"

# Internal Weblate variable to indicate we're running inside Celery
CELERY_WORKER_RUNNING="1"

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

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

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

Weblate には、スケジュール済みのタスク用の設定が標準搭載されています。または、settings.py で追加のタスクを設定できます。Lazy commits の例を確認してください。

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

Celery の状態の監視¶

celery_queues を使用して、Celery タスクキューの現在の長さを確認できます。キューが長くなりすぎると、管理インターフェイスでも設定エラーが発生します。

警告

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

参考

Configuration and defaults、Workers Guide、Daemonization、Monitoring and Management Guide、celery_queues

Weblate の監視¶

Weblate は、例えば Kubernetes を使った簡単な健全性診断で使用する /healthz/ URLを提供します。

エラーレポートの収集¶

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": "master",
    "root": "/absolute/path/to/code/root",
}

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

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

Weblate を別のサーバーに移行するのは非常に簡単ですが、慎重に移行することが必要な少数の場所にデータが保存されています。最適な方法は、移行のために Weblate を停止することです。

データベースの移行¶

データベースのバックエンドによっては、データベースを移行するオプションが複数あります。最も簡単な方法は、1 つのサーバーにデータベースをダンプし、新しいサーバーにインポートすることです。データベースがレプリケーションに対応している場合は、レプリケーションを使用できます。

最良の方法は、データベースの標準機能を使用することです。これらは通常、最も効果的です（例: mysqldump`もしくは :command:`pg_dump）。異なるデータベース間で移行する場合の、Django 管理を使用してデータベースのダンプとインポートを行う唯一の方法:

# Export current data
weblate dumpdata > /tmp/weblate.dump
# Import dump
weblate loaddata /tmp/weblate.dump

VCS リポジトリの移行¶

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

その他の注意事項¶

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

設定手順¶

Weblate のインストール¶

ソフトウェア要件¶

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

その他のサービス¶

Python の依存関係¶

オプションの依存関係¶

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

その他のシステム要件¶

ビルド時の依存関係¶

Pango と Cairo¶

リリース署名の検証¶

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

Weblate のデータベース設定¶

PostgreSQL¶

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

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

MySQL と MariaDB¶

MySQL/MariaDB を使用するための Weblate の設定¶

その他の設定¶

メール送信の設定¶

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

HTTP プロキシ¶

詳細設定¶

データベースの準備¶

本番環境の設定¶

デバッグ モードの無効¶

管理者の適切な設定¶

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

HTTPS を正確に構成する¶

SECURE_HSTS_SECONDS を適切に設定¶

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

キャッシュの有効化¶

アバターのキャッシュ¶

メールの送信設定¶

許可するホストの登録¶

Django の秘密鍵¶

ホーム ディレクトリ¶

テンプレートの読み込み¶

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

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

カスタム認証局の使用¶

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

実行サーバー¶

Web サーバーの実行¶

静的ファイルの提供¶

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

NGINX および uWSGI の設定例¶

Apache の設定例¶

Apache と Gunicorn の設定例¶

パスの下での Weblate の実行¶

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

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

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

Celery の状態の監視¶

Weblate の監視¶

エラー レポートの収集¶

Sentry¶

Rollbar¶

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

データベースの移行¶

VCS リポジトリの移行¶

その他の注意事項¶

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

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

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

デバッグモードの無効¶

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

ホームディレクトリ¶

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

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

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

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

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

エラーレポートの収集¶