Docker を使用したインストール¶

Docker 化された Weblate デプロイでは、数秒で個人の Weblate インスタンスを起動して実行できます。Weblate の依存関係はすべて含まれています。PostgreSQL が、デフォルトデータベースとして設定され、Valkey がキャッシュバックエンドとして設定されます。

ハードウェア要件¶

Weblate は、最新のハードウェアであれば問題なく動作します。以下は、Weblate を単一のホスト（Weblate、データベース、Web サーバー）で動作させるために必要な最小限の構成:

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

注釈

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

メモリ使用量¶

メモリは多ければ多いほど良い - すべてのレベル（ファイルシステム、データベース、Weblate）でキャッシュとして使用します。数百の翻訳コンポーネントの場合は、少なくとも 4 GB の RAM を推奨します。

ヒント

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

CPU 使用率¶

同時使用者が多い場合、必要な CPU コアの数が増えます。

ストレージ使用量¶

一般的なデータベースストレージの使用量は、ホストサーバーで管理する 100 万語の単語につき約 300 MB 必要です。

リポジトリのクローンに必要なストレージスペースはさまざまですが、Weblate は、シャロークローンを実行してサイズを最小限に抑える努力をします。

ノード数¶

小規模から中規模のサイト（ホストされた単語数が数百万）の場合、Weblate のすべてのコンポーネント（参照: アーキテクチャの概要）を単一ノードで実行できます。

数億件の翻訳対象語を扱う規模に成長する場合は、専用のデータベースノードを用意することを推奨します（参照: Weblate のデータベース設定）。

インストール¶

ヒント

次の例は、docker-compose-plugin がインストール済みの Docker 環境が動作していることを前提としています。手順については、Docker のドキュメントを確認してください。

これにより、HTTP 経由で Weblate を展開するサーバーが作成されるため、HTTPS 終端プロキシの背後に配置することが必要です。HTTPS プロキシで展開することもできます。参照: Let's Encrypt による自動 SSL 証明書の発行。より大規模なセットアップについては、水平方向のスケーリングを確認してください。

weblate-docker リポジトリのクローンの作成:

git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
cd weblate-docker

設定した内容で docker-compose.override.yml ファイルを作成します。全ての環境変数の一覧は Docker 環境変数にあります。

services:
  weblate:
    image: weblate/weblate:latest
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SERVER_EMAIL: weblate@example.com
      WEBLATE_DEFAULT_FROM_EMAIL: weblate@example.com
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for the admin user
      WEBLATE_ADMIN_EMAIL: weblate.admin@example.com
    ports:
    - 80:8080

注釈

WEBLATE_ADMIN_PASSWORD が設定されていない場合は、最初の起動時に表示されるランダムなパスワードで、管理者ユーザーのアカウントが作成されます。

この例では、Weblate はポート 80 をリッスンします。変更する場合は、docker-compose.override.yml ファイルのポートマッピングを編集してください。

Weblate コンテナを起動する:
```
docker compose up
```

配置した Weblate をお楽しみください、それは weblate コンテナのポート 80 からアクセスできます。

参考

管理コマンドの起動

Docker イメージレジストリの選択¶

Weblate コンテナーの公開レジストリ:

Docker Hub、参照: https://hub.docker.com/r/weblate/weblate
GitHub パッケージレジストリ、参照: https://github.com/WeblateOrg/docker/pkgs/container/weblate

注釈

現在、すべての例は Docker Hub からイメージを取得しています。別のレジストリを使用するように設定を変更してください。

Docker イメージタグの選択¶

環境と希望と一致するタグの選択:

タグ名	説明	使用例
`latest`	Weblate 安定版リリース、最新のタグ付きリリースに対応	運用環境でのローリングアップデート
`<YEAR>`	Weblate 安定版のリリース	Rolling updates within a calendar year in a production environment
`<YEAR>.<MONTH>`	Weblate 安定版のリリース	Rolling updates within a monthly release in a production environment
`<YEAR>.<MONTH>.<PATCH>.<BUILD>`	Weblate 安定版のリリース	運用環境での明確な展開
`edge`	Docker コンテナに開発上の変更を加えた Weblate 安定版のリリース（例: 依存関係の更新など）	ステージング環境でのローリングアップデート
`edge-<DATE>-<SHA>`	Docker コンテナに開発上の変更を加えた Weblate 安定版のリリース（例: 依存関係の更新など）	ステージング環境での明確な展開
`bleeding`	Git から開発版の Weblate	今後の Weblate の機能をテストするためのローリングアップデート
`bleeding-<DATE>-<SHA>`	Git から開発版の Weblate	Weblate の新機能をテストするための明確な展開

すべてのイメージは、公開される前に CI によってテストされるため、bleeding 版であっても安全に使用できます。

公開されているタグの完全なリストは、GitHub Packages にあります

HTTPS に対応した Docker コンテナ¶

一般的な展開手順については、インストールを確認してください。この項目では、一般的な展開手順との違いについてのみ説明します。

SSL終端プロキシ¶

SSL は Weblate コンテナの外側で終端できます。連携させるため、Weblate が実際の環境を認識できるように、いくつかのヘッダーをコンテナに渡す必要があります。これらのヘッダーの詳細は、リバースプロキシの背後で実行に記載されています。

Docker コンテナのための Nginx リバースプロキシ設定例。¶

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_read_timeout 3600s;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
}

外部 SSL 終端のための Docker コンテナ環境設定。¶

WEBLATE_ENABLE_HTTPS=1
WEBLATE_IP_PROXY_HEADER=HTTP_X_FORWARDED_FOR

独自の SSL 証明書の使用¶

使用したい独自の SSL 証明書がある場合は、ファイルを Weblate データボリュームに配置するだけです（参照: Docker コンテナのボリューム）。

ssl/fullchain.pem 必要な CA 証明書を含んだ証明書を含む
ssl/privkey.pem 秘密鍵を含む

このファイルは両方とも、docker コンテナを起動したユーザーと同じユーザーが所有者であることが必要です。またファイルマスクは、600 （所有者のユーザーのみが読み書き可能）に設定してください。

さらに、Weblate コンテナはポート 4443 で SSL 接続を受け入れるようになりました。HTTPS のポート転送を docker compose オーバーライドに含めてください。ポート転送の設定方法:

version: '3'
services:
  weblate:
    ports:
      - 80:8080
      - 443:4443

すでに、同じサーバー上の他のサイトをホストしている場合は、ポート 80 と 443 が NGINX などのリバースプロキシによって使用されていることがあります。下記は、NGINX から Docker コンテナに HTTPS 接続を渡すために使用可能な構成方法:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name <SITE_URL>;
    ssl_certificate /etc/letsencrypt/live/<SITE>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<SITE>/privkey.pem;

    location / {
            proxy_set_header HOST $host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Host $server_name;
            proxy_pass https://127.0.0.1:<EXPOSED_DOCKER_PORT>;
    }
}

<SITE_URL>、<SITE> および <EXPOSED_DOCKER_PORT> は、実際に使用する環境の値に書き換えてください。

Let's Encrypt による自動 SSL 証明書の発行¶

公開サーバーで、Let’s Encrypt の自動生成 SSL 証明書を使用する場合は、追加の Docker コンテナにリバース HTTPS プロキシの追加が必要です。そのため、https-portal を使用します。これは、docker-compose-https.yml ファイルで使用されます。次に、設定した内容で docker-compose-https.override.yml ファイルを作成します。

version: '3'
services:
  weblate:
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for admin user
  https-portal:
    environment:
      DOMAINS: 'weblate.example.com -> http://weblate:8080'

docker compose を呼び出すときは常に、両方のファイルを渡すことが必要です。その後、次を実行:

docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml up

Docker コンテナーのアップグレード¶

通常は、Weblate コンテナのみを更新し、PostgreSQL コンテナは現在のバージョンを維持してください。PostgreSQL のアップグレードは非常に面倒であり、多くの場合あまり効果は期待できません。

Weblate コンテナのみの更新方法。既存の docker-compose を使用し、最新のイメージを取得して再起動する手順:

# Fetch latest versions of the images
docker compose pull
# Stop and destroy the containers
docker compose down
# Spawn new containers in the background
docker compose up -d
# Follow the logs during upgrade
docker compose logs -f

Weblate データベースは、初回の起動時に自動的に移行し、追加の手動操作は必要ありません。

注釈

Direct upgrades are only supported for releases from the current or previous calendar year. If you need to upgrade from an older release, upgrade first to an intermediate version listed in バージョン別の手順.

docker-compose リポジトリを更新したくなるかもしれませんが、ほとんどの場合は必要ありません。PostgreSQL サーバのアップグレードについては、PostgreSQL コンテナのアップグレードを参照してください。

PostgreSQL コンテナのアップグレード¶

注釈

