@intlayer/docs 5.8.0-canary.0 → 5.8.0

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

@@ -1,14 +1,14 @@
 ---
 createdAt: 2025-01-02
 updatedAt: 2025-06-29
-title: react-i18n vs react-intl vs Intlayer
-description: react-i18next和next-intl和Intlayer
+title: react-i18next vs react-intl vs Intlayer
+description: 将 react-i18next 与 next-intl 和 Intlayer 集成，用于 React 应用的国际化 (i18n)
 keywords:
   - next-intl
   - react-i18next
   - Intlayer
   - 国际化
-  - 文档
+  - 博客
   - Next.js
   - JavaScript
   - React
@@ -17,178 +17,137 @@ slugs:
   - react-i18next-vs-react-intl-vs-intlayer
 ---
 
-# React-Intl 与 React-i18next 与 Intlayer | React 国际化 (i18n)
+# react-Intl VS react-i18next VS intlayer | React 国际化 (i18n)
 
-以下是三个流行的 i18n（国际化）库在 React 中的简明比较：**React-Intl**、**React-i18next** 和 **Intlayer**。每个库都为在您的 React 应用中集成多语言支持提供了独特的功能和工作流程。阅读完本文后，您应该能够决定哪个解决方案最符合您的需求。
+本指南比较了三种成熟的 **React** 国际化方案：**react-intl**（FormatJS）、**react-i18next**（i18next）和 **Intlayer**。
+我们重点关注 **纯 React** 应用（例如 Vite、CRA、SPA）。如果您使用的是 Next.js，请参阅我们专门的 Next.js 比较。
 
----
-
-## 1. 介绍
-
-在 React 应用中实现国际化 (i18n) 有多种方式。这里介绍的三种库有不同的设计理念、功能集和社区支持：
+我们将评估：
 
-1. **React-Intl**
-2. **React-i18next**
-3. **Intlayer**
+- 架构与内容组织
+- TypeScript 与安全性
+- 缺失翻译的处理
+- 丰富的内容与格式化能力
+- 性能与加载行为
+- 开发者体验（DX）、工具链与维护
+- SEO/路由（依赖框架）
 
-下面，您将找到每个解决方案的概述，随后是功能比较、优缺点以及示例用例。
+> **简而言之**：这三者都能实现 React 应用的本地化。如果您需要**组件范围的内容**、**严格的 TypeScript 类型**、**构建时缺失键检查**、**支持 Tree-shaking 的字典**，以及内置的编辑工具（可视化编辑器/CMS + 可选的 AI 翻译），那么 **Intlayer** 是模块化 React 代码库中最完整的选择。
 
 ---
 
