@intlayer/docs 9.4.4 → 9.5.0

package/blog/ja/list_i18n_technologies/frameworks/react.md

@@ -23,16 +23,12 @@ author: aymericzip
 
 今日のデジタル環境では、ウェブサイトのリーチを拡大してグローバルな聴衆に対応することが不可欠です。Reactを使用して開発する開発者にとって、国際化（i18n）を実装することは、アプリケーションの構造、SEO価値、ユーザー体験を維持しながら翻訳を効率的に管理するための鍵です。本記事では、特定のライブラリからカスタムコードソリューションまで、さまざまなi18nアプローチを探求し、プロジェクトのニーズに最適な方法を決定する手助けをします。
 
----
-
 ## 国際化（i18n）とは？
 
 国際化、略してi18nは、ウェブサイトが複数の言語や文化的文脈をサポートするように設計し準備するプロセスです。Reactにおいては、アプリがさまざまな地域のユーザーに適応できるように、文字列、日付形式、数字形式、さらにはレイアウトを簡単に調整できるように設定することを意味します。Reactアプリをi18n用に準備することは、翻訳やその他のローカリゼーション機能をクリーンに統合するための基盤を築きます。
 
 i18nについての詳細は、この記事を読んでご確認ください: [国際化（i18n）とは？ 定義と課題](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/what_is_internationalization.md)。
 
----
-
 ## Reactアプリケーションにおける翻訳の課題
 
 Reactウェブサイトの翻訳には、いくつかの課題があります:
@@ -43,8 +39,6 @@ Reactウェブサイトの翻訳には、いくつかの課題があります:
 - **状態とコンテキストの管理:** ルートやコンポーネント全体で正しい言語が維持されることを確保するには、慎重な状態管理が必要です。
 - **開発のオーバーヘッド:** 翻訳ファイルの管理、コンテキストの正確性の確保、アプリケーションのスケーラビリティを維持することは継続的な考慮事項です。
 
----
-
 ## React向けの主要なi18nソリューション
 
 以下は、Reactアプリケーションで多言語コンテンツを管理するためのいくつかの人気のあるアプローチであり、それぞれが翻訳プロセスを異なる方法で円滑にするように設計されています。
@@ -69,8 +63,6 @@ Reactウェブサイトの翻訳には、いくつかの課題があります:
 
 - **コミュニティ＆エコシステム:** エコシステムは成長していますが、新しいため、コミュニティ主導のプラグインやツールが、より確立されたソリューションと比較して制限される可能性があります。
 
