Weblate のアップグレード

Docker イメージのアップグレード

公式の Docker イメージ（参照: Docker を使用したインストール）には、Weblate をアップグレードする手順がすべて組み込まれています。通常、最新バージョンを入手するだけです。他に必要な操作はありません。

参考

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

一般的なアップグレード方法

アップグレードをする前に、現在の ソフトウェア要件 に変更があるかもしれないので確認してください。すべての要件がインストールまたは更新されたあと、設定の変更に合わせて settings.py を設定してください（正しい値については settings_example.py を確認）。

アップグレードする前に、必ず バージョン固有の手順 を確認してください。バージョンをスキップする場合は、アップグレードでスキップしたすべてのバージョンの指示に従ってください。スムーズな移行を確実にするために、中間バージョンにアップグレードする方が良い場合があります。複数のリリース間でのアップグレードは機能するはずですが、単一バージョンのアップグレードほど十分なテストされていません。

注釈

アップグレードが失敗した場合、データベースをロールバックできるように、アップグレードの前に完全なデータベース バックアップを実行してください（ 参照: Weblate のバックアップと移動）。

1. wsgi および Celery プロセスを停止します。アップグレードは、データベースで互換性のない変更を実行することがあるため、アップグレード中に古いプロセスが実行されないようにする方が常に安全です。

2. Weblate のコードをアップグレードする。

   pip によるインストール方法:

   pip install -U "Weblate[all]==version"
   

   または、最新のリリース バージョンを入手するだけの場合:

   pip install -U "Weblate[all]"
   

   すべてのオプションの依存関係をインストールせずに、インストールする方法:

   pip install -U Weblate
   

   Gitチェックアウトでは、新しいソースコードを取得して、インストールを更新することが必要です。取得と更新方法:

   cd weblate-src
   git pull
   # Update Weblate inside your virtualenv
   . ~/weblate-env/bin/pip install -e .
   # Install dependencies directly when not using virtualenv
   pip install --upgrade -r requirements.txt
   # Install optional dependencies directly when not using virtualenv
   pip install --upgrade -r requirements-optional.txt
   

3. 新しい Weblate のリリースには、新しい オプションの依存関係 が含まれていることがあります。欲しい機能が含まれたかどうか確認する。

4. 設定ファイルをアップグレードするための、必要な手順については、 settings_example.py または バージョン固有の手順 を確認してください。

5. データベース構造をアップグレードする:

   weblate migrate --noinput
   

6. 更新された静的ファイルを収集する（参照: 実行サーバー および 静的ファイルの提供）:

   weblate collectstatic --noinput --clear
   

7. JavaScript ファイルと CSS ファイルを圧縮する（省略可能、参照: クライアント アセットの圧縮）:

   weblate compress
   

8. Git のバージョンを実行している場合は、アップグレードするたびに言語ファイルを再生成してください。再生成させるコマンド:

   weblate compilemessages
   

9. 設定が正常であるかを確認する（参照: 運用環境の設定）:

   weblate check --deploy
   

10. Celery ワーカーを再起動する（参照: Celery を使用するバックグラウンド タスク）。

バージョン固有の手順

2.x からアップグレード

2.x リリースからアップグレードする場合は、必ず先に 3.0.1 にアップグレードしてから、3.x シリーズのアップグレードを続行してください。この手順を省いたアップグレードには対応していませんので、中断します。

参考

Weblate 3.0 のドキュメント、2.20 から 3.0 にアップグレード

3.x からアップグレード

3.x リリースからアップグレードする場合は、必ず最初に 4.0.4 または 4.1.1 にアップグレードしてから、4.x シリーズのアップグレードを続行してください。この手順を省いたアップグレードには対応していませんので、中断します。

参考

Weblate 4.0 のドキュメント、3.11 から 4.0 にアップグレード

4.0 から 4.1 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

構成または依存関係の重要な変更:

• settings_example.py に変更があります。重要なのはミドルウェアの変更です。変更に合わせて設定を修正してください。

• 新しいファイル形式が追加されました。WEBLATE_FORMATS を変更する場合は、新しいファイル形式を含めてください。

• 新しい品質チェックが付かされました。CHECK_LIST を変更する場合は、新しい品質チェックを含めてください。

• DEFAULT_THROTTLE_CLASSES の設定を変更し、API で接続制限のレポート作成が可能となりました。