-## 2. React-Intl
-
-### 概述
-
-[**React-Intl**](https://formatjs.io/docs/react-intl/) 是 [FormatJS](https://formatjs.io/) 套件的一部分。它提供了一套强大的 **API 和组件** 来处理消息格式化、复数形式、日期/时间和数字格式化。React-Intl 在企业应用中被广泛使用，主要是因为它是标准化消息语法和格式化的生态系统的一部分。
-
-### 主要特性
-
-- **ICU 消息语法**：提供全面的语法来处理消息插值、复数形式等。
-- **本地化格式化**：内置工具根据地区格式化日期、时间、数字和相对时间。
-- **声明式组件**：提供 `<FormattedMessage>`、`<FormattedNumber>`、`<FormattedDate>` 等，以便在 JSX 中无缝使用。
-- **丰富的生态系统**：与 FormatJS 工具（例如 [babel-plugin-react-intl](https://formatjs.io/docs/tooling/babel-plugin/)）良好集成，用于提取、管理和编译消息。
-
-### 典型工作流程
-
-1. **定义消息目录**（通常是每个地区的 JSON 文件）。
-2. **在 `<IntlProvider locale="zh" messages={messages}>` 中包装您的应用**。
-3. **使用** `<FormattedMessage id="myMessage" defaultMessage="你好，世界" />` 或 `useIntl()` 钩子来访问翻译字符串。
-
-### 优点
-
-- 成熟且在许多生产环境中使用。
-- 高级消息格式化，包括复数形式、性别、时区等。
-- 对消息提取和编译的强大工具支持。
-
-### 缺点
+## 高层定位
 
-- 需要熟悉 **ICU 消息格式**，这可能比较冗长。
-- 处理动态或复杂翻译（不只是字符串）的方式不直观。
+- **react-intl** - 以 ICU 为先，符合标准的格式化（日期/数字/复数），拥有成熟的 API。目录通常是集中管理的；键的安全性和构建时验证主要由你负责。
+- **react-i18next** - 极其流行且灵活；支持命名空间、检测器和许多插件（ICU、后端等）。功能强大，但随着项目规模扩大，配置可能变得复杂。
+- **Intlayer** - 面向组件的 React 内容模型，**严格的 TS 类型**，**构建时检查**，**支持 Tree-shaking**，以及 **可视化编辑器/CMS** 和 **AI 辅助翻译**。兼容 React Router、Vite、CRA 等。
 
 ---
 
-## 3. React-i18next
+## 功能矩阵（React 重点）
+
+| 功能                                   | `react-intlayer` (Intlayer)                                                              | `react-i18next` (i18next)                                      | `react-intl` (FormatJS)                            |
+| -------------------------------------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------- | -------------------------------------------------- |
+| **组件附近的翻译**                     | ✅ 是，内容与每个组件共置                                                                | ❌ 否                                                          | ❌ 否                                              |
+| **TypeScript 集成**                    | ✅ 高级，自动生成严格类型                                                                | ⚠️ 基础；需要额外配置以保证安全                                | ✅ 良好，但不够严格                                |
+| **缺失翻译检测**                       | ✅ TypeScript 错误高亮和构建时错误/警告                                                  | ⚠️ 主要是运行时回退字符串                                      | ⚠️ 回退字符串                                      |
+| **丰富内容（JSX/Markdown/组件）**      | ✅ 直接支持                                                                              | ⚠️ 有限 / 仅插值                                               | ⚠️ ICU 语法，不是真正的 JSX                        |
+| **AI 驱动的翻译**                      | ✅ 是，支持多个 AI 提供商。可使用您自己的 API 密钥。考虑到您的应用程序和内容范围的上下文 | ❌ 否                                                          | ❌ 否                                              |
+| **可视化编辑器**                       | ✅ 是，本地可视化编辑器 + 可选 CMS；可以外部化代码库内容；可嵌入                         | ❌ 否 / 通过外部本地化平台提供                                 | ❌ 否 / 通过外部本地化平台提供                     |
+| **本地化路由**                         | ✅ 是，开箱即用支持本地化路径（兼容 Next.js 和 Vite）                                    | ⚠️ 无内置支持，需要插件（例如 `next-i18next`）或自定义路由配置 | ❌ 否，仅支持消息格式化，路由需手动管理            |
+| **动态路由生成**                       | ✅ 是                                                                                    | ⚠️ 依赖插件/生态系统或手动设置                                 | ❌ 不提供                                          |
+| **复数形式处理**                       | ✅ 基于枚举的模式                                                                        | ✅ 可配置（如 i18next-icu 插件）                               | ✅ （ICU）                                         |
+| **格式化（日期、数字、货币）**         | ✅ 优化的格式化器（底层使用 Intl）                                                       | ⚠️ 通过插件或自定义 Intl 使用                                  | ✅ ICU 格式化器                                    |
+| **内容格式**                           | ✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml 进行中)                                      | ⚠️ .json                                                       | ✅ .json, .js                                      |
+| **ICU 支持**                           | ⚠️ 进行中                                                                                | ⚠️ 通过插件（如 i18next-icu）                                  | ✅ 是                                              |
+| **SEO 辅助工具（hreflang，网站地图）** | ✅ 内置工具：网站地图、robots.txt、元数据辅助工具                                        | ⚠️ 社区插件/手动                                               | ❌ 非核心功能                                      |
+| **生态系统 / 社区**                    | ⚠️ 较小但增长迅速且反应灵敏                                                              | ✅ 最大且成熟                                                  | ✅ 大型                                            |
+| **服务器端渲染与服务器组件**           | ✅ 支持，针对 SSR / React 服务器组件进行了优化                                           | ⚠️ 支持页面级别，但需要在组件树上传递 t 函数给子服务器组件     | ❌ 不支持，需要在组件树上传递 t 函数给子服务器组件 |
+| **Tree-shaking（仅加载使用的内容）**   | ✅ 支持，通过 Babel/SWC 插件在构建时按组件进行优化                                       | ⚠️ 通常加载全部（可通过命名空间/代码拆分进行改进）             | ⚠️ 通常加载全部                                    |
+| **懒加载**                             | ✅ 是的，按语言环境 / 按词典                                                             | ✅ 是的（例如，按需加载后端/命名空间）                         | ✅ 是的（拆分语言包）                              |
+| **清除未使用内容**                     | ✅ 是的，按词典在构建时                                                                  | ❌ 否，仅通过手动命名空间分割                                  | ❌ 否，所有声明的消息都会被打包                    |
+| **大型项目管理**                       | ✅ 鼓励模块化，适合设计系统                                                              | ⚠️ 需要良好的文件管理                                          | ⚠️ 中央目录可能变得庞大                            |
 
-### 概述
-
-[**React-i18next**](https://react.i18next.com/) 是 [i18next](https://www.i18next.com/) 的 React 扩展，是最流行的 JavaScript i18n 框架之一。它提供了 **广泛的特性** 用于运行时翻译、懒加载和语言检测，使其对于各种用例极其灵活。
-
-### 主要特性
-
-- **灵活的翻译结构**：不绑定于像 ICU 这样的单一格式。您可以将翻译存储在 JSON 中，使用插值、复数形式等。
-- **动态语言切换**：内置语言检测插件和运行时更新。
-- **嵌套和结构化翻译**：可以轻松地将翻译嵌套在 JSON 中。
-- **广泛的插件生态系统**：用于检测（浏览器、路径、子域等）、资源加载、缓存等。
-
-### 典型工作流程
-
-1. **安装 `i18next` 和 `react-i18next`。**
-2. **配置 i18n** 加载翻译（JSON）并设置语言检测或回退。
-3. **在 `I18nextProvider` 中包装您的应用**。
-4. **使用 `useTranslation()` 钩子** 或 `<Trans>` 组件来显示翻译。
+---
 
-### 优点
+## 深度比较
 
-- 高度 **灵活** 和功能丰富。
-- 非常活跃的社区和大量插件生态系统。
-- 轻松 **动态加载** 翻译（例如，从服务器按需加载）。
+### 1) 架构与可扩展性
 
-### 缺点
+- **react-intl / react-i18next**：大多数配置保持每种语言的**集中式本地化文件夹**，有时按**命名空间**（i18next）拆分。早期效果良好，但随着应用增长，成为共享的表面区域。
+- **Intlayer**：提倡与其所服务的 UI **共置** 的 **每组件（或每功能）字典**。这保持了所有权的清晰，便于组件的复制/迁移，并减少跨团队的键变动。未使用的内容更容易识别和删除。
 
-- **配置可能比较冗长**，尤其是如果您有更高级的需求。
-- 如果您希望严格类型的翻译，可能需要额外的 TypeScript 设置。
+**重要原因：** 模块化内容反映模块化 UI。当翻译与其所属组件共存时，大型 React 代码库会保持更整洁。
 
 ---
 
-## 4. Intlayer
+### 2) TypeScript 与安全性
 
-### 概述
+- **react-intl**：类型定义扎实，但**没有自动键类型**；你需要自己强制安全模式。
+- **react-i18next**：为钩子提供强类型；**严格的键类型**通常需要额外配置或生成器。
+- **Intlayer**：**从您的内容自动生成严格类型**。IDE 自动完成和**编译时错误**可以在运行时之前捕获拼写错误和缺失的键。
 
-[**Intlayer**](https://github.com/aymericzip/intlayer) 是一个较新的开源 i18n 库，专注于 **组件级内容声明**、类型安全和 **动态路由**。它专为现代 React 工作流设计，支持 **Create React App** 和 **Vite** 设置。它还包括高级功能，如 **基于区域的路由** 和 **自动生成的 TypeScript 类型** 用于翻译。
+**重要原因：** 将失败“左移”（到构建/CI阶段）可以减少生产环境问题并加快开发者反馈循环。
 
-### 主要特性
+---
 
-- **声明性内容文件**：每个组件或模块可以在专用的 `.content.tsx` 或 `.content.json` 文件中声明其翻译，将内容紧邻使用处。
-- **内置路由和中间件**：可选模块用于本地化路由（例如，`/zh/about`、`/fr/about`）和用于检测用户区域的服务器中间件。
-- **自动生成的 TypeScript 类型**：通过自动完成功能和编译时错误检测，确保类型安全。
-- **动态和丰富的翻译**：可以在翻译中包含 JSX/TSX 以应对更复杂的用例（例如，链接、加粗文本、翻译中的图标）。
+### 3) 缺失翻译处理
 
-### 典型工作流程
+- **react-intl / react-i18next**：默认使用**运行时回退**（键回显或默认语言）。您可以添加代码检查/插件，但构建时不保证检测。
+- **Intlayer**：通过**构建时检测**，在缺少必需的语言或键时发出警告或错误。
 
-1. **安装 `intlayer` 和 `react-intlayer`。**
-2. **创建 `intlayer.config.ts`** 定义可用的区域和默认区域。
-3. **使用 Intlayer CLI** 或插件来 **转译** 内容声明。
-4. **在 `<IntlayerProvider>` 中包装您的应用** 并使用 `useIntlayer("keyName")` 获取内容。
+**重要原因：** CI 在缺失字符串时失败，防止“神秘的英文”泄漏到非英文界面中。
 
-### 优点
+---
 
-- **TypeScript 友好**，具有内置类型生成和错误检查。
-- 可能 **丰富的内容**（例如，将 React 节点传递作为翻译）。
-- **开箱即用的本地化路由**。
-- 与流行的构建工具（CRA、Vite）集成，易于设置。
+### 4) 丰富内容与格式化
 
-### 缺点
+- **react-intl**：对复数、选择、日期/数字和消息组合提供出色的 **ICU** 支持。可以使用 JSX，但思维模型仍以消息为中心。
+- **react-i18next**：灵活的插值和用于嵌入元素/组件的 **`<Trans>`** 组件；通过插件支持 ICU。
+- **Intlayer**：内容文件可以包含 **丰富节点**（JSX/Markdown/组件）和 **元数据**。格式化底层使用 Intl；复数模式设计符合人体工学。
 
-- 与 React-Intl 或 React-i18next 相比仍然 **相对较新**。
-- 更加注重“组件级内容声明”的方法, , 可能与典型的 .json 目录有一定差异。
-- 与更成熟的库相比，生态系统和社区较小。
+**重要原因：** 当库能够干净地支持 React 节点时，处理复杂的 UI 文本（链接、加粗部分、内联组件）会更加轻松。
 
 ---
 
-## 5. 功能比较
+### 5) 性能与加载行为
+
+- **react-intl / react-i18next**：您通常需要手动管理**目录拆分**和**懒加载**（命名空间/动态导入）。这种方式有效但需要严格的规范。
+- **Intlayer**：自动**摇树优化**未使用的字典，并开箱即用地支持**按字典/按语言的懒加载**。
 
-| **特性**            | **React-Intl**                                  | **React-i18next**                                                  | **Intlayer**                                                                                |
-| ------------------- | ----------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
-| **主要用例**        | 基于字符串的翻译，日期/数字格式化，ICU 消息语法 | 全功能 i18n，易于动态切换、嵌套、插件生态系统                      | 强类型翻译，聚焦于声明式内容、本地化路由和可选的服务器中间件                                |
-| **方法**            | 使用 `<IntlProvider>` 和 FormatJS 消息组件      | 使用 `I18nextProvider` 和 `useTranslation()` 钩子                  | 使用 `<IntlayerProvider>` 和 `useIntlayer()` 钩子以及内容声明                               |
-| **本地化格式**      | 基于 ICU 的字符串（JSON 或 JavaScript 目录）    | JSON 资源文件（或自定义加载程序）。ICU 格式可通过 i18next 插件选择 | `.content.[ts/js/tsx]` 或 JSON 声明；可以包含字符串或 React 组件                            |
-| **路由**            | 由外部处理（没有内置的本地化路由机制）          | 通过 i18next 插件（路径、子域检测等）外部处理                      | 内置支持本地化路由（如 `/zh/about`、`/fr/about`），以及可选的服务器中间件（用于 SSR/Vite）  |
-| **TypeScript 支持** | 良好（官方包的类型定义）                        | 良好，但如果您希望严格检查类型翻译，则需要额外的配置               | 优秀（自动生成内容键和翻译的类型定义）                                                      |
-| **复数和格式化**    | 高级：內置日期/时间/数字格式化、复数/性别支持   | 可配置的复数形式。日期/时间格式化通常通过外部库或 i18next 插件完成 | 可以依赖标准 JavaScript Intl 或将逻辑嵌入内容中。虽然不如 FormatJS 专业，但能处理典型案例。 |
-| **社区和生态系统**  | 大，属于 FormatJS 生态系统                      | 非常大，活跃，插件众多（检测、缓存、框架等）                       | 较小但正在成长；开源，现代方法                                                              |
-| **学习曲线**        | 中等（学习 ICU 消息语法，FormatJS 规范）        | 低到中等（使用比较简单，但高级配置可能会变得冗长）                 | 中等（内容声明的概念和专业构建步骤）                                                        |
+**重要性说明：** 更小的包体积和更少的未使用字符串能提升启动和导航性能。
 
 ---
 
-## 6. 何时选择每种
+### 6) 开发体验（DX）、工具链与维护
 
-1. **React-Intl**
+- **react-intl / react-i18next**：拥有广泛的社区生态系统；对于编辑工作流，通常采用外部本地化平台。
+- **Intlayer**：提供免费的**可视化编辑器**和**可选的内容管理系统（CMS）**（内容可保存在 Git 中或外部化）。还提供用于内容创作的**VSCode 扩展**，以及使用您自己的提供商密钥进行的**AI 辅助翻译**。
 
-   - 您需要 **强大的格式化** 用于日期/时间/数字，和强大的 **ICU 消息语法**。
-   - 您更倾向于使用“**基于标准**”的方法进行翻译。
-   - 您不需要本地化路由或强类型的翻译键。
+**重要原因：** 内置工具缩短了开发者与内容作者之间的反馈周期--减少了胶水代码，降低了对第三方依赖的需求。
 
-2. **React-i18next**
+---
 
-   - 您需要一个 **灵活、成熟** 的解决方案，具有 **动态** 和 **按需** 加载翻译的功能。
-   - 您希望使用 **基于插件** 的语言检测（例如，从 URL、Cookies、本地存储等）或高级缓存。
-   - 您需要最大的生态系统，具有针对各种框架（如 Next.js、React Native 等）的许多现有集成。
+## 何时选择哪种方案？
 
-3. **Intlayer**
-   - 您希望 **强类型** 和 **自动生成类型** 的集成，确保您很少遗漏翻译键。
-   - 您更喜欢将 **内容声明** 紧邻组件，可能包含 React 节点或在翻译中使用高级逻辑。
-   - 您需要 **内置本地化路由** 或想要轻松将其纳入您的 SSR 或 Vite 设置。
-   - 您希望采用现代方法或简单地希望拥有一个覆盖 **内容管理**（i18n）和 **路由** 的类型安全的库。
+- 如果您需要**以 ICU 为优先**的消息格式化，且希望使用简洁、符合标准的 API，并且您的团队能够手动维护目录和安全检查，**请选择 react-intl**。
+- 如果您需要**i18next 生态系统的广泛支持**（检测器、后端、ICU 插件、集成等），并且愿意接受更多配置以获得更高灵活性，**请选择 react-i18next**。
+- **选择 Intlayer** 如果你重视 **组件范围的内容管理**、**严格的 TypeScript 类型检查**、**构建时保证**、**摇树优化**，以及 **开箱即用** 的编辑工具 -- 尤其适用于 **大型、模块化** 的 React 应用。
 
 ---
 
-## 7. 结论
-
-每个库都为国际化 React 应用程序提供了强大的解决方案：
-
-- **React-Intl** 在消息格式化方面表现优异，是专注于 ICU 消息语法的企业解决方案的热门选择。
-- **React-i18next** 为高级或动态 i18n 需求提供了高度灵活和插件驱动的环境。
-- **Intlayer** 提供了 **现代、强类型** 的方法，结合了内容声明、高级的本地化路由和基于插件的（CRA，Vite）集成。
+## 实用迁移建议（react-intl / react-i18next → Intlayer）
 
-您的选择在很大程度上取决于项目需求、期望的开发人员体验（DX）以及类型翻译或高级路由的重要程度。如果您重视内置的本地化路由和 TypeScript 集成，**Intlayer** 可能最具吸引力。如果您想要一个经过考验的、生态系统丰富的解决方案，**React-i18next** 是一个不错的选择。对于直接的 ICU 基于格式化的需求，**React-Intl** 是一个可靠的选择。
+- **渐进迁移**：从一个功能或路由开始；在过渡期间并行保留旧版目录。
+- **采用每组件字典**：将内容与组件共置，减少耦合。
+- **启用严格检查**：让构建时错误提前暴露缺失的键/语言，便于 CI 早期发现。
+- **测量包体积**：预期未使用的字符串被剔除后包体积会减小。
 
 ---
 
-### 进一步阅读
+## 结论
 
-- [React-Intl 文档](https://formatjs.io/docs/react-intl/)
-- [React-i18next 文档](https://react.i18next.com/)
-- [Intlayer + CRA 开始指南](#)（来自您的文档）
-- [Intlayer + Vite 和 React 开始指南](#)（来自您的文档）
+所有三个库都能有效地实现 React 的本地化。区别在于你需要构建多少**基础设施**，才能达到一个**安全、可扩展**的环境：
 
-随意混合和匹配这些方法以满足您的需求, , 没有“放之四海而皆准”的解决方案，每个库都在不断发展，以应对 React 生态系统中的新用例。
+- 使用 **Intlayer**，**模块化内容**、**严格的 TS 类型检查**、**构建时安全性**、**摇树优化的包**以及**编辑工具**都是默认配置，而非额外负担。
+- 如果你的团队重视多语言、组件驱动的 React 应用中的**可维护性和速度**，Intlayer 提供了目前**最完整**的开发者和内容工作流。

package/blog/zh/vue-i18n_vs_intlayer.md

@@ -0,0 +1,269 @@
+---
+createdAt: 2024-08-11
+updatedAt: 2025-08-23
+title: vue-i18n 与 Intlayer 对比
+description: 比较 vue-i18n 与 Intlayer 在 Vue/Nuxt 应用中的国际化 (i18n) 方案
+keywords:
+  - vue-i18n
+  - Intlayer
+  - 国际化
+  - i18n
+  - 博客
+  - Vue
+  - Nuxt
+  - JavaScript
+slugs:
+  - blog
+  - vue-i18n-vs-intlayer
+---
+
+# vue-i18n VS Intlayer | Vue 国际化 (i18n)
+
+本指南比较了两个流行的 **Vue 3**（及 **Nuxt**）国际化选项：**vue-i18n** 和 **Intlayer**。
+我们聚焦于现代 Vue 工具链（Vite，Composition API），并评估：
+
+1. **架构与内容组织**
+2. **TypeScript 与安全性**
+3. **缺失翻译处理**
+4. **路由与 URL 策略**
+5. **性能与加载行为**
+6. **开发者体验 (DX)、工具链与维护**
+7. **SEO 与大型项目的可扩展性**
+
+> **简而言之**：两者都能实现 Vue 应用的本地化。如果你需要**组件范围的内容**、**严格的 TypeScript 类型**、**构建时缺失键检查**、**支持 Tree-shaking 的字典**，以及**内置的路由/SEO 辅助工具**，再加上**可视化编辑器和 AI 翻译**，那么 **Intlayer** 是更完整、更现代的选择。
+
+---
+
+## 高层定位
+
+- **vue-i18n** - Vue 的事实标准国际化库。支持灵活的消息格式（ICU 风格）、单文件组件（SFC）中的 `<i18n>` 块用于本地消息，并拥有庞大的生态系统。安全性和大规模维护主要依赖开发者自身。
+- **Intlayer** - 面向组件的内容模型，适用于 Vue/Vite/Nuxt，具备**严格的 TypeScript 类型检查**、**构建时校验**、**摇树优化**、**路由和 SEO 辅助工具**，可选的**可视化编辑器/CMS**，以及**AI 辅助翻译**。
+
+---
+
+## 并列功能对比（Vue 重点）
+
+| 功能                                         | **Intlayer**                                                           | **vue-i18n**                                             |
+| -------------------------------------------- | ---------------------------------------------------------------------- | -------------------------------------------------------- |
+| **组件附近的翻译**                           | ✅ 是，内容与组件共置（例如，`MyComp.content.ts`）                     | ✅ 是，通过 SFC `<i18n>` 块（可选）                      |
+| **TypeScript 集成**                          | ✅ 高级，自动生成 **严格** 类型和键自动补全                            | ✅ 良好的类型定义；**严格的键安全性需要额外的设置/规范** |
+| **缺失翻译检测**                             | ✅ **构建时** 警告/错误和 TS 显示                                      | ⚠️ 运行时回退/警告                                       |
+| **丰富内容（组件/Markdown）**                | ✅ 直接支持丰富节点和Markdown内容文件                                  | ⚠️ 有限支持（组件通过`<i18n-t>`，Markdown通过外部插件）  |
+| **AI驱动的翻译**                             | ✅ 内置使用您自己的AI提供商密钥的工作流程                              | ❌ 未内置                                                |
+| **可视化编辑器 / CMS**                       | ✅ 免费的可视化编辑器和可选的CMS                                       | ❌ 未内置（使用外部平台）                                |
+| **本地化路由**                               | ✅ 为 Vue Router/Nuxt 提供生成本地化路径、URL 和 `hreflang` 的辅助工具 | ⚠️ 非核心功能（使用 Nuxt i18n 或自定义 Vue Router 配置） |
+| **动态路由生成**                             | ✅ 支持                                                                | ❌ 不提供（由 Nuxt i18n 提供）                           |
+| **复数化与格式化**                           | ✅ 枚举模式；基于 Intl 的格式化工具                                    | ✅ ICU 风格消息；Intl 格式化工具                         |
+| **内容格式**                                 | ✅ `.ts`、`.js`、`.json`、`.md`、`.txt`（YAML 进行中）                 | ✅ `.json`、`.js`（加上 SFC `<i18n>` 块）                |
+| **ICU 支持**                                 | ⚠️ 进行中                                                              | ✅ 支持                                                  |
+| **SEO 辅助工具（站点地图、robots、元数据）** | ✅ 内置辅助工具（框架无关）                                            | ❌ 非核心功能（Nuxt i18n/社区提供）                      |
+| **SSR/SSG**                                  | ✅ 支持 Vue SSR 和 Nuxt；不阻塞静态渲染                                | ✅ 支持 Vue SSR/Nuxt                                     |
+| **Tree-shaking（仅打包使用的内容）**         | ✅ 构建时按组件进行                                                    | ⚠️ 部分支持；需要手动代码拆分/异步消息                   |
+| **懒加载**                                   | ✅ 按语言/词典级别                                                     | ✅ 支持异步语言消息                                      |
+| **清理未使用内容**                           | ✅ 是（构建时）                                                        | ❌ 非内置功能                                            |
+| **大型项目可维护性**                         | ✅ 鼓励模块化、设计系统友好的结构                                      | ✅ 可行，但需要严格的文件/命名空间管理                   |
+| **生态系统 / 社区**                          | ⚠️ 较小但增长迅速                                                      | ✅ Vue 生态系统中庞大且成熟                              |
+
+---
+
+## 深度比较
+
+### 1) 架构与可扩展性
+
+- **vue-i18n**：常见的设置是为每个语言环境使用**集中式目录**（可选地拆分为文件/命名空间）。SFC `<i18n>` 块允许局部消息，但随着项目增长，团队通常会回归使用共享目录。
+- **Intlayer**：提倡将**每个组件的字典**存储在其对应组件旁边。这减少了跨团队冲突，保持内容可发现性，并自然限制了漂移/未使用的键。
+
+**重要原因：** 在大型 Vue 应用或设计系统中，**模块化内容**比单体目录更易于扩展。
+
+---
+
+### 2) TypeScript 与安全性
+
+- **vue-i18n**：良好的 TS 支持；**严格键类型**通常需要自定义模式/泛型和谨慎的约定。
+- **Intlayer**：从您的内容中**生成严格类型**，提供**IDE 自动补全**和针对拼写错误/缺失键的**编译时错误**。
+
+**重要性说明：** 强类型可以在**运行前**捕获问题。
+
+---
+
+### 3) 缺失翻译处理
+
+- **vue-i18n**：**运行时**警告/回退（例如，回退到默认语言或键）。
+- **Intlayer**：通过**构建时**检测，针对不同语言和键发出警告/错误。
+
+**重要性说明：** 构建时强制执行确保生产环境界面干净且一致。
+
+---
+
+### 4) 路由与 URL 策略（Vue Router/Nuxt）
+
+- **两者**都支持本地化路由。
+- **Intlayer** 提供辅助工具来 **生成本地化路径**，**管理语言前缀**，并为 SEO 生成 **`<link rel="alternate" hreflang>`** 标签。在 Nuxt 中，它补充了框架的路由功能。
+
+**重要性：** 减少自定义粘合层，实现跨语言环境的 **更清晰的 SEO**。
+
+---
+
+### 5) 性能与加载行为
+
+- **vue-i18n**：支持异步加载语言消息；避免过度打包需要你自行管理（需谨慎拆分目录）。
+- **Intlayer**：在构建时进行 **Tree-shaking**，并按字典/语言进行 **懒加载**。未使用的内容不会被打包。
+
+**重要性：** 更小的包体积和更快的多语言 Vue 应用启动速度。
+
+---
+
+### 6) 开发者体验与工具链
+
+- **vue-i18n**：成熟的文档和社区；您通常会依赖**外部本地化平台**来进行编辑工作流程。
+- **Intlayer**：提供免费的**可视化编辑器**，可选的**CMS**（支持 Git 或外部化），一个**VSCode 扩展**，**CLI/CI** 工具，以及使用您自己的提供商密钥的**AI 辅助翻译**。
+
+**重要原因：** 降低运维成本，缩短开发与内容的循环时间。
+
+---
+
+### 7) SEO、SSR 与 SSG
+
+- **两者**均支持 Vue SSR 和 Nuxt。
+- **Intlayer**：增加了**SEO 辅助工具**（站点地图/元数据/`hreflang`），与框架无关，并且能很好地配合 Vue/Nuxt 构建。
+
+**重要原因：** 实现国际化 SEO，无需定制复杂配置。
+
+---
+
+## 为什么选择 Intlayer？（问题与方法）
+
+大多数 i18n 方案（包括 **vue-i18n**）都从**集中式目录**开始：
+
+```bash
+.
+├── locales
+│   ├── en.json
+│   ├── es.json
+│   └── fr.json
+└── src
+    └── components
+        └── MyComponent.vue
+```
+
+或者使用按语言区分的文件夹：
+
+```bash
+.
+├── locales
+│   ├── en
+│   │  ├── footer.json
+│   │  └── navbar.json
+│   ├── fr
+│   │  ├── footer.json
+│   │  └── navbar.json
+│   └── es
+│      ├── footer.json
+│      └── navbar.json
+└── src
+    └── components
+        └── MyComponent.vue
+```
+
+随着应用程序的增长，这通常会减慢开发速度：
+
+1. **对于新组件**，你需要创建/编辑远程目录，连接命名空间，并进行翻译（通常通过从 AI 工具手动复制粘贴）。
+2. **在更改组件时**，你需要寻找共享的键，进行翻译，保持各语言版本同步，删除无用键，并对齐 JSON 结构。
+
+**Intlayer** 将内容限定在**每个组件范围内**，并将其**保存在代码旁边**，就像我们已经对 CSS、故事、测试和文档所做的那样：
+
+```bash
+.
+└── components
+    └── MyComponent
+        ├── MyComponent.content.ts
+        └── MyComponent.vue
+```
+
+**内容声明**（每个组件）：
+
+```ts fileName="./components/MyComponent/MyComponent.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+// 组件示例内容声明
+const componentExampleContent = {
+  key: "component-example",
+  content: {
+    greeting: t({
+      en: "Hello World",
+      es: "Hola Mundo",
+      fr: "Bonjour le monde",
+    }),
+  },
+} satisfies Dictionary;
+
+export default componentExampleContent;
+```
+
+**在 Vue 中的使用**（组合式 API）：
+
+```vue fileName="./components/MyComponent/MyComponent.vue"
+<script setup lang="ts">
+import { useIntlayer } from "vue-intlayer"; // Vue 集成
+const { greeting } = useIntlayer("component-example");
+</script>
+
+<template>
+  <span>{{ greeting }}</span>
+</template>
+```
+
+这种方法：
+
+- **加快开发速度**（声明一次；IDE/AI 自动补全）。
+- **清理代码库**（1 个组件 = 1 个字典）。
+- **简化复制/迁移**（复制组件及其内容一起复制）。
+- **避免死键**（未使用的组件不导入内容）。
+- **优化加载**（懒加载组件携带其内容）。
+
+---
+
+## Intlayer 的额外功能（与 Vue 相关）
+
+- **跨框架支持**：支持 Vue、Nuxt、Vite、React、Express 等。
+- **基于 JavaScript 的内容管理**：在代码中声明，灵活度高。
+- **每个语言环境的声明文件**：为所有语言环境预设内容，工具自动生成其余部分。
+- **类型安全环境**：强大的 TypeScript 配置，支持自动补全。
+- **简化内容获取**：单一钩子/组合函数获取字典的所有内容。
+- **有序的代码库**：一个组件对应一个字典，存放在同一文件夹。
+- **增强的路由功能**：为 **Vue Router/Nuxt** 提供本地化路径和元数据的辅助工具。
+- **Markdown 支持**：按语言环境导入远程/本地 Markdown；将 frontmatter 暴露给代码。
+- **免费可视化编辑器和可选 CMS**：无需付费本地化平台即可创作；支持 Git 友好的同步。
+- **可摇树内容**：仅打包使用的内容；支持懒加载。
+- **静态渲染友好**：不阻塞静态站点生成（SSG）。
+- **AI驱动的翻译**：使用您自己的AI提供商/API密钥，支持翻译成231种语言。
+- **MCP服务器和VSCode扩展**：在您的IDE中自动化i18n工作流和内容创作。
+- **互操作性**：在需要时与**vue-i18n**、**react-i18next**和**react-intl**桥接。
+
+---
+
+## 何时选择哪一个？
+
+- 如果您想要**标准的Vue方案**，并且能够自行管理目录/命名空间，且您的应用是**小型到中型**（或者您已经依赖Nuxt i18n），请选择**vue-i18n**。
+- 如果您重视**组件范围的内容**、**严格的TypeScript**、**构建时保证**、**摇树优化**以及**内置的路由/SEO/编辑工具**，尤其是针对**大型、模块化的Vue/Nuxt代码库**，请选择**Intlayer**。
+
+---
+
+## 实用迁移注意事项（vue-i18n → Intlayer）
+
+- **按功能开始**：一次将一个路由/视图/组件迁移到本地 Intlayer 字典。
+- **迁移期间桥接**：保持 vue-i18n 目录并行存在；逐步替换查找。
+- **启用严格检查**：让构建时检测及早发现缺失的键/语言环境。
+- **采用路由/SEO 辅助工具**：标准化语言环境检测和 `hreflang` 标签。
+- **测量包大小**：随着未使用内容被排除，预计**包大小会减少**。
+
+---
+
+## 结论
+
+**vue-i18n** 和 **Intlayer** 都能很好地本地化 Vue 应用。区别在于你需要自己构建多少内容，才能实现一个健壮且可扩展的方案：
+
+- 使用 **Intlayer**，**模块化内容**、**严格的 TS**、**构建时安全性**、**摇树优化的包**以及**路由/SEO/编辑器工具**均为**开箱即用**。
+- 如果您的团队优先考虑在多语言、组件驱动的 Vue/Nuxt 应用中的**可维护性和速度**，Intlayer 提供了目前**最完整**的体验。
+
+有关更多详情，请参阅 ['为什么选择 Intlayer？' 文档](https://intlayer.org/doc/why)。

package/dist/cjs/generated/blog.entry.cjs

@@ -1600,6 +1600,47 @@ const blogEntry = {
       )
     )
   },
+  "./blog/en/vue-i18n_vs_intlayer.md": {
+    en: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/en/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    fr: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/fr/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    ru: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/ru/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    ja: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/ja/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    ko: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/ko/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    zh: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/zh/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    es: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/es/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    de: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/de/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    ar: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/ar/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    pt: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/pt/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    "en-GB": Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/en-GB/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    it: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/it/vue-i18n_vs_intlayer.md"), "utf8")
+    ),
+    hi: Promise.resolve(
+      (0, import_promises.readFile)((0, import_path.join)(dir, "../../../blog/hi/vue-i18n_vs_intlayer.md"), "utf8")
+    )
+  },
   "./blog/en/what_is_internationalization.md": {
     en: Promise.resolve(
       (0, import_promises.readFile)(