導入方法

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.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 (optional for Mercurial repositories support)

https://www.mercurial-scm.org/

phply (optional for PHP 文字列)

https://github.com/viraptor/phply

tesserocr (optional for OCR in Visual context for strings)

https://github.com/sirfz/tesserocr

python-akismet (optional for Spam protection)

https://github.com/Nekmo/python-akismet

ruamel.yamlYAML files 用のオプション)

https://pypi.org/project/ruamel.yaml/

ZeepMicrosoft Terminology Service 用のオプション)

https://docs.python-zeep.org/

aeidonSubtitle files 用のオプション)

https://pypi.org/project/aeidon/

fluent.syntax (optional for Fluent format)

https://projectfluent.org/

ヒント

When installing using pip, you can directly specify desired features when installing:

pip install "Weblate[PHP,Fluent]"

Or you can install Weblate will all optional features:

pip install "Weblate[all]"

Or you can install Weblate without any optional features:

pip install Weblate

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

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]
$ gpg --import wmxth3chu9jfxdxywj1skpmhsj311mzm
  • 鍵サーバーの 1 つから鍵をダウンロードしてインポートする:

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

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

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

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

鍵が信頼されると、警告は発生しない:

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

署名が無効な場合(アーカイブ改ざん時)、鍵が信頼できるかどうかにかかわらず、表示される明確なエラー:

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

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

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

デフォルトの設定では、これらは Weblate のソースと同じ階層に配置されますが、より適切な場所に移動が可能: /var/lib/weblate

Weblate は、これらのディレクトリを自動的に作成を試みます。しかし、アクセス権がない場合は失敗します。

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

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

Weblate のデータベース設定

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

PostgreSQL

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

注釈

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

PostgreSQL でデータベースの作成

通常は、データベースを分けて Weblate を実行することを推奨します。ユーザー アカウントも分ける:

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

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

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

ヒント

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

CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA weblate;

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

MySQL 8.x, MariaDB 10.5.x or newer have reasonable default configuration so that no server tweaking should be necessary and all what is needed can be configured on the client side.

以下は、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_HOSTEMAIL_HOST_PASSWORDEMAIL_USE_TLSEMAIL_USE_SSLEMAIL_HOST_USER および EMAIL_PORT。 名前は一目瞭然ですが、詳細については Django の資料を確認してください。

ヒント

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

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

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

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

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

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.pyweblate/settings.py にコピーし、設定に合わせて変更します。変更した方がいいオプション:

ADMINS

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

ALLOWED_HOSTS

これを設定して、サイトでサービスを提供する予定のホストを一覧表示することが必要です。設定例:

ALLOWED_HOSTS = ["demo.weblate.org"]

ワイルドカードを含めることも可能:

ALLOWED_HOSTS = ["*"]

SESSION_ENGINE

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

Redis をキャッシュとして使用している場合(参照: キャッシュの有効化)、セッションにも Redis を使用すべき:

SESSION_ENGINE = "django.contrib.sessions.backends.cache"

DATABASES

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

DEBUG

すべての本番環境サーバーでこの機能を無効にします。デバッグ モードを有効にすると、Django はユーザーにエラーが発生した場合にバックトレースを表示します。無効にすると、エラーはメールごとに ADMINS (上記参照)に送信されます。

デバッグ モードでは、Django がこの場合でより多くの情報を内部に保存するため、Weblate の速度が低下します。

DEFAULT_FROM_EMAIL

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

SECRET_KEY

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

参考

SECRET_KEY

SERVER_EMAIL

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

参考

SERVER_EMAIL

データベースの準備

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

非対話式でインストールを実行する場合は、weblate migrate --noinput を使用してから、createadmin コマンドを使用して admin ユーザーを作成します。

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

本番環境の設定

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

../_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 を正確に構成する

暗号化された HTTPS プロトコルを使用して Webrate を実行することを強く推奨します。有効にした後に ENABLE_HTTPS に設定が必要:

ENABLE_HTTPS = True

ヒント

HSTS も設定すべきです。詳細については、SSL/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 のデータベース設定 を確認してください。

  • Use adjacent location for running the database server, otherwise the networking performance or reliability might ruin your Weblate experience.

  • Check the database server performance or tweak its configuration, for example using PGTune.

キャッシュの有効化

可能であれば、設定変数 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 のキャッシュに加えて、Weblate はアバターのキャッシュも行います。別のファイル バックアップ キャッシュにすることを推奨します。設定例:

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

メールの送信設定

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

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

注釈

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

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

許可するホストの登録

Django では、サイトの使用を許可するドメイン名のリストを登録するために ALLOWED_HOSTS が必要です。空のままだと、リクエストはブロックされます。

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

ヒント

Docker コンテナでは、WEBLATE_ALLOWED_HOSTS として使用できます。

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 コンテンツを提供するユーザー(apachewww-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",
                    ],
                ),
            ],
        },
    },
]

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

パフォーマンスを最適化するには、メンテナンス タスクをバックグラウンドで実行することを推奨します。これは、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"``を設定します。

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

Apache on Ubuntu uses /etc/apache2/envvars:

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

Apache on CentOS uses /etc/sysconfig/httpd (or /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 イメージでは、この機能はすでに有効です。

実行サーバー

ヒント

In case you are not experienced with services described below, you might want to try Docker を使用したインストール.

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

注釈

サービス間には一部依存関係があります。例えば、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 を提供するようにルールを書き直すことが必要。

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

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

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

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 のように、個別のパッケージとして入手できます。

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>

パスの下での 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 uses Celery to execute regular and background tasks. You are supposed to run a Celery service that will execute these. For example, it is responsible for handling following operations (this list is not complete):

A typical setup using Redis as a backend looks like this:

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

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

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

注釈

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

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

Executing Celery tasks in the wsgi using eager mode

注釈

This will have severe performance impact on the web interface, and will break features depending on regullar trigger (for example commiting pending changes, digest notifications, or backups).

For development, you might want to use eager configuration, which does process all tasks in place:

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

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

You can find current length of the Celery task queues in the 管理画面 or you can use 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 は、例えば Kubernetes を使った簡単な健全性診断で使用する /healthz/ URLを提供します。Docker コンテナには、この URL を使用した健全性診断が標準搭載されています。

For monitoring metrics of Weblate you can use GET /api/metrics/ API endpoint.

エラー レポートの収集

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

Sentry

Weblate には`Sentry <https://sentry.io/>`_ への対応が組み込まれています。使用するには、 settings.pySENTRY_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 を停止することです。

データベースの移行

データベースのバックエンドによっては、データベースを移行するオプションが複数あります。最も簡単な方法は、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 が使用していた可能性のある他のサービスの移動を忘れないでください。