@intlayer/docs 9.4.3 → 9.5.0

package/blog/ko/transform_existing_vite_react_app_using_compiler.md

@@ -0,0 +1,353 @@
+---
+createdAt: 2024-03-07
+updatedAt: 2026-09-06
+title: "기존 Vite 및 React 애플리케이션을 사후에 다국어(i18n)화하는 방법 (2026 가이드)"
+description: "기존 Vite 및 React 앱을 대대적인 리팩토링 없이 다국어(i18n)화하는 2026년 가이드. Intlayer를 활용한 자동 텍스트 추출, AI 번역 및 번들 최적화를 경험하세요."
+keywords:
+  - Vite i18n
+  - React i18n
+  - 국제화
+  - 기존 Vite 앱 번역
+  - 기존 React 앱 번역
+  - Intlayer
+  - 다국어
+  - 컴파일러
+  - AI 번역
+  - SEO
+slugs:
+  - blog
+  - transform-existing-react-app-into-multilingual-app
+applicationTemplate: https://github.com/aymericzip/intlayer-vite-react-template
+applicationShowcase: https://intlayer-vite-react-template.vercel.app
+youtubeVideo: https://www.youtube.com/watch?v=dS9L7uJeak4
+history:
+  - version: 8.9.0
+    date: 2026-05-04
+    changes: "Update Solid useIntlayer API usage to direct property access"
+  - version: 8.2.0
+    date: 2026-03-09
+    changes: "Update compiler options, add FilePathPattern support"
+  - version: 8.1.6
+    date: 2026-02-23
+    changes: "Initial release"
+author: aymericzip
+---
+
+# 기존 Vite 및 React 애플리케이션을 사후에 다국어(i18n)화하는 방법 (2026 가이드)
+
+처음부터 Vite 및 React 프로젝트에 국제화(i18n)를 적용하는 것은 비교적 간단합니다. 하지만 이미 단일 언어로 구축되어 배포 중인 애플리케이션에 **사후에** 다국어를 적용해야 한다면 어떻게 해야 할까요?
+
+`react-i18next`나 `react-intl` 같은 기존 라이브러리를 사용해 본 개발자라면 그 번거로움을 잘 알고 있습니다:
+
+- 수백 개의 JSX 및 TSX 파일에서 하드코딩된 문자열을 일일이 찾아내기.
+- 중첩된 JSON 딕셔너리를 수동으로 생성하고 번역 키(`components.header.title` 등)를 임의로 작명하기.
+- UI 텍스트를 번거로운 훅(`t('...')`)으로 교체하기.
+- 클라이언트 측 라우팅, 상태 관리 및 언어 전환 로직을 재구성하기.
+
+2026년에는 코드베이스 전체를 처음부터 다시 작성할 필요가 없습니다. **Intlayer**를 사용하면 자동 텍스트 추출, AI 번역 및 매끄러운 Vite 통합을 통해 단 몇 분 만에 기존 Vite 및 React 앱에 다국어를 도입할 수 있습니다.
+
+> Vite 및 React에 대한 단계별 기술 가이드를 찾고 계신가요? 전용 문서를 확인하세요: [Intlayer로 Vite 및 React 번역하기](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ko/intlayer_with_vite+react.md).
+
+## 목차
+
+<TOC/>
+
+## 사후 적용의 딜레마: 기존 앱에 다국어를 추가하기 힘든 이유
+
+기존 Vite 및 React 애플리케이션에 국제화를 적용할 때 개발자는 세 가지 큰 장애물에 직면합니다:
+
+1. **코드베이스 오염**: 문자열을 수동으로 JSON 딕셔너리에 추출하려면 거의 모든 컴포넌트 파일을 수정해야 합니다. 이는 대규모 Git diff, 병합 충돌 위험 및 화면 깨짐 버그를 유발합니다.
+2. **번역 키 관리 부담**: 텍스트 조각마다 `dashboard.hero.ctaButton`과 같은 키를 작명하는 것은 개발 속도를 늦추고 문구가 바뀔 때마다 인지적 부담을 줍니다.
+3. **지루한 번역 작업**: 문자열을 추출한 후 5개, 10개 또는 20개 언어로 딕셔너리를 채우려면 끝없는 복사-붙여넣기나 값비싼 외부 번역 서비스가 필요합니다.
+
+Intlayer는 **컴파일러 기반 자동 추출**, **컴포넌트 단위 선언적 딕셔너리**, 그리고 **Vite와의 완벽한 통합**을 통해 이러한 문제를 근본적으로 해결합니다.
+
+## 자동 콘텐츠 추출 (수동 문자열 탐색 불필요)
+
+JSX에서 하드코딩된 문자열을 일일이 복사할 필요 없이, Intlayer는 두 가지 편리한 경로를 제공합니다:
+
+### 옵션 A: CLI 추출 도구 (`npx intlayer extract`)
+
+코드베이스에서 바로 Intlayer의 추출 도구를 실행할 수 있습니다:
+
+```bash packageManager="npm"
+npx intlayer extract
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer extract
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer extract
+```
+
+```bash packageManager="bun"
+bunx intlayer extract
+```
+
+이 명령어는 React 컴포넌트를 파싱하고 사용자에게 표시되는 텍스트를 감지하여 컴포넌트 파일 바로 옆에 콘텐츠 선언 파일(`.content.ts`)을 자동 생성합니다. 컴포넌트 로직은 선언적이고 명확하며 타입 안전하게 유지되며, 번역 키를 손수 작성할 필요가 없습니다.
+
+### 옵션 B: Intlayer 컴파일러 (빌드 타임 자동 추출)
+
+설정에서 Intlayer 컴파일러를 활성화하면 기본 언어의 일반 텍스트로 컴포넌트를 평소처럼 계속 작성할 수 있습니다. 빌드 시 컴파일러가 텍스트를 추출하고 지역화된 콘텐츠를 자동으로 주입합니다:
+
+```tsx fileName="src/App.tsx"
+// 일반적인 React 코드를 작성하세요. 컴파일러가 자동으로 텍스트를 추출합니다
+export default function App() {
+  return (
+    <section>
+      <h1>플랫폼에 오신 것을 환영합니다</h1>
+      <p>지금 최신 기능을 경험해 보세요.</p>
+    </section>
+  );
+}
+```
+
+백그라운드에서 Intlayer가 딕셔너리를 빌드하고 컴포넌트를 지역화된 콘텐츠와 자동으로 연결하므로 수동 리팩토링 단계가 완전히 생략됩니다.
+
+이 경우 다음과 같은 구조의 `src/App.content.ts` 선언 파일이 생성됩니다:
+
+```typescript fileName="src/App.content.ts"
+import { Dictionary } from "intlayer";
+
+const content = {
+  key: "app",
+  content: {
+    peullaespomeOsinGeoseulHwan: t({
+      ko: "플랫폼에 오신 것을 환영합니다",
+    }),
+    jigeumChoesinGineungeulGyeon: t({
+      ko: "지금 최신 기능을 경험해 보세요.",
+    }),
+  },
+};
+
+export default content;
+```
+
+## 선호하는 LLM을 활용한 AI 자동 번역
+
+콘텐츠가 추출된 후 수십 개 언어로 번역하는 데 며칠씩 걸릴 필요가 없습니다. Intlayer에는 자체 API 키를 사용하여 OpenAI, Anthropic, DeepSeek, Mistral과 직접 연동되는 AI 번역 CLI가 내장되어 있습니다:
+
+```bash packageManager="npm"
+npx intlayer fill
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer fill
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer fill
+```
+
+```bash packageManager="bun"
+bunx intlayer fill
+```
+
+`intlayer.config.ts`에서 지원할 로케일과 AI 제공자를 설정합니다:
+
+```typescript fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH, Locales.KOREAN],
+    defaultLocale: Locales.KOREAN,
+  },
+  ai: {
+    provider: "openai",
+    model: "gpt-4o-mini",
+    apiKey: process.env.OPENAI_API_KEY,
+    applicationContext:
+      "Vite 및 React로 구축된 최신 SaaS 애플리케이션 및 대시보드",
+  },
+};
+
+export default config;
+```
+
+`npx intlayer fill`을 실행하면 설정된 모든 로케일에 대해 고품질 번역이 콘텐츠 선언 파일에 채워집니다:
+
+```typescript fileName="src/App.content.ts"
+import { Dictionary } from "intlayer";
+
+const content = {
+  key: "app",
+  content: {
+    peullaespomeOsinGeoseulHwan: t({
+      ko: "플랫폼에 오신 것을 환영합니다",
+      en: "Welcome to our platform",
+      fr: "Bienvenue sur notre plateforme",
+      es: "Bienvenido a nuestra plataforma",
+    }),
+    jigeumChoesinGineungeulGyeon: t({
+      ko: "지금 최신 기능을 경험해 보세요.",
+      en: "Start exploring our modern features today.",
+      fr: "Découvrez nos fonctionnalités modernes dès aujourd'hui.",
+      es: "Comience a explorar nuestras funciones modernas hoy.",
+    }),
+  },
+};
+
+export default content;
+```
+
+Intlayer가 모델에 `applicationContext`를 제공하므로 생성된 번역은 일반 기계 번역보다 기술적 맥락, 브랜드 보이스 및 문법적 디테일을 훨씬 더 정확하게 유지합니다.
+
+배포 전 누락된 텍스트가 없는지 확인하려면 다음을 실행하세요:
+
+```bash
+npx intlayer test
+```
+
+## Vite 통합 및 Provider 설정
+
+Vite에 Intlayer를 통합하는 것은 `vite.config.ts`에 플러그인을 추가하고 루트 컴포넌트를 `IntlayerProvider`로 감싸는 것만으로 완료됩니다:
+
+```typescript fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import react from "@vitejs/plugin-react-swc";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [react(), intlayer()],
+});
+```
+
+> Intlayer v9부터 컴파일러는 `intlayer()` 플러그인에 내장되어 있어 `intlayer.config.ts`에 `compiler.enabled`를 설정하면 자동으로 활성화됩니다.
+
+루트 컴포넌트에서 애플리케이션을 `IntlayerProvider`로 감싸줍니다:
+
+```tsx fileName="src/App.tsx"
+import { FC } from "react";
+import { IntlayerProvider } from "react-intlayer";
+import { MainContent } from "./MainContent";
+
+const App: FC = () => {
+  return (
+    <IntlayerProvider>
+      <MainContent />
+    </IntlayerProvider>
+  );
+};
+
+export default App;
+```
+
+### 동적 언어 전환
+
+`useLocale` 훅을 사용하여 애플리케이션 어디에서나 간편하게 언어를 전환할 수 있습니다:
+
+```tsx fileName="src/components/LocaleSwitcher.tsx"
+import { FC } from "react";
+import { Locales } from "intlayer";
+import { useLocale } from "react-intlayer";
+
+export const LocaleSwitcher: FC = () => {
+  const { locale, setLocale, availableLocales } = useLocale();
+
+  return (
+    <select
+      value={locale}
+      onChange={(e) => setLocale(e.target.value as Locales)}
+    >
+      {availableLocales.map((loc) => (
+        <option key={loc} value={loc}>
+          {loc}
+        </option>
+      ))}
+    </select>
+  );
+};
+```
+
+## 다국어 SEO (Sitemap 및 Robots.txt)
+
+Intlayer는 정적 Vite 배포 환경을 위해 크롤러 친화적인 `sitemap.xml` 및 `robots.txt`를 생성하는 `generateSitemap` 및 `getMultilingualUrls`와 같은 유틸리티를 제공합니다:
+
+```javascript fileName="generate-seo.mjs"
+import fs from "fs";
+import path from "path";
+import { fileURLToPath } from "url";
+import { generateSitemap, getMultilingualUrls } from "intlayer";
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const SITE_URL = (process.env.SITE_URL || "https://example.com").replace(
+  /\/$/,
+  ""
+);
+
+const pathList = [
+  { path: "/", changefreq: "daily", priority: 1.0 },
+  { path: "/about", changefreq: "monthly", priority: 0.7 },
+];
+
+const sitemapXml = generateSitemap(pathList, { siteUrl: SITE_URL });
+fs.writeFileSync(path.join(__dirname, "public", "sitemap.xml"), sitemapXml);
+
+const getAllMultilingualUrls = (urls) =>
+  urls.flatMap((url) => Object.values(getMultilingualUrls(url)));
+
+const disallowedPaths = getAllMultilingualUrls(["/admin", "/private"]);
+
+const robotsTxt = [
+  "User-agent: *",
+  "Allow: /",
+  ...disallowedPaths.map((path) => `Disallow: ${path}`),
+  "",
+  `Sitemap: ${SITE_URL}/sitemap.xml`,
+].join("\n");
+
+fs.writeFileSync(path.join(__dirname, "public", "robots.txt"), robotsTxt);
+console.log("SEO 파일이 성공적으로 생성되었습니다.");
+```
+
+`package.json`에 `prebuild` 스크립트를 추가하여 `vite build` 전에 실행되도록 설정합니다:
+
+```json fileName="package.json"
+{
+  "scripts": {
+    "dev": "vite",
+    "prebuild": "node generate-seo.mjs",
+    "build": "vite build",
+    "preview": "vite preview"
+  }
+}
+```
+
+## 심층 가이드: 단계별 설정이 준비되셨나요?
+
+이 가이드는 2026년에 대규모 리팩토링 없이 기존 Vite 및 React 앱을 다국어화하는 전반적인 개념을 소개했습니다.
+
+엄격한 TypeScript 타입 안전성, 동적 딕셔너리 및 비주얼 에디터를 포함한 모든 설정 단계를 자세히 확인하려면 공식 기술 가이드를 참고하세요:
+
+👉 **[Intlayer를 활용한 Vite 및 React 번역 전체 가이드](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ko/intlayer_with_vite+react.md)**
+
+## 자주 묻는 질문 (FAQ)
+
+<FAQ>
+
+<Question title="모든 문자열을 수동으로 수정하지 않고도 Vite 및 React 앱을 다국어화할 수 있나요?">
+
+네. `npx intlayer extract`를 실행하여 하드코딩된 텍스트를 지역화된 콘텐츠 선언 파일로 자동 추출하거나, Intlayer 컴파일러를 사용하여 빌드 시 컴포넌트를 자동 변환하면서 표준 JSX를 작성할 수 있습니다.
+
+</Question>
+<Question title="react-i18next나 react-intl에 비해 Intlayer는 어떻게 Vite 번들 크기를 줄이나요?">
+
+Intlayer는 컴포넌트별 딕셔너리 정의와 빌드 타임 매크로 최적화를 사용합니다. 거대한 JSON 파일을 한 번에 불러오는 대신 현재 화면에 렌더링되는 컴포넌트에 필요한 데이터만 번들에 포함됩니다. 동적 딕셔너리를 통해 언어별 지연 로딩도 가능합니다.
+
+</Question>
+<Question title="AI를 사용하여 기존 컴포넌트를 여러 언어로 자동 번역할 수 있나요?">
+
+네. Intlayer CLI의 `npx intlayer fill` 명령어를 사용하면 설정된 AI 제공자(OpenAI, Anthropic, Mistral, DeepSeek)와 연동하여 프로젝트 전체에서 누락된 언어 번역을 문맥에 맞게 생성할 수 있습니다.
+
+</Question>
+<Question title="컴포넌트를 다시 작성하지 않고 react-i18next나 react-intl에서 마이그레이션할 수 있나요?">
+
+네. Intlayer는 `react-i18next` 및 `react-intl`을 위한 호환 어댑터를 제공하며, 기존 JSON 번역 파일을 동기화할 수 있는 전용 플러그인(`sync-json`)도 제공합니다.
+
+</Question>
+
+</FAQ>

