Weblate との連携¶
Weblate の基本¶
プロジェクトとコンポーネントの構造¶
Weblate では、翻訳はプロジェクトとコンポーネントで構成されています。各プロジェクトには複数のコンポーネントを含めることができ、コンポーネントには個々の言語への翻訳を含めることができます。コンポーネントは、翻訳可能な 1 つのファイル（例: GNU gettext PO（ポータブル オブジェクト） や Android 文字列リソース）に対応します。プロジェクトは、コンポーネントを論理的なまとまりに分類（例えば、1 つのアプリケーション内で使用するすべての翻訳をグループ化）するのに便利です。
さらに、プロジェクト内のコンポーネントは、カテゴリを使用して構造化できます。コンポーネントはカテゴリに属することができ、カテゴリは入れ子にできます。
内部ではデフォルトで、各プロジェクトごとに、共通する文字列の翻訳はプロジェクト内の他のコンポーネントに自動反映させます。これにより、反復や複数バージョンの翻訳の負担を軽減します。コンポーネント独自の翻訳が望ましい場合は、 翻訳の自動反映の有効化 を利用して翻訳の反映を コンポーネント構成 ごとに無効にできます。
リポジトリの統合¶
Weblate は上流のバージョン管理リポジトリと統合するように構築されています。継続的な現地語化 にはビルディング ブロックと、それらの間で変更がどのように流れるかについて説明されています。
参考
アーキテクチャの概要 は、Weblate 内部の動作原理を説明します。
ユーザー属性¶
Weblate は、翻訳者の氏名とメールアドレスを使用して、バージョン管理リポジトリ内に翻訳者の情報を適切に保存します。コミットに実際のメールアドレスを添付することは、分散型バージョン管理の精神に沿ったものであり、GitHub などのサービスが、Weblate で行われたあなたの貢献を GitHub プロフィールに関連付けることができます。
この機能は、バージョン管理コミット内に公開されたメールアドレスが悪用されるリスクも伴います。さらに、そのようなコミットが GitHub などの公開ホスティングで公開されると、事実上、それを削除する方法はありません。Weblate では、これを回避するために、アカウント でコミット用の匿名メールアドレスが選択できます。
したがって、管理者が考慮する必要がある Weblate の設定時の項目:
そのようなメールの使用については、サービス条件に明確に記載することが必要です。そのようなドキュメントが必要な場合は、法的文書 を参考になります。
PRIVATE_COMMIT_EMAIL_OPT_INを設定すると、デフォルトでメールアドレスを非公開にできます。
現地語化プロジェクトを Weblate にインポート¶
Weblate は基本機能として、VCS との連携を前提に開発されています。そのため、インポートする最も簡単な方法は、Weblate に対してリポジトリへのアクセス権を付与することです。インポートの処理では、翻訳を Weblate コンポーネントへ変換する設定の方法が表示されます。
また、Weblate では翻訳を統合せずに、すべての翻訳を含むローカル専用のリポジトリを設定することもできます。
Weblate の機能で更新済みの翻訳の取得¶
Weblate は、更新された文字列をデータベースに保存し、ローカルのバージョン管理リポジトリにコミットします。 Weblate リポジトリ（ Git エクスポーター が有効になっている場合）を別のリモートリポジトリとして追加し、そこから翻訳の更新を取得できます。
事前に、Weblate で行った保留中の変更をコミットしておいてください（参照: 遅延コミット）。これは、ユーザーインターフェイス（ リポジトリのメンテナンス ）または、Weblate クライアント を使用してコマンドラインから行います。
リポジトリへのプッシュを自動化するには、Weblate にリポジトリへのプッシュ アクセスを許可し、コンポーネント構成 で リポジトリの送信先 URL を設定します。参照: 変更点を Weblate からプッシュ。
または、Weblate の REST API を使用して、リモート VCS リポジトリの上流から最新バージョンに一致するように翻訳を更新してください。
リモートでの変更を Weblate に取り込む¶
Weblate が、リモート VCS リポジトリで最近更新された文字列を取得するには、Weblate に上流リポジトリからプルすることを許可してください。これは、ユーザーインターフェイス （リポジトリのメンテナンス から）、またはコマンドラインから Weblate クライアント を使用して行います。
これを自動化するには、リポジトリ内の Webhook を設定し、新しいコミットがあるたびに Weblate を起動するようにします。詳細は、リポジトリの更新 を確認してください。
VCS との連携を使用しない場合は、UI または Weblate の REST API を使用して、翻訳データをコードベースと同期させることができます。
新しい原文の追加¶
翻訳ファイルがコードと共にリモート VCS に保存されている場合、開発者が新しい文字列を追加するワークフローになっていることが多いです。どのような方法で文字列を追加するとしても、誤りが入らないように、原文の品質ゲートウェイ の使用を検討してください。
翻訳ファイルがコードから分離されている場合、次の方法で Weblate に新しい文字列を導入できます。
手動で、原文言語の ツール メニューから 新しい翻訳文字列を追加 を使用します。フォーム内のラジオ ボタン 単数形 と 複数形 を選択できます。追加する新しい翻訳文字列の適切な形式を選択します。
自動で、API
POST /api/translations/(string:project)/(string:component)/(string:language)/units/を使用します。原文のファイルを 既存の翻訳ファイルの置き換え としてアップロードします（これは既存の文字列を上書きするので、ファイルに古い文字列と新しい文字列の両方が含まれていることを確認してください)。または 新しい文字列の追加 をします。参照: インポート方法。
注釈
Weblate で文字列を追加するには、文字列の管理 が必要です。
翻訳対象の言語ファイルの更新¶
モノリンガル ファイル（参照: Localization file formats）の場合、Weblate は、モノリンガル用の、基礎となる言語ファイル に存在するが、実際の翻訳には存在しない新しい翻訳文字列を追加することがあります。しかし、Weblate は古い翻訳文字列を自動的に削除することはしません。これは、予期しない結果が生じる可能性があるためです。それでも削除したい場合は、翻訳ファイルのクリーンアップ アドオンをインストールしてください。このアドオンは、あなたの要件に応じてクリーンアップ処理をします。
また、Weblate はソースが変更されてもバイリンガル ファイルを更新しません。そのため、pot ファイルから po ファイルを更新する必要がある場合は、インポート方法 原文の更新 で手動で更新するか POT に合わせて PO ファイルを更新 (msgmerge) アドオンを使用してください。
ヒント
xgettext や lupdate などの原文抽出ツールは、Weblate の外部での実行が必要です。
新しい文字列の紹介¶
文字列の管理 を有効にして Weblate に新しい文字列を追加できます。しかし、通常は、新しい文字列を導入したコード変更と一緒に導入することをお勧めします。
モノリンガル形式では、新しい文字列が モノリンガル用の、基礎となる言語ファイル に追加されるように設定することが必要です。これは通常、コードの開発中に開発者が追加します。この文字列の査読は、原文の品質ゲートウェイ を使用してください。
通常、バイリンガル形式では何らかのツールを使用してソース コードから文字列を抽出します（like xgettext や intltool-update のように）。その方法については、現地語化フレームワークのドキュメントに従ってください。文字列が抽出されたら、既存の翻訳を更新するために追加の手順が必要になることがあります。参照: 翻訳対象の言語ファイルの更新。
ヒント
現在、Weblate では文字列抽出の自動化は対象外です。文字列抽出には、信頼されていないコードの実行が通常必要であるため、現地語化専用のプラットフォームよりも、一般的な継続的な現地語化に適しています。
これを継続的な連携パイプラインに統合して、新しい文字列を翻訳用に自動的に表示させることもできます。このようなパイプラインは マージ競合の回避 もカバーする必要があります。
ローカル VCS リポジトリの管理¶
Weblate は、すべての翻訳を基礎となるバージョン管理リポジトリに保存します。リモート リポジトリに接続することをお勧めしますが、内部のみの設定も可能です。リポジトリのメンテナンス を使用すると、このリポジトリを管理できます。
ヒント
With 継続的な現地語化, any changes are automatically pushed from the repository, so there is usually no need to manage it manually.