• 新しい要件と、更新された要件が複数あります。

• INSTALLED_APPS が変更されました。

• MT_DEEPL_API_VERSION の設定は、バージョン 4.7 で削除されました。DeepL の機械翻訳では、代わりに新しい MT_DEEPL_API_URL を使用するように変更されました。サブスクリプションに合わせて MT_DEEPL_API_URL の修正が必要になることがあります。

参考

一般的なアップグレード方法

4.1 から 4.2 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

構成または依存関係の重要な変更:

• 3.x リリースからのアップグレードには未対応となりました。先に 4.0.4 または 4.1.1 にアップグレードしてください。

• 新しい要件と、更新された要件が複数あります。

• settings_example.py には複数の変更があります。重要なのは、新しいミドルウェアと変更されたアプリケーションの順序です。

• JSON を基にしたフォーマットのキーには、先行するドットが含まれなくなりました。文字列はデータベースの移行中に調整されますが。しかし、エクスポートまたは API のキーに依存する場合に備え、外部コンポーネントの修正が必要となることがあります。

• Celery の構成は、memory キューを使用しないように変更されました。起動スクリプトと CELERY_TASK_ROUTES 設定を修正してください。

• Weblate ドメインは、設定ファイルに設定するように変更されました。Weblate を実行する前に、設定を変更することが必要です。

• ユーザー データベースのユーザー名フィールドとメールアドレスのフィールドは、大文字と小文字を区別しない一意のフィールドにすることが必要です。PostgreSQL では、ミスにより強制されていませんでした。

参考

一般的なアップグレード方法

4.2 から 4.3 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

構成または依存関係の重要な変更:

• 品質検査には複数の変更があります。CHECK_LIST を変更した場合は、それを含めてください。

• 原文の言語属性は、プロジェクトから API で公開しているコンポーネントに移動しました。使用する場合は、Weblate クライアント の更新が必要です。

• 4.3 のデータベースへの移行時間は、翻訳する文字列の数によって長くなることがあります（100,000 原文あたり約 1 時間の移行時間が必要）。

• INSTALLED_APPS が変更されました。

• SESSION_COOKIE_AGE_AUTHENTICATED を補完する、新しい設定 SESSION_COOKIE_AGE が追加されました。

• hub または lab`を使用して、GitHub または GitLab と連携していた場合は、再設定が必要です。参照: :setting:`GITHUB_CREDENTIALS および GITLAB_CREDENTIALS。

バージョン 4.3.1 で変更:

• Celery の設定に memory キューが追加されました。スタートアップ スクリプトおよび CELERY_TASK_ROUTES の設定を修正してください。

バージョン 4.3.2 で変更:

• アドオンの post_update メソッドは、追加の skip_push パラメータを受け取ることになりました。

参考

一般的なアップグレード方法

4.3 から 4.4 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

構成または依存関係の重要な変更:

• INSTALLED_APPS に変更がされ、そこに weblate.configuration の追加が必要となりました。

• Django 3.1 が必須となりました。

• MySQL または MariaDB を使用している場合、最低限必要なバージョンを上げました。

バージョン 4.4.1 で変更:

• モノリンガルの gettext は、 msgid と msgctxt が存在すれば両方を使用するように変更されました。ファイル内の翻訳文字列の識別が変更されたことで、スクリーンショットや査読状態などの Weblate 翻訳情報へのリンクが壊れます。アップグレードの前に、このようなファイルの保留中の変更は、コミットを完了させておいてください。loadpo を使用して、影響を受けるコンポーネントを強制的にロードすることが望ましいです。

• ファイル形式の問題に対処するため、翻訳ツールキットの最低限必要なバージョンを上げました。

参考

一般的なアップグレード方法

4.4 から 4.5 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

構成または依存関係の重要な変更:

• 容量の大きい用語集がある場合、移行時間が長くなることがあります。

• 用語集は、通常のコンポーネントとして保存するように変更されました。

• 用語集の API を削除しました。通常の翻訳 API を使用して用語集にアクセスしてください。

• INSTALLED_APPS は変更されました — weblate.metrics の追加が必要です。

バージョン 4.5.1 で変更:

• pyahocorasick モジュールには、新しい依存関係があります。

参考

一般的なアップグレード方法

4.5 から 4.6 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

構成または依存関係の重要な変更:

• 新しいファイル形式が追加されました。WEBLATE_FORMATS を変更する場合は、新しいファイル形式を含めてください。

• コンポーネントを作成するための API は、自動的に Weblate の内部 URL を使用するように変更されました。参照: POST /api/projects/(string:project)/components/。

• 依存関係と PASSWORD_HASHERS が変更され、パスワードのハッシュ化には Argon2 を優先するように変更されました。

参考

一般的なアップグレード方法

4.6 から 4.7 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

構成または依存関係の重要な変更:

• settings_example.py に変更があり、重要なのはミドルウェアの変更（MIDDLEWARE）です。変更に合わせて設定を修正してください。

• DeepL 機械翻訳には、汎用的な MT_DEEPL_API_URL 設定が追加されました。適切にサブスクリプションの違いに対応できるようになりました。MT_DEEPL_API_VERSION の設定項目は削除されました。

• Django 3.2 が必須となりました。

参考

一般的なアップグレード方法

4.7 から 4.8 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

このリリースでは、追加のアップグレード作業は必要ありません。

参考

一般的なアップグレード方法

4.8 から 4.9 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

• 保存するメトリクスに変更があり、大規模なサイトではアップグレードに時間がかかることがあります。

参考

一般的なアップグレード方法

4.9 から 4.10 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

• プロジェクト単位のグループに変更があり、数千のプロジェクトがあるサイトでは、アップグレードに時間がかかります。

• Django 4.0 では、互換性のない変更が行われました（参照: Backwards incompatible changes in 4.0）。問題が発生した場合に備えて、 Weblate は、今はまだ Django 3.2 に対応しています。Weblate が影響を受ける可能性がある重要な変更項目:

  • PostgreSQL 9.6 への対応は終了しました。Django 4.0 は、PostgreSQL 10 以降に対応します。

  • CSRF_TRUSTED_ORIGINS のファイル形式の変更。

• Docker コンテナは、Django 4.0 の使用に変更。変更点は上記を確認。

参考

一般的なアップグレード方法

4.10 から 4.11 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

• Weblate は、Python 3.7 以降が必須となりました。

• プロジェクトごとのアクセス制御の管理 の実装が変更されました。グループ名からプロジェクト接頭辞が削除されました。これにより、API ユーザが影響を受けます。

• Weblate は、文字セット検出に chardet モジュールの代わりに charset-normalizer を使用するよう変更されました。

• 4.11.1 で変更: REST_FRAMEWORK 設定に変更があります（DEFAULT_AUTHENTICATION_CLASSES のバックエンドの 1 つが削除されました）。

参考

一般的なアップグレード方法

4.11 から 4.12 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

• 特別な操作は必要ありません。

参考

一般的なアップグレード方法

4.12 から 4.13 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

• 言語の定義 は、アップグレード時に自動的に更新されるようになりました。これを無効にするには、UPDATE_LANGUAGES を使用します。

• コンテキストとロケーションの処理が、Windows RC ファイル、HTML ファイル、IDML 形式、および テキスト ファイル のファイル形式で変更されました。ほとんどの場合、コンテキストにはロケーションが表示されます。

• 機械翻訳サービスの設定はユーザーインターフェイスで行うようになりました。データベースの移行中に設定ファイルでの設定がインポートされます。

参考

一般的なアップグレード方法

4.13 から 4.14 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

• Java 形式の検査が GNU gettext フラグと一致するようになりました。Weblate で設定したフラグは自動的に移行されますが、サードパーティのスクリプトでは java-format の代わりに java-printf-format を使用し、java-messageformat の代わりに java-format を使用してください。

• jellyfish への依存は rapidfuzz に置き換わりました。

• 4.14 .2で変更: _CREDENTIALS リストの代わりに _TOKEN/_USERNAME 構成を使用した VCS サービス API キーの非推奨の安全な構成。Docker で、matching_HOST ディレクティブを追加してください。例として、WEBLATE_GITHUB_HOST と GITHUB_CREDENTIALS を確認してください。

参考

一般的なアップグレード方法

4.14 から 4.15 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

• Weblate では、PostgreSQL の btree_gin 拡張が必要になりました。 必要とする権限がすべてあれば、移行プロセスに従ってインストールされます。 手動でアップグレードする場合は PostgreSQL でデータベースの作成 を確認してください。