PostgreSQL 18 では、コンテナ内のデフォルトデータディレクトリが変更されました。従来の一般的な構成では /var/lib/postgresql/data にボリュームをマウントしていましたが、PostgreSQL 18 ではデフォルトが /var/lib/postgresql に変更されました。

古いバージョンからアップグレードする場合は、Docker 設定でマウント先を新しいパスに更新するか、旧パスのまま PGDATA を設定してください。

PGDATA を設定せずに旧マウント先をそのまま使用すると、PostgreSQL が永続化されていない場所にデータを書き込む可能性があります。

詳細は PGDATA のドキュメントを確認してください。

PostgreSQL コンテナは、バージョンの自動アップグレードには対応していません。手動でアップグレードしてください。次の手順は、アップグレードの方法の中の 1 つです。

参考

https://github.com/docker-library/postgres/issues/37

Weblate コンテナの停止:
```
docker compose stop weblate cache
```

データベースのバックアップ:

docker compose exec database pg_dumpall --clean --if-exists --username weblate > backup.sql

データベースコンテナの停止:
```
docker compose stop database
```
PostgreSQL ボリュームの削除:
```
docker compose rm -v database
docker volume remove weblate-docker_postgres-data
```
ヒント

ボリューム名には、Docker Compose プロジェクトの名前が含まれます。デフォルトのディレクトリ名は、このドキュメントでは weblate-docker です。
新しい PostgreSQL のバージョンを使用するように docker-compose.yml を編集します。
データベースコンテナの起動:
```
docker compose up -d database
```
データベースをバックアップから復元:
```
cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate
```
ヒント

データベース名が POSTGRES_DB と一致していることを確認してください。
（オプション）Weblate ユーザーのパスワードを更新させる。これは、パスワードの保存方法が変更されたため、PostgreSQL 14 または 15 に移行するときに必要となる場合の方法:
```
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
```
ヒント

データベース名が POSTGRES_DB と一致していることを確認してください。
残りのコンテナをすべて起動:
```
docker compose up -d
```

管理者としてサインイン¶

コンテナの設定後、WEBLATE_ADMIN_PASSWORD に設定したパスワードを使用して、admin ユーザーとしてサインインできます。設定していない場合は、初回の起動時にランダムなパスワードが生成されます。

admin パスワードをリセットするには、WEBLATE_ADMIN_PASSWORD に新しいパスワードを設定してコンテナを再起動します。

参考

WEBLATE_ADMIN_PASSWORD
WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

プロセス数とメモリ消費量¶

WSGI と Celery のワーカープロセスの数は、CPU の数に基づいて自動的に決定されます。これは、ほとんどのクラウド仮想マシンで適切に機能します。これは通常、CPUが少なく、メモリの量が多いためです。

CPU のコア数が多く、メモリ不足の問題が発生する場合、ワーカーの数を減らしてみてください。ワーカー数の設定例:

environment:
  WEBLATE_WORKERS: 2

個々のワーカーのカテゴリーを詳細に設定する方法:

environment:
  WEB_WORKERS: 4
  CELERY_MAIN_OPTIONS: --concurrency 2
  CELERY_NOTIFY_OPTIONS: --concurrency 1
  CELERY_TRANSLATE_OPTIONS: --concurrency 1

Celery プロセスを 1 つだけ実行して、メモリ使用量をさらに削減する方法:

environment:
  CELERY_SINGLE_PROCESS: 1

参考

WEBLATE_WORKERS
CELERY_MAIN_OPTIONS
CELERY_NOTIFY_OPTIONS
CELERY_MEMORY_OPTIONS
CELERY_TRANSLATE_OPTIONS
CELERY_BACKUP_OPTIONS
CELERY_BEAT_OPTIONS
CELERY_SINGLE_PROCESS
WEB_WORKERS

水平方向のスケーリング¶

Added in version 4.6.

複数の Weblate コンテナを実行して、サービスを水平方向にスケーリングできます。/app/data ボリュームはすべてのコンテナで共有することが必要であるため、GlusterFS などのクラスタファイルシステムを使用してください。/app/cache ボリュームは、コンテナごとに別々にしてください。

各 Weblate コンテナには、WEBLATE_SERVICE 環境変数を使用して役割が定義されています。一部のサービスはクラスター内で 1 回だけ実行すべきで、サービスの順序も重要であるため、ドキュメントに注意して従ってください。

設定例は、docker-compose リポジトリに docker-compose-split.yml として記載されています。

Docker 環境変数¶

Weblate の設定の多くは、以下の環境変数を使用して Docker コンテナに設定できます。

Docker 環境変数で公開されていない設定を定義する場合は、環境変数以外の設定を確認してください。

シークレットの受け渡し¶

Added in version 5.0.

Weblate コンテナは、ファイルでシークレットを受け渡すことに対応しています。これを使用するには、環境変数に _FILE 接尾辞を付加し、シークレットファイルを Docker 経由で受け渡します。

関連する docker-compose.yml の場合:

services:
   weblate:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password
   database:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password


secrets:
   db_password:
     file: db_password.txt

参考

Docker Compose でシークレットを使用する方法

一般的な設定¶

WEBLATE_DEBUG¶

DEBUG を使用して Django デバッグモードを設定します。

例:

environment:
  WEBLATE_DEBUG: 1

参考

デバッグモードの無効化

WEBLATE_LOGLEVEL¶

ログの詳細度を設定します。より詳細なログを取得するには、これを DEBUG に設定してください。

WEBLATE_DEBUG が無効の場合は、デフォルトで INFO になり、デバッグモードが有効の場合は DEBUG となります。

よりサイレントなロギングを行うには、ERROR または WARNING を使用します。

WEBLATE_LOGLEVEL_DATABASE¶: データベースクエリの冗長性のログの設定します。

WEBLATE_LOG_GELF_HOST¶: Added in version 5.9.

GELF TCP 接続を使用してリモートロギングを設定します。Graylog との連携に使用できます。

WEBLATE_LOG_GELF_PORT¶: Added in version 5.9.

WEBLATE_LOG_GELF_HOST にカスタムポートを使用します。デフォルトは 12201 です。

WEBLATE_SITE_TITLE¶: すべてのページのヘッダーに表示される、サイトタイトルを変更します。

WEBLATE_SITE_DOMAIN¶

サイトのドメインを設定します。このパラメーターは必須です。

標準ではないポートを使用する場合、ポートを指定してください。

例:

environment:
  WEBLATE_SITE_DOMAIN: example.com:8080

参考

WEBLATE_ADMIN_NAME¶

WEBLATE_ADMIN_EMAIL¶

サイト管理者の名前とメールアドレスを設定します。これは、ADMINS 設定と、admin ユーザーの作成の両方に使用されます（詳細については、WEBLATE_ADMIN_PASSWORD を確認してください）。

例:

environment:
  WEBLATE_ADMIN_NAME: Weblate admin
  WEBLATE_ADMIN_EMAIL: noreply@example.com

参考

WEBLATE_ADMIN_PASSWORD¶

管理者ユーザーのパスワードを設定します。

管理者パスワードが設定されておらず、管理者ユーザーも存在しない場合は、最初のコンテナ起動時に表示されるランダムなパスワードで作成されます。
管理者パスワードが設定されておらず、管理者ユーザーが存在する場合、管理者パスワードは設定されません。
管理者パスワードが設定されている場合、管理者ユーザーは、コンテナが起動するたびに WEBLATE_ADMIN_PASSWORD、WEBLATE_ADMIN_NAME および WEBLATE_ADMIN_EMAIL に設定されます。

警告

設定ファイルにパスワードを格納すると、セキュリティ上のリスクがあります。この変数は、初期設定（または Weblate の初期起動時にランダムパスワードを生成させる）またはパスワードの回復にのみ使用してください。

参考

管理者としてサインイン
シークレットの受け渡し
WEBLATE_ADMIN_PASSWORD
WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

WEBLATE_ADMIN_NOTIFY_ERROR¶

サーバーエラーが発生したときに、管理者にメールを送信するかどうか。デフォルトでは有効。

Sentry やRollbar のような他のエラー収集ツールを使うことを検討し、可能ならこれを無効にしてください。

参考

WEBLATE_SERVER_EMAIL¶

エラーメッセージ送信元のメールアドレス。

参考

WEBLATE_DEFAULT_FROM_EMAIL¶

送信用のメールアドレスを設定します。

参考

WEBLATE_ADMINS_CONTACT¶: ADMINS_CONTACT の設定。

WEBLATE_CONTACT_FORM¶: 問い合わせフォームの動作を設定します。参照: CONTACT_FORM。

WEBLATE_ALLOWED_HOSTS¶

ALLOWED_HOSTS を使用して、許可する HTTP ホスト名を設定します。

デフォルトは * で、すべてのホスト名を許可します。

