experience-ui-bundle-localize

UI バンドルをローカライズする

UI バンドルをローカライズします。ユーザーに表示する文字列を Salesforce Custom Labels に抽出し、Platform SDK バックエンド上でランタイム i18n ライブラリを接続して、各ロケールのラベルを検証します。

このファイルでは、フレームワークに依存しないワークフローとガードレールの基本部分を説明します。i18n ライブラリ、翻訳呼び出しの規約、スキャン対象ファイル、接続方法、ドキュメントの詳細など、フレームワーク固有の内容は、フレームワークごとのリファレンスに記載されています。

1 段落で理解するメンタルモデル

UI バンドルでは、LWC のようにコンパイル時のラベルインポートを使用できません（@salesforce/label/* はプラットフォームのコンパイラー内で解決されますが、スタンドアロンのバンドルはその処理を通りません）。代わりに、アプリは Salesforce GraphQL UI API を通じて実行時にラベルを取得し、標準の i18n ライブラリに渡して表示します。Platform SDK は、ユーザーの言語を読み取る検出機能、GraphQL 経由でラベルを取得するバックエンド、コンテキスト取得機能を通じて、実行時の処理を担います。作成するファイルは 2 つだけです。SDK の各要素を i18n ライブラリに接続する短い初期化ファイルと、アプリが使用するラベルを一覧にしたマニフェストです。ラベル自体は Salesforce Custom Labels メタデータとして作成します。使用するライブラリと呼び出し規約はフレームワークによって異なります。詳しくは、お使いのフレームワークのリファレンスを参照してください。

ステップ 0：タスクの振り分け

タスクの内容	移動先
バンドルがまだ存在しない	experience-ui-bundle-frontend-generate スキル
ラベルを含めてアプリをデプロイする	experience-ui-bundle-deploy スキル
サイトの言語または sfdc_cms__languageSettings を設定する	experience-ui-bundle-site-generate スキル
既存のバンドルをローカライズする	フレームワークを特定して（以下を参照）、ワークフローに進む

フレームワークを特定します。 通常、呼び出し元のコンテキストによってすでに決まっています。このスキルを呼び出したコーディネータースキルから渡されているか、ユーザーのリクエストに記載されています。それを使用してください。

このスキルがサポートするフレームワークは、localize.md を含む <SKILL_DIR>/references/ 配下の参照フォルダーにあるものに限られます（たとえば react → <SKILL_DIR>/references/react/localize.md）。これが唯一の信頼できる情報源です。フレームワークを追加するには参照フォルダーを追加するだけで、ここを変更する必要はありません。

• フレームワークがわかっている場合 — <SKILL_DIR>/references/<framework>/localize.md を開き、この手順書と併せて参照してください。そこには、ライブラリ、呼び出し規約、スキャン対象ファイル、配線コードが記載されています。

• 不明な場合（どのフレームワークか指示されていない単独実行の場合）— 誰かに尋ねる前に、アプリまたは uiBundle のルートで決定的な検出を実行してください。

  bash "<SKILL_DIR>/scripts/detect-framework.sh" "<app-or-uiBundle-root>"
  

  この検出では、ルート以下にある angular.json、node_modules 以外の任意の package.json に含まれる @angular/core / react、およびソースファイルのシグネチャを組み合わせ、トークンを 1 つ出力して対応する終了コードを設定します。

  • react または angular（終了コード 0）→ 該当するフレームワークを使用します。ユーザーに尋ねないでください。検出結果は決定的です。<SKILL_DIR>/references/<framework>/localize.md を開いてください。
  • ambiguous（終了コード 2）→ 両方のフレームワークが存在します。<SKILL_DIR>/references/ を一覧表示し、どちらをローカライズするかユーザーに尋ねてください。参照フォルダーに存在しないフレームワークを指定された場合、ここではサポートされていないため、停止してください。
  • unknown（終了コード 3）→ サポート対象のフレームワークが検出されませんでした。ワークフローを終了してください。 推測して先に進んではいけません。バンドル内に React と Angular のどちらのシグナルも見つからず、ローカライズを続行できないことを報告し、ここで停止してください。

以下のステップで <framework> は、ここで選択したフォルダーを意味します。決定的なチェック用スクリプトは、依存関係に応じて分かれています。

• フレームワークに依存せず、<SKILL_DIR>/scripts/ に共通配置 — detect-framework.sh（上記のステップ 0 の検出スクリプト）、check-org-api-version.sh と detect-bundle-type.sh（組織／メタデータのみのチェック）、および check-manifest-registered.sh（汎用の骨組み。呼び出し箇所の文法を選択するには --framework <framework> を指定します）。
• フレームワーク固有で、<SKILL_DIR>/references/<framework>/ に配置 — check-i18n-wired.sh（マニフェストからバックエンドへの検出は i18n ライブラリの形式に依存するため、各フレームワークに固有のものが用意されています）。

---

前提条件：編集前に確認する

#	要件	確認方法	不足している場合
1	uiBundles/*/src/ のプロジェクト（React または Angular）である	プロジェクト構造が一致している	UI Bundle ではありません → 適切なスキルに振り分けてください
2	Platform SDK、UI Bundle、ビルドプラグインの各関連パッケージがインストールされ、バージョンが揃っている（≥11.49.3）	UI Bundle ディレクトリ内の package.json	バージョンを揃えてアップグレードするようユーザーに伝えてください。続行できません
3	アプリのマウント箇所を特定できる	エントリーファイルを読み取る（フレームワークのリファレンスを参照）	明確なマウント箇所がない → ユーザーに場所を示すよう依頼してください
4	対象の組織が実際に API v68.0 以降をサポートしている（UI Bundle 用の実行時ラベル GraphQL は Release 264 で提供開始）	以下の実行時組織リリース確認を実行	組織の最大 API バージョンが v68.0 未満（Release 262 以前） → 続行できません。Release 264 以降の組織を対象にするか、組織をアップグレードしてください
5	Bundle が認証済み B2E であるか、リクエスト／コンテキストで B2C サイトであることが明示されており、B2B ではない	以下の Bundle タイプ検出を実行し、サイトの製品種別にはリクエスト／コンテキストを使用	B2B であることが明示されている → 拒否してください。サイトの種別が明示されていない → ユーザーに確認し、確認が取れるまで停止してください。B2C の場合は前提条件 6 も必要です
6	B2C の場合のみ、管理者が GraphQLApiOrgPrefForGuestUsers を有効にしている	組織の設定がすでに有効になっていることを管理者に確認するよう依頼	有効化しないでください。これがないとゲストの GraphQL リクエストは HTTP 403 を返すことを説明し、停止してください（依存関係：W-23854208）

