@intlayer/docs 8.1.6 → 8.1.8

package/blog/ko/l10n_platform_alternative/phrase.md

@@ -25,11 +25,11 @@ history:
 
 # 번역 관리 시스템 (TMS)
 
-A Translation Management System (TMS) is a software platform designed to automate and streamline the translation and localization (L10n) process. Traditionally, a TMS serves as a centralized hub where content is uploaded, organized, and assigned to human translators. It manages workflows, stores translation memories (to avoid re-translating the same sentence twice), and handles the delivery of translated files back to the developers or content managers.
+번역 관리 시스템(TMS)은 번역 및 현지화(L10n) 프로세스를 자동화하고 간소화하도록 설계된 소프트웨어 플랫폼입니다. 전통적으로 TMS는 콘텐츠를 업로드하고 정리하며 인간 번역가에게 할당하는 중앙 허브 역할을 합니다. 워크플로우를 관리하고, 번역 메모리(같은 문장을 다시 번역하는 일을 방지하기 위해)를 저장하며, 번역된 파일을 개발자나 콘텐츠 관리자에게 다시 전달하는 작업을 처리합니다.
 
-In essence, a TMS has historically been the bridge between the technical code (where strings live) and the human linguists (who understand the culture).
+본질적으로 TMS는 기술적인 코드(문자열이 존재하는 곳)와 문화적 이해를 가진 인간 언어 전문가들 사이를 잇는 다리 역할을 해왔습니다.
 
-# Phrase (formerly PhraseApp)
+# Phrase (이전 PhraseApp)
 
 Phrase는 엔터프라이즈 로컬라이제이션 분야의 강자입니다. 원래 PhraseApp으로 알려졌으며, 특히 Memsource와의 합병 이후 크게 성장했습니다. 소프트웨어 현지화를 위해 설계된 포괄적인 Localization Suite로 자리매김하며, 강력한 API 기능과 광범위한 포맷 지원을 제공합니다.
 
@@ -49,7 +49,7 @@ Phrase가 AI 기능을 통합하긴 했지만, 그 기능들은 종종 사람
 
 오늘날 가장 효율적인 워크플로우는 먼저 AI를 사용해 페이지를 글로벌하게 번역하고 포지셔닝하는 것입니다. 그런 다음 두 번째 단계에서 제품이 이미 수익을 창출하기 시작한 후 특정 트래픽이 많은 콘텐츠를 인간 카피라이터가 최적화하여 전환율을 높이는 방식입니다.
 
-## 왜 Intlayer가 Phrase에 대한 좋은 대안인가?
+## 왜 Intlayer가 Phrase의 좋은 대안인가?
 
 Intlayer는 AI 시대에 탄생한 솔루션으로, 현대 JavaScript/TypeScript 생태계에 맞춰 설계되었습니다. 민첩성과 투명성으로 Phrase의 무거운 엔터프라이즈 모델에 도전합니다.
 
@@ -75,4 +75,4 @@ Intlayer는 콘텐츠의 깊은 통합을 가능하게 하는 완전한 올인
 
 Phrase는 복잡하고 다중 포맷의 엔터프라이즈 요구사항(예: PDF, 자막 및 소프트웨어를 동시에 번역하는 경우)에 대해 강력한 도구인 것은 부정할 수 없지만, Intlayer는 product teams가 웹 애플리케이션을 구축하면서 full ownership, type safety 및 엔터프라이즈 오버헤드 없이 현대적이고 AI-driven한 워크플로우를 원할 때 더 우수한 선택입니다.
 
-마지막으로 데이터 주권(data sovereignty)과 통제를 우선시하는 경우, Intlayer는 open-source이며 self-hosted가 가능합니다. Docker 파일은 리포지토리에서 직접 제공되어 로컬라이제이션 인프라에 대한 완전한 소유권을 부여합니다 — Phrase의 폐쇄형 SaaS 생태계에서는 불가능한 일입니다.
+마지막으로 데이터 주권(data sovereignty)과 통제를 우선시하는 경우, Intlayer는 open-source이며 self-hosted가 가능합니다. Docker 파일은 리포지토리에서 직접 제공되어 로컬라이제이션 인프라에 대한 완전한 소유권을 부여합니다. Phrase의 폐쇄형 SaaS 생태계에서는 불가능한 일입니다.

package/blog/ko/list_i18n_technologies/frameworks/angular.md

@@ -48,7 +48,30 @@ Angular 애플리케이션을 번역하는 데는 여러 가지 도전 과제가
 
 Angular는 내장 i18n 프레임워크를 제공하며, 다국어 설정을 단순화하기 위해 설계된 여러 서드파티 라이브러리가 있습니다. 아래는 가장 인기 있는 솔루션 중 일부입니다.
 
