開発に合わせて翻訳を最新に保つ処理

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

参考

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 内と外部の両方で変更された場合に発生します。状況に応じて、役立つ可能性のある解決方法:

• Weblate でのみ翻訳ファイルを変更することで、マージ競合を回避する

• 外部で変更を行う際に Weblate をロックしてマージコンフリクトを回避する

• Git 操作に注視しマージの競合を回避する

Weblate でのみ翻訳ファイルを変更することで、マージ競合を回避する

Weblate の外で編集を避けることは、モノリンガル ファイルで簡単です。Weblate 上で新しい文字列を追加し、ファイルの編集も全てそこで行います。バイリンガル ファイルの場合、通常、ソースコードから翻訳可能なファイルを生成するため、何らかのメッセージ抽出プロセスがあります。場合によっては、これを 2 つの処理に分割できます。

1. 抽出によりテンプレートが生成されます（例: gettext POT は xgettext を使用して生成されます）。

2. その後のプロセスで、それは実際の翻訳にマージされます（gettext PO ファイルは msgmerge を使用して更新されます）。

この第2ステップは Weblate 内部で実行でき、その操作の前にすべての保留中の変更が含まれることを保証します。

外部で変更を行う際に Weblate をロックしてマージコンフリクトを回避する

Weblate を更新プロセスに組み込み、Weblate 外のファイルを更新する前に変更を反映させたい場合は、Weblate の REST API を利用して Weblate に保留中の変更をすべてプッシュさせ、作業中は翻訳をロックするように設定できます。

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

# 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 キーなどの）設定が必要です。Weblate クライアント の代わりに任意の HTTP クライアントを使って同じことを行うこともでき、たとえば curl を利用できます。詳細は Weblate の REST API を参照してください。

Git 操作に注視しマージの競合を回避する

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 フックの設定画面:

Payload URL 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/）。

問題解決方法

• Webhook が配信されているか、GitLab webhook request history を確認してください。

• レスポンスのペイロードには、一致したコンポーネントに関する情報が含まれています。

参考

• 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 フック リポジトリの中にある 設定 で指定します。

参考

• Gitea の Webhook マニュアル

• POST /hooks/gitea/

• Hosted Weblate からリポジトリへの接続

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

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

参考

• Gitee の Webhook マニュアル

• POST /hooks/gitee/

• Hosted Weblate からリポジトリへの接続

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

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

変更点を Weblate からプッシュ

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

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

In case you do not want direct pushes by Weblate, there is support for GitHub プルリクエスト, GitLab マージリクエスト, Gitea プルリクエスト, Pagure マージリクエスト, Azure DevOps プル リクエスト or Gerrit reviews, you can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as バージョン管理システム in コンポーネント構成.

Git、Mercurial、GitHub、GitLab、Gitea、Pagure、Azure DevOps、Bitbucket Data Center、および Bitbucket Cloud で使用可能なオプション:

理想的な初期設定	バージョン管理システム	リポジトリの送信先 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]	ブランチ名
Bitbucket Data Center のフォークからのプルリクエスト	Bitbucket Data Center のプルリクエスト	空	空
Bitbucket Data Center のブランチからのプルリクエスト	Bitbucket Data Center のプルリクエスト	SSH URL [1]	ブランチ名
フォークからの Bitbucket Cloud プルリクエスト	Bitbucket Cloud のプルリクエスト	空	空
ブランチからの Bitbucket Cloud プルリクエスト	Bitbucket Cloud のプルリクエスト	SSH URL [1]	ブランチ名

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

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

注釈

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

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

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

翻訳の反映

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

伝播の前提条件:

• すべてのコンポーネントは、単一のプロジェクト内に存在する必要があります（コンポーネントのリンクでは不十分です）。

• 一致する文字列の翻訳を自動的に再利用するには、翻訳の自動反映の有効化 を有効にしてください。

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

• 文字列は翻訳中に伝播されますが、リポジトリからロードされた文字列は伝播されません。

Tip

この機能には現在、制限事項があります。より普遍的なものにしたいと考えていますので、ぜひ https://github.com/WeblateOrg/weblate/issues/3166 でご意見をお聞かせください。

整合性検査

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

自動翻訳

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