例:

environment:
  WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com

参考

WEBLATE_REGISTRATION_OPEN¶

REGISTRATION_OPEN を 0 か 1 に切り替えることによって、登録を公開するかどうかを設定します。

例:

environment:
  WEBLATE_REGISTRATION_OPEN: 0

WEBLATE_REGISTRATION_CAPTCHA¶

Added in version 5.10.

登録やその他の未認証操作で CAPTCHA を使用するかどうかを設定します。参照: REGISTRATION_CAPTCHA。

例:

environment:
  WEBLATE_REGISTRATION_CAPTCHA: 0

WEBLATE_REGISTRATION_ALLOW_BACKENDS¶

REGISTRATION_ALLOW_BACKENDS を使用して、新しいアカウントの作成に使用できる認証方式を設定します。

例:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
  WEBLATE_REGISTRATION_ALLOW_BACKENDS: azuread-oauth2,azuread-tenant-oauth2

WEBLATE_REGISTRATION_REBIND¶: Added in version 4.16.

REGISTRATION_REBIND を設定します。

WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS¶

Added in version 5.16.1.

REGISTRATION_ALLOW_DISPOSABLE_EMAILS を設定します。

例:

environment:
  WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS: 1

WEBLATE_PROJECT_WEB_RESTRICT_PRIVATE¶

Added in version 5.17.

PROJECT_WEB_RESTRICT_PRIVATE を設定します。

デフォルトでは有効です。

WEBLATE_PROJECT_WEB_RESTRICT_ALLOWLIST¶

Added in version 5.17.

Configures PROJECT_WEB_RESTRICT_ALLOWLIST.

Expects a comma-separated list of trusted project slugs.

WEBLATE_WEBHOOK_RESTRICT_PRIVATE¶

Added in version 5.17.

WEBHOOK_RESTRICT_PRIVATE を設定します。

デフォルトでは有効です。

WEBLATE_WEBHOOK_PRIVATE_ALLOWLIST¶

Added in version 5.17.

WEBHOOK_PRIVATE_ALLOWLIST を設定します。

Expects a comma-separated list of trusted hostnames or domains.

WEBLATE_ASSET_RESTRICT_PRIVATE¶

Added in version 2025.5.

Configures ASSET_RESTRICT_PRIVATE.

デフォルトでは有効です。

WEBLATE_ASSET_PRIVATE_ALLOWLIST¶

Added in version 2025.5.

Configures ASSET_PRIVATE_ALLOWLIST.

Expects a comma-separated list of trusted hostnames or domains.

WEBLATE_TIME_ZONE¶

Weblate で使用するタイムゾーンを設定します。参照: TIME_ZONE。

注釈

Docker コンテナー自体のタイムゾーンを変更するには、環境変数 TZ を使用します。

例:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague

WEBLATE_ENABLE_HTTPS¶

Weblate が、リバース HTTPS プロキシの背後で動作している前提で、メールや API リンクで HTTPS を使用したり、Cookie にセキュリティフラグを設定します。

ヒント

考えられる問題点については、ENABLE_HTTPS ドキュメントを確認してください。

注釈

これにより、Weblate コンテナが HTTPS 接続を受け入れるようにはなりません。 HTTPS 接続には設定が必要です。例については、HTTPS に対応した Docker コンテナ確認してください。

例:

environment:
  WEBLATE_ENABLE_HTTPS: 1

参考

WEBLATE_NGINX_IPV6¶

Added in version 5.17.

Controls whether the bundled NGINX listens on IPv6 addresses.

対応する値：

auto to enable IPv6 listeners only when IPv6 is available in the container runtime. This is the default.
on to always enable IPv6 listeners.
off to disable IPv6 listeners.

例:

environment:
  WEBLATE_NGINX_IPV6: auto

WEBLATE_IP_PROXY_HEADER¶

Weblate が、どのような HTTP ヘッダーからも IP アドレスを取得できるようにします。これは、Weblate コンテナの前段階でリバースプロキシを使用する場合に使用します。

IP_BEHIND_REVERSE_PROXY を有効にし、IP_PROXY_HEADER を設定します。

注釈

形式は Django に準拠させてください。Django が生の HTTP ヘッダー名を transforms する例:

すべての文字を大文字に変換する
ハイフンをアンダースコアに置き換える
HTTP_ 接頭辞の追加

したがって、X-Forwarded-For は HTTP_X_FORWARDED_FOR にマッピングされます。

例:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR

WEBLATE_IP_PROXY_OFFSET¶: Added in version 5.0.1.

IP_PROXY_OFFSET の設定。

WEBLATE_USE_X_FORWARDED_PORT¶: Added in version 5.0.1.

このブール値は、SERVER_PORT META 変数の代わりに X-Forwarded-Port ヘッダーを使用するかどうかを指定します。このヘッダーを設定するプロキシが使用されている場合にのみ有効にしてください。

参考

USE_X_FORWARDED_PORT

注釈

これは論理値の設定です（"true" または "false" を使用する）。

WEBLATE_SECURE_PROXY_SSL_HEADER¶

A tuple representing an HTTP header/value combination that signifies a request is secure. This is needed when Weblate is running behind a reverse proxy doing SSL termination which does not pass standard HTTPS headers.

例:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

参考

WEBLATE_REQUIRE_LOGIN¶

REQUIRE_LOGIN を有効にして、Weblate 全体に認証を強制します。

例:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

WEBLATE_LEGAL_INTEGRATION¶

Enables the 法務モジュール module in Docker deployments. By default, the integration is disabled; leave this variable unset or empty to disable it.

対応する値：

tos-confirm to enable the legal module and enforce terms of service confirmation during social authentication and for signed-in users.
wllegal to enable the same integration and additionally load the hosted legal document templates from wllegal. These templates are used by services operated by Weblate s.r.o. and are not intended for general use.

To provide your own legal documents in Docker, override the templates in /app/data/python/customize/templates/legal/documents, see ロゴおよびその他の静的ファイルの変更.

例:

environment:
  WEBLATE_LEGAL_INTEGRATION: tos-confirm

参考

法務モジュール
ロゴおよびその他の静的ファイルの変更

WEBLATE_PUBLIC_ENGAGE¶: PUBLIC_ENGAGE を有効にします。

WEBLATE_GOOGLE_ANALYTICS_ID¶: GOOGLE_ANALYTICS_ID を変更して、Google Analytics の ID を設定します。

WEBLATE_DEFAULT_PULL_MESSAGE¶: DEFAULT_PULL_MESSAGE を変更して、API を利用したプルリクエストのデフォルトのタイトルとメッセージを設定します。

参考

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES¶: 言語簡略化ポリシーを設定します。参照: SIMPLIFY_LANGUAGES。

WEBLATE_HIDE_SHARED_GLOSSARY_COMPONENTS¶: 共有された用語集コンポーネントを他のプロジェクトで非表示にします。参照: HIDE_SHARED_GLOSSARY_COMPONENTS。

WEBLATE_DEFAULT_ACCESS_CONTROL¶: 新規プロジェクトのデフォルトアクセス制御を設定します。参照: DEFAULT_ACCESS_CONTROL。

WEBLATE_DEFAULT_TRANSLATION_REVIEW¶: Added in version 5.16.

査読の有効化のデフォルト値を設定します。初期設定は無効です。

WEBLATE_DEFAULT_SOURCE_REVIEW¶: Added in version 5.16.

原文の査読の有効化のデフォルト値を設定します。初期設定は無効です。

WEBLATE_DEFAULT_RESTRICTED_COMPONENT¶: 新しいコンポーネントのアクセス制限のデフォルト値を設定します。参照: DEFAULT_RESTRICTED_COMPONENT。

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION¶: 新しいコンポーネントの翻訳の自動反映の有効化のデフォルト値を設定します。参照: DEFAULT_TRANSLATION_PROPAGATION。

WEBLATE_DEFAULT_COMMITER_EMAIL¶: DEFAULT_COMMITER_EMAIL を設定します。

WEBLATE_DEFAULT_COMMITER_NAME¶: DEFAULT_COMMITER_NAME を設定します。

WEBLATE_DEFAULT_SHARED_TM¶: DEFAULT_SHARED_TM を設定します。

WEBLATE_DEFAULT_AUTOCLEAN_TM¶: DEFAULT_AUTOCLEAN_TM を設定します。

WEBLATE_COMMIT_PENDING_HOURS¶: 新しいコンポーネントに対するコミットするまでの経過時間のデフォルト値を設定します。参照: COMMIT_PENDING_HOURS。

WEBLATE_GPG_IDENTITY¶: コミットの GPG 署名を設定します。参照: WEBLATE_GPG_IDENTITY。

参考

GnuPG を使用した Git コミットの署名

WEBLATE_URL_PREFIX¶: Weblate が動作している URL の接頭辞を設定します。参照: URL_PREFIX。

