@intlayer/docs 5.5.10 → 5.5.12

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

@@ -0,0 +1,285 @@
+---
+createdAt: 2024-08-11
+updatedAt: 2025-06-29
+title: next-i18next vs next-intl vs Intlayer
+description: 比较Next.js应用程序的next-i18next与next-intl与Intlayer
+keywords:
+  - next-intl
+  - next-i18next
+  - Intlayer
+  - 国际化
+  - 文档
+  - Next.js
+  - JavaScript
+  - React
+slugs:
+  - blog
+  - next-i18next-vs-next-intl-vs-intlayer
+---
+
+# next-i18next VS next-intl VS Intlayer | Next.js 国际化 (i18n)
+
+下面是 **三个流行库** 进行 Next.js 应用国际化 (i18n) 的简要比较：**next-intl**、**next-i18next** 和 **Intlayer**。
+
+本文档强调关键标准：
+
+1. **架构**（将翻译与其组件保持紧密）
+2. **TypeScript 支持**
+3. **缺失翻译的管理**
+4. **服务器组件支持**
+5. **增强的路由和中间件** 适用于 Next.js
+6. **设置的简单性**
+
+该指南还提供了对 **Intlayer** 的 **深入了解**，展示了它为什么可以成为一个强大的选择, , 特别是对于 Next.js 13+，包括 **App Router** 和 **服务器组件**。
+
+---
+
+## 各库概述
+
+### 1. next-intl
+
+**主要焦点**：快速简便的设置，采用轻量级的本地化方式。
+
+- **架构**：鼓励将翻译放在单一文件夹中（例如，`locales/`），但也允许多种策略。不严格执行“每个组件一个翻译”的架构。
+- **TypeScript 支持**：基础的 TypeScript 集成。存在一些类型定义，但并不以从翻译文件自动生成 TypeScript 定义为主要方向。
+- **缺失翻译**：基本的回退机制。默认情况下，回退到一个键或默认语言字符串。没有强大的开箱即用的工具来进行高级缺失翻译检查。
+- **服务器组件支持**：通常与 Next.js 13+ 一起工作，但对于深层服务器端使用（例如，复杂动态路由的服务器组件），模式不够专用。
+- **路由和中间件**：中间件支持是可能的，但有限。通常依赖于 Next.js 的 `Middleware` 进行语言检测，或手动配置以重写语言路径。
+- **设置简单性**：非常简单。需要最少的样板代码。
+
+**使用时机**：当你想要一种更简单的方法或熟悉以更传统的方式管理你的翻译（如一个包含语言 JSON 文件的文件夹）时。
+
+---
+
+### 2. next-i18next
+
+**主要焦点**：使用 `i18next` 背后的成熟解决方案，广泛应用于 Next.js 项目。
+
+- **架构**：通常将翻译组织在 `public/locales` 文件夹中。并不是专门设计为将翻译“靠近”每个组件，尽管你可以手动采用不同的结构。
+- **TypeScript 支持**：合理的 TypeScript 覆盖，但需要自定义配置以进行类型化翻译和类型化钩子。
+- **缺失翻译**：i18next 提供插值/回退机制。然而，缺失翻译检测通常需要额外设置或第三方插件。
+- **服务器组件支持**：已记录基本用法与 Next.js 13 兼容，但高级用法（例如，深度集成服务器组件、动态路由生成）可能比较麻烦。
+- **路由和中间件**：在语言子路径的重写中严重依赖于 Next.js 的 `Middleware`。对于更复杂的设置，你可能需要深入了解高级 i18next 配置。
+- **设置简单性**：对于习惯 i18next 的人来说是熟悉的方式。然而，在需要高级 i18n 特性时（命名空间、多种回退语言等）可能会增加更多样板代码。
+
+**使用时机**：当你已经致力于 `i18next` 生态系统或有现有 i18next 基础的翻译时。
+
+---
+
+### 3. Intlayer
+
+**主要焦点**：一个现代的开源 i18n 库，专门为 Next.js **App Router**（12, 13, 14 和 15）量身定制，内置支持 **服务器组件** 和 **Turbopack**。
+
+#### 主要优点
+
+1. **架构**
+
+   - 鼓励将 **翻译紧密放置于组件旁边**。每个页面或组件可以拥有自己的 `.content.ts`（或 JSON）文件, , 无须在巨大的翻译文件夹中翻找。
+   - 这使得你的代码更加 **模块化和可维护**，特别是在大型代码库中。
+
+2. **TypeScript 支持**
+
+   - **自动生成的类型定义**：一旦你定义了内容，Intlayer 将生成可以支持自动完成并捕捉翻译错误的类型。
+   - 最小化运行时错误，比如缺失键，并直接在你的 IDE 中提供高级 **自动完成**。
+
+3. **缺失翻译的管理**
+
+   - 在构建期间，Intlayer 可以 **检测缺失的翻译键** 并抛出警告或错误。
+   - 这确保你永远不会在多语言之间意外发布缺失文本。
+
+4. **针对服务器组件的优化**
+
+   - 完全支持 Next.js 的 **App Router** 和新的 **服务器组件** 范式。
+   - 提供专门的提供者（`IntlayerServerProvider`、`IntlayerClientProvider`）以 **隔离服务器上下文**（处理 Next.js 13+ 时至关重要）。
+
+5. **增强的路由和中间件**
+
+   - 包含一款专用的 [**`intlayerMiddleware`**](#) 用于 **自动语言检测**（通过 cookies 或浏览器头）和高级路由生成。
+   - 动态处理本地化路径（例如，`/en-US/about` 与 `/fr/about`），配置最小化。
+   - 提供助手方法如 `getMultilingualUrls` 用于生成替代语言链接（非常适合 **SEO**）。
+
+6. **简化的设置**
+   - 一个配置文件（`intlayer.config.ts`）来定义你的语言、默认语言和集成偏好。
+   - 一个包装插件 `withIntlayer(nextConfig)` 可以 **注入** 所有环境变量和内容监视器。
+   - **没有大型回退配置**, , 该系统旨在“正常工作”，减少摩擦。
+
+> **底线**：Intlayer 是一个现代化的解决方案，旨在 **推动最佳实践**：从 **将翻译紧邻** 其每个 React 组件，到提供 **强大的 TS 支持** 和 **简便的服务器端** 使用，同时 **大幅减少样板代码**。
+
+---
+
+## 并排特性比较
+
+| **特性**                | **next-intl**             | **next-i18next**               | **Intlayer**                    |
+| ----------------------- | ------------------------- | ------------------------------ | ------------------------------- |
+| **将翻译靠近组件**      | 部分 - 通常一个语言文件夹 | 非默认 - 通常 `public/locales` | **是 - 推荐且简单**             |
+| **TypeScript 自动生成** | 基本 TS 定义              | 基本 TS 支持                   | **是 - 高级开箱即用**           |
+| **缺失翻译检测**        | 主要是回退字符串          | 主要是回退字符串               | **是 - 构建时检查**             |
+| **服务器组件支持**      | 有效但不专用              | 支持但可能冗长                 | **完全支持专用提供者**          |
+| **路由和中间件**        | 手动集成与 Next 中间件    | 通过重写配置提供               | **专用 i18n 中间件 + 高级钩子** |
+| **设置复杂性**          | 简单，最小配置            | 传统，对于高级用法可能冗长     | **一个配置文件 & 插件**         |
+
+---
+
+## 为什么选择 Intlayer？
+
+对于迁移到或建立在 **Next.js App Router**（版本 13、14 或 15）与 **服务器组件** 之上的团队，Intlayer 提供：
+
+1. **精简的架构**
+
+   - 每个路由或组件都持有自己的翻译。这促进了清晰性和可维护性。
+
+2. **强大的 TypeScript 集成**
+
+   - 你获得编译器级别的安全性，避免“拼写错误”或缺失的翻译键。
+
+3. **真实的缺失翻译警报**
+
+   - 如果你忘记了某个键或语言翻译，你将在构建时收到警告（而不是发布不完整的 UI）。
+
+4. **内置高级路由**
+
+   - 自动语言检测、动态路由生成和简单的本地化 URL 管理均包含在内。
+   - 标准的 `intlayerMiddleware` 不需要深入自定义重写。
+
+5. **一站式设置**
+
+   - 最少的样板代码：只需定义你的 `intlayer.config.ts`，用 `withIntlayer` 包装 `next.config`，并添加官方中间件。
+   - 清晰、直接的用法，适用于 **服务器** 和 **客户端** 组件，通过 `IntlayerServerProvider` 和 `IntlayerClientProvider` 实现。
+
+6. **SEO 友好**
+   - 内置的助手（`getMultilingualUrls`、`hrefLang` 属性等）使得生成符合 SEO 的页面和网站地图变得简单。
+
+---
+
+## 示例：Intlayer 的实际应用
+
+以下是一个 _非常_ 简明的代码片段，展示了如何在 Next.js 15 项目中利用 Intlayer。有关详细信息和代码示例，请 [查看完整的 Intlayer 指南](#)。
+
+<details>
+<summary>逐步示例</summary>
+
+1. **安装和配置**
+
+   ```bash
+   npm install intlayer next-intlayer
+   ```
+
+   ```ts
+   // intlayer.config.ts
+   import { Locales, type IntlayerConfig } from "intlayer";
+
+   const config: IntlayerConfig = {
+     internationalization: {
+       locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+       defaultLocale: Locales.ENGLISH,
+     },
+   };
+   export default config;
+   ```
+
+2. **使用插件**
+
+   ```ts
+   // next.config.mjs
+   import { withIntlayer } from "next-intlayer/server";
+
+   /** @type {import('next').NextConfig} */
+   const nextConfig = {};
+
+   export default withIntlayer(nextConfig);
+   ```
+
+3. **添加中间件**
+
+   ```ts
+   // src/middleware.ts
+   export { intlayerMiddleware as middleware } from "next-intlayer/middleware";
+
+   export const config = {
+     matcher:
+       "/((?!api|static|assets|robots|sitemap|sw|service-worker|manifest|.*\\..*|_next).*)",
+   };
+   ```
+
+4. **创建本地化布局**
+
+   ```tsx
+   // src/app/[locale]/layout.tsx
+   import { getHTMLTextDir } from "intlayer";
+   import { NextLayoutIntlayer } from "next-intlayer";
+
+   const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
+     const { locale } = params;
+     return (
+       <html lang={locale} dir={getHTMLTextDir(locale)}>
+         <body>{children}</body>
+       </html>
+     );
+   };
+
+   export { generateStaticParams } from "next-intlayer";
+   export default LocaleLayout;
+   ```
+
+5. **声明并使用内容**
+
+   ```tsx
+   // src/app/[locale]/page.content.ts
+   import { t } from "intlayer";
+
+   export default {
+     key: "page",
+     content: {
+       getStarted: {
+         main: t({
+           en: "Get started by editing",
+           fr: "Commencez par éditer",
+           es: "Comience por editar",
+         }),
+         pageLink: "src/app/page.tsx",
+       },
+     },
+   };
+   ```
+
+   ```tsx
+   // src/app/[locale]/page.tsx
+   import { IntlayerServerProvider } from "next-intlayer/server";
+   import { IntlayerClientProvider, useIntlayer } from "next-intlayer";
+
+   const PageContent = () => {
+     const { content } = useIntlayer("page");
+     return (
+       <>
+         <p>{content.getStarted.main}</p>
+         <code>{content.getStarted.pageLink}</code>
+       </>
+     );
+   };
+
+   export default function Page({ params }) {
+     return (
+       <IntlayerServerProvider locale={params.locale}>
+         <IntlayerClientProvider locale={params.locale}>
+           <PageContent />
+         </IntlayerClientProvider>
+       </IntlayerServerProvider>
+     );
+   }
+   ```
+
+   </details>
+
+---
+
+## 结论
+
+每个解决方案, **next-intl**、**next-i18next** 和 **Intlayer**, 在多语言 Next.js 项目中都证明了其有效性。然而，**Intlayer** 更进一步，通过：
+
+- **强烈鼓励组件级翻译架构**
+- 与 **Next.js 13+ 和服务器组件** 无缝集成
+- 提供 **强大的 TypeScript** 自动生成以确保更安全的代码
+- 在构建时处理 **缺失翻译**
+- 提供一个 **简化的单一配置** 方法和增强的路由与中间件
+
+如果你想要符合 **现代** i18n 特性的解决方案，并且针对 Next.js App Router 寻找 **完全类型化** 的体验，无需手动调整回退逻辑、路由重写或复杂的构建步骤，**Intlayer** 是一个引人注目的选择。它不仅缩短了你的设置时间，还确保了团队对翻译的更可维护、可扩展的方法。

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

@@ -0,0 +1,194 @@
+---
+createdAt: 2025-01-02
+updatedAt: 2025-06-29
+title: react-i18n vs react-intl vs Intlayer
+description: react-i18next和next-intl和Intlayer
+keywords:
+  - next-intl
+  - react-i18next
+  - Intlayer
+  - 国际化
+  - 文档
+  - Next.js
+  - JavaScript
+  - React
+slugs:
+  - blog
+  - react-i18next-vs-react-intl-vs-intlayer
+---
+
+# React-Intl 与 React-i18next 与 Intlayer | React 国际化 (i18n)
+
+以下是三个流行的 i18n（国际化）库在 React 中的简明比较：**React-Intl**、**React-i18next** 和 **Intlayer**。每个库都为在您的 React 应用中集成多语言支持提供了独特的功能和工作流程。阅读完本文后，您应该能够决定哪个解决方案最符合您的需求。
+
+---
+
+## 1. 介绍
+
+在 React 应用中实现国际化 (i18n) 有多种方式。这里介绍的三种库有不同的设计理念、功能集和社区支持：
+
+1. **React-Intl**
+2. **React-i18next**
+3. **Intlayer**
+
+下面，您将找到每个解决方案的概述，随后是功能比较、优缺点以及示例用例。
+
+---
+
+## 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 消息格式**，这可能比较冗长。
+- 处理动态或复杂翻译（不只是字符串）的方式不直观。
+
+---
+
+## 3. React-i18next
+
+### 概述
+
+[**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>` 组件来显示翻译。
+
+### 优点
+
+- 高度 **灵活** 和功能丰富。
+- 非常活跃的社区和大量插件生态系统。
+- 轻松 **动态加载** 翻译（例如，从服务器按需加载）。
+
+### 缺点
+
+- **配置可能比较冗长**，尤其是如果您有更高级的需求。
+- 如果您希望严格类型的翻译，可能需要额外的 TypeScript 设置。
+
+---
+
+## 4. Intlayer
+
+### 概述
+
+[**Intlayer**](https://github.com/aymericzip/intlayer) 是一个较新的开源 i18n 库，专注于 **组件级内容声明**、类型安全和 **动态路由**。它专为现代 React 工作流设计，支持 **Create React App** 和 **Vite** 设置。它还包括高级功能，如 **基于区域的路由** 和 **自动生成的 TypeScript 类型** 用于翻译。
+
+### 主要特性
+
+- **声明性内容文件**：每个组件或模块可以在专用的 `.content.tsx` 或 `.content.json` 文件中声明其翻译，将内容紧邻使用处。
+- **内置路由和中间件**：可选模块用于本地化路由（例如，`/zh/about`、`/fr/about`）和用于检测用户区域的服务器中间件。
+- **自动生成的 TypeScript 类型**：通过自动完成功能和编译时错误检测，确保类型安全。
+- **动态和丰富的翻译**：可以在翻译中包含 JSX/TSX 以应对更复杂的用例（例如，链接、加粗文本、翻译中的图标）。
+
+### 典型工作流程
+
+1. **安装 `intlayer` 和 `react-intlayer`。**
+2. **创建 `intlayer.config.ts`** 定义可用的区域和默认区域。
+3. **使用 Intlayer CLI** 或插件来 **转译** 内容声明。
+4. **在 `<IntlayerProvider>` 中包装您的应用** 并使用 `useIntlayer("keyName")` 获取内容。
+
+### 优点
+
+- **TypeScript 友好**，具有内置类型生成和错误检查。
+- 可能 **丰富的内容**（例如，将 React 节点传递作为翻译）。
+- **开箱即用的本地化路由**。
+- 与流行的构建工具（CRA、Vite）集成，易于设置。
+
+### 缺点
+
+- 与 React-Intl 或 React-i18next 相比仍然 **相对较新**。
+- 更加注重“组件级内容声明”的方法, , 可能与典型的 .json 目录有一定差异。
+- 与更成熟的库相比，生态系统和社区较小。
+
+---
+
+## 5. 功能比较
+
+| **特性**            | **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. 何时选择每种
+
+1. **React-Intl**
+
+   - 您需要 **强大的格式化** 用于日期/时间/数字，和强大的 **ICU 消息语法**。
+   - 您更倾向于使用“**基于标准**”的方法进行翻译。
+   - 您不需要本地化路由或强类型的翻译键。
+
+2. **React-i18next**
+
+   - 您需要一个 **灵活、成熟** 的解决方案，具有 **动态** 和 **按需** 加载翻译的功能。
+   - 您希望使用 **基于插件** 的语言检测（例如，从 URL、Cookies、本地存储等）或高级缓存。
+   - 您需要最大的生态系统，具有针对各种框架（如 Next.js、React Native 等）的许多现有集成。
+
+3. **Intlayer**
+   - 您希望 **强类型** 和 **自动生成类型** 的集成，确保您很少遗漏翻译键。
+   - 您更喜欢将 **内容声明** 紧邻组件，可能包含 React 节点或在翻译中使用高级逻辑。
+   - 您需要 **内置本地化路由** 或想要轻松将其纳入您的 SSR 或 Vite 设置。
+   - 您希望采用现代方法或简单地希望拥有一个覆盖 **内容管理**（i18n）和 **路由** 的类型安全的库。
+
+---
+
+## 7. 结论
+
+每个库都为国际化 React 应用程序提供了强大的解决方案：
+
+- **React-Intl** 在消息格式化方面表现优异，是专注于 ICU 消息语法的企业解决方案的热门选择。
+- **React-i18next** 为高级或动态 i18n 需求提供了高度灵活和插件驱动的环境。
+- **Intlayer** 提供了 **现代、强类型** 的方法，结合了内容声明、高级的本地化路由和基于插件的（CRA，Vite）集成。
+
+您的选择在很大程度上取决于项目需求、期望的开发人员体验（DX）以及类型翻译或高级路由的重要程度。如果您重视内置的本地化路由和 TypeScript 集成，**Intlayer** 可能最具吸引力。如果您想要一个经过考验的、生态系统丰富的解决方案，**React-i18next** 是一个不错的选择。对于直接的 ICU 基于格式化的需求，**React-Intl** 是一个可靠的选择。
+
+---
+
+### 进一步阅读
+
+- [React-Intl 文档](https://formatjs.io/docs/react-intl/)
+- [React-i18next 文档](https://react.i18next.com/)
+- [Intlayer + CRA 开始指南](#)（来自您的文档）
+- [Intlayer + Vite 和 React 开始指南](#)（来自您的文档）
+
+随意混合和匹配这些方法以满足您的需求, , 没有“放之四海而皆准”的解决方案，每个库都在不断发展，以应对 React 生态系统中的新用例。

package/blog/zh/what_is_internationalization.md

@@ -0,0 +1,165 @@
+---
+createdAt: 2025-01-16
+updatedAt: 2025-06-29
+title: 什么是国际化？定义和挑战
+description: 了解为什么对你的网站进行国际化是必要的。了解如何加速搜索引擎，提高用户体验，并扩大你的全球影响力。
+keywords:
+  - i18n
+  - 多语言
+  - SEO
+  - 国際化
+  - 博客
+  - Next.js
+  - JavaScript
+  - React
+slugs:
+  - blog
+  - what-is-internationalization
+---
+
+# 什么是国际化 (i18n)? 定义与挑战
+
+![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
+
+## 理解国际化 (i18n)
+
+**国际化**，通常缩写为 **i18n**，是设计和准备一个应用程序以支持多种语言、文化和地区惯例的过程**而不**对代码库进行重大更改。i18n这个名称源于“国际化”这个词中**i**和**n**之间有18个字母这一事实。
+
+## 为什么国际化很重要
+
+### SEO
+
+国际化在增强网站搜索引擎优化（SEO）方面发挥着至关重要的作用。搜索引擎如Google和Bing分析您内容的语言和文化相关性，以确定其排名。通过调整您的网站以支持多种语言和地区格式，您可以显著提高其在搜索结果中的可见性。这不仅吸引了更广泛的受众，还帮助您的网站获得更高的排名，因为搜索引擎认识到为迎合多样化用户群体所做的努力。
+
+### 全球覆盖
+
+国际化所提供的全球覆盖同样重要。当您消除语言障碍并设计应用程序以支持各种文化规范时，您为来自世界各地的数百万潜在用户打开了大门。提供本地化内容和用户界面将您的产品与可能仅提供有限语言支持的竞争对手区分开。这种包容性的方法确保用户无论身处何地都能感到被认可和重视，最终扩大您产品的市场并提高其在全球市场中的竞争力。
+
+### 用户体验
+
+国际化的另一个显著好处是增强用户体验。用户往往对以其母语进行交流并尊重当地惯例（例如日期格式、货币和计量单位）的软件感到更舒适和与之相连。这种个性化的体验是建立信任和满意度的关键，促进长期用户留存。当用户能够无缝地导航和理解一个应用程序时，他们更可能深度参与，从而为积极的评价、推荐和持续增长铺平道路。
+
+## 国际化 (i18n) 与本地化 (l10n)
+
+**国际化 (i18n)** 是设计您的产品，以便可以轻松支持多种语言和地区差异的过程。例如，如果您构建一个考虑到国际化的网站，您将确保文本字段支持各种字符集，日期遵循不同的本地格式，并在翻译成其他语言时，布局调整以适应文本扩展。
+
+**本地化 (l10n)** 是国际化之后进行的工作。它涉及翻译内容并调整文化细节以满足特定受众的需求。例如，一旦网站经过国际化，您可能会通过翻译所有文本、将日期格式更改为日/月/年，甚至调整图像或图标来更好地符合法国文化规范而将其本地化。
+
+总之，国际化为您的产品的全球使用做好准备，而本地化则为特定市场进行调整。
+
+## 网站中应该国际化的内容是什么？
+
+1. **文本内容：** 所有书面元素，如标题、正文和按钮都需要翻译。例如，像“欢迎访问我们的网站”这样的标题应该变成“Bienvenido a nuestro sitio web”以供西班牙语受众使用。
+
+2. **错误消息：** 清晰简明的错误通知至关重要。如果表单错误显示“无效的电子邮件地址”，则应在法语中呈现为“Adresse e-mail non valide”，以帮助用户理解问题。
+
+3. **电子邮件和通知：** 自动化通讯，包括密码重置或订单确认，必须进行本地化。例如，订单确认邮件可能会在英语中以“尊敬的客户”来问候用户，而在法语中则为“Cher(e) client(e)”。
+
+4. **可访问性标签：** 图像的标签和替代文本需要翻译，以便辅助技术能够正常工作。例如，具有替代文本“微笑的孩子在玩”的图像在法语中应改为“Enfant souriant qui joue”。
+
+5. **编号：** 不同地区对数字的格式不同。对于讲英语的地区，“1,000.50”适用，但许多欧洲格式需要“1.000,50”，因此地方适应性很重要。
+
+6. **货币：** 按照本地的符号和格式显示价格。例如，在美国标示为“$99.99”的商品，在面向欧洲客户时应转为“€97.10”。
+
+7. **测量单位：** 温度、距离和体积等单位应根据当地偏好显示。例如，天气应用可能会为美国用户显示“68°F”，但对其他用户则显示“20°C”。
+
+8. **文本方向：** 应根据语言的不同方向调整阅读顺序和布局。用英语（从左到右）的网站在阿拉伯语本地化时必须切换对齐方式，阿拉伯语从右到左阅读。
+
+9. **日期和时间：** 格式在不同地区之间有所不同。在美国显示为“12/25/2025 at 3:00 PM”的事件，在其他地方可能需要作为“25/12/2025 at 15:00”来显示，以避免混淆。
+
+10. **时区：** 为本地时区进行调整，确保时间敏感内容（例如事件时间表、交货时间或客户支持时间）准确显示。例如，计划为“3:00 PM EST”的在线网络研讨会应转换为相应的本地时间，例如对英国用户来说为“8:00 PM GMT”。
+
+这个简要概述涵盖了应该国际化的主要元素，确保内容易于访问、文化适宜，并易于全球受众理解。
+
+## 常见的国际化挑战
+
+![i18n pain illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/pain_i18n.webp)
+
+- **可维护性**  
+  每个网站更新都必须在每种语言中反映，要求高效的工作流程和仔细的协调，以确保所有版本的一致性。
+
+- **字符串连接**  
+  避免构造类似于“`Hello, " + username + "!"`”的消息，因为单词顺序在不同语言中可能不同；相反，应该使用占位符，例如`Hello, {username}!`来适应语言变化。
+
+- **复数形式**  
+  不同的语言具有不同的复数规则，有时有多种形式。使用像ICU MessageFormat这样的库可以简化处理这些复数复杂性。
+
+- **用户界面和文本长度**  
+  某些语言（例如德语）文字往往比英语长。如果设计不够灵活，这可能会破坏布局，因此响应式设计是关键。
+
+- **字符编码**  
+  使用适当的字符编码（如UTF-8）对于正确显示多样化的字母表和符号至关重要，以防止文本误解或乱码。
+
+- **硬编码布局**  
+  固定大小的用户界面组件可能无法很好地适应较长的翻译，导致文本溢出。灵活的响应式布局有助于减轻此问题。
+
+- **动态语言切换**  
+  用户希望在不重新启动应用程序或重新身份验证的情况下切换语言。该功能要求在架构中进行无缝、精心规划的实现。
+
+- **语言方向支持**  
+  忽视从右到左（RTL）语言的支持可能在后期产生重大重新设计挑战。最好从一开始就为RTL兼容性做好规划。
+
+- **文化敏感性**  
+  图标、颜色和符号在不同文化之间可能具有不同的含义。重要的是调整视觉和文本内容以尊重当地文化细微差别。
+
+---
+
+## 实施国际化的最佳实践
+
+- **提前规划**  
+  在项目的最开始就整合国际化。提前解决国际化的问题成本较低、简单，确保从一开始就能提供更顺畅的开发过程。
+
+- **自动化翻译管理**  
+  利用人工智能驱动的翻译服务，例如Intlayer提供的服务，以高效管理您的翻译。通过自动化，当您发布新文章时，所有翻译会自动生成，从而节省时间并减少人工错误。
+
+- **使用可视化编辑器**  
+  实施可视化编辑器以帮助翻译者以其实际用户界面上下文查看内容。像Intlayer的可视化编辑器这样的工具最小化错误和混淆，确保翻译准确并反映最终设计。
+
+- **翻译重用性**  
+  组织翻译文件，使其能够在多个网站或应用程序中重用。例如，如果您有一个多语言的页脚或页头，设置专用翻译文件，以便通用元素可以轻松应用于所有项目。
+
+---
+
+## 本地内容声明与CMS内容外部化
+
+在创建网站时，像WordPress、Wix或Drupal这样的**内容管理系统（CMS）通常提供更好的可维护性**。尤其对于博客或落地页，因为它们集成了国际化功能。
+
+然而，对于具有复杂功能或业务逻辑的应用程序，**CMS可能显得太过不灵活，您可能需要考虑国际化库**。
+
+**许多国际化库的挑战在于，它们通常要求将翻译硬编码到代码库中**。这意味着，如果内容管理者想要更新翻译，他们被迫修改代码并重建应用程序。为了解决这个问题，一些工具作为“基于Git的CMS”或“国际化CMS”出现，以协助内容管理者。但是，即使**这些解决方案通常在内容更改时也需要进行代码库更新和重建**。
+
+鉴于这些挑战，通常会选择无头CMS来外部化内容并简化翻译管理。然而，在使用CMS进行国际化时存在一些显著的缺点：
+
+- **并非所有CMS提供国际化功能：** 一些流行的CMS平台缺乏强大的国际化能力，迫使您寻找额外的插件或解决方案。
+- **重复配置：** 管理翻译往往涉及配置CMS和应用程序代码，导致重复工作和潜在的不一致性。
+- **难以维护：** 随着翻译散落在CMS和代码之间，维护一个一致和无错误的系统可能变得具有挑战性。
+- **许可费用：** 高级CMS平台或额外的国际化工具可能会引入额外的许可费用，这可能对于每个项目来说都不可行。
+
+选择合适的工具以满足您的需求并从一开始规划您的国际化策略至关重要。**Intlayer通过结合区域内容声明与紧密集成的无头CMS提供了一个引人注目的解决方案，提供了两者的最佳组合。**
+
+---
+
+### 按技术查看国际化库和工具列表
+
+如果您希望查看按技术划分的国际化库和工具列表，请查看以下资源：
+
+### 内容管理系统 (CMS)
+
+- WordPress: [查看国际化库和工具列表](https://github.com/aymericzip/intlayer/blob/main/docs/blog/zh/list_i18n_technologies/CMS/wordpress.md)
+- Drupal: [查看国际化库和工具列表](https://github.com/aymericzip/intlayer/blob/main/docs/blog/zh/list_i18n_technologies/CMS/drupal.md)
+
+### JavaScript 应用程序 (前端)
+
+- React: [查看国际化库和工具列表](https://github.com/aymericzip/intlayer/blob/main/docs/blog/zh/list_i18n_technologies/frameworks/react.md)
+- Angular: [查看国际化库和工具列表](https://github.com/aymericzip/intlayer/blob/main/docs/blog/zh/list_i18n_technologies/frameworks/angular.md)
+- Vue: [查看国际化库和工具列表](https://github.com/aymericzip/intlayer/blob/main/docs/blog/zh/list_i18n_technologies/frameworks/vue.md)
+- Svelte: [查看国际化库和工具列表](https://github.com/aymericzip/intlayer/blob/main/docs/blog/zh/list_i18n_technologies/frameworks/svelte.md)
+- React Native: [查看国际化库和工具列表](https://github.com/aymericzip/intlayer/blob/main/docs/blog/zh/list_i18n_technologies/frameworks/react-native.md)
+
+---
+
+## 结论
+
+国际化 (i18n) 不仅仅是一个技术任务；它是一个**战略投资**，使您的软件能够“说”用户的语言, , 字面上。通过抽象掉特定于区域的元素，适应语言和文化的变化，并为未来的扩展做好规划，您能够让您的产品在全球市场中蓬勃发展。
+
+无论您是在构建移动应用程序、安全即服务平台，还是企业工具，**i18n确保您的产品能够适应并吸引来自全球各地的用户**，而无需不断重写代码。通过利用最佳实践、强大的框架和持续本地化策略，开发人员和产品团队能够提供**真正全球化**的软件体验。