package/blog/ko/vue-i18n_vs_intlayer.md

@@ -33,15 +33,11 @@ author: aymericzip
 
 > **요약**: 두 솔루션 모두 Vue 앱을 현지화할 수 있습니다. 만약 **컴포넌트 범위 콘텐츠**, **엄격한 TypeScript 타입**, **빌드 시 누락 키 검사**, **트리 쉐이킹된 사전**, 그리고 **기본 제공 라우터/SEO 도우미**와 더불어 **비주얼 에디터 및 AI 번역**을 원한다면, **Intlayer**가 더 완전하고 현대적인 선택입니다.
 
----
-
 ## 상위 수준 포지셔닝
 
 - **vue-i18n** - Vue의 사실상 표준 i18n 라이브러리입니다. 유연한 메시지 포맷팅(ICU 스타일), 로컬 메시지를 위한 SFC `<i18n>` 블록, 그리고 방대한 생태계를 갖추고 있습니다. 안전성과 대규모 유지보수는 주로 사용자의 몫입니다.
 - **Intlayer** - 엄격한 TS 타이핑, 빌드 타임 검사, 트리 쉐이킹, 라우터 및 SEO 도우미, 선택적 비주얼 에디터/CMS, AI 지원 번역 기능을 갖춘 Vue/Vite/Nuxt용 컴포넌트 중심 콘텐츠 모델입니다.
 