WEBLATE_STATIC_URL¶: Configures URL prefix for static files served from CACHE_DIR.

WEBLATE_SILENCED_SYSTEM_CHECKS¶: 非表示にする検査項目を設定します。詳細については、SILENCED_SYSTEM_CHECKS を確認してください。

WEBLATE_CSP_SCRIPT_SRC¶

WEBLATE_CSP_IMG_SRC¶

WEBLATE_CSP_CONNECT_SRC¶

WEBLATE_CSP_STYLE_SRC¶

WEBLATE_CSP_FONT_SRC¶

WEBLATE_CSP_FORM_SRC¶

Content-Security-Policy HTTP ヘッダーの変更を可能にします。

参考

WEBLATE_LICENSE_FILTER¶: LICENSE_FILTER の設定。

WEBLATE_LICENSE_REQUIRED¶: LICENSE_REQUIRED を設定します。

WEBLATE_WEBSITE_REQUIRED¶: WEBSITE_REQUIRED を設定します。

WEBLATE_VERSION_DISPLAY¶: Configures VERSION_DISPLAY.

WEBLATE_HIDE_VERSION¶: HIDE_VERSION を設定します。

WEBLATE_BASIC_LANGUAGES¶: BASIC_LANGUAGES を設定します。

WEBLATE_DEFAULT_AUTO_WATCH¶: DEFAULT_AUTO_WATCH を設定します。

WEBLATE_RATELIMIT_ATTEMPTS¶

WEBLATE_RATELIMIT_LOCKOUT¶

WEBLATE_RATELIMIT_WINDOW¶

Added in version 4.6.

接続制限を設定します。

ヒント

接続制限の範囲を設定できます。そのため、接続制限に記載のある設定のいずれかに、WEBLATE_ 接頭辞を追加します。

参考

WEBLATE_API_RATELIMIT_ANON¶

WEBLATE_API_RATELIMIT_USER¶: Added in version 4.11.

API リクエストの接続制限の設定。デフォルトでは、匿名ユーザーの場合は 100 リクエスト / 日、認証済みユーザーの場合は 5000 リクエスト / 時間 に制限しています。

参考

API 接続制限

WEBLATE_ENABLE_HOOKS¶: Added in version 4.13.

ENABLE_HOOKS を設定します。

WEBLATE_ENABLE_AVATARS¶: Added in version 4.6.1.

ENABLE_AVATARS を設定します。

WEBLATE_AVATAR_URL_PREFIX¶: Added in version 4.15.

AVATAR_URL_PREFIX の設定。

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶: Added in version 4.9.

LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH を設定します。

WEBLATE_SSH_EXTRA_ARGS¶: Added in version 4.9.

SSH_EXTRA_ARGS を設定します。

WEBLATE_BORG_EXTRA_ARGS¶

Added in version 4.9.

BORG_EXTRA_ARGS をコンマ区切りの引数リストとして設定します。

例:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/

WEBLATE_ENABLE_SHARING¶: Added in version 4.14.1.

ENABLE_SHARING を設定します。

WEBLATE_SUPPORT_STATUS_CHECK¶: Added in version 5.5.

SUPPORT_STATUS_CHECK の設定。

WEBLATE_EXTRA_HTML_HEAD¶: Added in version 4.15.

EXTRA_HTML_HEAD を設定します。

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE¶: Added in version 4.15.

PRIVATE_COMMIT_EMAIL_TEMPLATE を設定します。

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN¶: Added in version 4.15.

PRIVATE_COMMIT_EMAIL_OPT_IN を設定します。

WEBLATE_PRIVATE_COMMIT_NAME_TEMPLATE¶: Added in version 5.16.

PRIVATE_COMMIT_NAME_TEMPLATE を設定します。

WEBLATE_PRIVATE_COMMIT_NAME_OPT_IN¶: Added in version 5.16.

PRIVATE_COMMIT_NAME_OPT_IN を設定します。

WEBLATE_UNUSED_ALERT_DAYS¶: Added in version 4.17.

UNUSED_ALERT_DAYS の設定。

WEBLATE_UPDATE_LANGUAGES¶: Added in version 4.3.2.

UPDATE_LANGUAGES を設定します。

WEBLATE_VCS_ALLOW_HOSTS¶: Added in version 5.15.

VCS_ALLOW_HOSTS を設定します。

WEBLATE_VCS_ALLOW_SCHEMES¶: Added in version 5.15.

VCS_ALLOW_SCHEMES を設定します。

WEBLATE_VCS_RESTRICT_PRIVATE¶: Added in version 5.17.

Configures VCS_RESTRICT_PRIVATE.

WEBLATE_VCS_CLONE_DEPTH¶: Added in version 5.4.

VCS_CLONE_DEPTH の設定。

WEBLATE_VCS_API_DELAY¶: Added in version 5.4.

VCS_API_DELAY の設定。

WEBLATE_VCS_API_TIMEOUT¶: Added in version 5.15.

VCS_API_TIMEOUT の設定。

WEBLATE_CORS_ALLOWED_ORIGINS¶

Added in version 4.16.

指定したオリジンからの API への CORS 要求を許可します。

例:

environment:
  WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org

WEBLATE_CORS_ALLOW_ALL_ORIGINS¶: Added in version 5.6.1: すべてのオリジンからの API への CORS リクエストを許可します。

WEBLATE_WEBSITE_ALERTS_ENABLED¶: Added in version 5.17.

WEBSITE_ALERTS_ENABLED を設定します。

CLIENT_MAX_BODY_SIZE¶

Added in version 4.16.3.

内蔵の Web サーバーにアップロードできるファイルの最大サイズを設定します。

environment:
    CLIENT_MAX_BODY_SIZE: 200m

ヒント

この変数は、Let's Encrypt による自動 SSL 証明書の発行で使用されるサードパーティのコンテナーと共有されるため、意図的に WEBLATE_ 接頭辞がありません。

WEBLATE_TRANSLATION_UPLOAD_MAX_SIZE¶

Configures TRANSLATION_UPLOAD_MAX_SIZE.

The value is in bytes.

WEBLATE_COMPONENT_ZIP_UPLOAD_MAX_SIZE¶

Configures COMPONENT_ZIP_UPLOAD_MAX_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_UPLOAD_MAX_SIZE¶

Configures PROJECT_BACKUP_UPLOAD_MAX_SIZE.

The value is in bytes. Make sure CLIENT_MAX_BODY_SIZE is also large enough for uploaded backup files.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_MEMBERS¶: Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_MEMBERS.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE¶

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE¶

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE¶

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO¶: Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO.

サイトの認証情報をホストするコード¶

In the Docker container, the code hosting credentials can be configured either in separate variables or using a Python dictionary to set them at once. The following examples are for GitHub プルリクエスト, but apply to all バージョン管理との連携 with appropriately changed variable names.

重要

すべての環境変数名には、WEBLATE_ の接頭辞を含める必要があります。たとえば、GitHub の認証情報を設定するには、GITHUB_USERNAME ではなく、WEBLATE_GITHUB_USERNAME を使用してください。これは、プルリクエストの設定であろうと、その他の VCS 連携の設定であろうと適用されます。

GitHub のプルリクエストの設定例:

WEBLATE_GITHUB_USERNAME=api-user
WEBLATE_GITHUB_TOKEN=api-token
WEBLATE_GITHUB_HOST=api.github.com

しよう例:

GITHUB_CREDENTIALS = {
    "api.github.com": {
        "username": "api-user",
        "token": "api-token",
    }
}

または、Python 辞書を文字列として提供する方法:

WEBLATE_GITHUB_CREDENTIALS='{ "api.github.com": { "username": "api-user", "token": "api-token", } }'

または、Python 辞書を含むファイルへのパス:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

WEBLATE_GITHUB_USERNAME¶

WEBLATE_GITHUB_TOKEN¶

WEBLATE_GITHUB_HOST¶

WEBLATE_GITHUB_CREDENTIALS¶: Configures GitHub プルリクエスト by changing GITHUB_CREDENTIALS.

参考

Configuring code hosting credentials in Docker

WEBLATE_GITLAB_USERNAME¶

WEBLATE_GITLAB_TOKEN¶

WEBLATE_GITLAB_HOST¶

WEBLATE_GITLAB_CREDENTIALS¶: Configures GitLab マージリクエスト by changing GITLAB_CREDENTIALS.

参考

Configuring code hosting credentials in Docker

WEBLATE_GITEA_USERNAME¶

WEBLATE_GITEA_TOKEN¶

WEBLATE_GITEA_HOST¶

WEBLATE_GITEA_CREDENTIALS¶: Configures Gitea プルリクエスト by changing GITEA_CREDENTIALS.

参考

Configuring code hosting credentials in Docker

