翻訳プロジェクト#
翻訳データの構造#
Weblate は、プロジェクト / コンポーネントの翻訳可能な VCS コンテンツをツリー状の構造に整理します。さらに、プロジェクト内でコンポーネントをカテゴリで整理できます。
最下位レベルのオブジェクトは プロジェクトの設定 であり、すべての翻訳をまとめて保持することが必要です（たとえば、複数のバージョンのアプリケーションの翻訳および付属のドキュメントなど）。
中間レベルは、必要に応じて カテゴリ を作成できます。カテゴリを入れ子にして、より複雑な構造を実現できます。
その上のレベルである コンポーネント構成 （実際に翻訳するコンポーネント）では、使用する VCS リポジトリと翻訳するファイルのマスクを定義します。
コンポーネント構成 の上には個々の翻訳があり、翻訳ファイル（コンポーネント構成 で定義した ファイル マスク と一致する）が VCS リポジトリに反映されると Weblate によって自動的に処理されます。
Weblate は、Translate Toolkit が対応している幅広い翻訳ファイル形式（バイリンガルとモノリンガルの両方）に対応しています。参照: 対応するファイル形式。
注釈
クローンした VCS リポジトリは、Weblate の内部 URL を使用して共有できます。同じ VCS を共有する多くのコンポーネントがある場合、必ずこの機能を使用してください。これにより、性能が向上し、必要なディスク容量が減少します。
翻訳プロジェクトとコンポーネントの追加#
アクセス権があれば、新しい翻訳プロジェクトおよびコンポーネントを作成できます。これは、新しいプロジェクトの追加 権限を持つユーザーには常に許可されています。有料のインスタンスを使用している場合（例: https://hosted.weblate.org/ 参照: 課金）、課金を管理するユーザー アカウントから、プランの割り当て基づいて作成することもできます。
ヒント
新しいプロジェクトを作成する権限をすべてのユーザーに付与するには、プロジェクト作成者 チーム用に新しい 自動チーム割り当て を作成します。
別のページで、現在の請求プランを表示した例:
ここからプロジェクトの作成を開始できます。また、ナビゲーション バーのメニューから、翻訳プロジェクトに関する基本情報を入力し、プロジェクトを追加できます。プロジェクト作成画面:
プロジェクトを作成すると、プロジェクト ページに直接移動します。移動画面:
新しい翻訳コンポーネントの作成は、そこをクリックするだけで開始できます。コンポーネントの作成は複数の段階に分かれ、ほとんどの翻訳パラメータは自動的に検出されます。コンポーネントを作成する複数の方法:
- バージョン管理から
リモート バージョン管理リポジトリからコンポーネントを作成します。
- 既存のコンポーネントから
別のファイルを選択して、既存のコンポーネントに新しいコンポーネントを追加します。
- ブランチの追加
別のブランチ用に、既存のコンポーネントに新しいコンポーネントを追加します。
- 翻訳ファイルのアップロード
バージョン管理をしていない、または Weblate と連携したくない場合に、翻訳ファイルを Weblate にアップロードします。あとから Web 画面または、Weblate の REST API を使用してコンテンツを更新できます。
- ドキュメントの翻訳
1 つの文書または翻訳ファイルをアップロードして翻訳します。
- ゼロから始める
空の翻訳プロジェクトを作成し、文字列を手動で追加します。
既存の翻訳コンポーネントがあれば、同じリポジトリを使用して追加のファイルやブランチに新しいコンポーネントを簡単に追加できます。
まず、名前とリポジトリの場所の入力が必要です。入力画面:
次のページでは、検出された翻訳可能なリソースの一覧が表示されます。翻訳可能なリソース一覧:
最後のステップとして、翻訳コンポーネント情報を確認し、オプションの詳細を入力します。入力画面:
プロジェクトの設定#
翻訳プロジェクトを作成し、プロジェクトに翻訳用の新しいコンポーネントを追加します。プロジェクトは、実際の翻訳が積み重ねられた棚のようなものです。同じプロジェクト内のすべてのコンポーネントは、提案と辞書を共有します； 翻訳は、単一プロジェクト内のすべてのコンポーネント（コンポーネントの設定で無効していない限り）にも自動的に反映されます。参照: 翻訳メモリ。
参考
次はプロジェクトを設定し、翻訳者に通知する基本属性:
プロジェクト名#
プロジェクト名を表示するために使用する、詳細なプロジェクト名。
URL スラッグ#
URL に適したプロジェクト名。
プロジェクトの Web サイト#
翻訳者がプロジェクトの詳細情報を確認できる URL。
これは、WEBSITE_REQUIRED で無効にしない限り、必須のパラメーターです。
翻訳についての説明#
プロジェクトの現地語化の手順を解説する文章、および翻訳者に役立つその他の情報。マークダウンは、テキストの書式設定やリンクの挿入に使用します。
"Language-Team" ヘッダーの設定#
Weblateが Language-Team ヘッダーを管理する必要があるかどうか（これは現在 GNU gettext PO (Portable Object) のみの機能）。
アクセス制御#
プロジェクトごとにアクセス制御を設定します。詳細については、プロジェクトのアクセス制御 を確認してください。
デフォルト値は DEFAULT_ACCESS_CONTROL で変更できます。
査読の有効化#
翻訳の査読処理を有効にします。参照: 専任の査読者。
参考
原文の査読の有効化#
原文の査読ワークフローを有効にします。参照: 原文の査読。
フックの有効化#
このリポジトリで、認証していない 通知フック を使用するかどうか。
言語の別名#
翻訳を Weblate にインポートするときに、言語コードのマッピングを定義します。これは、リポジトリで言語コードに一貫性がなく、Weblate で一貫性のある表示をする場合、または翻訳ファイルに非標準の名前を付ける場合に使用します。
アメリカ英語を英語にマッピングする、典型的な使用例: en_US:en
コンマで区切る、複数のマッピング例: en_GB:en, en_US:en
非標準コードの使用例: ia_FOO:ia
ヒント
言語コードは翻訳ファイルとの照合時にマッピングされ、大文字と小文字は区別されます。そのため、原文の言語コードはファイル名と同じ形式にしてください。
コンポーネント構成#
コンポーネントとは、翻訳対象をグループ化したものです。翻訳するファイルの VCS リポジトリの場所とファイル マスクを入力すると、Weblate は VCS から自動的に取得し、一致するすべての翻訳可能ファイルを検索します。
参考
一般的な設定例については、対応するファイル形式 を確認してください。
注釈
翻訳コンポーネントは適切なサイズを維持してください — 翻訳を意味のあるもの（個々のアプリやアドオン、本の章や Web サイト）に分割してください。
Weblate は、1 万個の文字列の翻訳を簡単に処理できますが、大きな翻訳コンポーネントを使用する翻訳者間で作業を分割して調整することは困難です。
翻訳したい言語の定義がない場合は、空の定義が作成され、"cs_CZ (generated) " という名前が付けられます。この定義を編集して Weblate の作成者に報告すると、次のリリースで足りない言語が含まれます。
コンポーネントには、VCS を操作したり、VCS から翻訳を取得するために必要な重要なパラメータはすべて含まれています。
コンポーネント名#
コンポーネント名を表示するために使用する、詳細なコンポーネント名。
コンポーネント スラッグ#
URL 用のコンポーネント名。
コンポーネント プロジェクト#
コンポーネントが所属する プロジェクトの設定。
バージョン管理システム#
使用する VCS。詳細については、バージョン管理との連携 を確認してください。
ソースコードのリポジトリ#
変更のプルに使用する VCS リポジトリ。
参考
URL の指定方法の詳細については、リポジトリへの接続 を確認してください。
ヒント
これは、実際の VCS の URL か、リポジトリを別のコンポーネントと共有する必要があることを示す weblate://project/component のいずれかです。詳細については、Weblate の内部 URL を確認してください。
リポジトリの送信先 URL#
プッシュに使用するリポジトリ URL です。この動作は バージョン管理システム に依存しており、この詳細は 変更点を Weblate からプッシュ に解説があります。
リンクされたリポジトリの場合、これは使用されません。リンクされたコンポーネントの設定が適用されます。
参考
リポジトリの URL の指定方法の詳細については リポジトリへの接続 を、Weblate から変更をプッシュする方法の詳細については 変更点を Weblate からプッシュ を確認してください。
リポジトリ ブラウザー#
ソースファイル（使用した原文の位置）の表示に使用する、リポジトリ ブラウザーの URL。空の場合、位置表示のリンクは生成されません。テンプレート用のマークアップ が使用できます。
GitHub での使用例: https://github.com/WeblateOrg/hello/blob/{{branch}}/{{filename}}#L{{line}}
パスが、別のフォルダへの相対パス（.. を含むパス）である場合、先頭のディレクトリを parentdir フィルター（参照: テンプレート用のマークアップ）を使用して取り除いてください。ディレクトリの除去方法: https://github.com/WeblateOrg/hello/blob/{{branch}}/{{filename|parentdir}}#L{{line}}
エクスポートするリポジトリ URL#
Weblate で行われた変更をエクスポートする URL。これは、継続的な現地語化 を使用していない場合、または変更を手動でマージすることが必要な場合に重要となります。Git リポジトリの場合は、Git エクスポーター を使用してエクスポートを自動化できます。
リポジトリのブランチ#
VCS からチェックアウトするブランチと、翻訳を検索する場所です。
リンクされたリポジトリの場合、これは使用されません。リンクされたコンポーネントの設定が適用されます。
プッシュ先のブランチ#
変更をプッシュするためのブランチは、空のままにして リポジトリのブランチ を使用します。
リンクされたリポジトリの場合、これは使用されません。リンクされたコンポーネントの設定が適用されます。
注釈
現在、Git、GitLab、および GitHub にのみ対応しており、他の VCS との連携では無効になります。
ファイル マスク#
パスを含む、翻訳するファイルのマスク。言語コード（処理方法、参照: ref:languages）を置き換えるために "*" を 1 つ含めてください。リポジトリに複数の翻訳ファイル（多数の gettext ドメインなど）が含まれている場合は、それぞれにコンポーネントを作成してください。
例: po/*.po または locale/*/LC_MESSAGES/django.po。
ファイル名に [, ] などの特殊文字が含まれている場合、[[] または []] としてエスケープすることが必要です。
スクリーンショット ファイルのマスク#
この機能により、VCS リポジトリからのパスを使用して、スクリーンショット ファイル マスクを通じてスクリーンショットの検出と更新が可能になります。これはコンポーネント レベルで動作するため、スクリーンショット ファイル名をアスタリスク「*」で置き換えることが必要です。
使用できる形式は、WebP、JPEG、PNG、APNG、および GIF です。
注意:
ファイルマスクとスクリーンショット ファイル マスクは連携していません。これは個別に設定します。
コンポーネントで検出されたスクリーンショットを特定の翻訳キーにリンクするのは手作業です。
例:
VCS リポジトリが次のような構造になっていると仮定します:
component_A
└── docs
├── image1.png
└── image2.jpg
component_Aに対して、PNG形式のスクリーンショットの検出と更新を許可したい場合、component_Aのスクリーンショットファイルマスクを component_A/docs/*.png と設定します。これにより、component_A の docs ディレクトリ内の PNG 画像が検出されて更新されることが可能になります。したがって、例えば image1.png を更新したい場合、提供する新しいスクリーンショットは既存の filename と一致するように image1.png と名前を付け、component_A/docs/ ディレクトリ内へ保存することが必要です。
モノリンガル用の、基礎となる言語ファイル#
モノリンガル コンポーネント の文字列を定義した、基礎となる翻訳ファイルです。
基礎となる翻訳ファイルの編集#
モノリンガル用の、基礎となる言語ファイル 内の文字列の編集を許可するかどうか。
中間言語ファイル#
モノリンガル コンポーネント の中間言語ファイル。ほとんどの場合、これは開発者によって提供される翻訳ファイルであり、実際の原文を作成するときに使用されます。
設定すると、原文はこのファイルに基づきますが、他のすべての言語は モノリンガル用の、基礎となる言語ファイル に基づきます。文字列が原文の言語に翻訳されていない場合、他の言語への翻訳は禁止されます。これにより、 原文の品質ゲートウェイ が提供されます。
新しい翻訳のテンプレート#
新しい翻訳を生成するために使用する基礎となる翻訳ファイル。
ほとんどのモノリンガル形式では、このフィールドを空のままにしておいてください。これらは通常、空のファイルから開始できます。
GNU gettext PO ファイルを含む
.potファイルを選択します。翻訳がない場合は、空白のファイルを選択します。
キーの完全なセットが必要なモノリンガル形式の場合は、モノリンガル用の、基礎となる言語ファイル を選択します。
ドキュメントの翻訳には、モノリンガル用の、基礎となる言語ファイル を選択します。
他の翻訳ファイルを選択します。
通常、テンプレート ファイルはベース ファイルと同じにできます。
ヒント
Weblate は、さまざまなモノリンガル形式として開始する場合、デフォルトで空のファイルを用意します。新しい翻訳を作成するときに、すべての文字列を空の値として設定する場合に使用します。
ファイル形式#
翻訳ファイル形式、 参照: 対応するファイル形式。
原文ミスの報告先アドレス#
上流のバグの報告に使用するメール アドレス。このアドレスは、Weblate が作成した原文へのコメントについての通知も受け取ります。
GNU gettext PO (Portable Object) 形式では、このアドレスはファイルの Report-Msgid-Bugs-To ヘッダーに Weblate によって保存されます。
翻訳の自動反映の有効化#
同じプロジェクト内の他のコンポーネントから、このコンポーネントへの翻訳の自動反映を無効にできます。これは何を翻訳しているかによりますが、翻訳を個別に行う方が望ましい場合もあります。
通常、プロジェクト全体で同じ ID を使用していない限り、モノリンガル翻訳ではこれを無効にしてください。
デフォルト値は DEFAULT_TRANSLATION_PROPAGATION で変更します。
提案の有効化#
このコンポーネントの翻訳の提案を採用するかどうか。
参考
提案への投票#
提案に対する投票の有効化。参照: 提案への投票。
参考
Automatically accept suggestions#
投票が集まった提案の自動採用。参照: 提案への投票。
参考
翻訳フラグ#
品質検査やその他の Weblate の動作のカスタマイズ。参照: フラグを使用した動作の設定。
検査の強制#
除外できない検査一覧。参照: 検査の強制。
注釈
検査を強制しても自動的に有効化されません。 翻訳フラグ または 原文の追加情報 の フラグを使用した動作の設定 を使用して有効化してください。
翻訳のライセンス#
翻訳のライセンス（ソースコードのライセンスと同一である必要はありません） 。
貢献者同意条項#
ユーザーがこのコンポーネントを翻訳する前に必要な同意書。
新しい翻訳の追加#
新しい言語の作成依頼の取り扱い方法。次の選択肢があります。
- 保守担当者に連絡
ユーザーは希望する言語を選択して、プロジェクトの保守担当者は言語についての通知を受け取ります。言語をリポジトリに追加するかどうかは、担当者次第です。
- 翻訳案内の URL の指定
ユーザーには、新しい翻訳を開始する過程の説明ページへのリンクを表示します。これは、より正式な過程を必要とする場合（たとえば、実際の翻訳を開始する前にチームを結成する場合など）に使用します。
- 新しい言語ファイルの作成
ユーザーが言語を選択すると、Weblate が自動的に必要なファイルを自動生成し、翻訳を開始できます。
- 新しい翻訳の追加の無効化
ユーザーが新しい翻訳を開始できなくなります。
ヒント
プロジェクト管理者は、ここで無効化されている場合でも、対応（新しい翻訳のテンプレート またはファイル形式が空のファイルからの開始に対応している場合）していれば新しい翻訳を追加できます。
文字列の管理#
バージョン 4.5 で追加.
Weblate のユーザーが新しい文字列を追加したり、既存の文字列を削除したりすることを許可するかどうかを設定します。現地語化ワークフロー（新しい文字列の導入方法）に合わせて調整します。
バイリンガル形式の場合、文字列は通常、ソースコードから抽出（例: xgettext）されるので、Weblate での新しい文字列の追加は、無効にすることが必要です（次回、翻訳ファイルを更新したときに破棄される） 。Weblate では、すべての翻訳の文字列を管理できますが、すべての翻訳の文字列の一貫性を強制するわけではありません。
モノリンガル形式の場合、文字列は原文言語でのみ管理され、翻訳で自動的に追加または削除されます。文字列は、翻訳すると翻訳ファイルに反映されます。
ヒント
モノリンガル形式では、文字列の管理 と一緒に 基礎となる翻訳ファイルの編集 を有効にしてください。
言語コード スタイル#
Weblate が自動生成する翻訳のファイル名の言語コードをカスタマイズします。
注釈
Weblate は、翻訳ファイルを解析するときにすべての言語コードを認識します。次の設定は、新しいファイルの作成方法にのみ影響します。
- ファイル形式に応じたデフォルト
ファイル形式によって異なるが、ほぼ POSIX が使用される。
- アンダースコアを区切り文字とする POSIX 形式
通常、gettext および関連ツールで使用され、
pt_BRのような言語コードを生成する。- 国コードを含む、下線を区切り文字とする POSIX 形式
必要でない場合でも国コードを含む POSIX 形式の言語コード（例:
cs_CZ）。- 国コード（小文字）を含む、アンダースコアを区切り文字とする POSIX 形式
必要でない場合でも国コードを含む（小文字の）POSIX 形式の言語コード（例:
cs_cz）。- ハイフンを区切り文字とする BCP 形式
通常、Web プラットフォームで使用し、
pt-BRなどの言語コードを生成する。- 国コードを含む、ハイフンを区切り文字とする BCP 形式
必要でない場合でも国コードを含む BCP 形式の言語コード（例:
cs-CZ）。- 従来の言語コードを使った、ハイフンを区切り文字とする BCP 形式
中国語の従来の言語コードと BCP スタイルの表記を使用する。
- 小文字で、ハイフンを区切り文字とする BCP 形式
BCP スタイルの記法。全て小文字で表記する（例:
cs-cz）。- Apple App Store のメタデータ形式
メタデータを Apple App Store にアップロードするのに適したスタイル。
- Google Play のメタデータ形式
メタデータを Google Play ストアにアップロードするのに適したスタイル。
- Android 形式
Android アプリでのみ使用し、
pt-rBRのような言語コードを生成する。- Linux 形式
Linux で使用するロケール。ロケールは、中国語や POSIX 形式の表記にレガシーコードが使用されています。
マージ スタイル#
上流リポジトリからの更新の処理方法を設定できます。実際の実装は VCS に依存します。参照: バージョン管理との連携。
- リベース
更新時に上流リポジトリの上に Weblate でのコミットをリベースします。これにより、追加のマージ コミットをせずにクリーンな履歴を提供できます。
リベースは、複雑なマージの場合には問題が発生することがあります。そのため、有効にするかどうかは慎重に検討してください。
特に別のブランチにプッシュする場合は、Git に強制プッシュ を バージョン管理システム として選択してから、強制プッシュを有効にしてください。
- マージ
上流リポジトリの変更は、Weblate リポジトリにマージされます。この設定では、可能な場合は fast-forward を使用します。これは最も安全な方法ですが、多くのマージ コミットが生成されることがあります。
- fast-forward なしでマージする
上流リポジトリの変更は、（fast-forward が可能な場合でも）毎回マージ コミットを実行して Weblate にマージされます。すべての Weblate の変更は、Weblate リポジトリではマージ コミットとして表示されます。
デフォルト値は、DEFAULT_MERGE_STYLE で変更できます。
コミット、追加、削除、マージ、アドオン、およびマージ リクエストのメッセージ#
翻訳のコミット時に使用するメッセージ。参照: テンプレート用のマークアップ。
デフォルト値は、 DEFAULT_ADD_MESSAGE、DEFAULT_ADDON_MESSAGE、DEFAULT_COMMIT_MESSAGE、DEFAULT_DELETE_MESSAGE、DEFAULT_MERGE_MESSAGE、DEFAULT_PULL_MESSAGE で変更します。
コミット時にプッシュする#
コミットされた変更を上流リポジトリに自動的にプッシュするかどうか。有効にすると、Weblate が基になるリポジトリ（参照: 遅延コミット）に変更をコミットした時点でプッシュが開始されます。実際にプッシュを有効にするには、リポジトリのプッシュ URL の設定も必要です。
コミットするまでの経過時間#
変更が、バックグラウンド タスクまたは commit_pending 管理コマンドによりコミットされるまでの経過時間（時間単位）を設定します。設定した経過時間より古い変更が 1 つでもあれば、コンポーネントのすべての変更はコミットされます。
デフォルト値は、COMMIT_PENDING_HOURS を変更します。
ヒント
保留中の変更がコミットされる状況は他にもあります。参照: 遅延コミット。
エラー時のロック#
上流リポジトリへの最初のプッシュまたはマージ、あるいは上流リポジトリからのプルに失敗した場合に、そのコンポーネント（およびリンクされたコンポーネント、参照: Weblate の内部 URL）をロックします。これにより、手動での解決が必要な別の競合の追加を回避します。
コンポーネントは、リポジトリのエラーがなくなると自動的にロックが解除されます。
原文の言語#
原文に使用する言語。英語以外から翻訳する場合は、これを変更してください。
ヒント
英語から翻訳してバイリンガルのファイルを作成しているが、英語への翻訳でも修正を行えるようにする場合、English (Developer) を選択して、原文の言語の名前と、既存の翻訳の名前との競合を避けます。
この場合、モノリンガル翻訳では、中間翻訳を使用します。参照: 中間言語ファイル。
言語フィルター#
ファイル マスクのスキャン時に、翻訳ファイルをフィルター処理する正規表現。Weblate が管理する言語のリストを制限するために使用します。
注釈
ファイル名に付加する言語コードのリストが必要です。
フィルター処理の例:
フィルターの説明 |
正規表現 |
|---|---|
使用言語の選択 |
|
言語を除外する |
|
2 文字のコードのみ |
|
言語以外のファイルを除外する |
|
すべてのファイルを含める（既定） |
|
別表記を特定する正規表現#
文字列の別表記を特定するために使用する正規表現。参照: 文字列の別表記。
注釈
ほとんどの項目は、Weblate 管理画面からプロジェクトの所有者または管理者が編集できます。
優先度#
優先度の高いコンポーネントから順に翻訳者に提供されます。
バージョン 4.15 で変更: これは、一致した用語集の用語の順序にも影響します。
アクセス制限#
注釈
この機能は、 Hosted Weblate では使用できません。
デフォルトでは、コンポーネントに変更を加えることができない場合でも、プロジェクトにアクセスできるすべてのユーザーにコンポーネントを表示します。これにより、プロジェクト内での翻訳の一貫性が維持しやすくなります。
コンポーネントまたはコンポーネント リストにアクセス制限をかけると、プロジェクトに付加されたアクセス権に関係なく、コンポーネントへのアクセス権が引き継がれます。明示的にアクセスを許可してください。これを行うには、新しいユーザー グループへのアクセスを許可し、そのグループにユーザーを登録するか、デフォルトの custom または private アクセス制御グループを使用して設定します。
デフォルト値は DEFAULT_RESTRICTED_COMPONENT で変更できます。
ヒント
これはプロジェクト管理者にも適用されます — ステータスを切り替えた後、コンポーネントに接続できなくならないように注意してください。
用語集として使用#
バージョン 4.5 で追加.
このコンポーネントを用語集として使用できます。用語集の色 を使用して、リストの表示方法を設定します。
用語集は、プロジェクトで共有 に定義したすべてのプロジェクトからアクセスできます。
用語集に新しい単語を追加できるようにするには、用語集で 文字列の管理 を有効にしてください。
参考
用語集の色#
一致した単語を表示するときに使用する用語集の表示色。
カテゴリ#
カテゴリは、プロジェクト内のコンポーネントに構造を与えるためのものです。カテゴリを入れ子にして、より複雑な構造を実現できます。
テンプレート用のマークアップ#
Weblate では、テキストのレンダリングが必要な複数の場所で、分かりやすいマークアップ言語を使用しています。これは The Django Template Language に基づいているので、非常に強力です。
現在使用している場所:
コミット メッセージの書式設定。参照: コンポーネント構成
- 複数のアドオン
コンポーネントのテンプレートで使用できる変数:
{{ language_code }}言語コード
{{ language_name }}言語名
{{ component_name }}コンポーネント名
{{ component_slug }}コンポーネント スラッグ
{{ project_name }}プロジェクト名
{{ project_slug }}プロジェクト スラッグ
{{ url }}翻訳 URL
{{ filename }}翻訳ファイル名
{{ stats }}翻訳統計、これにはさらに属性があります。以下は例です。
{{ stats.all }}文字列の総数
{{ stats.fuzzy }}査読が必要な文字列数
{{ stats.fuzzy_percent }}査読が必要な文字列の割合
{{ stats.translated }}翻訳済みの文字列数
{{ stats.translated_percent }}翻訳済みの文字列の割合
{{ stats.allchecks }}検査不合格の文字列数
{{ stats.allchecks_percent }}検査不合格の文字列の割合
{{ author }}現在のコミットの作成者。コミット範囲でのみ使用できる。
{{ addon_name }}現在実行しているアドオンの名前。アドオンのコミット メッセージでのみ使用できる。
リポジトリのブラウザーまたはエディタのテンプレートで使用できる変数:
{{branch}}現在のブランチ
{{line}}ファイル内の行
{{filename}}ファイル名、
parentdirフィルターを使用して、先頭の部分の削除もできます。例:{{filename|parentdir}}
ヒント
場所によっては、追加の変数が使用できます。参照: コンポーネントの検出。
フィルターと組み合わせる方法:
{{ component|title }}
条件の使用方法:
{% if stats.translated_percent > 80 %}Well translated!{% endif %}
文字の置換に使用できる追加のタグ:
{% replace component "-" " " %}
フィルターと組み合わせる方法:
{% replace component|capfirst "-" " " %}
追加された、ファイル名を操作するためのフィルター:
Directory of a file: {{ filename|dirname }}
File without extension: {{ filename|stripext }}
File in parent dir: {{ filename|parentdir }}
It can be used multiple times: {{ filename|parentdir|parentdir }}
...および、その他の Django テンプレート機能。
インポート速度#
VCS リポジトリの取得と Weblate への翻訳のインポートは、翻訳のサイズにもよりますが、処理に時間がかかります。解決のヒント:
設定の最適化#
デフォルトの設定は、Weblate のテストとデバッグには便利ですが、運用環境の設定には調整が不可欠です。設定により、性能は大きく左右されます。詳細については、 運用環境の設定 を確認してください。特に確認が必要なもの:
バックグラウンド タスクの実行に必要な Celery の設定（参照: Celery を使用するバックグラウンド タスク ）
リソース制限の確認#
大量の翻訳やリポジトリをインポートする場合は、サーバーのリソース制限の影響を受けます。
メモリの空き容量を確認します。オペレーティング システムに翻訳ファイルをキャッシュさせると、パフォーマンスが大幅に向上します。
処理する文字列が多数ある場合、ディスク操作がボトルネックになることがあります—ディスクは Weblate とデータベースの両方から書き込まれます。
CPU コアを追加すると、バックグラウンド タスクのパフォーマンスが向上することがあります（参照: Celery を使用するバックグラウンド タスク ）。
不要な検査の無効#
一部の品質検査には、非常にコストがかかります。不要な場合は省略するとインポート中の時間を短縮できます。 設定の詳細については CHECK_LIST を確認してください。
コンポーネントの自動生成#
プロジェクトに多くの翻訳ファイル（例: 異なる gettext ドメインまたは Android アプリの一部）がある場合は、それらを自動的に読み込みたくなります。これは、コマンド行から import_project または import_json を使用するか、コンポーネントの検出 アドオンをインストールすることで実行できます。
アドオンを使用するには、まず 1 つの翻訳ファイル（将来的に名前変更または削除する可能性が最も低いものを選択）用のコンポーネントを作成し、このコンポーネントにアドオンをインストールすることが必要です。
管理コマンドの場合は、すべてのコンポーネントを含むプロジェクトを作成してから、import_project または import_json の実行が必要です。
参考