----
-
 ## 나란히 기능 비교 (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 STARs
 
 GitHub stars는 프로젝트의 인기도, 커뮤니티 신뢰도, 장기적 관련성의 강력한 지표입니다. 기술적 품질을 직접 측정하는 것은 아니지만, 얼마나 많은 개발자들이 프로젝트를 유용하게 생각하고, 진행 상황을 따르고 있으며, 채택할 가능성이 있는지를 반영합니다. 프로젝트의 가치를 추정하기 위해 stars는 대안들 간의 견인력을 비교하고 생태계 성장에 대한 통찰력을 제공합니다.
 
 [![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/ko/what_is_internationalization.md

@@ -99,8 +99,6 @@ i18n의 또 다른 중요한 이점은 사용자 경험의 향상입니다. 사
 - **문화적 민감성**  
   아이콘, 색상 및 기호는 문화에 따라 다른 의미를 가질 수 있습니다. 지역 문화적 뉘앙스를 존중하여 시각적 및 텍스트 콘텐츠를 조정하는 것이 중요합니다.
 
----
-
 ## i18n 구현을 위한 모범 사례
 
 - **조기 계획**  
@@ -115,8 +113,6 @@ i18n의 또 다른 중요한 이점은 사용자 경험의 향상입니다. 사
 - **번역 재사용성**  
   여러 웹사이트나 애플리케이션에서 재사용할 수 있도록 번역 파일을 조직하십시오. 예를 들어, 다국어 바닥글이나 머리글이 있는 경우, 전용 번역 파일을 설정하여 공통 요소를 모든 프로젝트에 쉽게 적용할 수 있도록 합니다.
 
----
-
 ## 로케일 콘텐츠 선언 vs. CMS 콘텐츠 외부화
 
 웹사이트를 생성할 때 **WordPress, Wix 또는 Drupal과 같은 콘텐츠 관리 시스템(CMS)은 일반적으로 개선된 유지보수성을 제공합니다.** 특히 블로그나 랜딩 페이지의 경우 통합된 i18n 기능 덕분입니다.
@@ -134,8 +130,6 @@ i18n의 또 다른 중요한 이점은 사용자 경험의 향상입니다. 사
 
 필요에 맞는 올바른 도구를 선택하고 국제화 전략을 처음부터 계획하는 것이 중요합니다. **Intlayer는 로케일 콘텐츠 선언과 긴밀히 통합된 해드리스 CMS를 결합하여 두 가지 세계의 장점을 제공하는 매력적인 솔루션을 제공합니다.**
 
----
-
 ### 기술별 i18n 라이브러리 및 도구 목록 보기
 
 기술별 i18n 라이브러리 및 도구 목록을 찾고 있다면 다음 자료를 확인하십시오:
@@ -153,8 +147,6 @@ i18n의 또 다른 중요한 이점은 사용자 경험의 향상입니다. 사
 - Svelte: [i18n 라이브러리 및 도구 목록 보기](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ko/list_i18n_technologies/frameworks/svelte.md)
 - React Native : [i18n 라이브러리 및 도구 목록 보기](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ko/list_i18n_technologies/frameworks/react-native.md)
 
----
-
 ## 결론
 
 국제화(i18n)는 단순한 기술적 작업 그 이상입니다. 이는 사용자의 언어를 구사할 수 있게 해주는 **전략적 투자**입니다. 지역별 특정 요소를 추상화하고 언어적 및 문화적 변variation을 수용하며, 향후 확장을 계획함으로써, 글로벌 시장에서 제품이 성공적으로 성장할 수 있도록 합니다.

package/blog/pl/hreflang_guide_multilingual_seo.md

@@ -25,8 +25,6 @@ Przetłumaczyłeś swoją aplikację. Wdrożyłeś `/en`, `/fr`, `/es`. A użytk
 
 Tłumaczenie to łatwa połowa. Trudna połowa to poinformowanie wyszukiwarek, że te strony to **ta sama strona w innym języku**, a nie trzy dokumenty konkurujące ze sobą. To jest to, co robi `hreflang`, i to jest gdzie większość wielojęzycznych stron po cichu traci swój ruch.
 
----
-
 ## Co naprawdę robi hreflang
 
 Adnotacja na stronie mówiąca: _ten URL ma równoważne wersje tam, dla tych języków._
@@ -42,8 +40,6 @@ Daje ci dwie rzeczy: wyświetlenie prawidłowej wersji właściwemu użytkowniko
 
 Warto wyjaśnić, czym to nie jest. To **nie jest przekierowanie** — to wskazówka, którą Google może zastąpić. To **nie jest wzmocnienie rankingu** — zmienia _którą_ wersję rankingu, a nie _czy_ się plasują. A Bing w ogóle to ignoruje, polegając zamiast tego na `content-language` i geo-targetowaniu.
 
----
-
 ## Gdzie to zadeklarować
 
 Trzy umiejscowienia, wszystkie prawidłowe. Wybierz jedno i pozostań tam — ten sam klaster zadeklarowany w dwóch miejscach to jak zestawy dryfują.
@@ -54,8 +50,6 @@ Trzy umiejscowienia, wszystkie prawidłowe. Wybierz jedno i pozostań tam — te
 
 **Nagłówek HTTP `Link`** jest jedyną opcją dla plików innych niż HTML, takich jak pliki PDF.
 
----
-
 ## Reguły
 
 ### Samoodwołanie i wzajemność
@@ -107,8 +101,6 @@ Ludzie źle rozumieją, co to oznacza. `x-default` **nie jest „wersją angiels
 
 Dwie rzeczy do zapamiętania: `x-default` to jeden dodatkowy wpis w zestawie, a nie zamiennik dla samoreferentalnego, i jak każdy inny wpis musi pojawić się identycznie na każdej stronie w klastrze.
 
----
-
 ## Pułapka canonical
 
 Każda zlokalizowana strona musi być **swoją własną canonical**:
@@ -131,8 +123,6 @@ mówi, że francuska strona jest duplikatem, który nie powinien być indeksowan
 
 **Canonical jest samoodnośny na lokalizację. `hreflang` opisuje klaster.**
 
----
-
 ## Wybór struktury URL
 
 `hreflang` adnotuje adresy URL, więc struktura ma pierwszeństwo.
@@ -149,14 +139,11 @@ Jedyna struktura do uniknięcia: serwowanie różnych języków pod **tym samym
 
 > Intlayer obejmuje wszystkie trzy poprzez `routing.mode` i `routing.domains`. Patrz [niestandardowe domeny](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/custom_domains.md) i [dokumentacja konfiguracji](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/configuration.md).
 
----
-
 ## Implementacja
 
 Ręczne pisanie tych tagów nie przetrwa kontakt z drugim locale'em. Wyprowadź je z listy locale'a.
 
 <Steps>
-
 <Step number={1} title="Emituj klaster na każdej stronie">
 
 Ten sam zestaw wszędzie, canonical dla każdego locale'a, bezwzględne adresy URL, `x-default` włączony.
@@ -247,7 +234,6 @@ export const Route = createFileRoute("/{-$locale}/about")({
 </Tabs>
 
 </Step>
-
 <Step number={2} title="Lub przenieś to wszystko do sitemapy">
 
 Na dużą skalę trzymaj adnotacje całkowicie z dala od swoich stron. `generateSitemap` emituje `xhtml:link` alternates dla każdego wpisu, czytając locales i tryb routingu z twojej konfiguracji:
@@ -270,7 +256,6 @@ Dwie warte poznania opcje:
 - `entryPerLocale` (domyślnie `false`) — domyślnie jeden wpis `<url>` zawiera wszystkie alternatywy. Obie formy są prawidłowe, ale tylko adres URL wymieniony jako `<loc>` liczy się jako _przesłany_ w Search Console; alternatywne ustawienia regionalne pozostają odkrywalne, ale nie są przypisane do żadnej mapy witryny. Włączenie tego ustawienia daje każdemu zlokalizowanemu adresowi URL własny wpis z pełnym zestawem alternatyw powtórzonym. Zwiększa to liczbę wpisów przez liczbę ustawień regionalnych, więc zwróć uwagę na limit 50 000 adresów URL / 50 MB i podziel na indeks mapy witryny po jego przekroczeniu.
 
 </Step>
-
 <Step number={3} title="Sprawdź, co otrzymuje crawler">
 
 `hreflang` zawodzi bezgłośnie, więc sprawdź go zamiast go zakładać.
@@ -283,8 +268,6 @@ W przypadku crawlowania specyficznego dla wielu języków, [Intlayer SEO Scanner
 
 </Steps>
 
----
-
 ## Checklist
 
 - [ ] Każda lokalizacja ma odrębny, możliwy do przeszukania adres URL
@@ -298,8 +281,6 @@ W przypadku crawlowania specyficznego dla wielu języków, [Intlayer SEO Scanner
 - [ ] Zadeklarowane w dokładnie jednym miejscu
 - [ ] Brak przekierowań alternacyjnych
 
----
-
 ## Podsumowanie
 
 `hreflang` jest prosty i nieubłagany. Jeden brakujący tag powrotny, jeden względny URL, jeden canonical pomiędzy lokalizacjami, a cały klaster jest odrzucany bez żadnego błędu. Każdy z tych problemów pochodzi z ręcznego pisania tagów.

package/blog/pl/i18n_meaning.md

@@ -92,8 +92,6 @@ Skoro ustaliliśmy już prawdziwe **znaczenie i18n**, jak je zastosować?
 - **Wyodrębnij cały tekst skierowany do użytkownika:** Upewnij się, że w komponentach interfejsu użytkownika nie ma zakodowanego na sztywno tekstu.
 - **Zastosuj solidny system zarządzania tłumaczeniami:** Narzędzia takie jak **Intlayer** wypełniają lukę między programistami a tłumaczami. Intlayer działa jako headless CMS, który jest ściśle zintegrowany z bazą kodu, umożliwiając menedżerom treści wizualną aktualizację tłumaczeń bez konieczności uruchamiania nowej kompilacji przez programistę.
 
----
-
 ### Zobacz listę bibliotek i narzędzi i18n według technologii
 
 Jeśli szukasz listy bibliotek i narzędzi i18n według technologii, zapoznaj się z poniższymi zasobami:
@@ -112,8 +110,6 @@ Jeśli szukasz listy bibliotek i narzędzi i18n według technologii, zapoznaj si
 - Svelte: [Zobacz listę bibliotek i narzędzi i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/pl/list_i18n_technologies/frameworks/svelte.md)
 - React Native: [Zobacz listę bibliotek i narzędzi i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/pl/list_i18n_technologies/frameworks/react-native.md)
 
----
-
 ## Podsumowanie
 
 **Znaczenie i18n** to fundamentalna koncepcja dla każdego nowoczesnego biznesu cyfrowego dążącego do globalnego wpływu. To coś więcej niż tylko osobliwy skrót techniczny od „internacjonalizacji” – i18n reprezentuje architekturę techniczną wymaganą do płynnego dostosowania oprogramowania do różnych języków, kultur i standardów regionalnych.