WEBLATE_PAGURE_USERNAME¶

WEBLATE_PAGURE_TOKEN¶

WEBLATE_PAGURE_HOST¶

WEBLATE_PAGURE_CREDENTIALS¶: Configures Pagure マージリクエスト by changing PAGURE_CREDENTIALS.

参考

Configuring code hosting credentials in Docker

WEBLATE_BITBUCKETSERVER_USERNAME¶

WEBLATE_BITBUCKETSERVER_TOKEN¶

WEBLATE_BITBUCKETSERVER_HOST¶

WEBLATE_BITBUCKETSERVER_CREDENTIALS¶: Configures Bitbucket Data Center のプルリクエスト by changing BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME¶

WEBLATE_BITBUCKETCLOUD_WORKSPACE¶

WEBLATE_BITBUCKETCLOUD_TOKEN¶

WEBLATE_BITBUCKETCLOUD_HOST¶

WEBLATE_BITBUCKETCLOUD_CREDENTIALS¶: Configures Bitbucket Cloud のプルリクエスト by changing BITBUCKETCLOUD_CREDENTIALS.

参考

Configuring code hosting credentials in Docker

WEBLATE_AZURE_DEVOPS_USERNAME¶

WEBLATE_AZURE_DEVOPS_ORGANIZATION¶

WEBLATE_AZURE_DEVOPS_TOKEN¶

WEBLATE_AZURE_DEVOPS_HOST¶

WEBLATE_AZURE_DEVOPS_CREDENTIALS¶: Configures Azure DevOps プルリクエスト by changing AZURE_DEVOPS_CREDENTIALS.

参考

Configuring code hosting credentials in Docker

自動提案の設定¶

バージョン 4.13 で変更: 自動提案サービスは、ユーザーインタフェースから設定するように変更されました。参照: 自動提案。

既存の環境変数は、Weblate 4.13 への移行時にインポートされますが、変更してもそれ以上の影響はありません。

認証設定¶

ヒント

Eメールベースの認証は、WEBLATE_NO_EMAIL_AUTH によって無効化されない限り、有効になります。

LDAP¶

WEBLATE_AUTH_LDAP_SERVER_URI¶

WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE¶

WEBLATE_AUTH_LDAP_USER_ATTR_MAP¶

WEBLATE_AUTH_LDAP_BIND_DN¶

WEBLATE_AUTH_LDAP_BIND_PASSWORD¶

WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS¶

WEBLATE_AUTH_LDAP_USER_SEARCH¶

WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER¶

LDAP 認証の設定。

直接バインドの例:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE: uid=%(user)s,ou=People,dc=example,dc=net
  # map weblate 'full_name' to ldap 'name' and weblate 'email' attribute to 'mail' ldap attribute.
  # another example that can be used with OpenLDAP: 'full_name:cn,email:mail'
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail

検索とバインドの例:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com

ユニオン検索とバインドの例:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH_UNION: ou=users,dc=example,dc=com|ou=otherusers,dc=example,dc=com

Active Directory に対する検索とバインドの例:

environment:
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS: 0
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER: (sAMAccountName=%(user)s)

参考

シークレットの受け渡し
LDAP 認証

GitHub¶

WEBLATE_SOCIAL_AUTH_GITHUB_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_NAME¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_ID¶: GitHub 認証を有効にします。

GitHub エンタープライズ版¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE¶: GitHub EE 認証を有効にします。

Bitbucket¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET¶: Bitbucket 認証を有効にします。

Facebook¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶: Facebook OAuth 2 を有効にします。

Google¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS¶: Google OAuth 2 を有効にします。

GitLab¶

WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶: GitLab OAuth 2 を有効にします。

Gitea¶

WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶

WEBLATE_SOCIAL_AUTH_GITEA_KEY¶

WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶: Gitea 認証を有効にします。

Microsoft Entra ID¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶: Enables Microsoft Entra ID authentication, see Microsoft Entra ID.

Microsoft Entra ID with Tenant support¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID¶: Enables Microsoft Entra ID authentication with Tenant support, see Microsoft Entra ID.

Keycloak¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_KEY¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_SECRET¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ALGORITHM¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_TITLE¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_IMAGE¶: Keycloak 認証を有効にします。参照: Keycloak - Open Source Red Hat SSO。

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ID_KEY¶

Added in version 5.17.

Configures which claim is used as the unique user identifier from Keycloak. Defaults to email.

ヒント

Keycloak がサードパーティ IDP を抽象化するように設定されている場合、サードパーティ IDP ドメインに対して WEBLATE_CSP_FORM_SRC を設定する必要があります。

Keycloak が Microsoft の認証を利用している場合の例。¶

environment:
  WEBLATE_CSP_FORM_SRC: login.microsoftonline.com

Linux ベンダー¶

Linux ベンダー認証サービスを使用した認証を有効にするには、以下の変数を指定の値に設定します。

WEBLATE_SOCIAL_AUTH_FEDORA¶

WEBLATE_SOCIAL_AUTH_OPENSUSE¶

WEBLATE_SOCIAL_AUTH_OPENINFRA¶

WEBLATE_SOCIAL_AUTH_UBUNTU¶

Slack¶

WEBLATE_SOCIAL_AUTH_SLACK_KEY¶

WEBLATE_SOCIAL_AUTH_SLACK_SECRET¶: Slack 認証を有効にします。参照: Slack。

OpenID Connect¶

Added in version 4.13-1.

WEBLATE_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT¶

WEBLATE_SOCIAL_AUTH_OIDC_KEY¶

WEBLATE_SOCIAL_AUTH_OIDC_SECRET¶

WEBLATE_SOCIAL_AUTH_OIDC_USERNAME_KEY¶

WEBLATE_SOCIAL_AUTH_OIDC_TITLE¶

WEBLATE_SOCIAL_AUTH_OIDC_IMAGE¶: 一般的な OpenID Connect との連携を設定します。

参考

OIDC (OpenID Connect)

Fedora OpenID Connect¶

Added in version 5.15.

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_KEY¶

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_SECRET¶: Fedora OpenID Connect の統合を設定します。

参考

Fedora

SAML¶

自己署名 SAML 鍵は、最初のコンテナ起動時に自動的に生成されます。独自の鍵を使用するには、証明書と秘密鍵を /app/data/ssl/saml.crt と /app/data/ssl/saml.key に配置します。

WEBLATE_SAML_IDP_ENTITY_ID¶

WEBLATE_SAML_IDP_URL¶

WEBLATE_SAML_IDP_X509CERT¶

WEBLATE_SAML_IDP_IMAGE¶

WEBLATE_SAML_IDP_TITLE¶: SAML ID プロバイダーを設定します。参照: SAML 認証。

WEBLATE_SAML_ID_ATTR_FULL_NAME¶

WEBLATE_SAML_ID_ATTR_FIRST_NAME¶

WEBLATE_SAML_ID_ATTR_LAST_NAME¶

WEBLATE_SAML_ID_ATTR_USERNAME¶

WEBLATE_SAML_ID_ATTR_EMAIL¶

WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID¶: Added in version 4.18.

SAML 属性のマッピング。

その他の認証設定¶

WEBLATE_NO_EMAIL_AUTH¶: 値を設定すると、メール認証を無効にします。参照: パスワード認証の無効化。

WEBLATE_MIN_PASSWORD_SCORE¶

zxcvbn パスワード強度評価ツールによって評価された最小パスワードスコア。デフォルトは 3 で、強度検査を無効にするには 0 に設定します。

参考

PostgreSQL データベースの設定¶

データベースは docker-compose.yml によって作成されるので、この設定は、Weblate と PostgreSQL の両方のコンテナに影響を与えます。

参考

Weblate のデータベース設定

POSTGRES_PASSWORD¶: PostgreSQL のパスワード。

参考

シークレットの受け渡し

POSTGRES_USER¶: PostgreSQL ユーザー名。

POSTGRES_DB¶: PostgreSQL データベース名。

POSTGRES_HOST¶: PostgreSQL サーバーのホスト名または IP アドレス。デフォルトは database です。

POSTGRES_PORT¶: PostgreSQL サーバーのポート。デフォルトは none です（デフォルト値を使用する）。

POSTGRES_SSL_MODE¶: PostgreSQL がサーバーへの接続で SSL を処理する方法を設定します。可能な選択肢については、 SSL Mode Descriptions を確認してください。

POSTGRES_ALTER_ROLE¶

データベースの移行中に変更する PostgreSQL ロールの名前を設定します。参照: Weblate で PostgreSQL を使用するための設定。

デフォルトは、POSTGRES_USER です。

POSTGRES_CONN_MAX_AGE¶

Added in version 4.8.1.

データベース接続の寿命を、秒単位の整数で指定します。各リクエストの最後にデータベース接続を閉じるには、0 を指定します。