• Docker イメージは、デフォルトでデバッグ モードが有効ではなくなりました。必要に応じて、WEBLATE_DEBUG を使用して環境にあわせて有効にしてください。

• データベースの移行では、一部のインデックスが再作成されるため、大きなインスタンスでは数時間かかります。

• 4.15.1 で変更: REST フレームワーク設定の DEFAULT_PAGINATION_CLASS のデフォルト値が変更されました。

参考

一般的なアップグレード方法

4.15 から 4.16 にアップグレード

更新するには、一般的なアップグレード方法 に従ってください。

• 現在、celery beat はデータベースにタスク スケジュールを保存するようになりました。そのため、``CELERY_BEAT_SCHEDULER`および INSTALLED_APPS の変更が必要です。

• 非推奨の VCS 設定による認証情報への対応は終了しました。 参照: 4.13 から 4.14 にアップグレード。

• django-crispy-forms をアップグレードするには、INSTALLED_APPS の変更が必要です。

• django-cors-headers を統合するには、INSTALLED_APPS と MIDDLEWARE の変更が必要です。

参考

一般的なアップグレード方法

Python 2 から Python 3 にアップグレード

Weblate は、Python 3.6 未満への対応は終了しました。まだ古いバージョンで実行している場合は、事前に既存のバージョンから Python 3 に移行を完了させたあと、アップグレードを実行してください。参照: Python 2 から Python 3 にアップデート — Weblate 3.11.1 ドキュメント 。

他のデータベースから PostgreSQL に移行

PostgreSQL 以外のデータベースで Weblate を実行している場合は、Weblate が最適に動作できるように PostgreSQL への移行を検討してください。次の手順に従って、データベース間でデータを移行します 。移行前に Web サーバと Celery サーバの両方を停止させてください。停止していない場合は、データの不整合が発生することがあります。

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 -D -P weblate

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

Django JSON ダンプを使用する移行

最も簡単な移行の方法は、Django JSON ダンプを使用することです。これは、小規模なインストールに適しています。より大きなサイトでは、代わりに pgloader が良いかもしれません。

1. 追加のデータベース接続として PostgreSQL を、settings.py に追加する:

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": "database.example.com",
        # Set to empty string for default
        "PORT": "",
        # Additional database options
        "OPTIONS": {
            # In case of using an older MySQL server, which has MyISAM as a default storage
            # 'init_command': 'SET storage_engine=INNODB',
            # Uncomment for MySQL older than 5.7:
            # 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
            # If your server supports it, see the Unicode issues above
            "charset": "utf8mb4",
            # Change connection timeout in case you get MySQL gone away error:
            "connect_timeout": 28800,
        },
    },
    "postgresql": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
    },
}

2. 移行を実行し、テーブルに挿入されたデータを削除する:

weblate migrate --database=postgresql
weblate sqlflush --database=postgresql | weblate dbshell --database=postgresql

3. 古いデータベースをダンプし、PostgreSQL にインポートする:

weblate dumpdata --all --output weblate.json
weblate loaddata weblate.json --database=postgresql

4. デフォルトで、PostgreSQL データベースのみを使用するように DATABASES を修正し、古い接続を削除する。

これで、Weblate を PostgreSQL データベースで実行する準備が整いました。

pgloader を使用した PostgreSQL への移行

pgloader は、PostgreSQL にデータを移行するための一般的な移行ツールです。この機能を使用して、Weblate データベースを移行します。

1. PostgreSQL をデータベースとして使用するように settings.py を調整する。

2. PostgreSQL データベース内のスキーマを移行する:

   weblate migrate
   weblate sqlflush | weblate dbshell
   

3. pgloader を実行してデータを転送します。以下のスクリプトを使用してデータベースを移行する（できれば、pgloader の機能を理解し、設定に合わせて修正してください）:

   LOAD DATABASE
        FROM      mysql://weblate:password@localhost/weblate
        INTO postgresql://weblate:password@localhost/weblate
   
   WITH include no drop, truncate, create no tables, create no indexes, no foreign keys, disable triggers, reset sequences, data only
   
   ALTER SCHEMA 'weblate' RENAME TO 'public'
   ;
   

Pootle から移行

Weblate は、そもそも Pootle を置き換えるために開発されたので、Pootle からのユーザー アカウントの移行にも対応しています。Pootle からユーザーをダンプして、 importusers を使用してインポートします。