開発に合わせて翻訳を最新に保つシステム

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

参考

Weblate との連携 describes basic ways to integrate your development with Weblate. Code hosting integrations lists provider-specific setup steps for common code hosting sites.

処理の流れ:

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

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

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

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

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

6. Changes are pushed back to the upstream repository (see 変更点を Weblate からプッシュ).

ヒント

上流のコード ホスティングは必要ありません。Weblate 内にリポジトリのみがある場合は、ローカル ファイル で Weblate を使用できます。

リポジトリの更新

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

• Use 通知フック to integrate with the majority of common code hosting services, see Code hosting integrations. You must also フックの有効化 for this to work.

• リポジトリ管理から、または 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 を参照してください。

リポジトリのメンテナンス

リポジトリ メンテナンス 画面では、プロジェクト、コンポーネント、翻訳単位ごとのリポジトリ状態を表示し、権限を持つユーザーが管理画面からメンテナンス操作を実行できます。

同じ操作は Weblate の REST API や、対応している範囲では Weblate クライアント からも実行できます。

各操作の利用可否は、権限、設定されたバージョン管理システム、プッシュ設定の有無、選択した対象がロック可能かどうかに依存します。

処理	何を行うか	代表的な使用例
コミット	保留中の変更を Weblate からローカル リポジトリにコミットします。	他の場所でリポジトリ作業を行う前に、Weblate 側の保留中変更をフラッシュします。
プッシュ	コミット済みのローカル リポジトリの変更を、設定された上流リポジトリにプッシュします。	自動プッシュが無効または遅延している場合に、コミット済みの翻訳を上流へ送信します。
更新	上流の変更を取得し、コンポーネントで設定された マージ スタイル を使用して統合します。	デフォルトの統合方式を使用して、Weblate を上流と同期させます。
マージして更新	上流の変更を取得し、明示的なマージで統合します。	単一の更新操作に限り、デフォルトのマージ方式を上書きします。
リベースして更新	上流の変更を取得し、Weblate のローカル コミットを上流の上にリベースします。	ワークフローに適している場合、履歴を時系列順に保持します。
fast-forward なしでマージして更新	上流の変更を取得し、fast-forward が可能な場合でも明示的なマージコミットを作成します。	監査やブランチ管理の理由でマージコミットを保持したい場合に使用します。
ロック / ロック解除	翻訳者が Weblate 上で変更を加えることを禁止または許可します。	Weblate 外でリポジトリ メンテナンスを行う間、翻訳の変更を一時的に凍結します。
リセットして破棄	Weblate のローカル リポジトリを上流にリセットし、Weblate 側の保留中変更を破棄します。	上流の状態でローカルの Weblate リポジトリを上書きしたい場合に使用します。
リセットして再適用	Weblate のローカル リポジトリを上流にリセットしつつ、保留中の翻訳を保持します。参照: リセットして復旧処理を再実行。	履歴が分岐してしまった場合でも、保留中の Weblate 翻訳を保持したまま復旧できます。
クリーンアップ	ローカル リポジトリのチェックアウトから、未追跡ファイルや古いブランチを削除します。	Weblate のチェックアウト内に残っている不要ファイルや古いリポジトリ状態をクリーンアップします。
同期	Weblate が把握しているすべての翻訳を、強制的にリポジトリ ファイルへ書き戻します。	リポジトリ ファイルがデータベースの状態とずれてしまった場合に修復します。
再スキャン	ローカル リポジトリから翻訳ファイルを再読み込みして Weblate に取り込みます。	手動でリポジトリ作業やファイル作成を行った後の変更を取り込むために使用します。

リセットして復旧処理を再実行

リセットして再実行 操作は、Weblate の保留中翻訳を保持したまま、ローカル リポジトリの状態を上流に合わせてリセットします。

対象言語ファイルがリセット後も存在する場合、またはコンポーネントが有効な 新しい翻訳のテンプレート を使用してファイルを作成できる場合に限り、保留中の翻訳を復元できます。

この条件を満たさない場合、Weblate は保留中の変更をデータベースに保持し、後で一般的なパースエラーとして失敗する代わりに、復旧エラーとして報告します。

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

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

The reason for merge conflicts is different in this case. Weblate can have new local commits after you merge earlier Weblate commits upstream. This typically happens if merging is not automated and changes wait for days or weeks for a human review. Git is then sometimes no longer able to identify upstream changes as matching the Weblate ones and refuses to perform a rebase.

Squash merging Weblate changes makes this harder to recover from. A squash merge creates a new commit instead of preserving the individual Weblate commits in the upstream history. Weblate still has the original commits in its local repository, and Git can no longer prove that upstream already contains them. If the conflict was also resolved manually, the file contents can differ from both repositories, so Weblate can keep failing to update even after the pull request was merged upstream.

If upstream no longer contains Weblate commits because they were squash merged, updating the repository might not be enough. Use Reset and reapply from Repository maintenance to reset Weblate to upstream while keeping pending translations; see リセットして復旧処理を再実行. Use Reset and discard only when upstream should fully replace Weblate's local changes.

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

これを回避する方法:

• Do not use Git コミットのスカッシュ or squash merging for Weblate changes. Squashing is why Git might no longer recognize the changes after merging.

• When resolving conflicts outside Weblate, merge the Weblate commits with a regular merge commit and push that result upstream. Do not squash merge the conflict-resolution pull request.

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

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

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

参考

Weblate クライアント

Code hosting notifications

Provider-specific app and webhook instructions for GitHub, GitLab, Bitbucket, Pagure, Azure Repos, Gitea, Forgejo, and Gitee are covered in Code hosting integrations.

Provider-specific notifications

These legacy anchors are kept for compatibility. Current provider-specific app and webhook setup is documented in Code hosting integrations.

参考

• GitHub notifications

• GitLab notifications

• Bitbucket notifications

• Pagure notifications

• Azure Repos notifications

• Gitea notifications

• Forgejo notifications

• Gitee notifications

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

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

変更点を Weblate からプッシュ

Each translation component can have a push URL set up (see リポジトリの送信先 URL), and in that case Weblate will be able to push changes to the remote repository. Weblate can also be configured to automatically push changes on every commit, see コミット時にプッシュする.

For the push options table and provider-specific pull, merge, and review request workflows, see 変更点を 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 でご意見をお聞かせください。

整合性検査

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

自動翻訳

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