@intlayer/docs 9.4.4 → 9.5.1

package/blog/ja/vue-i18n_vs_intlayer.md

@@ -33,15 +33,11 @@ author: aymericzip
 
 > **要約**：どちらもVueアプリのローカライズが可能です。もし**コンポーネント単位のコンテンツ管理**、**厳格なTypeScript型**、**ビルド時の未翻訳キー検出**、**ツリーシェイク可能な辞書**、そして**ルーターやSEOヘルパーが標準装備**されていて、さらに**ビジュアルエディターとAI翻訳**も欲しいなら、**Intlayer**がより完全でモダンな選択肢です。
 
----
-
 ## 高レベルのポジショニング
 
 - **vue-i18n** - Vueの事実上の標準i18nライブラリ。柔軟なメッセージフォーマット（ICUスタイル）、ローカルメッセージ用のSFC `<i18n>` ブロック、大規模なエコシステムを持ちます。安全性や大規模メンテナンスは主にユーザーの責任です。
 - **Intlayer** - Vue/Vite/Nuxt向けのコンポーネント中心のコンテンツモデルで、**厳格なTS型付け**、**ビルド時チェック**、**ツリーシェイキング**、**ルーター＆SEOヘルパー**、オプションの**ビジュアルエディター/CMS**、および**AI支援翻訳**を備えています。
 
----
-
 ## 機能の比較（Vueに特化）
 
 | 機能                                                     | **Intlayer**                                                                          | **vue-i18n**                                                                |
@@ -65,8 +61,6 @@ author: aymericzip
 | **大規模プロジェクトの保守性**                           | ✅ モジュール化されたデザインシステムに適した構造を推奨                               | ✅ 可能だが、強力なファイル/名前空間の規律が必要                            |
 | **エコシステム / コミュニティ**                          | ⚠️ 小規模だが急速に成長中                                                             | ✅ Vueエコシステム内で大規模かつ成熟している                                |
 
----
-
 ## 詳細比較
 
 ### 1) アーキテクチャとスケーラビリティ
@@ -76,8 +70,6 @@ author: aymericzip
 
 **重要な理由:** 大規模なVueアプリやデザインシステムでは、**モジュール化されたコンテンツ**の方がモノリシックなカタログよりもスケールしやすいです。
 
----
-
 ### 2) TypeScript と安全性
 
 - **vue-i18n**: TSサポートは良好ですが、**厳密なキー型付け**には通常カスタムスキーマやジェネリクス、慎重な規約が必要です。
@@ -85,8 +77,6 @@ author: aymericzip
 
 **重要な理由:** 強力な型付けにより、実行時**前に問題を検出**できます。
 
----
-
 ### 3) 翻訳欠落の処理
 
 - **vue-i18n**: **実行時**の警告やフォールバック（例：フォールバックロケールやキー）。
@@ -94,8 +84,6 @@ author: aymericzip
 
 **重要な理由:** ビルド時の検証により、本番環境のUIをクリーンかつ一貫性のある状態に保てます。
 
----
-
 ### 4) ルーティングとURL戦略（Vue Router/Nuxt）
 
 - **両者**ともローカライズされたルートに対応可能です。
@@ -103,8 +91,6 @@ author: aymericzip
 
 **重要な理由:** カスタムの接着層が減り、ロケール間での **よりクリーンな SEO** を実現します。
 
----
-
 ### 5) パフォーマンスと読み込み動作
 
 - **vue-i18n**: 非同期ロケールメッセージをサポートしますが、過剰なバンドルを避けるのはユーザー次第です（カタログを慎重に分割してください）。
@@ -112,8 +98,6 @@ author: aymericzip
 
 **重要な理由:** マルチロケールの Vue アプリで、より小さなバンドルサイズと高速な起動を実現します。
 
----
-
 ### 6) 開発者体験とツール
 
 - **vue-i18n**: 成熟したドキュメントとコミュニティを持ち、編集ワークフローには通常、**外部のローカリゼーションプラットフォーム**に依存します。
@@ -121,8 +105,6 @@ author: aymericzip
 
 **重要な理由:** 運用コストの削減と開発–コンテンツのループ短縮。
 
----
-
 ### 7) SEO、SSR & SSG
 
 - **両者**ともにVue SSRおよびNuxtと連携します。
@@ -130,8 +112,6 @@ author: aymericzip
 
 **重要な理由:** カスタム配線なしでの国際SEO。
 
----
-
 ## なぜIntlayerなのか？（問題とアプローチ）
 
 ほとんどのi18nスタック（**vue-i18n**を含む）は、**集中型カタログ**から始まります：
@@ -221,8 +201,6 @@ const { greeting } = useIntlayer("component-example");
 - **不要なキーを回避**（未使用のコンポーネントはコンテンツをインポートしない）。
 - **読み込みを最適化**（遅延読み込みされるコンポーネントは自身のコンテンツを持つ）。
 