実行時組織リリース確認（前提条件 4）。 UI Bundle のラベルを実行時に解決する platform.labels GraphQL パスは、Salesforce Release 264（API v68.0 以降）で提供開始されます。sfdx-project.json の sourceApiVersion に記録されるのは宣言したバージョンであり、組織がサポートするバージョンではありません。そのため、新しい CLI を古い組織に対して実行すると、静的なファイル確認には通っても、実行時に失敗する可能性があります。何かを接続する前に、組織の実際の最大 API バージョンを照会してください。

bash <SKILL_DIR>/scripts/check-org-api-version.sh <org-alias-or-username>

終了コード 0 → 組織は v68.0 以降をサポートしています。続行してください。終了コード 1 → 組織が古すぎるか、到達できません。i18n の接続やラベルの記述は行わず、バージョンの不一致をユーザーに報告して停止してください。（スクリプト内の sf api request rest は CLI のトランスポート層で認証を行うため、アクセストークンがコンテキストに入りません。）

Bundle タイプ検出（前提条件 5）。 Bundle のタイプによって、適用するローカライズ分岐が決まります。これはフレームワークに依存しない（Salesforce メタデータのみを使った）処理です。Bundle ディレクトリのフルパスを渡してください。スクリプトがそこからメタデータのルートを導出するため、現在のディレクトリは関係ありません。

bash <SKILL_DIR>/scripts/detect-bundle-type.sh <path-to-uiBundles/<name>/ dir>

終了コードの仕様に従って対応してください。0 → 認証済みアプリ（B2E またはインコアの内部アプリ）。B2E 分岐を使用してください。10 → パブリックサイトにバインドされた app-container の候補です。サイトへのバインドとゲストアクセスはメタデータで確認できますが、B2C か B2B かは確認できません。11 → パブリックではない、またはサポート対象外のサイトにバインドされています。停止してください。12 → CustomApplication とサイトへのバインドの両方が存在します。ローカライズの対象となる実行時コンテキストをユーザーに確認してください。13 → 一致する Experience サイトのバインドが複数あります。報告されたサイト名を提示し、対象のサイト／実行時コンテキストをユーザーに確認してください。2 → バインドがないか不明です。スクリプトの出力を報告し、推測せずに停止してください。