バージョン 5.1 で変更: デフォルトの動作では、永続的なデータベース接続は無制限になります。

通常、接続の永続性を有効にすると、データベースへの接続がより開放されます。有効にする前にデータベース設定を変更してください。

設定例:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

参考

POSTGRES_DISABLE_SERVER_SIDE_CURSORS¶

Added in version 4.9.1.

データベース内のサーバー側カーソルを無効にします。これは一部の pgbouncer 設定で必要となります。

設定例:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

参考

WEBLATE_DATABASES¶: Added in version 5.1.

Set to false to disable environment based configuration of the database connection. Use データボリュームからの設定のオーバーライド to configure the database connection manually.

データベースのバックアップ設定¶

参考

バックアップ用にダンプしたデータ

WEBLATE_DATABASE_BACKUP¶: DATABASE_BACKUP を使用して、毎日のデータベースのダンプを設定します。デフォルトは plain。

データストアサーバーの設定¶

Weblate コンテナでは Valkey または Redis の使用が必須であり、Docker で Weblate を実行する際には接続パラメーターの設定が必要です。

参考

キャッシュの設定

REDIS_HOST¶: データストアサーバーのホスト名または IP アドレス。デフォルトは cache。

REDIS_PORT¶: データストアサーバーのポート番号。デフォルトは 6379。

REDIS_DB¶: データストアのデータベースの番号。デフォルトは 1。

REDIS_USER¶: Added in version 5.13: データストア用のデータベースユーザー。デフォルトでは使用しない。

REDIS_PASSWORD¶: データストアサーバーのパスワード。デフォルトでは使用しない。

参考

シークレットの受け渡し

REDIS_TLS¶: データストア接続での SSL の使用を有効にします。

REDIS_VERIFY_SSL¶: データストア接続の SSL 証明書の検証を無効にするために使用します。

メールサーバーの設定¶

メール送信をするには、メールサーバーが必要です。

TLS 設定の例:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass

SSL 設定の例:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_PORT: 465
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass
    WEBLATE_EMAIL_USE_TLS: 0
    WEBLATE_EMAIL_USE_SSL: 1

参考

メール送信の設定

WEBLATE_EMAIL_HOST¶

メールサーバーのホスト名または IP アドレス。

参考

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_SSL
WEBLATE_EMAIL_USE_TLS
EMAIL_HOST

WEBLATE_EMAIL_PORT¶: メールサーバーのポート。デフォルトは 25。

参考

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER¶: メール認証ユーザー。

参考

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD¶

メール認証のパスワード。

参考

シークレットの受け渡し
EMAIL_HOST_PASSWORD

WEBLATE_EMAIL_USE_SSL¶

SMTP サーバと通信するときに、暗黙的な TLS（セキュア）接続を使用するかどうか。多くのメールのドキュメントでは、この種類の TLS 接続を SSL と呼びます。通常はポート 465 で使用されます。問題が発生した場合は、詳細な TLS 設定 WEBLATE_EMAIL_USE_TLS を確認してください。

バージョン 4.11 で変更: SSL/TLS への対応は、WEBLATE_EMAIL_PORT の設定により自動的に有効となります。

参考

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_TLS
EMAIL_USE_SSL

WEBLATE_EMAIL_USE_TLS¶