-### 1. Angular의 내장 i18n
+---
+
+### 1. Intlayer
+
+웹사이트: [https://intlayer.org/](https://intlayer.org/)
+
+**개요**  
+**Intlayer**는 현대 JavaScript 앱(특히 Angular 환경)에서 다국어 지원을 간소화하도록 설계된 혁신적인 오픈 소스 국제화(i18n) 라이브러리입니다. 구성 요소와 함께 직접 사전을 정의할 수 있는 선언적 접근 방식을 제공합니다.
+
+**주요 기능**
+
+- **선언적 번역**: 보수가 쉽고 확장 가능한 구조를 위해 구성 요소 수준에서 직접 번역을 선언할 수 있습니다.
+- **TypeScript 및 자동 완성**: 번역 키에 대한 타입 정의를 자동으로 생성하여 개발자 친화적인 자동 완성과 강력한 오류 검사가 가능합니다.
+- **서버 측 렌더링(SSR) 지원**: Angular Universal과 원활하게 작동하여 서버 측에서 효율적인 로컬라이제이션 결과를 제공합니다.
+- **SEO 최적화**: 로컬라이제이션된 메타데이터, 동적 로케일 기반 라우팅 및 사이트맵을 처리하여 웹 사이트의 가시성을 높입니다.
+- **지연 로딩**: 번역 사전을 지연 로딩하여 초기 번들 크기를 줄이고 애플리케이션 성능을 유지합니다.
+
+**고려 사항**
+
+- **생태계**: 더 확립된 솔루션에 비해 커뮤니티 플러그인이 적을 수 있지만, 현대 웹 개발 워크플로우를 위해 설계되었습니다.
+
+---
+
+### 2. Angular의 내장 i18n
 
 **개요**  
 Angular는 번역 문자열 추출, 복수형 및 보간 처리, 컴파일 타임에서의 번역 통합을 위한 도구를 포함한 **내장 i18n** 시스템을 제공합니다. 이 공식 솔루션은 작은 프로젝트나 Angular의 권장 구조에 밀접하게 정렬할 수 있는 프로젝트에 강력합니다.
@@ -68,7 +91,7 @@ Angular는 번역 문자열 추출, 복수형 및 보간 처리, 컴파일 타
 
 ---
 
-### 2. ngx-translate
+### 3. ngx-translate
 
 웹사이트: [https://github.com/ngx-translate/core](https://github.com/ngx-translate/core)
 
@@ -90,7 +113,7 @@ Angular는 번역 문자열 추출, 복수형 및 보간 처리, 컴파일 타
 
 ---
 
-### 3. Transloco
+### 4. Transloco
 
 웹사이트: [https://ngneat.github.io/transloco/](https://ngneat.github.io/transloco/)
 

package/blog/ko/list_i18n_technologies/frameworks/react-native.md

@@ -18,47 +18,47 @@ slugs:
   - react-native
 ---
 
-# Exploring i18n Solutions to Translate Your React Native App
+# React Native 앱 번역을 위한 i18n 솔루션 탐구
 
-In an increasingly global market, delivering your React Native app in multiple languages can significantly enhance accessibility and user satisfaction. Internationalization (i18n) is central to managing translations effectively, allowing you to display language-specific text, date and time formats, currency, and more without complicating your codebase. In this article, we’ll dive into various i18n approaches, ranging from dedicated libraries to more general solutions, and help you find the one that best fits your React Native project.
+점점 더 커지는 글로벌 시장에서 React Native 앱을 다국어로 제공하는 것은 접근성을 크게 높이고 사용자 만족도를 개선할 수 있습니다. 국제화(i18n)는 번역을 효율적으로 관리하는 데 핵심적인 역할을 하며, 코드베이스를 복잡하게 만들지 않고도 언어별 텍스트, 날짜 및 시간 형식, 통화 등을 표시할 수 있게 해줍니다. 이 글에서는 전용 라이브러리부터 보다 일반적인 솔루션에 이르기까지 다양한 i18n 접근 방식을 살펴보고, 귀하의 React Native 프로젝트에 가장 적합한 라이브러리를 찾는 데 도움을 드리고자 합니다.
 
 ---
 
 ![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
 
-## What is Internationalization (i18n)?
+## 국제화(i18n)란 무엇인가요?
 
-Internationalization, or i18n, involves structuring an application so it can easily adapt to different languages, regional formats, and cultural norms. In React Native, i18n includes handling strings for buttons and labels, as well as formatting dates, times, currencies, and more according to a user’s locale. Properly prepared React Native apps let you seamlessly integrate additional languages and locale-specific behavior later on, without massive refactors.
+국제화(i18n)는 애플리케이션을 다양한 언어, 지역 형식 및 문화적 관습에 쉽게 적응할 수 있도록 구조화하는 것을 포함합니다. React Native에서 i18n은 버튼과 라벨의 문자열을 처리하는 것뿐만 아니라 사용자의 로케일에 따라 날짜, 시간, 통화 등을 형식화하는 것을 포함합니다. 적절하게 준비된 React Native 앱을 사용하면 대대적인 리팩토링 없이도 나중에 추가 언어와 로케일별 동작을 원활하게 통합할 수 있습니다.
 
-For a deeper dive into internationalization concepts, check out our article:  
+국제화 개념에 대해 더 자세히 알아보려면 다음 기사를 확인하세요:  
 [What is Internationalization (i18n)? Definition and Challenges](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ko/what_is_internationalization.md).
 
 ---
 
-## The Translation Challenge for React Native Applications
+## React Native 애플리케이션을 위한 번역 도전 과제
 
-Working with translations in React Native introduces its own unique considerations:
+React Native에서 번역 작업을 수행할 때는 몇 가지 고유한 고려 사항이 있습니다:
 
-- **Component-Based Architecture**  
-  Just like in React for the web, React Native’s modular design can scatter text across numerous components. It’s crucial to centralize these translations in a robust manner.
+- **구성 요소 기반 아키텍처**  
+  웹용 React와 마찬가지로 React Native의 모듈식 디자인은 수많은 구성 요소에 텍스트를 분산시킬 수 있습니다. 이러한 번역을 견고한 방식으로 중앙 집중화하는 것이 중요합니다.
 
-- **Offline and Remote Data**  
-  While some strings can be embedded within the app, other content (e.g., newsfeeds, product data) may be fetched remotely. Handling translations for data that arrives asynchronously can be more complex on mobile.
+- **오프라인 및 원격 데이터**  
+  일부 문자열은 앱 내에 포함될 수 있지만, 다른 콘텐츠(예: 뉴스피드, 제품 데이터)는 원격으로 가져올 수 있습니다. 비동기적으로 도착하는 데이터에 대한 번역 처리는 모바일에서 더 복잡할 수 있습니다.
 
-- **Platform-Specific Behaviors**  
-  iOS and Android each have their own locale settings and formatting quirks. Ensuring consistent rendering of dates, currencies, and numbers across both platforms requires thorough testing.
+- **플랫폼별 동작**  
+  iOS와 Android는 각각 고유한 로케일 설정과 형식 지정 특성이 있습니다. 두 플랫폼 모두에서 날짜, 통화 및 숫자의 일관된 렌더링을 보장하려면 철저한 테스트가 필요합니다.
 
-- **State and Navigation Management**  
-  Maintaining the user’s selected language across screens, deep links, or tab-based navigations means tying i18n into your Redux, Context API, or other state management solution.
+- **상태 및 내비게이션 관리**  
+  스크린, 딥 링크 또는 탭 기반 내비게이션 전반에서 사용자가 선택한 언어를 유지하는 것은 Redux, Context API 또는 다른 상태 관리 솔루션에 i18n을 연결하는 것을 의미합니다.
 
-- **App Updates & Over-the-Air (OTA)**  
-  If you use CodePush or another OTA update mechanism, you need to plan how translation updates or new languages will be delivered without requiring a full app store release.
+- **앱 업데이트 및 OTA(Over-the-Air)**  
+  CodePush 또는 다른 OTA 업데이트 메커니즘을 사용하는 경우, 전체 앱 스토어 출시 없이 번역 업데이트나 새로운 언어가 어떻게 전달될지 계획해야 합니다.
 
 ---
 
-## Leading i18n Solutions for React Native
+## React Native를 위한 주요 i18n 솔루션
 
-Below are several popular approaches to managing multilingual content in React Native. Each aims to simplify your translation workflow in different ways.
+아래는 React Native에서 다국어 콘텐츠를 관리하기 위한 몇 가지 인기 있는 접근 방식입니다. 각각은 서로 다른 방식으로 번역 워크플로우를 간소화하는 것을 목표로 합니다.
 
 ### 1. Intlayer
 
@@ -138,7 +138,7 @@ Below are several popular approaches to managing multilingual content in React N
   `<FormattedMessage>`, `<FormattedDate>`, `<FormattedTime>` 등은 iOS 및 Android 간의 형식화 작업을 간소화합니다.
 
 - **Lightweight & Extensible**  
-  필요한 FormatJS의 부분만 가져와 전체 번들을 얇게 유지할 수 있습니다, 모바일에 매우 중요합니다.
+  필요한 FormatJS의 부분만 가져와 전체 번들을 얇게 유지할 수 있습니다. 이는 모바일에 매우 중요합니다.
 
 - **Polyfills for Unsupported Locales**  
   오래된 Android 또는 iOS 버전에서도 일관된 날짜/숫자 형식을 보장합니다.
@@ -193,29 +193,25 @@ Below are several popular approaches to managing multilingual content in React N
 
 ---
 
-## Final Thoughts
+## 최종 생각
 
-When selecting an i18n solution for your React Native application:
+React Native 애플리케이션을 위한 i18n 솔루션을 선택할 때:
 
-1. **Assess Your Requirements**
+1.  **요구 사항 평가**
+    - 현재와 미래에 얼마나 많은 언어가 필요한가요?
+    - 대규모 앱을 위한 온디맨드 로딩이 필요한가요?
 
-   - How many languages are needed now and in the future?
-   - Do you require on-demand loading for large apps?
+2.  **플랫폼 차이 유의**
+    - 어떤 라이브러리든 iOS와 Android 로케일 변형, 특히 날짜/숫자/통화 특성을 지원하는지 확인하세요.
+    - 오프라인 사용을 고려하세요. 일부 번역은 앱과 함께 번들로 제공되어야 할 수 있고, 다른 일부는 원격으로 가져올 수 있습니다.
 
-2. **Mind Platform Differences**
+3.  **확장성을 위한 구조 선택**
+    - 대규모 또는 장기 프로젝트를 계획 중이라면 강력한 추출 워크플로우나 타입 키가 번역을 잘 정리하는 데 도움이 될 수 있습니다.
 
-   - Ensure any library supports iOS and Android locale variations, especially date/number/currency quirks.
-   - Consider offline usage, some translations might need to be bundled with the app, while others can be fetched remotely.
+4.  **성능 및 번들 크기**
+    - 모바일 데이터 제약으로 인해 번역 파일과 폴리필의 크기를 면밀히 관찰해야 합니다.
 
-3. **Choose a Structure for Scalability**
+5.  **개발자 경험(DX)**
+    - 팀의 기술 수준과 일치하는 라이브러리를 찾으세요. 일부 솔루션은 장황하지만 직관적이며, 다른 솔루션은 설정의 복잡성 대신 더 많은 자동화를 제공합니다.
 
-   - If you’re planning a large or long-lived application, a strong extraction workflow or typed keys can help keep translations well-organized.
-
-4. **Performance & Bundle Size**
-
-   - Mobile data constraints mean you should keep a close eye on the size of your translation files and any polyfills.
-
-5. **Developer Experience (DX)**
-   - Look for libraries that align with your team’s skill set, some solutions are more verbose but straightforward, while others offer more automation at the cost of setup complexity.
-
-Each solution, Intlayer, React-i18next, React Intl, and LinguiJS, has proven effective in React Native environments, though with slightly different priorities. Evaluating your project’s roadmap, developer preferences, and localization needs will guide you to the ideal fit for delivering a truly global React Native app.
+Intlayer, React-i18next, React Intl 및 LinguiJS와 같은 각 솔루션은 각각 조금씩 다른 우선순위를 가지고 있지만 React Native 환경에서 효과적임이 입증되었습니다. 프로젝트의 로드맵, 개발자 선호도 및 로컬라이제이션 요구 사항을 평가하면 진정으로 글로벌한 React Native 앱을 제공하기 위한 최적의 솔루션을 찾을 수 있을 것입니다.

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

@@ -18,7 +18,7 @@ slugs:
   - react
 ---
 
-# Exploring i18n Solutions to Translate Your React Website
+# React 웹사이트 번역을 위한 i18n 솔루션 탐구
 
 오늘날의 디지털 환경에서, 전 세계 고객을 대상으로 웹사이트의 범위를 확장하는 것은 필수적입니다. React로 개발하는 개발자에게 국제화(i18n)를 구현하는 것은 번역을 효율적으로 관리하면서 애플리케이션 구조, SEO 가치 및 사용자 경험을 유지하는 데 중요한 요소입니다. 이 글에서는 전용 라이브러리에서 맞춤형 코딩 솔루션에 이르기까지 다양한 i18n 접근 방식을 탐색하여 귀하의 프로젝트 요구에 가장 적합한 방법을 결정하는 데 도움을 줍니다.
 
@@ -26,17 +26,17 @@ slugs:
 
 ![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
 
-## What is Internationalization (i18n)?
+## 국제화(i18n)란 무엇인가요?
 
 국제화란 i18n의 약어로, 웹사이트가 여러 언어와 문화적 맥락을 지원할 수 있도록 디자인하고 준비하는 과정입니다. React에서 이는 문자열, 날짜 형식, 숫자 형식 및 레이아웃이 서로 다른 지역의 사용자에 맞게 쉽게 조정될 수 있도록 앱을 설정하는 것을 의미합니다. React 앱을 i18n에 대비시키는 것은 번역 및 기타 지역화 기능을 깔끔하게 통합할 수 있는 기초를 마련합니다.
 
-i18n에 대해 더 알아보려면 다음 기사를 읽어보세요: [What is Internationalization (i18n)? Definition and Challenges](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ko/what_is_internationalization.md).
+i18n에 대해 더 알아보려면 다음 기사를 읽어보세요: [국제화(i18n)란 무엇인가요? 정의와 도전 과제](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ko/what_is_internationalization.md).
 
 ---
 
-## The Translation Challenge for React Applications
+## React 애플리케이션의 번역 도전 과제
 
-React 웹사이트를 번역하는 데는 여러 가지 어려움이 있습니다:
+React 웹사이트를 번역하는 데에는 여러 가지 어려움이 있습니다:
 
 - **컴포넌트 기반 아키텍처**: React의 모듈형 디자인으로 인해 텍스트가 여러 컴포넌트에 분산될 수 있어, 번역 문자열을 중앙 집중화하고 조직하는 것이 중요합니다.
 - **동적 콘텐츠**: 실시간으로 업데이트되는 콘텐츠나 API에서 가져오는 콘텐츠의 번역 관리는 추가적인 복잡성을 더할 수 있습니다.
@@ -46,7 +46,7 @@ React 웹사이트를 번역하는 데는 여러 가지 어려움이 있습니
 
 ---
 
-## Leading i18n Solutions for React
+## React를 위한 주요 i18n 솔루션
 
 다음은 React 애플리케이션에서 다국어 콘텐츠를 관리하는 데 널리 사용되는 접근 방식으로, 각각은 번역 프로세스를 간소화하는 데 특화되어 있습니다.
 
@@ -54,10 +54,10 @@ React 웹사이트를 번역하는 데는 여러 가지 어려움이 있습니
 
 > Website: [https://intlayer.org/](https://intlayer.org/)
 
-**Overview**  
+**개요**
 **Intlayer**는 현대의 React(및 기타) 웹 애플리케이션에서 다국어 지원을 간소화하도록 설계된 혁신적인 오픈 소스 국제화(i18n) 라이브러리입니다. 구성 요소 내에서 번역 사전을 직접 정의할 수 있는 선언적 접근 방식을 제공합니다.
 
-**Key Features**
+**주요 기능**
 
 - **Translation Declaration**: 모든 번역을 단일 파일에서 선언할 수 있으며, 구성 요소 수준에 배치되어 유지 보수 및 확장이 용이합니다.
 - **TypeScript & Autocompletion**: 번역 키에 대한 자동 생성된 타입 정의를 제공하며, 강력한 자동 완성과 오류 감지를 지원합니다.
@@ -66,7 +66,7 @@ React 웹사이트를 번역하는 데는 여러 가지 어려움이 있습니
 - **Seamless Integration**: Create React App, Next.js 및 Vite와 같은 주요 번들러 및 프레임워크와 호환되어 설정이 간단합니다.
 - **Asynchronous Loading**: 번역 사전을 동적으로 로드하여 초기 번들 크기를 줄이고 성능을 개선합니다.
 
-**Considerations**
+**고려 사항**
 
 - **Community & Ecosystem**: 커뮤니티 기반 플러그인 및 도구는 더 적을 수 있지만, 생태계는 성장 중입니다.
 
@@ -76,10 +76,10 @@ React 웹사이트를 번역하는 데는 여러 가지 어려움이 있습니
 
 Website: [https://react.i18next.com/](https://react.i18next.com/)
 
-**Overview**  
+**개요**
 **React-i18next**는 인기 있는 **i18next** 프레임워크 위에 구축된 국제화에 가장 널리 사용되는 React 라이브러리 중 하나입니다. 복잡한 번역 시나리오를 처리하기 위한 유연하고 플러그인 기반 아키텍처를 제공합니다.
 
-**Key Features**
+**주요 기능**
 
 - **Seamless React Integration**: 최대한 유연성을 위해 React hooks, 고차 컴포넌트(HOCs) 및 렌더링 props와 함께 작동합니다.
 - **Asynchronous Loading**: 번역 리소스를 동적으로 로드하여 초기 번들 크기를 줄이고 성능을 개선합니다.
@@ -88,7 +88,7 @@ Website: [https://react.i18next.com/](https://react.i18next.com/)
 - **Localized Metadata & URLs**: Next.js와 통합되어 지역화된 경로, 사이트맵 및 robots.txt를 개선하여 SEO를 향상시킬 수 있습니다.
 - **Server Components & SSR**: Next.js 또는 기타 SSR 설정을 사용하여 서버에서 완전히 지역화된 콘텐츠를 제공할 수 있습니다.
 
-**Considerations**
+**고려 사항**
 
 - **Maintainability**: 복잡하게 구성될 수 있으므로 대규모 또는 다중 팀 프로젝트에서는 번역 파일의 구조를 신중하게 작성하는 것이 필수적입니다.
 - **Plugin Ecosystem**: 다양한 플러그인 및 미들웨어의 폭넓은 생태계가 마련되어 있지만, 적절한 도구를 찾기 위해 여러 패키지를 검토해야 할 수도 있습니다.
@@ -100,10 +100,10 @@ Website: [https://react.i18next.com/](https://react.i18next.com/)
 
 Website: [https://formatjs.io/docs/react-intl/](https://formatjs.io/docs/react-intl/)
 
-**Overview**  
+**개요**
 **React Intl**은 **FormatJS** 스위트의 일환으로, 메시지 포맷화, 날짜/숫자/시간 지역화, 상대 시간 메시지를 표준화하는 데 중점을 둡니다. 메시지 추출 워크플로를 사용하여 번역을 효율적으로 처리합니다.
 
-**Key Features**
+**주요 기능**
 
 - **Format-Focused Components**: `<FormattedMessage>`, `<FormattedDate>`, `<FormattedTime>` 등을 통해 React에서 포맷팅을 간소화합니다.
 - **Server Components & SSR**: SSR 설정을 지원하여 지역화된 콘텐츠를 제공하여 성능과 SEO를 개선합니다.
@@ -111,7 +111,7 @@ Website: [https://formatjs.io/docs/react-intl/](https://formatjs.io/docs/react-i
 - **TypeScript & Autocompletion**: TypeScript와 결합할 수 있지만, 메시지 ID의 자동 완성을 위한 추가 도구가 필요할 수 있습니다.
 - **Polyfills for Unsupported Browsers**: 레거시 환경 간 일관된 동작을 보장합니다.
 
-**Considerations**
+**고려 사항**
 
 - **Verbosity & Boilerplate**: 전용 컴포넌트에 대한 의존성으로 인해 특히 대규모 애플리케이션에서 더 장황한 코드가 발생할 수 있습니다.
 - **Splitting Translations**: 코어 라이브러리는 번역을 여러 파일로 분할하는 데 대한 기본 지원을 제공하지 않으므로 추가 설정 또는 플러그인이 필요합니다.
@@ -121,10 +121,10 @@ Website: [https://formatjs.io/docs/react-intl/](https://formatjs.io/docs/react-i
 
 Website: [https://lingui.js.org/](https://lingui.js.org/)
 
-**Overview**  
+**개요**
 **LinguiJS**는 JavaScript 및 React에서 i18n 관리를 위한 현대적인, 개발자 친화적인 접근 방식을 제공합니다. 구성 최소화를 중심으로 견고한 CLI 및 메시지 추출 워크플로를 제공합니다.
 
-**Key Features**
+**주요 기능**
 
 - **Automatic Message Extraction**: 코드에서 메시지를 발견하고 추출하는 전용 CLI로 수동 단계를 최소화합니다.
 - **Minimal Runtime Overhead**: 컴파일된 번역은 번들 크기와 실행 성능 비용을 줄입니다.
@@ -132,7 +132,7 @@ Website: [https://lingui.js.org/](https://lingui.js.org/)
 - **Server Components & SSR**: 서버 사이드 렌더링 전략과 호환되어 Next.js 또는 다른 SSR 프레임워크와 통합할 수 있습니다.
 - **Localized Metadata & URLs**: 다른 라이브러리만큼 명시적이지는 않지만, 사이트맵, robots.txt 및 지역화된 경로 처리를 위해 라우팅 설정과 통합될 수 있습니다.
 
-**Considerations**
+**고려 사항**
 
 - **Maintainability**: 자동 추출은 코드를 깔끔하게 유지하는 데 도움이 되지만, 대규모 앱의 경우 여러 번역 파일을 구조화하려면 체계적인 조직이 필요합니다.
 - **Community & Plugins**: 생태계는 성장 중이지만 i18next 또는 FormatJS에 비해 여전히 작습니다.
@@ -140,14 +140,14 @@ Website: [https://lingui.js.org/](https://lingui.js.org/)
 
 ---
 
-### Final Thoughts
+## 최종 생각
 
 React용 i18n 라이브러리를 선택할 때:
 
-- **Evaluate Your Requirements**: 프로젝트 크기, 개발자 경험 및 번역 처리 방식(수동 vs. 자동 추출)을 고려하세요.
-- **Check Server Compatibility**: SSR이나 서버 컴포넌트(특히 Next.js)를 사용하는 경우, 선택한 라이브러리가 무리 없이 지원하는지 확인하세요.
-- **TypeScript & Autocompletion**: TypeScript가 우선이라면, 타입이 지정된 키와 강력한 개발 도구를 쉽게 통합할 수 있는 라이브러리를 선택하세요.
-- **Maintainability & Scalability**: 큰 프로젝트는 번역에 대한 명확하고 유지 가능한 구조가 필요하므로 장기 로드맵을 감안하는 것이 중요합니다.
-- **SEO & Metadata**: SEO가 중요하다면, 선택한 솔루션이 각 언어에 대해 지역화된 메타데이터, 경로 및 사이트맵/robots를 지원하는지 확인하세요.
+- **요구 사항 평가**: 프로젝트 크기, 개발자 경험 및 번역 처리 방식(수동 vs. 자동 추출)을 고려하세요.
+- **서버 호환성 확인**: SSR이나 서버 컴포넌트(특히 Next.js)를 사용하는 경우, 선택한 라이브러리가 무리 없이 지원하는지 확인하세요.
+- **TypeScript 및 자동 완성**: TypeScript가 우선이라면, 타입이 지정된 키와 강력한 개발 도구를 쉽게 통합할 수 있는 라이브러리를 선택하세요.
+- **유지 관리 및 확장성**: 큰 프로젝트는 번역에 대한 명확하고 유지 가능한 구조가 필요하므로 장기 로드맵을 감안하는 것이 중요합니다.
+- **SEO 및 메타데이터**: SEO가 중요하다면, 선택한 솔루션이 각 언어에 대해 지역화된 메타데이터, 경로 및 사이트맵/robots를 지원하는지 확인하세요.
 
 이 모든 라이브러리는 다국어 React 애플리케이션을 지원할 수 있습니다. 각각의 약간 다른 우선순위와 강점을 가지고 있습니다. 프로젝트의 **성능**, **개발자 경험(DX)** 및 **비즈니스 목표**에 가장 잘 부합하는 것을 선택하세요.

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

@@ -50,7 +50,28 @@ Svelte 애플리케이션을 번역하는 것은 몇 가지 장벽을 제시할
 
 Svelte는 Angular처럼 기본 제공 i18n 솔루션을 제공하지 않지만, 커뮤니티에서 강력한 여러 라이브러리와 패턴을 만들었습니다. 아래는 몇 가지 인기 있는 접근 방식입니다.
 
-### 1. svelte-i18n
+### 1. Intlayer
+
+웹사이트: [https://intlayer.org/](https://intlayer.org/)
+
+**개요**  
+**Intlayer**는 현대 SvelteKit(및 기타) 웹 애플리케이션에서 다국어 지원을 간소화하도록 설계된 혁신적 오픈 소스 국제화(i18n) 라이브러리입니다. 구성 요소 내에서 직접 번역 사전을 정의할 수 있는 선언적 접근 방식을 제공합니다.
+
+**주요 기능**
+
+- **번역 선언**: 보수가 쉽고 확장 가능한 구조를 위해 모든 번역을 단일 파일에서 선언하여 구성 요소 수준에 배치할 수 있습니다.
+- **TypeScript 및 자동 완성**: 번역 키에 대한 타입 정의를 자동으로 생성하여 견고한 자동 완성과 오류 감지를 제공합니다.
+- **SvelteKit 및 SSR**: SvelteKit을 염두에 두고 구축되어 클라이언트와 서버 모두에서 지역화된 콘텐츠가 효율적으로 렌더링되도록 보장합니다.
+- **SEO 최적화**: 로컬라이제이션된 메타데이터와 동적 로케일 기반 경로를 쉽게 처리하여 웹 사이트의 발견 가능성을 높입니다.
+- **비동기 로딩**: 번역 사전을 동적으로 로드하여 초기 번들 크기를 줄이고 성능을 개선합니다.
+
+**고려 사항**
+
+- **커뮤니티 및 생태계**: 성장 중이지만, 더 오래된 솔루션에 비해 커뮤니티 기반 플러그인이나 도구는 아직 적을 수 있습니다.
+
+---
+
+### 2. svelte-i18n
 
 저장소: [https://github.com/kaisermann/svelte-i18n](https://github.com/kaisermann/svelte-i18n)
 
@@ -68,11 +89,11 @@ Svelte는 Angular처럼 기본 제공 i18n 솔루션을 제공하지 않지만,
 
 - **프로젝트 조직**: 프로젝트가 커짐에 따라 번역 파일을 논리적으로 구조화해야 합니다.
 - **SSR 설정**: SEO를 위한 SSR 구성을 위해 서버 측에서 올바른 로케일 감지를 보장하기 위한 추가 단계를 수행해야 할 수 있습니다.
-- **성능**: 런타임에서 유연하지만 한 번에 많은 수의 번역을 로드하면 초기 로드 시간이 영향을 받을 수 있으므로 지연 로딩 또는 캐싱 전략을 고려해야 합니다.
+- **성능**: 런타임에서 유연하지만 한 번에 많은 수의 번역을 로드하면 초기 로드 시간이 영향을 받을 수 있습니다. 지연 로딩 또는 캐싱 전략을 고려해야 합니다.
 
 ---
 
-### 2. svelte-intl-precompile
+### 3. svelte-intl-precompile
 
 저장소: [https://github.com/cibernox/svelte-intl-precompile](https://github.com/cibernox/svelte-intl-precompile)
 
@@ -94,7 +115,7 @@ Svelte는 Angular처럼 기본 제공 i18n 솔루션을 제공하지 않지만,
 
 ---
 
-### 3. Svelte / SvelteKit와 함께 사용하는 i18next
+### 4. Svelte / SvelteKit와 함께 사용하는 i18next
 
 웹사이트: [https://www.i18next.com/](https://www.i18next.com/)
 
@@ -120,10 +141,10 @@ Svelte는 Angular처럼 기본 제공 i18n 솔루션을 제공하지 않지만,
 
 Svelte 앱에 대한 i18n 전략을 선택할 때:
 
-1. **프로젝트 규모 평가**: 더 작은 프로젝트나 빠른 프로토타입의 경우 **svelte-i18n**과 같은 간단한 라이브러리나 최소한의 i18n 접근 방식이 충분할 수 있습니다. 더 크고 복잡한 앱은 보다 강Typed, 사전 컴파일 또는 더 강력한 생태계 기반 솔루션이 유리할 수 있습니다.
-2. **SSO 및 SSR 고려 사항**: SEO 비판적이거나 **SvelteKit**과 함께 서버 측 렌더링이 필요한 경우 SSR을 효과적으로 지원하고 지역화된 라우트, 메타데이터 및 사이트 맵을 처리할 수 있는 라이브러리를 선택하세요.
+1. **프로젝트 규모 평가**: 더 작은 프로젝트나 빠른 프로토타입의 경우 **svelte-i18n**과 같은 간단한 라이브러리나 최소한의 i18n 접근 방식이 충분할 수 있습니다. 더 크고 복잡한 앱은 보다 강력하고 사전 컴파일되거나 더 강력한 생태계 기반 솔루션이 유리할 수 있습니다.
+2. **SEO 및 SSR 고려 사항**: SEO가 중요하거나 **SvelteKit**과 함께 서버 측 렌더링이 필요한 경우 SSR을 효과적으로 지원하고 지역화된 라우트, 메타데이터 및 사이트 맵을 처리할 수 있는 라이브러리를 선택하세요.
 3. **런타임 대 빌드 시간**: 런타임에서 동적 언어 전환이 필요한지 또는 성능 향상을 위해 사전 컴파일된 번역을 선호하는지 결정하세요. 각 접근 방식은 서로 다른 트레이드오프를 포함합니다.
 4. **TypeScript 통합**: TypeScript에 크게 의존하는 경우 **Intlayer** 또는 타입 키가 있는 라이브러리 솔루션은 런타임 오류를 크게 줄이고 개발자 경험을 향상시킬 수 있습니다.
 5. **유지 관리 및 확장성**: 번역 파일을 어떻게 구성하고 업데이트하며 버전 관리를 할 것인지 계획하세요. 자동 추출, 명명 규칙 및 일관된 폴더 구조는 장기적으로 시간을 절약할 수 있습니다.
 
-궁극적으로 각 라이브러리는 고유의 강점을 제공합니다. 귀하의 선택은 **성능**, **개발자 경험**, **SEO 요구 사항** 및 **장기 유지 관리성**에 따라 달라집니다. 프로젝트 목표와 일치하는 솔루션을 선택함으로써 Svelte에서 진정한 글로벌 애플리케이션을 만들 수 있습니다, 전 세계 사용자들을 매료시키는 애플리케이션입니다.
+궁극적으로 각 라이브러리는 고유의 강점을 제공합니다. 귀하의 선택은 **성능**, **개발자 경험**, **SEO 요구 사항** 및 **장기 유지 관리성**에 따라 달라집니다. 프로젝트 목표와 일치하는 솔루션을 선택함으로써 Svelte에서 진정한 글로벌 애플리케이션을 만들 수 있습니다. 전 세계 사용자들을 만족시키는 애플리케이션을 만드세요.

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

@@ -52,7 +52,27 @@ Vue.js 애플리케이션을 번역하는 것은 자체적인 몇 가지 도전
 
 ---
 
-### 1. Vue I18n
+### 1. Intlayer
+
+> 웹사이트: [https://intlayer.org/](https://intlayer.org/)
+
+**개요**  
+**Intlayer**는 **Vue**를 포함한 여러 프레임워크에서 다국어 지원을 단순화하도록 설계된 혁신적 오픈 소스 i18n 솔루션입니다. 구성 요소 수준에서 직접 번역 사전을 정의할 수 있는 선언적 접근 방식을 강조합니다.
+
+**주요 기능**
+
+- **선언적 번역**: 보수가 쉽고 확장 가능한 구조를 위해 구성 요소 수준에서 직접 번역을 선언할 수 있습니다.
+- **TypeScript 및 자동 완성**: 번역 키에 대한 자동 생성된 타입 정의를 제공하여 강력한 자동 완성과 오류 감지를 지원합니다.
+- **비동기 로딩**: 번역 자산을 동적으로 로드하여 다국어 앱의 초기 번들 크기를 잠재적으로 줄입니다.
+- **매끄러운 통합**: 주요 번들러 및 Vue 생태계와 호환되어 설정이 간단합니다.
+
+**고려 사항**
+
+- **커뮤니티**: 생태계는 성장 중이지만, 더 오래된 솔루션에 비해 커뮤니티 플러그인은 아직 적을 수 있습니다.
+
+---
+
+### 2. Vue I18n
 
 > 웹사이트: [https://vue-i18n.intlify.dev/](https://vue-i18n.intlify.dev/)
 
@@ -83,7 +103,7 @@ Vue.js 애플리케이션을 번역하는 것은 자체적인 몇 가지 도전
 
 ---
 
-### 2. LinguiJS (Vue 통합)
+### 3. LinguiJS (Vue 통합)
 
 > 웹사이트: [https://lingui.js.org/](https://lingui.js.org/)
 

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

@@ -39,7 +39,7 @@ Next.js를 위한 세 가지 i18n 옵션인 next-i18next, next-intl, Intlayer의
 
 > **요약**: 세 가지 모두 Next.js 앱을 현지화할 수 있습니다. 만약 **컴포넌트 범위 콘텐츠**, **엄격한 TypeScript 타입**, **빌드 시 누락 키 검사**, **트리 쉐이킹된 사전**, 그리고 **최고급 App Router + SEO 도우미**를 원한다면, **Intlayer**가 가장 완전하고 현대적인 선택입니다.
 
-> 개발자들이 자주 혼동하는 점 중 하나는 `next-intl`이 `react-intl`의 Next.js 버전이라고 생각하는 것입니다. 그렇지 않습니다—`next-intl`은 [Amann](https://github.com/amannn)이 유지 관리하며, `react-intl`은 [FormatJS](https://github.com/formatjs/formatjs)가 유지 관리합니다.
+> 개발자들이 자주 혼동하는 점 중 하나는 `next-intl`이 `react-intl`의 Next.js 버전이라고 생각하는 것입니다. 그렇지 않습니다, `next-intl`은 [Amann](https://github.com/amannn)이 유지 관리하며, `react-intl`은 [FormatJS](https://github.com/formatjs/formatjs)가 유지 관리합니다.
 
 ---
 

package/blog/ko/per-component_vs_centralized_i18n.md

@@ -86,7 +86,7 @@ extension Localization on String {
 
 ### 그렇다면 중앙집중식 접근 방식이 왜 이렇게 인기 있을까요?
 
-- 먼저, i18next는 널리 사용된 최초의 솔루션 중 하나로, PHP와 Java 아키텍처(MVC)에서 영감을 받은 철학(관심사의 엄격한 분리 — 콘텐츠를 코드와 분리해서 유지)을 따랐습니다. 2011년에 등장하여 React와 같은 컴포넌트 기반 아키텍처로의 대대적인 전환보다도 먼저 그 표준을 확립했습니다.
+- 먼저, i18next는 널리 사용된 최초의 솔루션 중 하나로, PHP와 Java 아키텍처(MVC)에서 영감을 받은 철학(관심사의 엄격한 분리, 콘텐츠를 코드와 분리해서 유지)을 따랐습니다. 2011년에 등장하여 React와 같은 컴포넌트 기반 아키텍처로의 대대적인 전환보다도 먼저 그 표준을 확립했습니다.
 - 한 번 라이브러리가 널리 채택되면 에코시스템을 다른 패턴으로 전환하기가 어려워집니다.
 - 중앙집중식 접근 방식은 Crowdin, Phrase 또는 Localized와 같은 번역 관리 시스템(Translation Management Systems)에서도 작업을 더 수월하게 만듭니다.
 - 컴포넌트별 접근 방식의 로직은 중앙집중식 방식보다 더 복잡하고 개발에 추가 시간이 필요합니다. 특히 콘텐츠가 어디에 위치하는지 식별하는 문제를 해결해야 할 때 그렇습니다.

package/blog/pl/compiler_vs_declarative_i18n.md

@@ -20,7 +20,7 @@ slugs:
 
 # Argumenty za i przeciw internacjonalizacji opartej na kompilatorze
 
-Jeśli budujesz aplikacje webowe od ponad dekady, wiesz, że internacjonalizacja (i18n) zawsze była punktem zapalnym. Często jest to zadanie, którego nikt nie chce wykonywać — wyciąganie stringów, zarządzanie plikami JSON i martwienie się o zasady pluralizacji.
+Jeśli budujesz aplikacje webowe od ponad dekady, wiesz, że internacjonalizacja (i18n) zawsze była punktem zapalnym. Często jest to zadanie, którego nikt nie chce wykonywać, wyciąganie stringów, zarządzanie plikami JSON i martwienie się o zasady pluralizacji.
 
 Niedawno pojawiła się nowa fala **narzędzi i18n opartych na kompilatorze**, obiecujących, że ta uciążliwość zniknie. Oferta jest kusząca: **Po prostu pisz tekst w swoich komponentach, a narzędzie budujące zajmie się resztą.** Bez kluczy, bez importów, po prostu magia.
 
@@ -205,7 +205,7 @@ Więc, którą opcję powinieneś wybrać?
 Podejście oparte na kompilatorze jest dobrym wyborem. Pozwala na niezwykle szybkie działanie. Nie musisz się martwić o strukturę plików czy klucze. Po prostu budujesz. Dług techniczny to problem dla „Przyszłego Ciebie”.
 
 **Jeśli jesteś Junior Developerem lub nie zależy Ci na optymalizacji:**  
-Jeśli chcesz jak najmniej ręcznego zarządzania, podejście oparte na kompilatorze jest prawdopodobnie najlepsze. Nie będziesz musiał samodzielnie obsługiwać kluczy czy plików tłumaczeń — po prostu piszesz tekst, a kompilator automatyzuje resztę. To zmniejsza nakład pracy przy konfiguracji i typowe błędy i18n związane z ręcznymi krokami.
+Jeśli chcesz jak najmniej ręcznego zarządzania, podejście oparte na kompilatorze jest prawdopodobnie najlepsze. Nie będziesz musiał samodzielnie obsługiwać kluczy czy plików tłumaczeń, po prostu piszesz tekst, a kompilator automatyzuje resztę. To zmniejsza nakład pracy przy konfiguracji i typowe błędy i18n związane z ręcznymi krokami.
 
 **Jeśli internacjonalizujesz istniejący projekt, który już zawiera tysiące komponentów do refaktoryzacji:**  
 Podejście oparte na kompilatorze może być tutaj pragmatycznym wyborem. Początkowa faza ekstrakcji może zaoszczędzić tygodnie lub miesiące ręcznej pracy. Jednak rozważ użycie narzędzia takiego jak polecenie `transform` Intlayer, które może wyodrębnić ciągi znaków i przekształcić je w jawne deklaracje treści deklaratywnej. Daje to szybkość automatyzacji przy jednoczesnym zachowaniu bezpieczeństwa i przenośności podejścia deklaratywnego. Otrzymujesz to, co najlepsze z obu światów: szybką początkową migrację bez długoterminowego długu architektonicznego.