終了コードが 10 の場合は、明示されたリクエスト／コンテキストに基づいて振り分けてください。B2C と記載されている場合は、前提条件 6 を確認して B2C 分岐を使用してください。B2B と記載されている場合は、拒否してください。製品種別が明示されていない場合は、サイトが B2C か B2B かをユーザーに確認し、確認が取れるまで停止してください。終了コードが 12 または 13 の場合は、ユーザーに実行時コンテキストを選んでもらい（終了コードが 13 の場合はサイトも選んでもらい）、その後、その分岐のフォールバックと前提条件を適用してください。DigitalExperienceConfig、appSpace、appContainer、AUTHENTICATED_WITH_PUBLIC_ACCESS_ENABLED から B2C だと推測してはいけません。認証値が示すのは、ゲストアクセスが有効であることです。

B2C の場合、GraphQLApiOrgPrefForGuestUsers を有効にできるのは組織管理者のみです。決してプロビジョニングしたり変更したりしないでください。これがない場合、ゲストのラベルリクエストは HTTP 403 を返します。利用可能状況は W-23854208 で追跡してください。 前提条件が満たされていない場合は、作業を中止してください。該当する問題を具体的にユーザーへ報告し、解決後に戻って対応する計画項目を記録してください。B2B バンドルまたは不明なバンドルには、i18n の設定や TODO マーカーを追加しないでください。

---

ワークフロー：5 つのステップ

各ステップには完了条件と、続行前に確認するための一時停止があります。フレームワーク固有の情報（ファイル拡張子、翻訳呼び出し、インストール、初期化コード）は、<SKILL_DIR>/references/<framework>/localize.md に記載されています。

ステップ 1：検出

目標： フレームワークのコンポーネントファイルを調べ、ユーザー向けのハードコードされた文字列を探します。（スキャンするファイル拡張子は、フレームワークのリファレンスに記載されています。）

スキャン対象：

• マークアップ内でユーザーに表示される文字列：見出しの Welcome → 候補
• ユーザーに表示される文字列プロパティ：placeholder="Enter name" → 候補
• ユーザー向けのアクセシブルテキスト：aria-label、aria-describedby、alt → 候補（スクリーンリーダーのユーザーにも読み上げられるため、これらもローカライズする必要があります）

スキップ対象：

• import 文
• オブジェクトキー／プロパティ名
• data-* 属性（機械可読）
• テスト ID（data-testid、id 属性）
• すでに翻訳呼び出しで囲まれているテキスト
• コンソールログ、開発者向けのエラーメッセージ（ユーザー向けではないもの）
• クラス名、ファイルパス、技術的な定数

作業：

1. src/ ディレクトリで、フレームワークのコンポーネントファイルをスキャンします
2. 候補を抽出し、それぞれのファイルパスと行番号を表示します
3. リストを開発者に提示します

完了条件： 開発者がリストを確認します（または誤検出を削除するよう編集します）。

一時停止： 「M 個のコンポーネントで、ユーザー向け文字列が N 個見つかりました。こちらがリストです：[ファイル名:行番号 + 文字列を表示]。よさそうですか？[確認／リストを編集／一部をスキップ]」

---

ステップ 2：抽出

目標： 確認済みの文字列ごとに Custom Label を追加し、文字列リテラルを翻訳呼び出しに置き換えます。

文字列ごとの作業：

1. キー名を提案します。形式は <Context>_<Role> です（例："Welcome" → Welcome_Text、"Save" → Save_Button、"Failed to save" → Save_Failed_Message）。命名規則：単語は PascalCase、各パートはアンダースコアで区切り、一意に特定できるだけの説明的な名前にします。
2. force-app/main/default/labels/CustomLabels.labels-meta.xml にラベルを追加します：

   <labels>
     <fullName>Welcome_Text</fullName>
     <language>en_US</language>
     <protected>false</protected>
     <shortDescription>Welcome banner heading</shortDescription>
     <value>Welcome</value>
   </labels>
   

   （XML の完全な構造：references/common/label-xml.md）
3. コンポーネント内の文字列を、フレームワークの翻訳呼び出しに置き換え、必要な import／注入を追加します。呼び出しの正確な規約は、フレームワークのリファレンスに記載されています。