----
-
 ### 2. React-i18next
 
 ウェブサイト: [https://react.i18next.com/](https://react.i18next.com/)
@@ -93,8 +85,6 @@ Reactウェブサイトの翻訳には、いくつかの課題があります:
 - **プラグインエコシステム:** 幅広いプラグインとミドルウェアのエコシステムが利用可能ですが、最適なツールを見つけるためにさまざまなパッケージを選別する必要があります。
 - **サーバーコンポーネント:** Next.js以外のフレームワークを使用する場合、サーバーコンポーネントが正しいロケールを取得するための追加の設定が必要です。
 
----
-
 ### 3. React Intl (FormatJSから)
 
 ウェブサイト: [https://formatjs.io/docs/react-intl/](https://formatjs.io/docs/react-intl/)
@@ -137,8 +127,6 @@ Reactウェブサイトの翻訳には、いくつかの課題があります:
 - **コミュニティとプラグイン:** エコシステムは成長していますが、i18nextやFormatJSと比較するとまだ小さいです。
 - **サーバーコンポーネント:** サーバーコンポーネントが正しいロケールデータを受け取るために、より明示的な設定が必要になることがあります。
 
----
-
 ### 最後の考慮事項
 
 Reactのためのi18nライブラリを選択する際は:

package/blog/ja/list_i18n_technologies/frameworks/svelte.md

@@ -29,8 +29,6 @@ author: aymericzip
 
 i18nの基本についての詳細は、以下の記事をお読みください: [国際化 (i18n) とは？ 定義と課題](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/what_is_internationalization.md)。
 
----
-
 ## Svelteアプリケーションの翻訳の課題
 
 Svelteアプリケーションを翻訳する際には、いくつかのハードルがあります。
@@ -41,8 +39,6 @@ Svelteアプリケーションを翻訳する際には、いくつかのハー
 - **状態とルーティング**: 複数のルートや動的ページ間で正しい言語を保持することは、しばしばSvelteKit内でグローバル状態、ルートガード、またはカスタムフックをオーケストレーションすることを含みます。
 - **保守性**: コードベースと翻訳ファイルが増えるにつれて、すべてを適切に整理し、同期しておくことは継続的な努力になります。
 
----
-
 ## Svelte向けの主要なi18nソリューション
 
 Svelteはネイティブのi18nソリューションを提供していませんが（Angularのようには）、コミュニティはさまざまな堅牢なライブラリとパターンを作成しています。以下は、いくつかの一般的なアプローチです。
@@ -66,8 +62,6 @@ Svelteはネイティブのi18nソリューションを提供していません
 
 - **コミュニティとエコシステム**: 成長していますが、エコシステムは新しいため、コミュニティ主導のプラグインとツールは、より確立されたソリューションと比較して限定的な場合があります。
 
----
-
 ### 2. svelte-i18n
 
 リポジトリ: [https://github.com/kaisermann/svelte-i18n](https://github.com/kaisermann/svelte-i18n)
@@ -88,8 +82,6 @@ Svelteはネイティブのi18nソリューションを提供していません
 - **SSR設定**: SEOのためにSSRを構成するには、サーバー側でのロケール検出を確実に行うための追加の手順が必要になる場合があります。
 - **パフォーマンス**: ランタイムで柔軟ですが、一度に大量の翻訳を読み込むと初期の読み込み時間に影響を及ぼす可能性があります。レイジーローディングまたはキャッシング戦略を考慮してください。
 
----
-
 ### 3. svelte-intl-precompile
 
 リポジトリ: [https://github.com/cibernox/svelte-intl-precompile](https://github.com/cibernox/svelte-intl-precompile)
@@ -110,8 +102,6 @@ Svelteはネイティブのi18nソリューションを提供していません
 - **動的コンテンツ**: ユーザー生成コンテンツの即時翻訳が必要な場合、このアプローチではランタイムでの更新に追加の手順が必要となることがあります。
 - **学習曲線**: メッセージ抽出と事前コンパイルの組み合わせは、新参者にとってやや複雑かもしれません。
 
----
-
 ### 4. i18next with Svelte / SvelteKit
 
 ウェブサイト: [https://www.i18next.com/](https://www.i18next.com/)
@@ -132,8 +122,6 @@ Svelteはネイティブのi18nソリューションを提供していません
 - **オーバーヘッド**: i18nextは強力ですが、小さなSvelteプロジェクトには一部の機能が過剰かもしれません。
 - **ルーティングと状態**: 言語ルーティングの処理には、カスタムSvelteKitフックやミドルウェアが必要になるでしょう。
 
----
-
 ### 最後に
 
 Svelteアプリでのi18n戦略を選択する際:

package/blog/ja/list_i18n_technologies/frameworks/vue.md

@@ -23,16 +23,12 @@ author: aymericzip
 
 ますますグローバル化するデジタル環境において、Vue.jsウェブサイトのユーザーを複数の言語に拡大することは、もはや「あると良いもの」ではなく、競争のための必須条件です。国際化（i18n）は、開発者が翻訳を管理し、SEOの価値、ユーザーエクスペリエンス、保守可能なコード構造を保存しながら、さまざまなロケールにアプリケーションを適応させることを可能にします。この記事では、専用のライブラリからカスタムコーディングされたソリューションまで、i18nをVue.jsプロジェクトにスムーズに統合するのを助けるさまざまなアプローチを探ります。
 
----
-
 ## 国際化（i18n）とは？
 
 国際化（i18n）とは、ソフトウェアアプリケーション（またはウェブサイト）を複数の言語および文化的慣習のために準備する実践です。Vue.jsエコシステム内では、テキスト、日付、数値、通貨、およびその他のローカライズ可能な要素がどのようにさまざまなロケールに適応できるかを確立することが含まれます。最初からi18nを設定することで、新しい言語を追加し、将来のローカリゼーションニーズに対応するための組織的でスケーラブルな構造を確保します。
 
 i18nの基本について詳しく学ぶには、次のリファレンスをチェックしてください: [国際化とは？（i18n）定義と課題](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/what_is_internationalization.md)。
 
----
-
 ## Vueアプリケーションにおける翻訳の課題
 
 Vue.jsアプリケーションを翻訳する際には、独自の課題が存在します：
@@ -43,14 +39,10 @@ Vue.jsアプリケーションを翻訳する際には、独自の課題が存
 - **状態とリアクティブコンテキスト:** 現在のロケールがルートやコンポーネント間で維持され、テキストやフォーマットがリアクティブに更新されるようにするには、特にVuexやPiniaを使用して状態管理を行う際に、慎重なアプローチが必要です。
 - **開発のオーバーヘッド:** 翻訳ファイルを整理し、一貫性を保ち、最新の状態を維持することは、注意深く管理しないとすぐに大きなタスクになります。
 
----
-
 ## Vue.jsの主要なi18nソリューション
 
 以下は、Vueアプリケーションに国際化を組み込むために使用できるいくつかの人気ライブラリやアプローチです。それぞれが翻訳、SEO、パフォーマンスの考慮を異なる方法で合理化することを目指しています。
 
----
-
 ### 1. Intlayer
 
 > ウェブサイト: [https://intlayer.org/](https://intlayer.org/)
@@ -94,8 +86,6 @@ Vue.jsアプリケーションを翻訳する際には、独自の課題が存
 - **プラグインエコシステム**  
   強力ですが、完璧なセットアップを構築するためには、複数のプラグインやモジュール（Nuxt I18n、Vue I18nなど）から慎重に選択する必要があります。
 
----
-
 ### 3. LinguiJS（Vue統合）
 
 > ウェブサイト: [https://lingui.js.org/](https://lingui.js.org/)
@@ -123,8 +113,6 @@ Vue.jsアプリケーションを翻訳する際には、独自の課題が存
 - **小さなコミュニティ**  
   Vue I18nと比較して、相対的に小さなエコシステムです。公式に管理されているプラグインやサードパーティ製のアドオンは、より制限される可能性があります。
 
----
-
 ## 最後の考え
 
 Vue.jsアプリケーションに対するi18nソリューションを決定する際には：

package/blog/ja/next-i18next_vs_next-intl_vs_intlayer.md

@@ -42,16 +42,12 @@ Next.js向けの3つのi18nオプション、next-i18next、next-intl、Intlayer
 
 > 開発者がよく混同しがちなのは、`next-intl`が`react-intl`のNext.js版だと思うことです。そうではありません。`next-intl`は[Amann](https://github.com/amannn)によってメンテナンスされており、`react-intl`は[FormatJS](https://github.com/formatjs/formatjs)によってメンテナンスされています。
 
----
-
 ## 簡単に言うと
 
 - **next-intl** - 軽量でシンプルなメッセージフォーマットを提供し、Next.jsのサポートがしっかりしています。カタログは中央集権的であることが多く、開発者体験（DX）はシンプルですが、安全性や大規模なメンテナンスは主にあなたの責任となります。
 - **next-i18next** - Next.js向けにラップされたi18nextです。成熟したエコシステムとプラグイン（例：ICU）による機能を持ちますが、設定が冗長になりがちで、プロジェクトが大きくなるにつれてカタログは中央集権化しやすいです。
 - **Intlayer** - Next.js向けのコンポーネント中心のコンテンツモデル、**厳格なTS型付け**、**ビルド時チェック**、**ツリーシェイキング**、**組み込みのミドルウェア＆SEOヘルパー**、オプションの**ビジュアルエディター/CMS**、および**AI支援翻訳**。
 
----
-
 | Library                | GitHub Stars                                                                                                                                                                     | Total Commits                                                                                                                                                                        | Last Commit                                                                                                                                           | First Version | NPM Version                                                                                                         | NPM Downloads                                                                                                                  |
 | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
 | `aymericzip/intlayer`  | [![GitHub Repo stars](https://img.shields.io/github/stars/aymericzip/intlayer?style=for-the-badge&label=%E2%AD%90%20stars)](https://github.com/aymericzip/intlayer/stargazers)   | [![GitHub commit activity](https://img.shields.io/github/commit-activity/t/aymericzip/intlayer?style=for-the-badge&label=commits)](https://github.com/aymericzip/intlayer/commits)   | [![Last Commit](https://img.shields.io/github/last-commit/aymericzip/intlayer?style=for-the-badge)](https://github.com/aymericzip/intlayer/commits)   | April 2024    | [![npm](https://img.shields.io/npm/v/intlayer?style=for-the-badge)](https://www.npmjs.com/package/intlayer)         | [![npm downloads](https://img.shields.io/npm/dm/intlayer?style=for-the-badge)](https://www.npmjs.com/package/intlayer)         |
@@ -61,8 +57,6 @@ Next.js向けの3つのi18nオプション、next-i18next、next-intl、Intlayer
 
 > バッジは自動的に更新されます。スナップショットは時間とともに変動します。
 
----
-
 ## 並列機能比較（Next.jsに特化）
 
 | 機能                                                         | `next-intlayer` (Intlayer)                                                                                                     | `next-intl`                                                                                                          | `next-i18next`                                                                                                       |
@@ -88,16 +82,12 @@ Next.js向けの3つのi18nオプション、next-i18next、next-intl、Intlayer
 | **大規模プロジェクトの管理**                                 | ✅ モジュール化を推奨し、デザインシステムに適している                                                                          | ✅ セットアップによるモジュール化対応                                                                                | ✅ セットアップによるモジュール化対応                                                                                |
 | **翻訳漏れのテスト（CLI/CI）**                               | ✅ CLI: `npx intlayer content test`（CIに適した監査）                                                                          | ⚠️ 組み込みではない；ドキュメントでは `npx @lingual/i18n-check` を推奨                                               | ⚠️ 組み込みではない；i18nextツールやランタイムの `saveMissing` に依存                                                |
 
----
-
 ## はじめに
 
 Next.jsは国際化されたルーティング（例：ロケールセグメント）を組み込みでサポートしています。しかし、その機能だけでは翻訳は行われません。ユーザーにローカライズされたコンテンツを表示するには、別途ライブラリが必要です。
 
 多くのi18nライブラリが存在しますが、Next.jsの世界では現在、next-i18next、next-intl、そしてIntlayerの3つが注目されています。
 
----
-
 ## アーキテクチャとスケーラビリティ
 
 - **next-intl / next-i18next**: ロケールごとに **集中管理されたカタログ**（および i18next の場合は **ネームスペース**）をデフォルトとします。初期段階では問題なく機能しますが、結合度が高まりキーの変更が頻繁になると、大きな共有領域となってしまいます。
@@ -105,8 +95,6 @@ Next.jsは国際化されたルーティング（例：ロケールセグメン
 
 **なぜ重要か:** 大規模なコードベースやデザインシステムのセットアップでは、**モジュール化されたコンテンツ**の方がモノリシックなカタログよりもスケールしやすいです。
 
----
-
 ## バンドルサイズと依存関係
 
 アプリケーションをビルドした後、バンドルとはブラウザがページをレンダリングするために読み込むJavaScriptのことです。したがって、バンドルサイズはアプリケーションのパフォーマンスにとって重要です。
@@ -172,8 +160,6 @@ Next.jsは国際化されたルーティング（例：ロケールセグメン
 | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
 | ![最適化されたバンドル](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle.png?raw=true) | ![最適化されていないバンドル](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.png?raw=true) |
 
----
-
 ## TypeScript と安全性
 
 <Columns>
@@ -198,12 +184,11 @@ Next.jsは国際化されたルーティング（例：ロケールセグメン
 - **コンテンツから厳密な型を生成**します。**IDEのオートコンプリート**や**コンパイル時エラー**により、デプロイ前にタイプミスやキーの欠落を検出します。
 
   </Column>
+
 </Columns>
 
 **なぜ重要か:** 強い型付けにより、失敗を**右（実行時）**ではなく**左（CI/ビルド時）**にシフトさせます。
 
----
-
 ## ルーティング、ミドルウェア & URL戦略
 
 <Columns>
@@ -228,12 +213,11 @@ Next.jsは国際化されたルーティング（例：ロケールセグメン
 - 上記すべてに加え、**i18nミドルウェア**（ヘッダーやクッキーによるロケール検出）およびローカライズされたURLや`<link rel="alternate" hreflang="…">`タグを生成する**ヘルパー**を提供。
 
   </Column>
+
 </Columns>
 
 **重要な理由:** カスタムの接着層が減り、**一貫したUX**と**クリーンなSEO**をロケール間で実現。
 
----
-
 ## サーバーコンポーネント（RSC）対応
 
 <Columns>
@@ -258,12 +242,11 @@ Next.jsは国際化されたルーティング（例：ロケールセグメン
 - Next.js 13+ をサポートし、一貫した API と RSC 指向のプロバイダーで **サーバー/クライアントの境界** をスムーズにし、フォーマッターや t-関数のやり取りを回避します。
 
   </Column>
+
 </Columns>
 
 **重要な理由:** ハイブリッドツリーにおけるメンタルモデルがより明確になり、エッジケースが減少します。
 
----
-
 ## DX、ツール＆メンテナンス
 
 <Columns>
@@ -288,6 +271,7 @@ Next.jsは国際化されたルーティング（例：ロケールセグメン
 - 無料の**ビジュアルエディター**と**オプションのCMS**（Git対応または外部化可能）を提供し、さらに**VSCode拡張機能**と、独自のプロバイダーキーを使用した**AI支援翻訳**も備えています。
 
   </Column>
+
 </Columns>
 
 **重要な理由:** 運用コストを削減し、開発者とコンテンツ作成者間のフィードバックループを短縮します。
@@ -798,8 +782,6 @@ const ClientComponentExample = () => {
   - **next-intl** は柔軟で、設定に応じてメッセージをロード可能。
   - **Intlayer** は TS/JS の辞書にコンテンツを格納し、キーで解決。
 
----
-
 ### サーバーコンポーネントでの使用
 
 UIコンポーネントの場合を考えます。このコンポーネントはサーバーコンポーネントであり、クライアントコンポーネントの子として挿入できる必要があります。（ページ（サーバーコンポーネント） -> クライアントコンポーネント -> サーバーコンポーネント）。このコンポーネントはクライアントコンポーネントの子として挿入できるため、非同期にはできません。
@@ -897,7 +879,7 @@ const ServerComponent = ({ count }: { count: number }) => {
 開発者はしばしばロケール間でページを適切に参照することを忘れがちです。
 
 <Tabs defaultTab="next-intl" group='techno'>
- 
+
   <Tab label="next-i18next" value="next-i18next">
 
 ```ts fileName="i18n.config.ts"
@@ -1155,8 +1137,6 @@ export default robots;
 
 > Intlayerは、サイトマップ用の多言語URLを生成するための`getMultilingualUrls`関数を提供しています。
 
----
-
 ### ロケール ルーティング用ミドルウェア
 
 <Tabs defaultTab="next-intl" group='techno'>
@@ -1274,9 +1254,8 @@ export const config = {
 - **統合ツール**：組み込みのルーティング、SEO ヘルパー、ビジュアルエディタサポートを活用してください。
 
   </Tab>
-</Tabs>
 
----
+</Tabs>
 
 ## そして勝者は…
 
@@ -1304,6 +1283,7 @@ export const config = {
 - モダンな Next.js 向けに構築されており、モジュラーコンテンツ、型安全性、ツール群、そしてボイラープレートの削減を実現しています。**コンポーネント単位のコンテンツ管理**、**厳格な TypeScript**、**ビルド時の保証**、**ツリーシェイキング**、そして**ルーティング/SEO/エディターツールがバッテリー込み**で提供されることを重視する場合、特に **Next.js App Router**、デザインシステム、そして**大規模でモジュラーなコードベース**に最適です。
 
   </Column>
+
 </Columns>
 
 セットアップを最小限に抑え、多少の手動設定を許容できるなら next-intl が良い選択です。すべての機能が必要で複雑さを気にしないなら next-i18next が適しています。しかし、モダンでスケーラブル、モジュラーなソリューションをビルトインツールと共に求めるなら、Intlayer はそれをすぐに提供することを目指しています。
@@ -1318,8 +1298,6 @@ GitHubのスターは、プロジェクトの人気、コミュニティの信
 
 [![スター履歴チャート](https://api.star-history.com/chart?repos=i18next/next-i18next%2Camannn/next-intl%2Caymericzip/intlayer&type=date&legend=top-left)](https://www.star-history.com/#i18next/next-i18next&amannn/next-intl&aymericzip/intlayer)
 
----
-
 ## 結論
 
 3つのライブラリはすべてコアなローカリゼーションに成功しています。違いは、**モダンな Next.js** で堅牢でスケーラブルなセットアップを実現するために、**どれだけの作業が必要か**という点です。

package/blog/ja/nextjs-multilingual-seo-comparison.md

@@ -26,8 +26,6 @@ author: aymericzip
 
 このブログでは、**なぜi18nがSEOの強力な武器となるのか**、そして`next-intl`、`next-i18next`、`Intlayer`を使ってNext.jsで正しく実装する方法を探っていきます。
 
----
-
 ## なぜSEOとi18nが重要なのか
 
 言語を追加することは単なるUXの向上だけではありません。それは**オーガニックな可視性**を高める強力な手段でもあります。理由は以下の通りです：
@@ -37,8 +35,6 @@ author: aymericzip
 3. **より良いUX:** 訪問者はすぐにサイトの適切なバージョンにアクセスできます。
 4. **競争優位性:** 多言語SEOを適切に実装しているサイトは少ないため、あなたのサイトは際立つことができます。
 
----
-
 ## Next.jsにおける多言語SEOのベストプラクティス
 
 すべての多言語アプリが実装すべきチェックリストはこちらです：
@@ -57,8 +53,6 @@ author: aymericzip
 
 これらは簡単なステップですが、スキップすると可視性を失う可能性があります。
 
----
-
 ## 実装例
 
 開発者はしばしばロケール間でページを適切に参照することを忘れがちなので、さまざまなライブラリでどのように機能するかを見てみましょう。
@@ -343,14 +337,10 @@ export default robots;
   </Tab>
 </Tabs>
 
----
-
 ## Intlayer SEO Scannerでウェブサイトを監査する
 
 多言語アプリが完全に最適化されていることを確認するために、[Intlayer SEO Scanner](https://intlayer.org/i18n-seo-scanner)を使用することをお勧めします。これは多言語ウェブサイトチェックに特化したツールであり、ローカライズされたすべてのページで不足しているhreflangタグ、リンク切れ、その他のSEO問題を特定するのに役立ちます。
 
----
-
 ## 結論
 
 Next.jsでi18nを正しく実装することは、単にテキストを翻訳するだけでなく、検索エンジンやユーザーがどのバージョンのコンテンツを提供すべきかを正確に認識できるようにすることです。

package/blog/ja/rag_powered_documentation_assistant.md

@@ -71,7 +71,6 @@ RAGが人気のアプローチになったのには理由があります。そ
 6.  **フィードバックのためのクエリのログ記録** すべてのユーザークエリを保存します。これは問題点の把握、ドキュメントの不足、新たな機会の発見に非常に役立ちます。
 
 <Steps>
-
 <Step number={1} title="ドキュメントの読み込み">
 
 最初のステップはシンプルでした：docs/フォルダ内のすべての.mdファイルをスキャンする方法が必要でした。Node.jsとglobを使って、各Markdownファイルの内容をメモリに取得しました。
@@ -79,7 +78,6 @@ RAGが人気のアプローチになったのには理由があります。そ
 これによりパイプラインは柔軟になります。Markdownの代わりに、データベースやCMS、さらにはAPIからドキュメントを取得することも可能です。
 
 </Step>
-
 <Step number={2} title="ドキュメントのチャンク分割">
 
 なぜチャンク分割をするのか？それは言語モデルには**コンテキストの制限**があるからです。ドキュメント全体を一度に与えることはできません。
@@ -99,7 +97,6 @@ RAGが人気のアプローチになったのには理由があります。そ
 - 大きすぎると → コンテキストサイズが膨れ上がります。
 
 </Step>
-
 <Step number={3} title="埋め込みの生成">
 
 ドキュメントをチャンクに分割したら、各チャンクを表す高次元ベクトルである**埋め込み**を生成します。
@@ -119,7 +116,6 @@ RAGが人気のアプローチになったのには理由があります。そ
 各ベクトルはテキストの数学的な指紋であり、類似検索を可能にします。
 
 </Step>
-
 <Step number={4} title="埋め込みのインデックス作成と保存">
 
 埋め込みを何度も再生成しないように、embeddings.jsonに保存しました。
@@ -134,7 +130,6 @@ RAGが人気のアプローチになったのには理由があります。そ
 ベクトルDBはインデックス作成、スケーラビリティ、高速検索を処理します。しかし、私のプロトタイプではローカルのJSONで十分でした。
 
 </Step>
-
 <Step number={5} title="コサイン類似度による検索">
 
 ユーザーが質問をしたとき：
@@ -148,7 +143,6 @@ RAGが人気のアプローチになったのには理由があります。そ
 この方法で、システムはクエリに最も近いドキュメントの部分を見つけます。
 
 </Step>
-
 <Step number={6} title="拡張＋生成">
 
 ここで魔法が始まります。上位のチャンクを取り出し、それらをChatGPTの**システムプロンプト**に注入します。
@@ -158,7 +152,6 @@ RAGが人気のアプローチになったのには理由があります。そ
 結果：正確で、**ドキュメントに基づいた応答**。
 
 </Step>
-
 <Step number={7} title="ユーザークエリのログ記録">
 
 これが隠れたスーパーパワーです。
@@ -173,7 +166,6 @@ RAGが人気のアプローチになったのには理由があります。そ
 これにより、あなたのRAGアシスタントは**継続的なユーザーリサーチツール**に変わります。
 
 </Step>
-
 <Step number={8} title="コストはどのくらいかかるのか？">
 
 RAGに対する一般的な反論の一つはコストですが、実際には驚くほど安価です：
@@ -185,7 +177,6 @@ RAGに対する一般的な反論の一つはコストですが、実際には
 その上に、ホスティングコストを含めることができます。
 
 </Step>
-
 <Step number={9} title="実装の詳細">
 
 スタック:
@@ -251,7 +242,6 @@ gpt-5も試しましたが、レイテンシが高すぎました（返信に最
 👉 [ここでデモを試す](https://intlayer.org/doc/why) 👉 [GitHubでコードテンプレートを確認](https://github.com/aymericzip/smart_doc_RAG)
 
 </Step>
-
 <Step number={10} title="さらに進むために">
 
 このプロジェクトは最小限の実装です。しかし、以下のように多くの方法で拡張できます：
@@ -265,7 +255,6 @@ gpt-5も試しましたが、レイテンシが高すぎました（返信に最
 - 改良されたプロンプティング → 再ランキング、フィルタリング、ハイブリッド検索（キーワード＋セマンティック）
 
 </Step>
-
 <Step number={11} title="直面した制限事項">
 
 - チャンク分割と重複は経験則に基づく。適切なバランス（チャンクサイズ、重複率、取得チャンク数）は反復とテストが必要。
@@ -273,7 +262,6 @@ gpt-5も試しましたが、レイテンシが高すぎました（返信に最
 - このプロトタイプでは、埋め込みはJSONに保存されています。これはデモには適していますが、Gitを汚染します。本番環境では、データベースや専用のベクターストアの方が適しています。
 
 </Step>
-
 <Step number={12} title="ドキュメントを超えて重要な理由">
 
 興味深いのは単なるチャットボットだけではありません。**フィードバックループ**です。
@@ -295,7 +283,6 @@ RAGを使うと、単に答えるだけではなく：
 それがユーザーから直接得られる**プロダクトインテリジェンス**です。
 
 </Step>
-
 <Step number={13} title="結論">
 
 RAGは、LLMを実用的にする最もシンプルで強力な方法の一つです。**検索（retrieval）＋生成（generation）**を組み合わせることで、静的なドキュメントを**スマートアシスタント**に変え、同時に継続的な製品インサイトの流れを得ることができます。

package/blog/ja/react-i18next_vs_react-intl_vs_intlayer.md

@@ -35,16 +35,12 @@ author: aymericzip
 
 > **要約**：3つともReactアプリのローカライズが可能です。もし**コンポーネント単位のコンテンツ管理**、**厳格なTypeScript型**、**ビルド時の未翻訳キー検出**、**ツリーシェイク可能な辞書**、そして組み込みの編集ツール（ビジュアルエディター／CMS＋オプションのAI翻訳）を求めるなら、**Intlayer**がモジュール化されたReactコードベースに最も適した選択肢です。
 
----
-
 ## ハイレベルな位置づけ
 
 - **react-intl** - ICU優先で、標準に準拠したフォーマット（日付／数値／複数形）を持つ成熟したAPI。カタログは通常集中管理され、キーの安全性やビルド時の検証は主にユーザーの責任です。
 - **react-i18next** - 非常に人気があり柔軟性が高い。ネームスペース、検出器、多数のプラグイン（ICU、バックエンドなど）を備えています。強力ですが、プロジェクトの規模が大きくなると設定が複雑化することがあります。
 - **Intlayer** - React向けのコンポーネント中心のコンテンツモデル、**厳格なTS型付け**、**ビルド時チェック**、**ツリーシェイク**、さらに**ビジュアルエディター／CMS**と**AI支援翻訳**を備えています。React Router、Vite、CRAなどと連携可能です。
 
----
-
 ## 機能マトリックス（Reactにフォーカス）
 
 | 機能                                                       | `react-intlayer` (Intlayer)                                                                                                      | `react-i18next` (i18next)                                                                                                    | `react-intl` (FormatJS)                                                                                        |
@@ -69,8 +65,6 @@ author: aymericzip
 | **未使用コンテンツの削除**                                 | ✅ はい、ビルド時に辞書ごとに対応                                                                                                | ❌ いいえ、手動で名前空間を分割する方法のみ対応                                                                              | ❌ いいえ、宣言されたすべてのメッセージがバンドルされる                                                        |
 | **大規模プロジェクトの管理**                               | ✅ モジュール化を促進し、デザインシステムに適している                                                                            | ⚠️ ファイル管理の規律が必要                                                                                                  | ⚠️ 中央カタログが大きくなる可能性がある                                                                        |
 
----
-
 ## 詳細比較
 
 ### 1) アーキテクチャとスケーラビリティ
@@ -80,8 +74,6 @@ author: aymericzip
 
 **重要な理由:** モジュール化されたコンテンツはモジュール化されたUIを反映します。大規模なReactコードベースでは、翻訳が所属するコンポーネントと共に存在することでコードがよりクリーンに保たれます。
 
----
-
 ### 2) TypeScriptと安全性
 
 - **react-intl**: 安定した型定義がありますが、**自動的なキーの型付けはありません**。安全性のパターンは自分で強制する必要があります。
@@ -90,8 +82,6 @@ author: aymericzip
 
 **なぜ重要か:** 失敗を**左側（ビルド/CI段階）に移す**ことで、本番環境の問題を減らし、開発者のフィードバックループを高速化します。
 
----
-
 ### 3) 翻訳欠落の取り扱い
 
 - **react-intl / react-i18next**: デフォルトは**実行時のフォールバック**（キーのエコーやデフォルトロケール）。リンティングやプラグインを追加可能ですが、ビルド時の保証はありません。
@@ -99,8 +89,6 @@ author: aymericzip
 
 **なぜ重要か:** CIで欠落文字列を検出し失敗させることで、非英語UIに「謎の英語」が混入するのを防ぎます。
 
----
-
 ### 4) リッチコンテンツとフォーマット
 
 - **react-intl**: 複数形、選択、日付/数値、メッセージ構成に対する優れた **ICU** サポート。JSX を使用可能ですが、メンタルモデルはメッセージ中心のままです。
@@ -109,8 +97,6 @@ author: aymericzip
 
 **重要な理由:** 複雑なUIテキスト（リンク、太字部分、インラインコンポーネント）が、ライブラリがReactノードをきれいに扱うことでより簡単になります。
 
----
-
 ### 5) パフォーマンスと読み込み動作
 
 - **react-intl / react-i18next**: 通常、**カタログの分割**や**遅延読み込み**は手動で管理します（名前空間や動的インポート）。効果的ですが、規律が必要です。
@@ -118,8 +104,6 @@ author: aymericzip
 
 **なぜ重要か:** バンドルサイズが小さくなり、未使用の文字列が減ることで、起動時間やナビゲーションのパフォーマンスが向上します。
 
----
-
 ### 6) DX、ツール＆メンテナンス
 
 - **react-intl / react-i18next**: 幅広いコミュニティエコシステムがあり、編集ワークフローには通常、外部のローカリゼーションプラットフォームを採用します。
@@ -127,16 +111,12 @@ author: aymericzip
 
 **重要な理由:** 組み込みのツールにより、開発者とコンテンツ作成者間のやり取りが短縮され、接着コードが減り、ベンダー依存も少なくなります。
 
----
-
 ## どれを選ぶべきか？
 
 - **react-intlを選ぶ**場合は、シンプルで標準に準拠したAPIを持つ**ICU優先**のメッセージフォーマットを求め、チームがカタログや安全チェックを手動で管理することに慣れている場合です。
 - **react-i18nextを選ぶ**場合は、**i18nextのエコシステムの幅広さ**（検出器、バックエンド、ICUプラグイン、統合など）が必要で、柔軟性を得るためにより多くの設定を受け入れられる場合です。
 - **Intlayerを選ぶべき場合**：**コンポーネント単位のコンテンツ管理**、**厳格なTypeScript**、**ビルド時の保証**、**ツリーシェイキング**、そして**充実した編集ツール**を重視する場合、特に**大規模でモジュール化された**Reactアプリに最適です。
 
----
-
 ## 実践的な移行ノート（react-intl / react-i18next → Intlayer）
 
 - **段階的に移行する**：まずは一つの機能やルートから始め、移行期間中は旧カタログを並行して維持します。
@@ -144,8 +124,6 @@ author: aymericzip
 - **厳格なチェックを有効にする**：ビルド時のエラーで欠落したキーやロケールをCIの早い段階で検出します。
 - **バンドルサイズを測定する**：未使用の文字列が削除されることでサイズ削減が期待できます。
 
----
-
 ## GitHub STARs
 
 GitHub スターはプロジェクトの人気度、コミュニティからの信頼、長期的な関連性の強い指標です。技術的な品質の直接的な測定ではありませんが、多くの開発者がプロジェクトを有用であると判断し、その進捗をフォローし、採用する可能性があることを反映しています。プロジェクトの価値を見積もるために、スターは代替案間での牽引力を比較し、エコシステムの成長に関する洞察を提供するのに役立ちます。