# 翻訳

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の実行時に使われるものではありません。

```bash
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`が実行され、古いコンパイル済みファイル、抽出の問題、ロケール対応の不足があると失敗します。生成は引き続きメンテナーが明示的に行う操作です。