----
-
 ## Intlayerの追加機能（Vue関連）
 
 - **クロスフレームワーク対応**：Vue、Nuxt、Vite、React、Expressなどで動作。
@@ -240,15 +218,11 @@ const { greeting } = useIntlayer("component-example");
 - **MCPサーバー＆VSCode拡張機能**: IDE内でのi18nワークフローとオーサリングを自動化。
 - **相互運用性**: 必要に応じて**vue-i18n**、**react-i18next**、**react-intl**と連携。
 
----
-
 ## どちらを選ぶべきか？
 
 - **vue-i18nを選ぶ場合**: 標準的なVueのアプローチを望み、カタログや名前空間の管理に慣れていて、アプリが**小規模から中規模**（またはすでにNuxt i18nを利用している）場合。
 - **Intlayerを選ぶ場合**: **コンポーネントスコープのコンテンツ**、**厳密なTypeScript**、**ビルド時の保証**、**ツリーシェイキング**、および**ルーティング/SEO/エディターツールが一式揃っていること**を重視し、特に**大規模でモジュール化されたVue/Nuxtコードベース**に適している場合。
 
----
-
 ## 実践的な移行ノート（vue-i18n → Intlayer）
 
 - **機能単位で開始**：ルート／ビュー／コンポーネントを一つずつローカルの Intlayer 辞書に移行します。
@@ -257,16 +231,12 @@ const { greeting } = useIntlayer("component-example");
 - **ルーター／SEO ヘルパーを採用**：ロケール検出と `hreflang` タグを標準化します。
 - **バンドルサイズを測定**：未使用のコンテンツが除外されることで、**バンドルサイズの削減**が期待できます。
 
