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