# General Translation Knowledge Base: 国际化与本地化（i18n 与 l10n）
URL: https://generaltranslation.com/zh/kb/internationalization-vs-localization.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 国际化（i18n）是让一款产品支持多种区域设置的代码与设计工作，例如使用 Intl 格式化日期、支持从右到左的文本等。本地化（l10n）则针对某一区域设置对产品进行适配，除翻译外，还涵盖货币、日期格式、计量单位、语气和法律细节等方面。
Category: 国际化
Last updated: 2026-10-20
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-20

国际化让产品具备适配能力，本地化则将这种能力落实到特定市场。在同一次发布中，开发者、设计师、译者和产品团队往往会同时参与这两项工作。翻译只是本地化的一部分，此外还涉及格式、布局和当地惯例。

## 什么是国际化 (i18n) ，什么是本地化 (l10n) ？

* **国际化 (i18n) **是指让你的代码库做好支持多个区域设置的准备 (处理日期、复数形式、货币和布局) 。W3C 将其定义为一种设计与开发方式，使产品能够面向文化、地区或语言各异的受众“轻松实现本地化”。在实践中，这意味着把面向用户的文本从硬编码的字符串中抽离出来，按区域设置格式化各类值，支持从右到左的文本，并全面采用 Unicode。 (参见 W3C 的 [Localization vs. Internationalization](https://www.w3.org/International/questions/qa-i18n)。) 
* **翻译**是将内容从一种语言转换为另一种语言。
* **本地化 (l10n) **是指针对另一个区域设置调整产品的更广泛过程。除翻译外，W3C 还列出了以下方面：数字、日期和时间格式，货币，排序，符号，图标和颜色，地址和电话格式，法律要求，以及可能被某种文化误读的引用内容。

区域设置是指一种语言或方言及其相关惯例，用 `en-US` 或 `de-DE` 这样的代码表示。

## i18n、l10n 和 g11n 的由来

它们都是数字缩写词 (numeronym) ：保留首字母和末字母，中间用两者之间的字母数代替。"Internationalization" (国际化) 的 i 和 n 之间有 18 个字母，因此写作 i18n；"localization" (本地化) 的 l 和 n 之间有 10 个字母，因此写作 l10n。"Globalization" (全球化) 同理写作 g11n。

三者中，"全球化"一词的用法最不统一。W3C 指出，有些人把它当作国际化的同义词；而 [Microsoft 的全球化术语表](https://learn.microsoft.com/en-us/globalization/reference/glossary)则用全球化指让应用程序在所有区域设置下都能正常运行，用国际化指将软件推向全球市场的整个过程。因此，看到 g11n 时，请先弄清作者指的是哪种含义。

## 本地化和翻译是一回事吗？

翻译只是本地化中的一个环节。[Microsoft 的本地化指南](https://learn.microsoft.com/en-us/globalization/localization/localization)举过这样一个例子：一句介绍某天火车票价格的话，仅仅译成德语是不够的，因为价格应以欧元标示，日期也应采用“日-月-年”的格式。该指南还指出，从美国英语本地化为英国英语时，可能完全不涉及翻译，只需调整拼写、用词和格式。

## 各举一例

**国际化是一项代码变更。** 下面是一个订单摘要在国际化前后的对比：

```js title="order-summary.mjs"
const date = new Date(Date.UTC(2026, 6, 30));
const total = 1234.5;

// 改造前：英文文本、美式日期顺序和美元符号都硬编码在代码里
console.log(
  `Order placed on ${date.getUTCMonth() + 1}/${date.getUTCDate()}/${date.getUTCFullYear()}. Total: $${total.toFixed(2)}`
);

// 改造后：文本取自各区域设置对应的消息，值由 Intl 负责格式化
const messages = {
  'en-US': 'Order placed on {date}. Total: {total}',
  'de-DE': 'Bestellt am {date}. Gesamt: {total}',
};

function orderSummary(locale, currency) {
  const values = {
    date: new Intl.DateTimeFormat(locale, { timeZone: 'UTC' }).format(date),
    total: new Intl.NumberFormat(locale, { style: 'currency', currency }).format(total),
  };
  return messages[locale].replace(/\{(\w+)\}/g, (_, key) => values[key]);
}

console.log(orderSummary('en-US', 'USD'));
console.log(orderSummary('de-DE', 'EUR'));
```

使用 Node.js 24 运行：

```text title="Output"
Order placed on 7/30/2026. Total: $1234.50
Order placed on 7/30/2026. Total: $1,234.50
Bestellt am 30.7.2026. Gesamt: 1.234,50 €
```

这段格式化代码适用于任一区域设置；德语消息则需另行提供。`Intl.NumberFormat` 会按所选货币格式化金额，但不会将美元换算为欧元。此处使用相同的金额数值仅作演示，并非按汇率换算。

**本地化的结果是一个经过适配的页面。** 将美国产品页面本地化为德国版本，需要改动的远不止文字：

| 元素   | en-US 页面                          | de-DE 页面                                |
| ---- | --------------------------------- | --------------------------------------- |
| 价格   | $49.00                            | 49,00 €                                 |
| 日期   | July 30, 2026                     | 30. Juli 2026                           |
| 客服时间 | 3:00 PM                           | 15:00                                   |
| 重量   | 2.2 lb                            | 1 kg                                    |
| 语气   | "Start your free trial" | 使用正式的 "Sie" 代替 "du" |

代码完成国际化后，前三行的格式即可由 `Intl` 自动处理。而计量单位、语气以及价格本身是否需要调整，则属于本地化决策，需要有人针对每个市场逐一做出判断。

## 谁负责 i18n 和 l10n？

* **开发者**负责国际化：包裹或提取字符串，添加符合区域设置的格式化和复数处理，配置按区域设置划分的路由，并针对较长文本和从右到左的文字体系调整布局。
* **译者、审校人员和本地化经理**负责本地化：翻译内容，保持术语一致，调整语气和示例，并在实际运行的产品中逐一检查各语言版本。
* **产品和法律团队**决定各市场需要调整的内容，例如货币、支付方式和必要的声明。

## 概览

|      | 国际化 (i18n)                            | 本地化 (l10n)               |
| ---- | ------------------------------------- | ------------------------ |
| 变更内容 | 代码和设计                                 | 特定区域设置的内容和惯例             |
| 时机   | 在支持第一种额外语言之前完成；随功能迭代持续维护              | 每个区域设置都需进行，且每次内容变更后需重新进行 |
| 负责人  | 开发者                                   | 译员、审校人员、本地化经理            |
| 产出   | 一套支持所有目标语言区域的代码库                      | 针对特定区域设置完成适配和审校的产品       |
| 示例   | 将 `$${total}` 替换为 `Intl.NumberFormat` | 以正式语体将结账流程翻译成德语          |

## 常见错误

* **把本地化等同于翻译。** 页面即使已经翻译，如果仍使用美式日期、美元价格，以及在其他文化中无法传达原意的习语，读起来依然让人觉得陌生。W3C 指出，本地化"往往是一个比翻译界面和文档复杂得多的问题"。
* **到后期才补做 i18n。** 硬编码的字符串、拼接而成的句子以及固定宽度的按钮，都会让大型代码库更难本地化。即使翻译后的标签含义准确，也可能撑破布局。[伪本地化](/kb/pseudo-localization)可以在翻译开始之前暴露出其中的许多问题。
* **自行编写复数逻辑。** `count === 1 ? 'item' : 'items'` 适用于英语，因为英语只有 2 种复数形式，但阿拉伯语有 6 种。 (参见[如何在 React 中处理复数形式？](/kb/how-to-handle-plurals-in-react)) 
* **脱离上下文进行翻译。** 译者或模型如果只看到孤零零的 "Save"，就无法判断它指的是保存到磁盘，还是省钱。

上线之前，可参考[多语言应用上线检查清单](/kb/multilingual-app-launch-checklist)，了解在每个区域设置中需要测试哪些内容。

## General Translation 如何划分 i18n 与 l10n

在国际化方面，General Translation 的开源库 (如 `gt-next`、`gt-react`、`gt-vue` 和 `gt-node`) 负责代码层面的工作。[`<T>`](/docs/react/reference/components/t) 组件直接在 JSX 所在位置将其包裹，因此无需把字符串提取到键文件中；[`<DateTime>`](/docs/react/reference/components/datetime)、[`<Currency>`](/docs/react/reference/components/currency) 和 [`<Plural>`](/docs/react/reference/components/plural) 则会根据区域设置格式化相应的值：

```jsx title="OrderSummary.jsx"
import { T, DateTime, Currency } from 'gt-next';

export function OrderSummary({ date, total, currency }) {
  return (
    <T>
      Order placed on <DateTime>{date}</DateTime>. Total:{' '}
      <Currency currency={currency}>{total}</Currency>
    </T>
  );
}
```

在本地化方面，只需在 `gt.config.json` 中添加一个区域设置，然后运行 [`npx gt translate`](/docs/cli/reference/commands/translate) 即可生成对应的译文。翻译平台会将组件、变量和开发者备注用作上下文；[上下文组](/docs/platform/dashboard/guides/defining-context-for-translations)可在多个项目间共享术语和风格规则；你的团队则可以在仪表板中[审校译文](/docs/platform/dashboard/guides/reviewing-translations)。如需检查公开网站，可以使用免费的 [Report Card](https://generaltranslation.com/report-card) 为其本地化质量评分，评估项包括 `hreflang` 标签、语言声明、区域设置路由、已翻译的元数据以及文本方向。

## 要点总结

* 国际化 (i18n) 为多个区域设置提供统一的基础支持。功能迭代时需要持续维护这种支持；国际化本身并不产出译文。
* 本地化 (l10n) 针对每个区域设置对产品进行适配：除翻译外，还涵盖货币、日期和数字格式、计量单位、语气，以及法律和文化方面的细节。
* i18n、l10n 和 g11n 中的数字表示首尾字母之间的字母个数；g11n 的具体含义因出处而异。

## Related questions

- [多语言应用本地化测试清单](https://generaltranslation.com/zh/kb/multilingual-app-launch-checklist.mdx): 在生产环境构建中，于每个支持的区域设置下测试九项内容：包括错误状态和邮件在内的完整流程、语言切换、复数形式、货币与时区、文本扩展、从右到左布局、无障碍访问、译文交付，以及可抓取的语言 URL。为每项检查设定明确的通过标准。
- [应该自建 i18n，还是使用 General Translation？](https://generaltranslation.com/zh/kb/general-translation-vs-in-house-i18n.mdx): 手写的 i18n（每种语言一个字典，外加一个简单的 t() 辅助函数）足以应对一两种语言、少量文案的场景。随着应用规模扩大，你会发现自己在重新实现复数规则、后备内容和文件同步，而且译文仍然得自己产出。General Translation 的开源库负责渲染，General Translation 则根据你的代码生成并更新译文。
- [什么是伪本地化？](https://generaltranslation.com/zh/kb/pseudo-localization.mdx): 伪本地化是一种测试方法：将源文本替换为改写后的版本——加上重音符号、长度扩充约 40%，并用方括号包裹——这样在还没有任何翻译之前，硬编码字符串、截断、字体显示异常和句子拼接等问题就会暴露出来。Android 为此内置了 en-XA 和 ar-XB 两个伪区域设置。
- [什么是翻译管理系统（TMS）？](https://generaltranslation.com/zh/kb/what-is-a-translation-management-system.mdx): 翻译管理系统（TMS）是一种用于存储源内容及其译文、并运行翻译工作流的软件，涵盖翻译记忆库、词汇表、审校、机器翻译和集成等功能。其翻译记忆库通过精确匹配或模糊匹配复用以往的译文。常见的 TMS 有 Crowdin、Lokalise、Phrase、Smartling 和 Transifex。
- [General Translation 与 i18next、react-intl 和 next-intl 对比：应该选择哪个国际化库？](https://generaltranslation.com/zh/kb/general-translation-vs-i18n-libraries.mdx): i18next、react-intl 和 next-intl 等开源库本身并不翻译任何内容。它们只负责显示你在各语言目录文件中提供的译文，这些译文由你、你的译者或其他服务编写。General Translation 的库同样开源，承担同样的工作，此外 General Translation 还会以你的代码为上下文完成翻译。

## Previous and next questions

- Previous question: [什么是翻译管理系统（TMS）？](https://generaltranslation.com/zh/kb/what-is-a-translation-management-system.mdx)
- Next question: [多语言 SEO：子目录、子域名与 ccTLD 对比](https://generaltranslation.com/zh/kb/multilingual-url-structure.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.