継続的な現地語化

開発と翻訳を密接に行えるように、インフラを整備しています。これにより、翻訳者は常に翻訳作業を続けることができ、リリース直前に膨大な量の新しいテキストを扱わずにすみます。

参考

Weblate との統合 で、開発環境と Weblate を統合する基本的な方法を説明しています。

処理の流れ:

1. 開発者は変更を行い、VCS リポジトリにプッシュする。

2. オプションで、翻訳ファイルを更新する（これはファイル形式によって異なる。参照: テンプレートを更新しても、Weblate に以前の翻訳文が表示されるのはなぜですか？）。

3. Weblate が、VCS リポジトリから変更をプルする。参照: リポジトリの更新。

4. Weblate が翻訳の変更を検出すると、登録者の設定に基づいて翻訳者に通知する。

5. 翻訳者は、Weblate の管理画面を使用して翻訳を送信するか、オフラインでの変更をアップロードします。

6. 翻訳者が作業を終えると、Weblate は変更をローカル リポジトリにコミットし（参照: 遅延コミット）、権限があれば元のリポジトリにプッシュします（参照: 変更点を Weblate からプッシュ）。

リポジトリの更新

ソースからバックエンド リポジトリを更新する方法を何か設定することが必要です。

• 一般的なコード ホスティング サービスと統合するために、通知フック を使用する機能:

  • 変更を GitHub から自動受信

  • 変更を GitLab から自動受信

  • 変更を Bitbucket から自動受信

  • 変更を Pagure から自動受信

  • 変更を Azure リポジトリから自動受信

  • 変更を Gitea リポジトリから自動受信

• リポジトリ管理から、または Weblate の REST API あるいは Weblate クライアント を使用して手動で更新を起動させる

• AUTO_UPDATE を有効にして、Weblate インスタンス上のすべてのコンポーネントを自動的に更新させる

• updategit の実行（プロジェクトの選択、または --all の選択ですべて更新）

Weblate がリポジトリを更新するたびに、更新後のアドオンが起動。参照: アドオン。

マージ競合の回避

Weblate によるマージ競合は、同じファイルが Weblate 内と外部の両方で変更された場合に発生します。対処方法は 2 つあります。Weblate 外部での編集を避けるか、Weblate を更新プロセスに統合して、Weblate 外部でファイルを更新する前に Weblate での変更を反映させます。

最初の方法は、モノリンガル ファイルで簡単です。Weblate 上で新しい文字列を追加し、ファイルの編集も全てそこで行います。バイリンガル ファイルの場合、通常、ソースコードから翻訳可能なファイルを生成するため、何らかのメッセージ抽出プロセスがあります。場合によっては、これを 2 つの処理に分割できます。まず、抽出してテンプレートを生成し（例えば、gettext POT は xgettext を使用して生成する）、次の処理で、テンプレートを実際の翻訳にマージします（gettext PO ファイルは msgmerge を使用して更新する）。2 番目の処理は Weblate で実行でき、この処理の前に、保留中の変更がすべて含まれているかどうかを確認できます。

2 番目の方法は、Weblate の REST API を使用して、保留中の変更をすべて強制的にプッシュし、自分で変更を行っている間に翻訳をロックして実現します。

更新を実行するスクリプトの例:

# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock

複数のコンポーネントが同じリポジトリを共有している場合、コンポーネントすべてを個別にロックすることが必要です。すべてロックする例:

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

注釈

この例では、Weblate クライアント を使用します。これには、Weblate をリモートで制御するための設定（API キー）が必要です。wlc の代わりにどのような HTTP クライアントを使用しても実現できます（curl など） 。参照: Weblate の REST API。

参考

Weblate クライアント

変更を GitHub から自動受信

Weblate は、GitHub に正式に対応しています。

Hosted Weblate を使用している場合は、Weblate app をインストールしてください。そうすれば、簡単に正しい初期設定ができます。変更を元に戻すためにも使用できます。

通知を、GitHub リポジトリへプッシュするたびに受け取るには、リポジトリの設定画面（Webhook）から Weblate の Web フックを追加します。Web フックの設定画面:

独自 URL の場合、Weblate URL に /hooks/github/ を追加します。たとえば、Hosted Weblate サービスの場合、https://hosted.weblate.org/hooks/github/ となります。

