継続的な現地語化

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

参考

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

処理の流れ:

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

2. オプションで、翻訳ファイルを更新する。参照: 新しい文字列の紹介。

3. Weblate は、VCS リポジトリから変更を取得し、翻訳ファイルを解析してデータベースを更新します。参照: リポジトリの更新。

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

5. 翻訳者が作業を完了したら、Weblate は変更をローカル リポジトリにコミットします（参照: 遅延コミット）。

6. 変更は、上流リポジトリにプッシュされます（参照: 変更点を Weblate からプッシュ）。

ヒント

上流のコード ホスティングは必要ありません。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 で発生した変更でのマージ競合の回避

Weblate が翻訳ファイルの唯一のソースである場合でも、Git コミットのスカッシュ アドオンを使用する場合、マージ スタイル が Rebase に設定されている場合、または Weblate 外でコミットを結合している場合（たとえば、プルリクエストをマージする場合）に、競合が発生することがあります。

この場合のマージ競合の理由は異なります。Weblate のコミットをマージした後、Weblate で変更が行われた場合に発生します。これは通常、マージが自動化されておらず、人間が査読するのに数日または数週間かかる場合に発生します。Git は、上流の変更を Weblate の変更と一致するものとして識別できなくなり、リベースの実行を拒否することがあります。

この問題に対処するには、プルリクエストをマージするときに Weblate の保留中の変更量を最小限に抑えるか、変更をスカッシュしないことで競合を完全に回避することが必要です。

これを回避する方法:

• マージ時に Git コミットのスカッシュ もスカッシュも使用しないでください。これが、マージ後に git が変更を認識しない根本的な原因です。

• マージする前に Weblate に保留中の変更をコミットさせます。これにより、すべての変更を含むプル リクエストが更新され、両方のリポジトリが同期されます。

• Weblate のレビュー機能を使用してください（参照: 翻訳ワークフロー）。これにより、CI が通過した後、GitHub プルリクエストを自動的にマージできます。

• Weblate でロックを使用すると、GitHub プル リクエストの査読中の変更を回避できます。

参考

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 から自動受信

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

参考

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

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

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

参考

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

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

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 リポジトリから自動受信

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 マージリクエスト、Azure DevOps プル リクエスト のプルリクエストまたは Gerrit 査読に対応しています。これを有効にするには、コンポーネント構成 で バージョン管理システム として GitHub、GitLab、Gitea、Gerrit、Azure DevOps または Pagure を選択します。

全体で使用できる、Git、Mercurial、GitHub、GitLab、Gitea、Pagure、および Azure DevOps のオプション:

理想的な初期設定	バージョン管理システム	リポジトリの送信先 URL	プッシュ先のブランチ
プッシュしない	Git	空	空
直接プッシュ	Git	SSH URL	空
別のブランチに push	Git	SSH URL	ブランチ名
プッシュしない	Mercurial	空	空
直接プッシュ	Mercurial	SSH URL	空
別のブランチに push	Mercurial	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]	ブランチ名
フォークからの Azure DevOps プル リクエスト	Azure DevOps プル リクエスト	空	空
ブランチからの Azure DevOps プル リクエスト	Azure DevOps プル リクエスト	SSH URL [1]	ブランチ名

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

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

注釈

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

参考

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

保護されたブランチ

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

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

他のユーザーとの対話

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

参考

Weblate の REST API

遅延コミット

Weblate は、可能であれば、同じ著者のコミットを 1 つのコミットにまとめます。これによりコミット数が大幅に削減されますが、例えばマージのために（これは、デフォルトで 管理者 グループに許可されます。参照: 権限一覧） VCS リポジトリと同期する場合は、明示的にコミットさせることが必要になります。

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

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

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

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

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

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

ヒント

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

経過時間を考慮せず頻繁に変更をコミットする場合は、定期的なタスクをスケジュールしてコミットを実行させます。これには、Django 管理画面 の Periodic Tasks を使用します。まず必要な Interval を作成します（例: 120秒）。次に、新しい定期タスクを追加し、Task に weblate.trans.tasks.commit_pending を、Keyword Arguments として {"hours": 0} を選択して必要な間隔時間を設定してください。

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

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

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

複数の翻訳コンポーネントを作成したとき、同じ文字列は同じ翻訳になるようにしたいことでしょう。これはいくつかのレベルで実現できます。

翻訳の反映

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

注釈

モノリンガルの翻訳形式では、キーが一致しないと翻訳は反映されません。翻訳キーの作成時には注意してください。

整合性検査

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

自動翻訳

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