Angular Blog の Angular localization with Ivy の翻訳です。
新しい Angular レンダリングエンジンの一部である Ivy には、アプリケーションをローカライズするための新しいアプローチ、特にテキストの抽出と翻訳が含まれています。この記事では、この新しいアプローチの利点といくつかの実装について説明します。
Ivy 以前は、ローカライズ可能なメッセージを Angular アプリケーションに追加する唯一の方法は、i18n 属性を使用してコンポーネントテンプレートでメッセージをマークすることでした。
<div i18n>Hello, World!</div>
一連の翻訳がコンパイラ設定で提供されている場合、 Angular コンパイラはテンプレートを別のテキストでコンパイルするときにこのテキストを置き換えます。i18n タグは非常に強力ですーこれらは、コンテンツだけでなく、属性で使用することができます。複雑な入れ子の ICU（International Components for Unicode）式 を含めることができます。メタデータを添付できます。詳細については、i18n ガイドを参照してください。
・・・
しかし、このアプローチにはいくつかの欠点がありました。
最も重要な問題は、テンプレートのコンパイル中に変換を行わなければならないことでした。これは、ビルドパイプラインの開始時に発生します。この結果、アプリケーションでサポートしたいロケールごとに、完全なビルド、コンパイル、バンドル、ミニファイなどを行う必要がありました。
1 つのビルドに 3 分かかった場合、9 つのロケールをサポートするための合計ビルド時間は 3 分 x 9 ロケール= 27 分になります。
さらに、アプリケーションコードのテキストに翻訳のマークを付けることはできませんでした。コンポーネントテンプレートのテキストのみです。これは、翻訳されるテキストを保持するために純粋に人工コンポーネントが作成されるという厄介な回避策をもたらしました。
最後に、実行時に翻訳をロードすることはできませんでした。つまり、アプリケーションを自分でビルドすることなく、独自の翻訳を提供したいエンドユーザーにアプリケーションを提供することは不可能でした。
・・・
新しい localization アプローチは、コード内の文字列に $localize という template literal tag handler をタグ付けするという概念に基づいています。翻訳が必要な文字列は、次のタグを使用して「マーク」されるという考え方です。
const message = $localize `Hello, World!`;
この $localize 識別子は、ブラウザーで実行時に変換を実行できる実際の関数にすることができます。 しかし、重要なことに、これはミニファイで残ったグローバルな識別子でもあります。 これは、コードがデプロイされる前に、静的後処理ツールが元のテキストを翻訳されたテキストに置き換えるために使用できる、単にコード内のマーカーとして機能できることを意味します。 たとえば、次のコード：
warning = $localize `${this.process} is not right`;
は、以下のように置き換えることができます：
warning = "" + this.process + ", ce n'est pas bon.";
その結果、 $localize へのすべての参照が削除され、翻訳されたテキストをレンダリングするための実行時コストはゼロになります。
・・・
Angular テンプレートコンパイラは、Ivy 用に再設計されており、翻訳自体を行うのではなく、 $localize タグ付き文字列を生成します。 たとえば、次のテンプレート：
ɵɵelementStart(0, "h1"); // <h1> ɵɵi18n(1, $localize`Hello, World!`); // Hello, World! ɵɵelementEnd(); // </h1>
これは、 Angular コンパイラーが作業を完了した後、i18n 属性でマークされたすべてのテンプレートテキストが $localize タグ付き文字列に変換され、他のタグ付き文字列と同じように処理できることを意味します。
これは、Angular コンパイラーが作業を完了した後、i18n 属性でマークされたすべてのテンプレートテキストが $localize タグ付き文字列に変換され、他のタグ付き文字列と同じように処理できることを意味します。
・・・
また、 $localize タグ付き文字列は任意のコード（ユーザーコードまたは両方のアプリケーションまたはライブラリのテンプレートから生成）で発生する可能性があり、ミニファイの影響を受けないため、後処理ツールは次のようなコードを受け取る可能性があります。
...var El,kl=n("Hfs6"),Sl=n.n(kl);El=$localize`Hello, World!`;let Cl=(()=>{class e{constructor(e)...
タグ付けされたメッセージを識別して翻訳することができます。 その結果、プロセスの最後にビルドパイプラインを並べ替えて翻訳を行うことができ、ビルド時間を大幅に短縮できます。
ここでは、ビルド時間がまだ 3 分であることがわかりますが、変換は後処理ステップとして行われるため、そのビルドコストは 1 回しか発生しません。 また、ツールは $localize タグ付き文字列のコードを解析するだけでよいため、翻訳の後処理は非常に高速です。 この場合、約 5 秒です。
その結果、9 つのロケールの合計ビルド時間は 3 分+（ 9 x 5 秒）= 3 分 45 秒になります。 Ivy 以前の翻訳済みビルドの 27 分と比較してください。
同様の改善が、すでにこのアプローチを使用しているチームによって実際に見られました。
翻訳の後処理は既に Angular CLI に組み込まれており、i18n ガイドに従ってプロジェクトを構成している場合は、これらの高速ビルド時間のメリットを享受できるはずです。
・・・
現在、アプリケーションコードでの $localize の使用は、まだ公的にサポートまたは文書化されていません。 これは今後数か月で完全にサポートされるように取り組んでいきます。 新しいメッセージ抽出ツールが必要です—現在の（ Ivy より前の）メッセージ抽出プログラムは、アプリケーションコードで $localize テキストを検出しません。 これは現在 CLI に統合されており、10.1.0 の一部としてリリースされる予定です。
また、この新しいアプローチを使用して、サードパーティライブラリでの翻訳をより適切にサポートする方法についても検討しています。 これは Angular Package Format（APF）に影響するため、実装する前に Request for Comment（RFC）を実行する必要があります。
それまでの間、改善されたビルド時間を楽しんで、テキストのアプリケーションレベルのローカリゼーションの完全なサポートに注目してください。
Minko Gechev、Mark Techson、Emma Twerskyに感謝します。