その他の値は、既定の設定に従えます（Weblate は両方の種類のコンテンツを処理でき、プッシュ イベントのみを使用する）。

参考

POST /hooks/github/、Hosted Weblate からリポジトリへの接続

変更を Bitbucket から自動受信

Weblate は、Bitbucket の Web フックに対応しています。リポジトリのプッシュ時に起動する Web フックを、インストールした Weblate の URL に /hooks/bitbucket/ を追加して、宛先（例: https://hosted.weblate.org/hooks/bitbucket/）を指定します。

参考

POST /hooks/bitbucket/、Hosted Weblate からリポジトリへの接続

変更を GitLab から自動受信

Weblate は、GitLab のフックに対応しています。プロジェクトの Web フックを、インストールした Weblate の URL に /hooks/gitlab/ を追加して、宛先を指定します（例: https://hosted.weblate.org/hooks/gitlab/）。

参考

POST /hooks/gitlab/、Hosted Weblate からリポジトリへの接続

変更を Pagure から自動受信

バージョン 3.3 で追加.

Weblate は、Pagure のフックに対応しています。Web フックを、インストールした Weblate の URL に /hooks/pagure/ を追加して、宛先を指定します（例: https://hosted.weblate.org/hooks/pagure/）。Project options の中で Activate Web-hooks を設定する方法:

参考

POST /hooks/pagure/、Hosted Weblate からリポジトリへの接続

変更を Azure リポジトリから自動受信

バージョン 3.8 で追加.

Weblate は、Azure リポジトリの Web フックに対応しています。コード プッシュ イベントの Web フックを、インストールした Weblate の URL に /hooks/azure/ を追加して、宛先を指定します（例: https://hosted.weblate.org/hooks/azure/）。これは、プロジェクトの設定 の中にある フック サービス で指定します。

参考

Azure DevOps を使用した Web フック マニュアル 、POST /hooks/azure/、Hosted Weblate からリポジトリへの接続

変更を Gitea リポジトリから自動受信

バージョン 3.9 で追加.

Weblate は、Gitea の Web フックに対応しています。プッシュ イベント 用の Gitea の Web フック を、インストールした Weblate の URL に /hooks/gitea/ を追加して、宛先を指定します（例: https://hosted.weblate.org/hooks/gitea/）。これは、Web フック リポジトリの中にある 設定 で指定します。

参考

Webhooks in Gitea manual 、POST /hooks/gitea/、Hosted Weblate からリポジトリへの接続

変更を Gitee リポジトリから自動受信

バージョン 3.9 で追加.

Weblate は、Gitee の Web フックに対応しています。プッシュ イベント用の Web フック を、インストールした Weblate の URL に /hooks/gitee/ を追加して、宛先を指定します（例: https://hosted.weblate.org/hooks/gitee/）。これは、管理 リポジトリの中にある Web フック で指定します。

参考

Webhooks in Gitee manual 、POST /hooks/gitee/、Hosted Weblate からリポジトリへの接続

リポジトリを毎晩自動更新

Weblate は、リモート リポジトリを夜間に自動的に取得し、後で変更をマージする性能を向上させます。オプションで、自動更新 の設定を有効にすると、これを夜間のマージの実行に変更できます。

変更点を Weblate からプッシュ

各翻訳コンポーネントは、プッシュ URL を指定できます（参照: リポジトリの送信先 URL）、その場合、Weblate は変更をリモート リポジトリにプッシュします。 Weblate は、変更をコミットのたびに自動的にプッシュする設定にすることもできます （これはデフォルトです、参照: コミット時にプッシュする）。変更を自動的にプッシュさせない場合は、リポジトリのメンテナンス から手動で操作するか、wlc push 経由で API を使用して操作できます。

プッシュのオプションは、使用する バージョン管理の統合 によって異なります。詳細については、その章を確認してください。

Weblate による直接のプッシュが不要な場合は、GitHub プルリクエスト、GitLab マージリクエスト、 Gitea プルリクエスト、Pagure マージリクエスト のプルリクエストまたは Gerrit 査読に対応しています。これを有効にするには、コンポーネント構成 で バージョン管理システム として GitHub、GitLab、Gitea、Gerrit または Pagure を選択します。

全体で使用できる、Git、GitHub、GitLab のオプション:

理想的な初期設定	バージョン管理システム	リポジトリの送信先 URL	プッシュ先のブランチ
プッシュしない	Git	空	空
直接プッシュ	Git	SSH URL	空
別のブランチに push	Git	SSH URL	ブランチ名
フォークの GitHub プル リクエスト	GitHub プルリクエスト	空	空
ブランチの GitHub プル リクエスト	GitHub プルリクエスト	SSH URL [1]	ブランチ名
フォークの GitLab マージ リクエスト	GitLab マージリクエスト	空	空
ブランチの GitLab マージ リクエスト	GitLab マージリクエスト	SSH URL [1]	ブランチ名
フォークの Gitea マージ リクエスト	Gitea プルリクエスト	空	空
ブランチの Gitea マージ リクエスト	Gitea プルリクエスト	SSH URL [1]	ブランチ名
フォークの Pagure マージ リクエスト	Pagure マージリクエスト	空	空
ブランチの Pagure マージ リクエスト	Pagure マージリクエスト	SSH URL [1]	ブランチ名

[1] (1,2,3,4)

ソースコードのリポジトリ がプッシュに対応している場合は、空にできます。

注釈

Weblate コミット後の、変更の自動プッシュを有効にすることもできます。これは、コミット時にプッシュする で設定します。

参考

SSH キーの設定は リポジトリへの接続 を、Weblate の変更をコミットするタイミングは 遅延コミット を参照してください。

保護されたブランチ

保護されたブランチで Weblate を使用している場合は、プル リクエストを使用し、翻訳の実際の査読をするように設定できます（知らない言語では問題になることがある）。その他の方法は、Weblate プッシュ ユーザーに対してこの制限を放棄することです。

GitHub で、リポジトリの設定から指定する例:

他のユーザーとの対話

Weblate は、API を使用して他の人と簡単に対話できます。

参考

Weblate の REST API

遅延コミット

Weblate は、可能であれば、同じ著者のコミットを 1 つのコミットにグループ化します。これによりコミット数が大幅に削減されますが、VCS リポジトリを同期させる場合（これは、デフォルトで 管理者 グループに許可されます。参照: アクセス権および組込みロールの一覧）に備えて、コミットを実行するように直接指定することが必要になります。

このモードで、変更がコミットされる条件:

• 他の誰かがすでに変更した文字列を変更する。

• 上流からのマージが発生した。

• 直接コミットが要求される。

• ファイルのダウンロードが要求される。

• 変更が、コンポーネント構成 で コミットするまでの経過時間 として設定した期間を超えている。

ヒント

コミットは、すべてのコンポーネントに対して作成されます。そのため、多くのコンポーネントがある場合も、多くのコミットが表示されます。その場合は、Git コミットのスカッシュ アドオンを使用できます。

If you want to commit changes more frequently and without checking of age, you can schedule a regular task to perform a commit. This can be done using Periodic Tasks in Django 管理画面. First create desired Interval (for example 120 seconds). Then add new periodic task and choose weblate.trans.tasks.commit_pending as Task with {"hours": 0} as Keyword Arguments and desired interval.

スクリプトを使用するリポジトリの処理

Weblate がリポジトリとのやり取りをカスタマイズするには、アドオン を使用します。アドオンを使用して外部スクリプトを実行する方法については、アドオンから実行するスクリプト を確認してください。

コンポーネント間で翻訳を同じ状態に維持

複数の翻訳コンポーネントを作成したら、同じ文字列は同じ翻訳になるようにしてください。これはどの段階でも実現できます。

翻訳の反映

翻訳の自動反映の有効化 を有効にすると（デフォルトについては、参照: コンポーネント構成）、一致する文字列を持つすべてのコンポーネントで、すべての新しい翻訳が自動的に実行されます。このような翻訳は、すべてのコンポーネントの現在の翻訳ユーザーに適切に署名されます。

注釈

翻訳の反映は、キーがモノリンガルの翻訳形式と一致する必要があるため、翻訳キーの作成時には注意してください。

整合性検査

一貫性の欠如 検査は、文字列が一致しないたびに起動します。これを利用して、このような違いを手動で確認し、適切な翻訳を選択できます。

自動翻訳

異なるコンポーネントに基づく自動翻訳は、コンポーネント間で翻訳を同期する方法です。手動で起動する（参照: 自動翻訳）ことも、アドオンを使用してリポジトリの更新時に自動的に実行する（参照:ref:addon-weblate.auttranslate.auttranslate）こともできます。