完了条件： 確認済みの文字列すべてに、CustomLabels エントリーと、元の場所にある翻訳呼び出しの両方が揃っています。

一時停止： 「各文字列に Custom Label を追加し、文字列リテラルを翻訳呼び出しに置き換えます。提案するキーはこちらです：[文字列 → 名前空間:キーの対応を表示]。これらの編集を適用しますか？[y／個別に確認]」

---

ステップ 3：登録

目標： 各キーをラベルマニフェストに追加し、i18n ランタイムが取得できるようにします。

操作：

1. src/i18n/label-manifest.ts のマニフェスト配列に各キーを追加します。

   export const labelManifest = [
     "c:Welcome_Text",
     "c:Save_Button",
     "c:Save_Failed_Message",
   ];
   

   ファイルがまだ存在しない場合は、ステップ 4 で作成します。以下の完了確認でファイルがないことが報告されるため、手動でファイルの有無を確認する必要はありません。

完了条件： UI バンドルのディレクトリから check-manifest-registered.sh を実行し（現在のディレクトリを基準に src/ をスキャンします）、返されたエラーを報告します。このスクリプトが確定的な検査を行います。すべての翻訳呼び出し箇所とマニフェストを照合し、呼び出し箇所があるのに label-manifest.ts がない場合は失敗として扱います。呼び出されているキーが登録されていない場合、実行時にはエラーにならず、キー名そのものがそのまま表示されます。これを防ぐための、見落としやすい失敗パターンです。

cd <path-to-uiBundles/<name>/ dir>   # scripts scan src/ relative to here
bash <SKILL_DIR>/scripts/check-manifest-registered.sh --framework <framework>

終了コードに応じて対応します。0 の場合、すべてのキーが登録されている（または確認対象となる呼び出し箇所がない）ため、次へ進みます。1 の場合、マニフェストがないか、列挙されたキーが登録されていません。ファイルを作成するかキーを追加して（ステップ 4 でファイルを作成します）、再実行します。64 の場合、使用方法に誤りがあるか、ソースディレクトリが存在しません（作業ディレクトリが違う、または引数が不正）。これは「キーが不足している」という結果ではないため、ファイルの作成や登録はせず、パスを修正して再実行します。

一時停止： 「label-manifest.ts に N 件を追加しました。check-manifest-registered.sh は成功しました：[確認内容]。」

ステップ 4：配線

目標： i18n の配線が存在することを確認します。アプリに i18n がまだない場合は、足場を作成します。インストールコマンド、配線コード、B2E と B2C のフォールバック設定は、いずれもフレームワークリファレンス（references/<framework>/localize.md とその i18n-setup.md）にあります。

確認： UI バンドルのディレクトリから check-i18n-wired.sh を実行し（現在のディレクトリを基準に src/ をスキャンします）、返された結果を報告します。このスクリプトが、決定論的な検査をすべて行います。フレームワークの i18n 配線（React：起動時に呼び出される initI18n() 初期化ファイル、Angular：カスタム TranslateLoader を登録する provideTranslateService／TranslateModule.forRoot と、起動時に TranslateService.use で読み込まれること）を探します。配線が存在する場合は、ラベルマニフェストがインポートされ、実際にラベルのバックエンド／ローダーに到達しているかどうかも報告します。ファイルを自分で読んで、これらを再確認してはいけません。

cd <path-to-uiBundles/<name>/ dir>   # scripts scan src/ relative to here
bash <SKILL_DIR>/references/<framework>/check-i18n-wired.sh

終了コードに基づいて分岐します（表示されるメッセージには報告すべき特定のファイル／シンボル名が含まれますが、判断は終了コードで行います）。