----
-
 ## GitHub スター
 
 GitHub のスターは、プロジェクトの人気度、コミュニティの信頼、および長期的な関連性の強力な指標です。技術的品質の直接的な尺度ではありませんが、多くの開発者がプロジェクトを有用であると認識し、その進行状況をフォローし、採用する可能性があることを反映しています。プロジェクトの価値を見積もるために、スターは代替案間の牽引力を比較し、エコシステムの成長に関する洞察を提供するのに役立ちます。
 
 [![Star History Chart](https://api.star-history.com/svg?repos=intlify/vue-i18n&repos=aymericzip/intlayer&type=Date)](https://www.star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
 
----
-
 ## 結論
 
 **vue-i18n** と **Intlayer** はどちらも Vue アプリのローカライズに優れています。違いは、堅牢でスケーラブルなセットアップを実現するために、**どれだけ自分で構築する必要があるか**にあります：

package/blog/ja/what_is_internationalization.md

@@ -101,8 +101,6 @@ i18nのもう一つの重要な利点は、ユーザーエクスペリエンス
 - **文化的感受性**  
   アイコン、色、シンボルは文化によって異なる意味を持つ場合があります。地元の文化的ニュアンスを尊重するために、視覚的およびテキストコンテンツを調整することが重要です。
 
----
-
 ## i18nを実装するためのベストプラクティス
 
 - **早期計画**  
@@ -117,8 +115,6 @@ i18nのもう一つの重要な利点は、ユーザーエクスペリエンス
 - **翻訳の再利用性**  
   複数のウェブサイトやアプリケーションで再利用可能な翻訳ファイルを整理します。たとえば、多言語のフッターやヘッダーがある場合、専用の翻訳ファイルを設定して、共通の要素をすべてのプロジェクトに簡単に適用できるようにします。
 
----
-
 ## ロケールコンテンツの宣言 vs. CMSコンテンツの外部化
 
 ウェブサイトを作成するとき、**WordPress、Wix、Drupalなどのコンテンツ管理システム（CMS）は一般に保守性を改善します**。特に、統合されたi18n機能によるブログやランディングページに対してです。
@@ -136,8 +132,6 @@ i18nのもう一つの重要な利点は、ユーザーエクスペリエンス
 
 ニーズに合った適切なツールを選択し、国際化戦略を初めから計画することが重要です。**Intlayerは、ロケールコンテンツの宣言と緊密に統合されたヘッドレスCMSを組み合わせる魅力的なソリューションを提供し、両方の世界の利点を提供します。**
 
----
-
 ### テクノロジー別のi18nライブラリとツールのリストを確認する
 
 テクノロジー別のi18nライブラリとツールのリストを探している場合、以下のリソースをチェックしてください：
@@ -155,8 +149,6 @@ i18nのもう一つの重要な利点は、ユーザーエクスペリエンス
 - Svelte: [i18nライブラリとツールのリストを見る](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/list_i18n_technologies/frameworks/svelte.md)
 - React Native : [i18nライブラリとツールのリストを見る](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/list_i18n_technologies/frameworks/react-native.md)
 
----
-
 ## 結論
 
 国際化（i18n）は単なる技術的な手間ではなく、ユーザーの言葉を話すための**戦略的投資**です。ロケール固有の要素を抽象化し、言語や文化の変化に対応し、将来の拡張に備えることで、グローバル市場で製品が繁栄する力を与えます。

package/blog/ko/hreflang_guide_multilingual_seo.md

@@ -25,8 +25,6 @@ author: aymericzip
 
 번역은 쉬운 부분입니다. 어려운 부분은 검색 엔진에 이 페이지들이 **다른 언어로 된 같은 페이지**이지, 서로 경쟁하는 세 개의 문서가 아니라는 것을 알리는 것입니다. 그것이 `hreflang`이 하는 일이며, 대부분의 다국어 사이트가 조용히 트래픽을 잃는 곳입니다.
 
----
-
 ## hreflang이 실제로 무엇인가
 
 페이지에 대한 주석으로, _이 URL은 저 언어들을 위해 다른 곳에 동등한 버전이 있습니다._
@@ -42,8 +40,6 @@ author: aymericzip
 
 이것이 무엇이 아닌지 명확히 하는 것이 중요합니다. 이것은 **리다이렉트가 아닙니다** — 힌트일 뿐이며, Google이 이를 무시할 수 있습니다. 이것은 **순위 부스트가 아닙니다** — 순위 여부가 아니라 _어느_ 버전이 순위를 얻을지 변경합니다. 그리고 Bing은 이를 완전히 무시하며 대신 `content-language`와 지역 타게팅에 의존합니다.
 
----
-
 ## 선언 위치
 
 세 가지 배치, 모두 유효합니다. 하나를 선택하고 거기에 머물러 있으세요 — 같은 클러스터가 두 곳에서 선언되면 세트가 분산되는 방식입니다.
@@ -54,8 +50,6 @@ author: aymericzip
 
 **HTTP `Link` header**는 PDF와 같은 non-HTML 파일의 유일한 옵션입니다.
 
----
-
 ## 규칙
 
 ### Self-reference와 상호성
@@ -107,8 +101,6 @@ getLocalizedUrl("https://example.com/about", "fr"); // → "https://example.com/
 
 두 가지를 명확히 해야 합니다: `x-default`는 self-referencing 항목을 대체하는 것이 아니라 세트의 추가 항목이며, 다른 모든 항목처럼 클러스터의 모든 페이지에서 동일하게 나타나야 합니다.
 
----
-
 ## canonical 함정
 
 각 로컬라이제이션된 페이지는 **자신의 canonical이어야 합니다**:
@@ -131,8 +123,6 @@ getLocalizedUrl("https://example.com/about", "fr"); // → "https://example.com/
 
 **Canonical은 로케일별로 자체 참조입니다. `hreflang`은 클러스터를 설명합니다.**
 
----
-
 ## URL 구조 선택
 
 `hreflang`은 URL에 주석을 달므로 구조가 먼저 정해집니다.
@@ -149,14 +139,11 @@ getLocalizedUrl("https://example.com/about", "fr"); // → "https://example.com/
 
 > Intlayer는 `routing.mode` 및 `routing.domains`를 통해 세 가지 모두를 지원합니다. [사용자 정의 도메인](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ko/custom_domains.md) 및 [구성 참조](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ko/configuration.md)를 참조하십시오.
 
----
-
 ## 구현
 
 이러한 태그를 수동으로 작성하면 두 번째 locale과의 접촉에서 유지되지 않습니다. 대신 locale 목록에서 파생시키세요.
 
 <Steps>
-
 <Step number={1} title="모든 페이지에서 cluster 내보내기">
 
 모든 곳에서 동일한 set, locale별 canonical, 절대 URL, `x-default` 포함.
@@ -245,7 +232,6 @@ export const Route = createFileRoute("/{-$locale}/about")({
 </Tabs>
 
 </Step>
-
 <Step number={2} title="또는 모든 것을 sitemap으로 이동">
 
 규모가 커지면 페이지에서 주석을 완전히 제거하세요. `generateSitemap`은 config에서 로케일과 라우팅 모드를 읽어 항목마다 `xhtml:link` alternates를 생성합니다:
@@ -268,7 +254,6 @@ const sitemap = generateSitemap(
 - `entryPerLocale` (기본값 `false`) — 기본적으로 하나의 `<url>` 항목이 모든 대체 언어를 포함합니다. 두 형식 모두 유효하지만, `<loc>`으로 나열된 URL만 Search Console에서 _제출됨_으로 계산되며, 대체 언어 전용 locale은 발견 가능하지만 sitemap에 속하지 않습니다. 이 옵션을 켜면 모든 지역화된 URL이 자체 항목을 가지고 전체 대체 언어 세트가 반복됩니다. 이렇게 하면 항목 수가 locale 수만큼 증가하므로 50,000 URL / 50 MB 제한을 주의하고, 초과하면 sitemap 인덱스로 분할하세요.
 
 </Step>
-
 <Step number={3} title="crawler가 수신하는 내용 확인">
 
 `hreflang`은 조용히 실패하므로, 가정하지 말고 확인하세요.
@@ -281,8 +266,6 @@ const sitemap = generateSitemap(
 
 </Steps>
 
----
-
 ## 체크리스트
 
 - [ ] 각 로캘은 고유하고 크롤 가능한 URL을 가집니다
@@ -296,8 +279,6 @@ const sitemap = generateSitemap(
 - [ ] 정확히 한 곳에서 선언됩니다
 - [ ] Alternate 리다이렉트가 없습니다
 
----
-
 ## 마무리
 
 `hreflang`은 단순하면서도 엄격합니다. 하나의 누락된 return 태그, 하나의 상대 URL, 하나의 cross-locale canonical이 있으면 클러스터가 아무 오류 없이 버려집니다. 이 모든 문제는 태그를 수동으로 작성하는 데서 비롯됩니다.

package/blog/ko/i18n_meaning.md

@@ -92,8 +92,6 @@ i18n 의미는 언어를 넘어 확장됩니다. 진정한 국제화는 다음
 - **모든 사용자 대면 텍스트 추상화:** UI 컴포넌트 내에 하드코딩된 텍스트가 전혀 없도록 하세요.
 - **강력한 번역 관리 시스템 활용:** **Intlayer**와 같은 도구는 개발자와 번역가 사이의 간극을 줄여줍니다. Intlayer는 코드베이스와 긴밀하게 통합된 헤드리스 CMS 역할을 하며, 콘텐츠 관리자가 개발자의 새로운 빌드 없이도 번역을 시각적으로 업데이트할 수 있도록 지원합니다.
 
----
-
 ### 기술별 i18n 라이브러리 및 도구 목록 보기
 
 기술별 i18n 라이브러리 및 도구 목록을 찾으신다면 다음 리소스를 확인해 보세요:
@@ -112,8 +110,6 @@ i18n 의미는 언어를 넘어 확장됩니다. 진정한 국제화는 다음
 - Svelte: [i18n 라이브러리 및 도구 목록 보기](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ko/list_i18n_technologies/frameworks/svelte.md)
 - React Native: [i18n 라이브러리 및 도구 목록 보기](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ko/list_i18n_technologies/frameworks/react-native.md)
 
----
-
 ## 결론
 
 **i18n 의미**는 글로벌 영향력을 목표로 하는 모든 현대 디지털 비즈니스의 초석입니다. 국제화라는 단순한 기술적 약어를 넘어, i18n은 소프트웨어를 다양한 언어, 문화 및 지역 표준에 원활하게 적응시키는 데 필요한 기술적 아키텍처를 의미합니다.

package/blog/ko/i18n_using_next-i18next.md

@@ -71,8 +71,6 @@ author: aymericzip
 
 > 국제화 및 SEO에 대해 알아야 할 모든 내용을 나열한 문서를 참조하세요: [next-intl을 사용한 국제화 (i18n)](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ko/internationalization_and_SEO.md).
 
----
-
 ## Next.js 애플리케이션에서 i18next 설정 단계별 가이드
 
 <iframe
@@ -119,7 +117,6 @@ author: aymericzip
 ```
 
 <Steps>
-
 <Step number={1} title="의존성 설치">
 
 npm을 사용하여 필요한 패키지를 설치합니다:
@@ -141,7 +138,6 @@ yarn add i18next react-i18next i18next-resources-to-backend
 - **i18next-resources-to-backend**: 필요한 네임스페이스만 동적으로 로드할 수 있도록 번역 파일의 동적 로딩을 가능하게 하는 플러그인입니다.
 
 </Step>
-
 <Step number={2} title="프로젝트 구성">
 
 지원하는 로케일, 기본 로케일, URL 현지화에 대한 헬퍼 함수를 정의하는 구성 파일을 만드세요. 이 파일은 i18n 설정의 단일 진실 소스 역할을 하며 애플리케이션 전반에 걸쳐 타입 안전성을 보장합니다.
@@ -196,7 +192,6 @@ export function getCookie(locale: Locale) {
 ```
 
 </Step>
-
 <Step number={3} title="번역 네임스페이스 중앙 집중화">
 
 애플리케이션에서 노출하는 모든 네임스페이스에 대해 단일 소스 오브 트루스를 만드세요. 이 목록을 재사용하면 서버, 클라이언트, 툴링 코드가 동기화되고 번역 헬퍼에 대한 강력한 타입 지원이 활성화됩니다.
@@ -208,7 +203,6 @@ export type Namespace = (typeof namespaces)[number];
 ```
 
 </Step>
-
 <Step number={4} title="TypeScript로 번역 키 강력한 타입 지정하기">
 
 `i18next`를 확장하여 표준 언어 파일(보통 영어)을 가리키도록 하세요. 그러면 TypeScript가 네임스페이스별 유효한 키를 추론하여 `t()` 호출이 끝까지 검사됩니다.
@@ -248,7 +242,6 @@ export type AboutTranslator = TFunction<"about">;
 ```
 
 </Step>
-
 <Step number={5} title="서버 사이드 i18n 초기화 설정">
 
 서버 컴포넌트용 번역을 로드하는 서버 사이드 초기화 함수를 만듭니다. 이 함수는 서버 사이드 렌더링을 위해 별도의 i18next 인스턴스를 생성하여 렌더링 전에 번역이 로드되도록 보장합니다.
@@ -305,7 +298,6 @@ export async function initI18next(
 ```
 
 </Step>
-
 <Step number={6} title="클라이언트 사이드 i18n 프로바이더 생성">
 
 애플리케이션을 i18next 컨텍스트로 감싸는 클라이언트 컴포넌트 프로바이더를 생성합니다. 이 프로바이더는 서버에서 미리 로드된 번역을 받아 미번역 콘텐츠 깜빡임(FOUC)을 방지하고 중복 요청을 피합니다.
@@ -390,7 +382,6 @@ export default function I18nProvider({
 ```
 
 </Step>
-
 <Step number={7} title="동적 로케일 라우트 정의">
 
 앱 폴더에 `[locale]` 디렉토리를 생성하여 로케일에 대한 동적 라우팅을 설정합니다. 이를 통해 Next.js는 각 로케일이 URL 세그먼트가 되는 로케일 기반 라우팅을 처리할 수 있습니다 (예: `/en/about`, `/fr/about`).
@@ -444,7 +435,6 @@ export default function LocaleLayout({
 ```
 
 </Step>
-
 <Step number={8} title="번역 파일 생성하기">
 
 각 로케일과 네임스페이스별로 JSON 파일을 생성하세요. 이 구조는 번역을 논리적으로 조직하고 각 페이지에 필요한 번역만 로드할 수 있게 해줍니다.
@@ -539,7 +529,6 @@ export default function LocaleLayout({
 </Tabs>
 
 </Step>
-
 <Step number={9} title="페이지에서 번역 활용하기">
 
 서버에서 i18next를 초기화하고 번역을 서버와 클라이언트 컴포넌트 모두에 전달하는 페이지 컴포넌트를 만듭니다. 이렇게 하면 렌더링 전에 번역이 로드되어 콘텐츠 깜빡임을 방지할 수 있습니다.
@@ -601,7 +590,6 @@ export default async function AboutPage({
 ```
 
 </Step>
-
 <Step number={10} title="클라이언트 컴포넌트에서 번역 사용하기">
 
 클라이언트 컴포넌트는 `useTranslation` 훅을 사용하여 번역에 접근할 수 있습니다. 이 훅은 번역 함수와 i18n 인스턴스에 접근할 수 있게 하여, 콘텐츠를 번역하고 로케일 정보를 사용할 수 있도록 합니다.
@@ -654,7 +642,6 @@ export default ClientComponent;
 ```
 
 </Step>
-
 <Step number={11} title="서버 컴포넌트에서 번역 사용하기">
 
 서버 컴포넌트는 React 훅을 사용할 수 없으므로, 부모 컴포넌트로부터 props를 통해 번역을 전달받습니다. 이 방법은 서버 컴포넌트를 동기적으로 유지하며 클라이언트 컴포넌트 내부에 중첩될 수 있도록 합니다.
@@ -702,7 +689,6 @@ export default ServerComponent;
 ```
 
 </Step>
-
 <Step number={12} title="콘텐츠 언어 변경하기" isOptional={true}>
 
 Next.js에서 콘텐츠의 언어를 변경하는 권장 방법은 로케일 접두사가 붙은 URL과 Next.js 링크를 사용하는 것입니다. 아래 예제는 현재 로케일을 경로에서 읽어와 경로명에서 제거하고, 사용 가능한 각 로케일에 대해 하나의 링크를 렌더링합니다.
@@ -776,7 +762,6 @@ export default function LocaleSwitcher() {
 ```
 
 </Step>
-
 <Step number={13} title="지역화된 Link 컴포넌트 만들기" isOptional={true}>
 
 앱 전반에 걸쳐 지역화된 URL을 재사용하면 내비게이션이 일관되고 SEO 친화적으로 유지됩니다. 내부 경로에는 활성 로케일을 접두사로 붙이고 외부 URL은 그대로 두는 작은 헬퍼로 `next/link`를 감싸세요.
@@ -829,7 +814,6 @@ export default function LocalizedLink({
 > 팁: `LocalizedLink`는 드롭인 교체이므로, import를 교체하고 컴포넌트가 로케일별 URL을 처리하도록 하여 점진적으로 마이그레이션하세요.
 
 </Step>
-
 <Step number={14} title="서버 액션 내에서 활성 로케일 접근하기" isOptional={true}>
 
 서버 액션은 종종 이메일, 로깅 또는 서드파티 통합을 위해 현재 로케일이 필요합니다. 프록시가 설정한 로케일 쿠키와 `Accept-Language` 헤더를 결합하여 폴백으로 사용하세요.
@@ -869,7 +853,6 @@ export async function stuffFromServer(formData: FormData) {
 > 이 헬퍼는 Next.js의 쿠키와 헤더에 의존하기 때문에, Route Handlers, Server Actions 및 기타 서버 전용 컨텍스트에서 작동합니다.
 
 </Step>
-
 <Step number={15} title="메타데이터 국제화하기" isOptional={true}>
 
 콘텐츠 번역도 중요하지만, 국제화의 주요 목표는 여러분의 웹사이트를 전 세계에 더 잘 노출시키는 것입니다. I18n은 적절한 SEO를 통해 웹사이트 가시성을 향상시키는 놀라운 수단입니다.
@@ -938,7 +921,6 @@ export default async function AboutPage() {
 ```
 
 </Step>
-
 <Step number={16} title="사이트맵 국제화하기" isOptional={true}>
 
 모든 로케일 버전의 페이지를 포함하는 사이트맵을 생성하세요. 이는 검색 엔진이 모든 언어 버전의 콘텐츠를 발견하고 색인화하는 데 도움을 줍니다.
@@ -995,7 +977,6 @@ export default function sitemap(): MetadataRoute.Sitemap {
 ```
 
 </Step>
-
 <Step number={17} title="robots.txt 국제화하기" isOptional={true}>
 
 보호된 경로의 모든 로케일 버전을 적절히 처리하는 robots.txt 파일을 만드세요. 이를 통해 검색 엔진이 어떤 언어로든 관리자(admin) 또는 대시보드 페이지를 인덱싱하지 않도록 보장합니다.
@@ -1028,7 +1009,6 @@ export default function robots(): MetadataRoute.Robots {
 ```
 
 </Step>
-
 <Step number={18} title="로케일 라우팅을 위한 미들웨어 설정" isOptional={true}>
 
 사용자의 선호 로케일을 자동으로 감지하고 적절한 로케일 접두사가 붙은 URL로 리디렉션하는 프록시를 만듭니다. 이를 통해 사용자는 선호하는 언어로 된 콘텐츠를 볼 수 있어 사용자 경험이 향상됩니다.
@@ -1119,7 +1099,6 @@ export const config = {
 ```
 
 </Step>
-
 <Step number={19} title="Intlayer를 사용하여 번역 자동화하기" isOptional={true}>
 
 Intlayer는 애플리케이션의 현지화 과정을 지원하기 위해 설계된 **무료**이자 **오픈 소스** 라이브러리입니다. i18next가 번역 로딩과 관리를 담당하는 반면, Intlayer는 번역 워크플로우 자동화를 도와줍니다.

package/blog/ko/i18n_using_next-intl.md

@@ -64,8 +64,6 @@ author: aymericzip
 
 > 국제화 및 SEO에 대해 알아야 할 모든 내용을 정리한 문서를 참고하세요: [next-intl과 함께하는 국제화(i18n)](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ko/internationalization_and_SEO.md).
 
----
-
 ## Next.js 애플리케이션에서 next-intl 설정 단계별 가이드
 
 <iframe
@@ -111,7 +109,6 @@ loading="lazy"
 ```
 
 <Steps>
-
 <Step number={1} title="의존성 설치">
 
 npm을 사용하여 필요한 패키지를 설치하세요:
@@ -131,7 +128,6 @@ yarn add next-intl
 - **next-intl**: Next.js App Router용 핵심 국제화 라이브러리로, 번역 관리를 위한 훅, 서버 함수, 클라이언트 프로바이더를 제공합니다.
 
 </Step>
-
 <Step number={2} title="프로젝트 구성">
 
 지원하는 로케일을 정의하고 next-intl의 요청 구성을 설정하는 구성 파일을 만드세요. 이 파일은 i18n 설정의 단일 진실 소스로 작동하며 애플리케이션 전반에 걸쳐 타입 안전성을 보장합니다.
@@ -217,7 +213,6 @@ export const proxy = createMiddleware(routingOptions);
 ```
 
 </Step>
-
 <Step number={3} title="동적 로케일 라우트 정의">
 
 앱 폴더에 `[locale]` 디렉토리를 생성하여 로케일 기반 동적 라우팅을 설정하세요. 이를 통해 Next.js는 각 로케일이 URL 세그먼트가 되는 로케일 기반 라우팅을 처리할 수 있습니다 (예: `/en/about`, `/fr/about`).
@@ -308,7 +303,6 @@ export default async function AboutPage({
 ```
 
 </Step>
-
 <Step number={4} title="번역 파일 생성하기">
 
 각 로케일과 네임스페이스별로 JSON 파일을 생성하세요. 이 구조는 번역을 논리적으로 구성하고 각 페이지에 필요한 번역만 로드할 수 있게 해줍니다.
@@ -370,7 +364,6 @@ export default async function AboutPage({
 </Tabs>
 
 </Step>
-
 <Step number={5} title="페이지에서 번역 활용하기">
 
 서버에서 번역을 로드하고 이를 서버 및 클라이언트 컴포넌트 모두에 전달하는 페이지 컴포넌트를 만드세요. 이렇게 하면 렌더링 전에 번역이 로드되어 콘텐츠 깜박임을 방지할 수 있습니다.
@@ -423,7 +416,6 @@ export default async function AboutPage({
 ```
 
 </Step>
-
 <Step number={6} title="클라이언트 컴포넌트에서 번역 사용하기">
 
 클라이언트 컴포넌트는 `useTranslations` 및 `useFormatter` 훅을 사용하여 번역 및 포맷팅 기능에 접근할 수 있습니다. 이 훅들은 `NextIntlClientProvider` 컨텍스트에서 값을 읽어옵니다.
@@ -461,7 +453,6 @@ const ClientComponent = () => {
 ```
 
 </Step>
-
 <Step number={7} title="서버 컴포넌트에서 번역 사용하기">
 
 서버 컴포넌트는 React 훅을 사용할 수 없으므로, 부모 컴포넌트로부터 props를 통해 번역과 포매터를 전달받습니다. 이 방법은 서버 컴포넌트를 동기적으로 유지하며 클라이언트 컴포넌트 내부에 중첩될 수 있게 합니다.
@@ -495,7 +486,6 @@ const ServerComponent = ({
 > 페이지나 레이아웃에서 `next-intl/server`의 `getTranslations`와 `getFormatter`를 사용하여 번역과 포맷팅을 미리 계산한 후, 이를 props로 서버 컴포넌트에 전달하세요.
 
 </Step>
-
 <Step number={8} title="콘텐츠의 언어 변경하기" isOptional={true}>
 
 next-intl을 사용하여 콘텐츠의 언어를 변경하려면, 동일한 경로명을 가리키면서 로케일을 전환하는 로케일 인식 링크를 렌더링하세요. 프로바이더가 URL을 자동으로 재작성하므로 현재 경로만 지정하면 됩니다.
@@ -569,7 +559,6 @@ export default function LocaleSwitcher() {
 ```
 
 </Step>
-
 <Step number={9} title="현지화된 Link 컴포넌트 사용하기" isOptional={true}>
 
 `next-intl`은 활성 로케일을 자동으로 적용하는 현지화된 링크 컴포넌트를 포함하는 서브패키지 `next-intl/navigation`을 제공합니다. 우리는 이미 `@/i18n` 파일에서 이를 추출해 두었으므로 다음과 같이 사용할 수 있습니다:
@@ -581,7 +570,6 @@ return <Link href="/about">t("about.title")</Link>;
 ```
 
 </Step>
-
 <Step number={10} title="서버 액션 내에서 활성 로케일 접근하기" isOptional={true}>
 
 서버 액션은 `next-intl/server`를 사용하여 현재 로케일을 읽을 수 있습니다. 이는 현지화된 이메일을 보내거나 제출된 데이터와 함께 언어 선호도를 저장하는 데 유용합니다.
@@ -606,7 +594,6 @@ export async function handleContactForm(formData: FormData) {
 > `getLocale`는 `next-intl` 프록시가 설정한 locale을 읽기 때문에 서버 어디서나 작동합니다: Route Handlers, Server Actions, 그리고 edge functions.
 
 </Step>
-
 <Step number={11} title="메타데이터 국제화하기" isOptional={true}>
 
 콘텐츠 번역도 중요하지만, 국제화의 주요 목표는 웹사이트를 전 세계에 더 잘 보이게 만드는 것입니다. I18n은 적절한 SEO를 통해 웹사이트 가시성을 향상시키는 놀라운 수단입니다.
@@ -647,7 +634,6 @@ export async function generateMetadata({
 ```
 
 </Step>
-
 <Step number={12} title="사이트맵 국제화하기" isOptional={true}>
 
 모든 로케일 버전의 페이지를 포함하는 사이트맵을 생성하세요. 이는 검색 엔진이 모든 언어 버전의 콘텐츠를 발견하고 색인화하는 데 도움이 됩니다.
@@ -703,7 +689,6 @@ export default function sitemap(): MetadataRoute.Sitemap {
 ```
 
 </Step>
-
 <Step number={13} title="robots.txt 국제화하기" isOptional={true}>
 
 보호된 경로의 모든 로케일 버전을 적절히 처리하는 robots.txt 파일을 만드세요. 이를 통해 검색 엔진이 어떤 언어로든 관리자(admin)나 대시보드 페이지를 인덱싱하지 않도록 할 수 있습니다.
@@ -738,7 +723,6 @@ export default function robots(): MetadataRoute.Robots {
 ```
 
 </Step>
-
 <Step number={14} title="로케일 라우팅을 위한 프록시 설정" isOptional={true}>
 
 사용자의 선호 로케일을 자동으로 감지하고 적절한 로케일 접두사가 붙은 URL로 리디렉션하는 프록시를 만드세요. next-intl은 이를 자동으로 처리하는 편리한 프록시 함수를 제공합니다.
@@ -760,7 +744,6 @@ export const config = {
 ```
 
 </Step>
-
 <Step number={15} title="로케일에 대한 TypeScript 타입 설정" isOptional={true}>
 
 TypeScript 설정은 키에 대한 자동완성과 타입 안전성을 제공하는 데 도움이 됩니다.
@@ -788,7 +771,6 @@ declare module "next-intl" {
 이 코드는 모듈 확장(Module Augmentation)을 사용하여 locales와 messages를 next-intl의 AppConfig 타입에 추가합니다.
 
 </Step>
-
 <Step number={16} title="Intlayer를 사용하여 번역 자동화하기" isOptional={true}>
 
 Intlayer는 애플리케이션의 현지화 과정을 지원하기 위해 설계된 **무료**이자 **오픈 소스** 라이브러리입니다. next-intl이 번역 로딩과 관리를 담당하는 반면, Intlayer는 번역 워크플로우를 자동화하는 데 도움을 줍니다.

package/blog/ko/index.md

@@ -20,8 +20,6 @@ author: aymericzip
 
 JavaScript 애플리케이션의 모든 것에 전념하는 블로그에 오신 것을 환영합니다! 여기에서 개발자가 전 세계적으로 디지털 제품을 확장할 수 있도록 돕는 모범 사례, 전략 및 도구를 탐구합니다.
 
----
-
 ## 왜 국제화(i18n)가 중요한가
 
 오늘날의 상호 연결된 세계에서 사용자는 매끄럽고 현지화된 경험을 기대합니다. 국제화(i18n)는 웹 애플리케이션이 다양한 언어와 문화적 뉘앙스에 적응할 수 있도록 보장합니다. 처음부터 i18n 관행을 포함하면 다음과 같은 여러 가지 이점을 얻을 수 있습니다:
@@ -31,8 +29,6 @@ JavaScript 애플리케이션의 모든 것에 전념하는 블로그에 오신
 3. **향상된 접근성:** 잘 구조화된 i18n은 종종 접근성 표준과 일치하여 애플리케이션을 더 포용적으로 만듭니다.
 4. **더 나은 SEO 성능:** 현지화된 콘텐츠는 지역별 검색 결과에서 가시성을 높일 수 있습니다.
 
----
-
 ## 오픈 소스 국제화 솔루션
 
 국제화된 애플리케이션을 구축하는 것은 복잡할 필요가 없습니다. 오픈 소스 커뮤니티는 현지화를 더 간단하게 만드는 많은 강력하고 잘 지원되는 도구와 라이브러리를 제공합니다. **react-intl**, **i18next**, **FormatJS**와 같은 인기 있는 솔루션은 유연한 API와 React, Vue, Angular와 같은 현대 JavaScript 프레임워크와의 손쉬운 통합을 제공합니다.
@@ -43,8 +39,6 @@ JavaScript 애플리케이션의 모든 것에 전념하는 블로그에 오신
 - **비용 절감:** 라이센스 요금이 없어 애플리케이션을 테스트하거나 확장하기가 더 간편합니다.
 - **커뮤니티 지원:** 큰 커뮤니티는 종종 더 많은 튜토리얼, 문서 및 기성 플러그인을 의미합니다.
 
----
-
 ## 공지사항 및 향후 계획
 
 글로벌 청중을 위해 JavaScript 애플리케이션을 최적화하는 방법에 대한 튜토리얼, 모범 사례 및 **사례 연구**를 발표하게 되어 기쁩니다. 다음은 미리 보기입니다:
@@ -55,8 +49,6 @@ JavaScript 애플리케이션의 모든 것에 전념하는 블로그에 오신
 
 이 업데이트와 더 많은 내용을 기대해 주세요!
 
----
-
 ## 블로그에 기여하세요!
 
 우리는 커뮤니티 주도의 지식 공유를 믿습니다. 국제화, **SEO**, 또는 기타 관련 주제에 대한 훌륭한 블로그 게시물 아이디어가 있다면 듣고 싶습니다. GitHub 리포지토리에 제안하는 블로그 게시물을 추가하여 Pull Request를 제출할 수 있습니다:
@@ -65,6 +57,4 @@ JavaScript 애플리케이션의 모든 것에 전념하는 블로그에 오신
 
 여러분의 기여는 저희 플랫폼을 풍요롭게 하고 전 세계 개발자에게 힘을 실어 줍니다. 글로벌 우선 애플리케이션의 커뮤니티를 함께 구축합시다.
 
----
-
 **읽어 주셔서 감사합니다. 그리고 저희 i18n 커뮤니티에 오신 것을 환영합니다!** JavaScript 애플리케이션을 국제적으로 성공시키기 위한 더 많은 통찰력, 팁 및 모범 사례를 기대해 주세요.