コンテンツへスキップ

翻訳

Markdownとして表示

Blockstudioは翻訳をlanguagesフォルダーに格納しています。サイトの言語、またはユーザープロフィールの言語がいずれかの翻訳に一致すると、WordPressがその翻訳を使用します。Blockstudioをプラグイン、必須プラグイン、またはComposerパッケージとして実行する場合も、同様に機能します。

対応言語

Blockstudioには、同梱のlanguages/locales.jsonに記録されているWordPressのロケール向け翻訳が含まれています。地域別や敬体・常体のバリエーションも含まれます。英語（en_US）はソース言語であり、翻訳ファイルは必要ありません。この一覧は、GlotPressでWordPressがサポートするロケールと、WordPressコア翻訳APIで利用できるバリエーションをまとめたものです。

既存のドイツ語（de_DE）と敬体のドイツ語（de_DE_formal）の翻訳はそのまま保持されています。追加された翻訳はGPT-6 Lunaで生成され、.poヘッダーで機械生成と明記されています。自動の完全性チェックと形式チェックには合格していますが、すべてがネイティブスピーカーによるレビューを受けたわけではありません。修正を歓迎します。

翻訳は、ブロックエディターのフィールドコントロール、管理ページ、キャンバス、devtoolsオーバーレイ、およびRESTエンドポイントのメッセージを対象としています。独自のblock.jsonファイルにあるラベルやヘルプテキストは、テーマまたはプラグインに属し、そのテキストドメインを使用します。

設定 > 一般 > サイトの言語で言語を選択するか、WordPressプロフィールで個人用の言語を選択してください。Blockstudioはそのロケールを自動的に使用します。WordPressの言語セレクターに言語を追加することはありません。ロケールは、WordPressのインストール環境でも利用可能である必要があります。サイトでAIへのリクエスト、翻訳サブスクリプション、追加のランタイム設定は必要ありません。

翻訳を上書きする

wp-content/languages/plugins内の翻訳ファイルは、同梱ファイルより優先されます。PHP文字列（blockstudio-de_DE.moまたはblockstudio-de_DE.l10n.php）とスクリプト（スクリプトハンドルごとに1ファイル。たとえばblockstudio-de_DE-blockstudio-blocks.json）の両方が対象です。

翻訳に参加する

各言語は.poファイルで、任意のテキストエディターやPoeditなどの翻訳ツールで編集できます。修正や新しい言語の追加をプルリクエストで歓迎します。

  1. 言語を追加するには、languages/blockstudio.potをlanguages/blockstudio-<locale>.poにコピーします（例：blockstudio-fr_FR.po）。次に、LanguageとPlural-Formsのヘッダーを設定します。既存の言語を改善するには、その.poファイルを編集します。
  2. 文字列を翻訳します。%1$sなどのプレースホルダーは翻訳内に残してください。
  3. npm run i18nを実行します。WordPressが読み込む.mo、.l10n.php、および.jsonファイルが生成されます。
  4. .poファイルを生成ファイルとともにコミットし、プルリクエストを作成します。

npmを実行できない場合は、.poファイルだけを含むプルリクエストでも構いません。生成ファイルはマージ前に追加できます。

不足している翻訳を生成する

メンテナーは、認証済みのCodex CLIを使って不足している項目を生成できます。これは任意の開発用コマンドであり、WordPressの実行時に使われるものではありません。

シェル
npm run i18n:translate -- --dry-run
npm run i18n:translate

デフォルトのモデルはgpt-6-lunaです。1つのロケールを対象にするには、npm run i18n:translate -- --locale fr_FRを使います。このコマンドは最新のソース文字列を抽出し、不足している翻訳を補完した後、.mo、.l10n.php、およびスクリプトごとの.jsonファイルをコンパイルします。Codexに送信されるのは、公開インターフェースの文字列、そのコンテキスト、既存の形式だけであり、サイトのコンテンツやユーザーデータは送信されません。

既存の空でない翻訳が置き換えられることはありません。完了したバッチは保存されるため、中断後に再実行すると不足している作業から再開できます。%1$sやHTMLのマークアップなどのプレースホルダー、技術的な識別子、必要な複数形は、保存前に検証されます。fuzzyエントリーやソースの複数形に変更があった場合は、翻訳者によるレビューのためにそのまま残されます。要求したモデルが利用できない場合、別のモデルへのフォールバックは行われません。

npm run i18n:localesは、WordPress/GlotPressからロケール一覧と複数形のルールを明示的に更新します。npm run i18n:coverageは、チェックイン済みの一覧にあるすべてのロケールが揃っているか確認します。網羅性チェックも通常のCIも、AIを呼び出したりロケールデータを取得したりしません。一括処理、並行処理、復旧のオプションについては、リポジトリのREADMEを参照してください。

コード内の翻訳可能な文字列

  • PHP: blockstudioテキストドメインを指定してWordPress関数を使用します。例: __( 'Invalid block.', 'blockstudio' )。
  • JavaScript: @/utils/__から__をインポートし、リテラル文字列を渡します。例: __( 'Add row' )。実行時に組み立てられる文字列は翻訳できないため、バリアントごとに1つのリテラル文字列を使用してください。
  • 翻訳可能な文字列を含む新しいスクリプトバンドルには、scripts/i18n.tsへのエントリーと、同じハンドルおよびTranslations::script_path()を指定したwp_set_script_translations()の呼び出しが必要です。

文字列を変更した後、npm run i18nを実行します。languages/blockstudio.potとすべての.poファイルが更新されます。翻訳者またはnpm run i18n:translateが入力するまで、新しい文字列は英語のままです。CIではnpm run i18n:checkとnpm run i18n:coverageが実行され、古いコンパイル済みファイル、抽出の問題、ロケール対応の不足があると失敗します。生成は引き続きメンテナーが明示的に行う操作です。