• 終了コード 0 → 配線は完全です。マニフェストはラベルのバックエンド／ローダーに到達しています。新しいキーを追加するだけです。
• 終了コード 1 → i18n の配線がありません。フレームワークリファレンスに従って、セットアップ全体の足場を作成します。
• 終了コード 2 → 配線は存在しますが、不完全です（React：初期化処理が起動時に呼び出されていない。Angular：ローダーが登録されていない、または登録されているが起動時に TranslateService.use が呼び出されていない）。再度足場を作成したり、既存の配線を上書きしたりしないでください。メッセージで指定された不足分の配線だけを追加し、再実行します。
• 終了コード 3 → 起動時の配線はありますが、マニフェストがバックエンド／ローダーに到達していることをスクリプトが確認できませんでした。この最後の確認はテキストベースのヒューリスティックです。マニフェストが変数、スプレッド、ファクトリー、ヘルパーを介して配線されている場合、スクリプトでは認識できないことがあります。そのため、終了コード 3 は「編集前に確認する」であり、「確実に壊れている」ではありません。整合性を取る前に、メッセージで指定されたファイルを開いて確認します。すでに機能している配線を再度足場作成したり、重複させたりしてはいけません。
• 終了コード 64 → 使用方法のエラーです。ソースディレクトリが存在しません（作業ディレクトリが間違っているか、引数が正しくありません）。これは「配線なし」という結果ではありません。足場を作成せず、パスを修正して再実行します。

B2C の上書き設定 — 終了コード 0 の場合も適用されます： 配線チェックで確認できるのは i18n が存在することだけであり、B2C に適した設定になっていることではありません。B2E の配線があるシード（dir = ctx.dir で、labelFallback のないローダー）は、check-i18n-wired.sh で終了コード 0 になりますが、B2C サイトでは誤りです。サイトが B2C の場合、「新しいキーを追加するだけ」で終わらせてはいけません。src/i18n/index.ts（またはフレームワークの初期化ファイル）を開き、resolvedLang（= SFDC_ENV.language || ctx.lang。検出処理は SFDC_ENV.language を読み取りません）を使って、(a) labelFallback: "USER_DEFAULT" を追加し、(b) 言語の方向を i18next.dir(resolvedLang) から設定します。ctx.dir は使わないでください。(c) 初期化にも使用します。React では i18next.init の lng: resolvedLang、Angular では translate.use(resolvedLang) を設定します。references/<framework>/i18n-setup.md を参照してください。B2C サイトに B2E の配線を残してはいけません。

完了条件： i18n の配線が存在し、起動時に一度呼び出されていること。マニフェストがラベルのバックエンド／ローダーに到達していること。B2C の場合は、3 つすべての resolvedLang の上書き（USER_DEFAULT フォールバック、表示言語（React の lng、Angular の translate.use）、i18next.dir(resolvedLang) による方向設定）が適用され、シードの B2E のデフォルト設定が残っていないこと。 正確な足場作成方法はフレームワークリファレンスに従い、既存の配線を決して壊さないでください。

一時停止：「i18n のセットアップは［存在します／作成しました］。起動時に読み込まれることを確認しました：[確認内容]。」

---

ステップ 5：検証

目標： 開発者が、2 つ目の言語でラベルが表示されることを検証できるようにします。

操作： references/common/verifying.md に記載されている、ブランチごとの手順に従います。

B2E の場合は、2 つ目の言語を有効にし、その翻訳メタデータを作成または取得して、対象の組織に対してビルドします。次に、対象のバンドルとラベルメタデータのみをデプロイし、認証済みユーザーの Language を変更して再読み込みします。

B2C の場合は、フレームワークのリファレンスに記載されているとおり、設定済みのサイト言語、URL ルーティング、SFDC_ENV.language、全ページ再読み込みを伴う言語切り替え、ローカライズされたローカルプレビュー、ゲストの GraphQL アクセス、キャッシュのクリアを検証します。

バンドル、ラベル、翻訳をデプロイしても、Experience サイトは公開されません。sf community publish は別個の本番公開操作として扱います。実行する直前に、対象のサイトと組織を正確に示し、ユーザーから明示的な確認を得てください。

表示されない場合： references/common/gotchas.md の注意点を確認します。

• マニフェストキーが未登録（ステップ 3 でラベルを登録し忘れた）
• API バージョンの不一致（別の組織に対してビルドした）
• ラベルキャッシュが古い（React：localStorage の i18next_res_*、Angular：メモリ内に保持され、再読み込みで再取得）
• B2C ゲストの GraphQL 403（GraphQLApiOrgPrefForGuestUsers が管理者によって有効化されていない）
• B2C のルート、サイト言語、SFDC_ENV.language が一致していない

完了条件： 2 つ以上のロケールでラベルが表示されるか、作業を妨げている注意点が特定されていること。

一時停止： 「検証するには、Translation Workbench で 2 つ目の言語を有効にして翻訳を作成（XML のひな形は私が用意できます）し、ビルド／デプロイしてから再読み込みします。［language］用の翻訳ファイルのひな形を用意しましょうか？［はい／手動で行います］」

