継続的な現地語化

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

参考

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 でのみ翻訳ファイルを変更することで、マージ競合を回避する

• Avoiding merge conflicts by locking Weblate while doing outside changes

• Avoiding merge conflicts by focusing on Git operations

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

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

1. The extraction generates template (for example gettext POT is generated using xgettext).

2. Further process merges it into actual translations (the gettext PO files are updated using msgmerge).

You can perform the second step within Weblate and it will ensure that all pending changes are included before this operation.

Avoiding merge conflicts by locking Weblate while doing outside changes

Integrating Weblate into your updating process so that it flushes changes before updating the files outside Weblate can be achieved by using Weblate の REST API to force Weblate to push all pending changes and lock the translation while you are doing changes on your side.

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

# 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

If you have multiple components sharing the same repository, you need to lock them all separately:

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

注釈

The example uses Weblate クライアント, which needs configuration (API keys) to be able to control Weblate remotely. You can also achieve this using any HTTP client instead of Weblate クライアント, for example curl, see Weblate の REST API.

Avoiding merge conflicts by focusing on Git operations

Even when Weblate is the single source of the changes in the translation files, conflicts can appear when using Git コミットのスカッシュ add-on, マージ スタイル is configured to Rebase, or you are squashing commits outside of Weblate (for example, when merging a pull request).

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

To approach this, you either need to minimize the amount of pending changes in Weblate when you merge a pull request, or avoid the conflicts completely by not squashing changes.

これを回避する方法:

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

• Let Weblate commit pending changes before merging. This will update the pull request with all its changes, and both repositories will be in sync.

• Use the review features in Weblate (see 翻訳ワークフロー) so that you can automatically merge GitHub pull requests after CI passes.

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

参考

Weblate クライアント

変更を GitHub から自動受信

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

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

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

The Payload URL consists of your Weblate URL appended by /hooks/github/, for example for the Hosted Weblate service, this is 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 は、リモート リポジトリを夜間に自動的に取得し、後で変更をマージする性能を向上させます。オプションで AUTO_UPDATE の設定を有効にすると、これを夜毎のマージの実行に変更できます。

変更点を Weblate からプッシュ

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

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

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

Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center and 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 pull request from fork	Bitbucket Data Center pull requests	空	空
Bitbucket Data Center pull request from branch	Bitbucket Data Center pull requests	SSH URL [1]	ブランチ名
フォークからの Bitbucket Cloud プルリクエスト	Bitbucket Cloud pull requests	空	空
ブランチからの Bitbucket Cloud プルリクエスト	Bitbucket Cloud pull requests	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 がリポジトリとのやり取りをカスタマイズするには、アドオン を使用します。アドオンを使用して外部スクリプトを実行する方法については、アドオンから実行するスクリプト を確認してください。

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

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

翻訳の反映

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

注釈

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

整合性検査

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

自動翻訳

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