SMTP サーバーと通信するときに TLS（セキュア）接続を使用するかどうか。これは、明示的な TLS 接続（通常はポート 587 または 25）で使用します。接続が停止する場合は、暗黙的なTLS設定 ( WEBLATE_EMAIL_USE_SSL）を確認してください。

バージョン 4.11 で変更: SSL/TLS への対応は、WEBLATE_EMAIL_PORT の設定により自動的に有効となります。

参考

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_SSL
EMAIL_USE_TLS

WEBLATE_EMAIL_BACKEND¶

メール送信に使用する Django バックエンドを設定します。

参考

WEBLATE_AUTO_UPDATE¶: Weblate がリポジトリを更新するかどうか、どのように更新するかを設定します。

参考

AUTO_UPDATE

注釈

これは論理値の設定です（"true" または "false" を使用する）。

サイト連携¶

WEBLATE_GET_HELP_URL¶: GET_HELP_URL の設定。

WEBLATE_STATUS_URL¶: STATUS_URL の設定。

WEBLATE_LEGAL_URL¶: LEGAL_URL の設定。

WEBLATE_PRIVACY_URL¶: PRIVACY_URL の設定。

WEBLATE_PASSWORD_RESET_URL¶: Configures PASSWORD_RESET_URL.

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

インストールから体系的にエラーを収集してください。参照: エラーレポートの収集とパフォーマンスの監視。

Rollbar への対応を有効にする設定方法:

ROLLBAR_KEY¶: Rollbar ポストサーバーへのアクセストークン。

ROLLBAR_ENVIRONMENT¶: Rollbar の環境設定。デフォルトは 運用環境（production）。

Sentry への対応を有効にする設定方法:

SENTRY_DSN¶: Sentry DSN を設定するには、SENTRY_DSN を参照してください。

SENTRY_ENVIRONMENT¶: Sentry の環境設定（オプション）。デフォルトは WEBLATE_SITE_DOMAIN です。

SENTRY_MONITOR_BEAT_TASKS¶: Sentry で Celery Beat タスクを監視するかどうかを設定します。デフォルトは True です。

SENTRY_TRACES_SAMPLE_RATE¶

SENTRY_TRACES_SAMPLE_RATE を設定します。

例:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5

SENTRY_PROFILES_SAMPLE_RATE¶

SENTRY_PROFILES_SAMPLE_RATE を設定します。

例:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5

SENTRY_SEND_PII¶: SENTRY_SEND_PII を設定します。

CDN の現地化¶

WEBLATE_LOCALIZE_CDN_URL¶

WEBLATE_LOCALIZE_CDN_PATH¶

Added in version 4.2.1.

Configuration for CDN add-ons, including JavaScript 現地語化 CDN and Translation files CDN.

WEBLATE_LOCALIZE_CDN_PATH はコンテナ内のパスです。一時ストレージではなく、永続ボリュームに格納することが必要です。

可能性の 1 つとして、それを Weblate データーディレクトリ内に保存する方法:

environment:
  WEBLATE_LOCALIZE_CDN_URL: https://cdn.example.com/
  WEBLATE_LOCALIZE_CDN_PATH: /app/data/l10n-cdn

注釈

You are responsible for setting up serving of the files generated by Weblate, it only stores the files in configured location. See CDN の現地化 for secure serving guidance.

参考

有効なアプリ、検査、アドオン、機械翻訳、または自動修正の変更¶

組み込まれた有効な品質検査、アドオン、または自動修正を設定する変数:

WEBLATE_ADD_APPS¶

WEBLATE_REMOVE_APPS¶

WEBLATE_ADD_CHECK¶

WEBLATE_REMOVE_CHECK¶

WEBLATE_ADD_AUTOFIX¶

WEBLATE_REMOVE_AUTOFIX¶

WEBLATE_ADD_ADDONS¶

WEBLATE_REMOVE_ADDONS¶

WEBLATE_ADD_MACHINERY¶: Added in version 5.6.1.

WEBLATE_REMOVE_MACHINERY¶: Added in version 5.6.1.

例:

environment:
  WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
  WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon

参考

コンテナの設定¶

WEBLATE_WORKERS¶

Added in version 4.6.1.

コンテナで実行されているワーカープロセスの基本数。設定しない場合、使用可能な CPU コアの数に基づき、コンテナの起動時に自動的に決定されます。

使用する設定項目 CELERY_MAIN_OPTIONS、CELERY_NOTIFY_OPTIONS、CELERY_MEMORY_OPTIONS、CELERY_TRANSLATE_OPTIONS、CELERY_BACKUP_OPTIONS、CELERY_BEAT_OPTIONS、および WEB_WORKERS。これらの設定を使用して微調整できます。

CELERY_MAIN_OPTIONS¶

CELERY_NOTIFY_OPTIONS¶

CELERY_MEMORY_OPTIONS¶

CELERY_TRANSLATE_OPTIONS¶

CELERY_BACKUP_OPTIONS¶

CELERY_BEAT_OPTIONS¶

これらの変数を使用すると、Celery ワーカーのオプションを変更できます。同時実行性を変更したり（---concurrency 16）、別のプールの実装を使用したり（---pool=gevent）するのに便利です。

デフォルトでは、同時ワーカーの数は WEBLATE_WORKERS に基づきます。

例:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

参考

CELERY_SINGLE_PROCESS¶

Added in version 5.7.1: この変数を 1 に設定すると、celery プロセスを 1 つだけ実行できます。これによりメモリ使用量は減りますが、Weblate の性能に影響がでることがあります。

environment:
  CELERY_SINGLE_PROCESS: 1

参考

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

WEB_WORKERS¶

実行する WSGI ワーカーの数を設定します。

デフォルトでは、WEBLATE_WORKERS の半分になりますが、常に最低 2 になります。

例:
environment:
  WEB_WORKERS: 4

バージョン 5.13 で変更: WEB_WORKERS は、granian が使用するワーカープロセス数を設定します。

WEBLATE_SERVICE¶

コンテナ内で実行するサービスを設定します。これは、水平方向のスケーリングに使用します。

サービスが定義されている項目:

celery-beat: Celery タスクスケジューラでは、実行は、1 つのインスタンスのみにしてください。このコンテナは、データベース構造の移行も行うため、他のコンテナよりも先に起動させてください。
celery-backup: バックアップ用の Celery ワーカー。実行は、1 つのインスタンスのみにしてください。
celery-celery: 一般的な Celery ワーカー。
celery-memory: 翻訳メモリ Celery ワーカー。
celery-notify: 通知 Celery ワーカー。
celery-translate: 自動翻訳 Celery ワーカー。
web: Web サーバー。

参考

バックグラウンドタスクの内部構造

WEBLATE_ANUBIS_URL¶

Added in version 5.11.4.

サブ要求認証を処理するための Anubis サーバーの URL。これは、プルーフ・オブ・ワークを使用して、AI クローラーを停止するための着信 HTTP リクエストをフィルタリングするのに役立ちます。これを機能させるには、Anubis for Subrequest Authentication を設定する必要があります。

参考

Anubis Docker コンテナの統合
Anubis

Docker コンテナのボリューム¶

Weblate コンテナによってエクスポートされる2つのボリューム（data および cache）があります。

注釈

他のサービスコンテナ（PostgreSQL や Valkey など）も独自のデータボリュームを持ち、Weblate の永続性を維持するために必要です。

PostgreSQL コンテナは /var/lib/postgresql ボリュームに、Valkey コンテナは /data ボリュームにデータベースを格納します。Valkey はデフォルトではデータ保存が無効であり、永続化を有効にするには追加の設定が必要です。

Weblate 提供の例に基づいて設定するか、詳細については公式ドキュメントを参照してください。

data ボリュームは /app/data としてマウントされ、クローンされたリポジトリなどの Weblate 永続データを保存したり、Weblate インストールをカスタマイズしたりするために使用されます。DATA_DIR には、ここに何が保存されるか、より詳細な説明がされています。

data ボリュームは、データボリュームからの設定のオーバーライド、ロゴおよびその他の静的ファイルの変更、コードのカスタマイズなど、Weblate のカスタマイズを格納する場所でもあります。

ホストシステム上の Docker ボリュームの配置は Docker 設定によって異なりますが、通常は次の場所に格納されます。/var/lib/docker/volumes/weblate-docker_weblate-data/_data/ （パスは、docker-compose ディレクトリの名前、コンテナ、およびボリューム名で構成される）。

The cache volume is mounted as /app/cache and is used to store static files and CACHE_DIR. Its content is recreated on container startup and the volume can be mounted using ephemeral filesystem such as tmpfs, but the mount has to allow execution because Weblate stores generated helper files there.

When mounting /app/cache explicitly as tmpfs in Docker Compose, enable execution:

tmpfs:
  - /app/cache:exec

When also setting ownership options, keep the exec option:

tmpfs:
  - /app/cache:exec,uid=1000,gid=1000

ボリュームを手動で作成する場合、ディレクトリの所有者は UID 1000 であることが必要です。これは、コンテナ内でユーザーが使用するディレクトリです。

Weblate コンテナは、ルートファイルシステムを読み取り専用で実行することもできます。この場合、追加で 2 つの tmpfs ボリューム（/tmp と /run）をマウントすることが必要です。

参考

読み取り専用のルートファイルシステム¶

Added in version 4.18.

読み取り専用のルートファイルを使用してコンテナを実行する場合は、追加で 2 つの tmpfs ボリュームが /tmp と /run に必ず必要です。

環境変数以外の設定¶

Docker 環境変数は、Weblate インストールに関連するほぼすべてのシステム設定の公開が目的です。

環境変数として公開されていない設定を見つけ、その設定が公開されるべきであると考えた場合は、お気軽に Weblate の将来のバージョンで公開されるように依頼してください。

Docker 環境変数として公開されていない設定を変更することが必要な場合でも、データボリュームからの設定のオーバーライドまたは Docker イメージの拡張による設定のオーバーライドを使用して変更できます。

参考

Weblate のカスタマイズ

データボリュームからの設定のオーバーライド¶

ファイルは、/app/data/settings-override.py に作成できます。つまり、データボリュームのルートにあり、環境変数で定義した設定を拡張またはオーバーライドします。

Docker イメージの拡張による設定のオーバーライド¶

データボリュームからではなく、Docker イメージの段階で設定をオーバーライドするには:

カスタム Python モジュールの作成。
weblate.settings_docker からすべての設定をインポートするモジュールをパッケージに追加します。

たとえば、Python モジュールの作成で設定されているサンプルのパッケージ構造内で、次の初期コードを使用して weblate_customization/weblate_customization/settings.py にファイルを作成します。作成方法:
```
from weblate.settings_docker import *
```

公式 Weblate Docker イメージから継承するカスタム Dockerfile を作成し、パッケージをインストールして DJANGO_SETTINGS_MODULE 環境変数を設定モジュールにポイントします。作成方法:

FROM weblate/weblate

USER root

COPY weblate_customization /usr/src/weblate_customization
RUN source /app/venv/bin/activate && uv pip install --no-cache-dir /usr/src/weblate_customization
ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings

USER 1000

公式の Weblate Docker イメージを使用する代わりに、この Dockerfile ファイルからカスタムイメージを作成します。

これを docker-compose.override.yml で行う綺麗な方法はありません。could は build: . を weblate に追加しますが、カスタムイメージがシステム内で weblate/weblate としてタグ付けされるため、問題が発生することがあります。

そのため、公開リポジトリから直接 docker-compose.yml を変更せずに使用し、それを docker-compose.override.yml を通じて拡張する代わりに、公式の docker-compose.yml ファイルのコピーを作成し、そのコピーを編集して image:weblate/weblate を build: . に置き換えることができます。

docker-compose を使用してソースコードからイメージをビルドする方法の詳細については、Compose ファイルのビルドリファレンスを確認してください。
カスタム設定モジュールを拡張して、設定を定義または再定義します。

上記の import ステートメントの前後に設定を定義して、どの設定を優先するかを決定できます。import ステートメントの前に定義された設定は、環境変数およびデータボリュームで定義された設定のオーバーライドによって上書きできます。import ステートメントの後に定義された設定は上書きできません。

さらに詳細な設定もできます。たとえば、設定を環境変数として公開したり、データボリューム内の Python ファイルからの設定のオーバーライドを許可したりするなど、weblate.docker_settings が行うことを一部再現できます。

ロゴおよびその他の静的ファイルの変更¶

Weblate に付属する静的ファイルは、 /app/data/python/customize/static （参照: Docker コンテナのボリューム）に配置することで変更できます。たとえば、 /app/data/python/customize/static/favicon.ico を作成すると、ファビコンが変更されます。

ヒント

ファイルはコンテナの起動時に対応する場所にコピーされるため、ボリュームの内容を変更した後にWeblate を再起動させてください。

この方法は、Weblate テンプレートの変更にも使用できます。たとえば、法務モジュールドキュメントは /app/data/python/customize/templates/legal/documents に配置できます。

あるいは、独自のモジュール（参照: Weblate のカスタマイズ）を追加し、個別のボリュームとして Docker コンテナに追加できます。例:

weblate:
  volumes:
    - weblate-data:/app/data
    - ./weblate_customization/weblate_customization:/app/data/python/weblate_customization
  environment:
    WEBLATE_ADD_APPS: weblate_customization

コードのカスタマイズ¶

注釈

Weblate の内部 API はリリース間で大幅に異なる可能性があり、安定していることを意図していません。アップグレードの際は、Weblate 内部と連携するカスタムコードを必ずレビューしてください。

追加の Python コードを /app/data/python/customize に配置できます（Docker コンテナのボリューム参照）。これは Weblate 内部に Django アプリケーションとしてすでにインストールされています（前述のとおり、テンプレートや静的ファイルをカスタマイズするために使用されます）。

これは、任意のコード（例: 独自の検査項目の作成）を配置したり、Celery タスクスケジューラにカスタムのメンテナンスタスクを追加するために使用できます。

An example of custom scheduled tasks in /app/data/python/customize/tasks.py.¶

"""Custom scheduled task."""

import subprocess  # noqa: S404

from celery.schedules import crontab

from weblate.utils.celery import app


@app.task
def custom_task() -> None:
    """Execute custom task code."""
    subprocess.run(["sleep", "1"], check=True)  # noqa: S607


@app.on_after_finalize.connect
def setup_periodic_tasks(sender, **kwargs) -> None:
    """Configure when periodic task is triggered."""
    sender.add_periodic_task(
        crontab(hour=1, minute=0), custom_task.s(), name="custom-task"
    )

サードパーティ製コンテナの統合¶

Weblate の Docker セットアップは、機械翻訳、スペルチェック、または翻訳ワークフローを強化するその他のツールといった補完サービスを提供するために、追加のコンテナで拡張できます。これらのサービスは、Docker Compose 設定に統合し、Weblate と連携して動作します。

サードパーティ製コンテナを追加する場合の考慮点:

ネットワーク接続: コンテナ同士を同じ Docker ネットワーク上に配置し、相互に通信できることを確保してください
データの永続化: データを永続化する必要があるサービスには、ボリュームを使用してください
セキュリティ: 適切なアクセス制御を設定し、不要なポートの公開は避けてください

LibreTranslate Dockerコンテナの統合¶

LibreTranslate は、セルフホストが可能な無料のオープンソース機械翻訳サービスです。Weblate と統合することで、外部サービスに依存することなくオフラインでの機械翻訳機能を提供できます。

LibreTranslate サービスを docker-compose.override.yml ファイルに含めることで、Weblate デプロイメントに組み込むことができます。LibreTranslate は Docker ネットワーク内で実行されるため、Weblate からのみアクセス可能でインターネットには公開されません。

docker-compose.override.yml を使用した基本設定:

services:
  libretranslate:
    image: libretranslate/libretranslate:latest
    command: --disable-web-ui
    restart: unless-stopped
    environment:
      LT_UPDATE_MODELS: true
    volumes:
      - libretranslate_models:/home/libretranslate/.local:rw
    healthcheck:
      test: ['CMD-SHELL', './venv/bin/python scripts/healthcheck.py']
      interval: 10s
      timeout: 4s
      retries: 4
      start_period: 5s

volumes:
  libretranslate_models:

GPU アクセラレーションによる翻訳を行う場合（NVIDIA GPU が利用可能な場合）:

services:
  libretranslate:
    image: libretranslate/libretranslate:latest-cuda
    command: --disable-web-ui
    restart: unless-stopped
    environment:
      LT_UPDATE_MODELS: true
      PUID: root
    volumes:
      - libretranslate_models:/home/libretranslate/.local:rw
    healthcheck:
      test: ['CMD-SHELL', './venv/bin/python scripts/healthcheck.py']
      interval: 10s
      timeout: 4s
      retries: 4
      start_period: 5s
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

volumes:
  libretranslate_models:

docker compose down && docker compose up -d を使用してサービスを開始した後、Weblate で LibreTranslate を設定してください:

Weblate 管理者インターフェイスへのアクセス
Machine translation → Automatic suggestions に移動します
次の設定で新しい LibreTranslate サービスを追加します:

サービス:

LibreTranslate

API URL:

http://libretranslate:5000

API キー:

空欄

LibreTranslate は Weblate で機械翻訳用に設定され、使用できるようになりました。

注釈

LibreTranslate サービスは、Web UI なしで（--disable-web-ui）実行され、Docker ネットワーク内で API を介してのみアクセス可能です。
モデルは、コンテナの起動時に自動的に更新されます。（LT_UPDATE_MODELS: true）
データは、最適なパフォーマンスとデータの安全性のために、Docker ボリュームを使用して永続化されます。
健全性診断は、Docker エンジンがサービスの状態を適切に監視していることを保証します。
GPU アクセラレーションのため、CUDA イメージバリアントを使用し、システムが NVIDIA Docker をサポートしていることを確認してください。GPU を使用できるように、このコンテナは特権ユーザーとして実行されます。
外部ポートが一切公開されていないため、この設定はデフォルトで安全です。

参考

Anubis Docker コンテナの統合¶

Anubis は、AI スクレイパーや他の障害トラフィックをサーバーで遮断する Web AI ファイアウォールユーティリティです。スクレイピングによる過負荷を回避するため、公開された Weblate 環境では一般的に必要です。

Anubis は Docker Compose を使用してデプロイできます:

anubis:
   image: ghcr.io/techarohq/anubis:latest
   environment:
      BIND: ":8923"
      DIFFICULTY: "4"
      METRICS_BIND: ":9090"
      SERVE_ROBOTS_TXT: "false"
      OG_PASSTHROUGH: "false"
      # The single space in TARGET enables subrequest authentication
      TARGET: " "
      # The redirect domain has to match WEBLATE_SITE_DOMAIN
      REDIRECT_DOMAINS: weblate.example.com
      # Generate a random private key using: openssl rand -hex 32
      ED25519_PRIVATE_KEY_HEX: "..."
      # Customize your Anubis policy
      POLICY_FNAME: /data/botPolicies.yaml
   healthcheck:
      test: ["CMD", "anubis", "--healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5
      start_period: 500ms
   volumes:
      - anubis-data:/data

volumes:
   anubis-data:

注釈

上記の構成における anubis-data ボリュームには、ニーズに合わせて設定されたボットポリシーを含む botPolicies.yaml が含まれている必要があります。

最低限、ステータスコードは https://anubis.techaro.lol/docs/admin/configuration/subrequest-auth に記載の通りに調整する必要があります。

また、永続ストレージバックエンドを https://anubis.techaro.lol/docs/admin/policies/#storage-backends に記載されている通りに設定することも推奨されます。

Weblate で Anubis を有効にする方法:

environment:
   WEBLATE_ANUBIS_URL: http://anubis:8923

参考

WEBLATE_ANUBIS_URL

PostgreSQL サーバーの設定¶

PostgreSQL コンテナは、デフォルトの PostgreSQL 設定を使用するため、CPU コアやメモリを効果的に使用できません。性能を向上させるために設定を変更してください。

設定は、https://hub.docker.com/_/postgres のデータベースの設定の説明に従って変更できます。環境に一致する設定は、https://pgtune.leopard.in.ua/ を使用して生成できます。

コンテナ内部¶

コンテナは supervisor を使用して個々のサービスを開始しています。水平方向のスケーリングの場合、コンテナ内の単一サービスのみを開始します。

サービスのステータスを確認する方法:

docker compose exec --user weblate weblate supervisorctl status

Celery キューごとに個別のサービスがあります（詳細参照: Celery を使用するバックグラウンドタスク）。適切なワーカーを停止することで、一部のタスクの処理を停止できます。

docker compose exec --user weblate weblate supervisorctl stop celery-translate

Docker を使用したインストール¶

ハードウェア要件¶

メモリ使用量¶

CPU 使用率¶

ストレージ使用量¶

ノード数¶

インストール¶

Docker イメージ レジストリの選択¶

Docker イメージ タグの選択¶

HTTPS に対応した Docker コンテナ¶

SSL終端プロキシ¶

独自の SSL 証明書の使用¶

Let's Encrypt による自動 SSL 証明書の発行¶

Docker コンテナーのアップグレード¶

PostgreSQL コンテナのアップグレード¶

管理者としてサイン イン¶

プロセス数とメモリ消費量¶

水平方向のスケーリング¶

Docker 環境変数¶

シークレットの受け渡し¶

一般的な設定¶

サイトの認証情報をホストするコード¶

自動提案の設定¶

認証設定¶

LDAP¶

GitHub¶

GitHub エンタープライズ版¶

Bitbucket¶

Facebook¶

Google¶

GitLab¶

Gitea¶

Microsoft Entra ID¶

Microsoft Entra ID with Tenant support¶

Keycloak¶

Linux ベンダー¶

Slack¶

OpenID Connect¶

Fedora OpenID Connect¶

SAML¶

その他の認証設定¶

PostgreSQL データベースの設定¶

データベースのバックアップ設定¶

データストア サーバーの設定¶

メールサーバーの設定¶

サイト連携¶

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

CDN の現地化¶

有効なアプリ、検査、アドオン、機械翻訳、または自動修正の変更¶

コンテナの設定¶

Docker コンテナのボリューム¶

読み取り専用のルート ファイルシステム¶

環境変数以外の設定¶

データ ボリュームからの設定のオーバーライド¶

Docker イメージの拡張による設定のオーバーライド¶

ロゴおよびその他の静的ファイルの変更¶

コードのカスタマイズ¶

サードパーティ製コンテナの統合¶

LibreTranslate Dockerコンテナの統合¶

Anubis Docker コンテナの統合¶

PostgreSQL サーバーの設定¶

コンテナ内部¶

Docker イメージレジストリの選択¶

Docker イメージタグの選択¶

管理者としてサインイン¶

データストアサーバーの設定¶

読み取り専用のルートファイルシステム¶

データボリュームからの設定のオーバーライド¶