---

エッジケース：適切に対処する

• すでにローカライズ済みのコード：既存の翻訳呼び出しの使用状況／入力済みのマニフェストを検出し、すべてを一から再構築するのではなく、既存の設定に追加することを提案します。
• 文字列が見つからない：その旨を明確に報告して終了します。作業をでっち上げないでください。
• アプリに i18n の設定がない：ステップ 3 で登録する前に、ステップ 4 で 2 つのファイルのひな形を用意します。
• 設定が一部のみ存在する（マニフェストはあるが初期化がない、またはその逆）：既存の内容を整合させます。既存の設定を上書きしてはいけません。
• B2B サイト：明確に対象外とします。B2C に対応していても、B2B に対応していることにはなりません。

---

ガードレール：以下を必ず守る

1. デプロイ可能なメタデータを機械翻訳してはいけません。 各ラベルに閉じた <customLabels> ブロックを含む、整形式の <Translations> ドキュメントを 1 つひな形として用意し、英語の原文を XML エスケープします。プレースホルダーを保持し、完了前に両方のメタデータファイルを解析します。翻訳者はひな形の値を手作業または Translation Workbench で置き換えます。翻訳に MT API を呼び出してはいけません。
2. ラベルのないキーを登録してはいけません。 マニフェストのエントリ数はラベル数と一致している必要があります（ステップ 3 の基準）。未登録のキーは、コンソール警告なしで自身のリテラル名として表示されます。これは最もよくあるローカライズの不具合です。
3. 既存の i18n 設定を上書きしてはいけません。 ステップ 4 で既存の initI18n() が見つかった場合は、ファイル全体を置き換えるのではなく、整合させます（不足していればマニフェストのインポートを追加します）。
4. すべてのファイルを顧客向けの内容にします。 webapps、コア専用のパス、内部インフラへの参照を一切含めてはいけません。SFDX プロジェクトを利用する外部顧客向けに書いてください。
5. B2C サイトを暗黙に公開してはいけません。 メタデータのデプロイとサイトの公開は別々の操作です。サイトと組織を示し、その公開について明示的な確認を得てから、sf community publish を実行してください。

---

コマンドと構成

<project-root>/                          ← SFDX project root
└── force-app/main/default/
    ├── labels/CustomLabels.labels-meta.xml          ← English base labels
    ├── translations/<locale>.translation-meta.xml   ← one per translated language
    └── uiBundles/<your-bundle>/
        ├── package.json
        └── src/
            ├── i18n/
            │   ├── index.ts              ← init wiring (you write this once)
            │   └── label-manifest.ts     ← list of labels to fetch (you maintain this)
            └── components/               ← components call the translation function

コマンド	実行場所	目的
i18n の依存関係をインストールする（references/<framework>/localize.md を参照）	UI バンドルのディレクトリ	フレームワークの i18n ライブラリをインストールします（ステップ 4）
npm run build	UI バンドルのディレクトリ	アプリをビルドします（API バージョンが組み込まれるため、最初に target-org を設定してください）
references/<framework>/verifying.md を参照	プロジェクトルート	対象バンドルと変更されたラベルのメタデータを明示した組織にデプロイし、内容を確認します
sf project retrieve start --metadata Translations:<locale>	プロジェクトルート	Translation Workbench で作成された翻訳を取得します

---

事前チェックリスト：作業全体の完了条件

• 確認済みのすべての文字列に、CustomLabels エントリーと翻訳呼び出しの両方がある
• label-manifest.ts のエントリー数 == ラベル数（未登録のキーがない）
• i18n の配線があり、起動時に一度呼び出される。マニフェストがラベルのバックエンド／ローダーに接続されている
• B2C のみ：ゲスト GraphQL の設定を確認済みで、USER_DEFAULT を設定し、サイトの言語ルートが SFDC_ENV.language と一致している
• B2E のみ：フォールバックの上書きがなく、フレームワークのリファレンスにあるデフォルトが維持されている
• ラベルが 2 つ以上のロケールで表示される（または、阻害要因が明示されている）
• *-meta.xml に手書きの機械翻訳が追加されていない（スキャフォールドの作成とガイドのみ）
• 両方のメタデータファイルを XML として解析できる。翻訳スキャフォールドに <Translations> ルートが 1 つあり、各ラベルに閉じたブロックが 1 つずつある