Which i18n library should I use for React, Vue, Angular, or Next.js?

The right internationalization library depends on your framework: react-i18next for React, vue-i18n for Vue, Angular's built-in @angular/localize (or ngx-translate for runtime switching) for Angular, and next-intl for Next.js App Router projects. None of these libraries replace a translation management system.

对于 React、Vue、Angular 或 Next.js 来说，哪个 i18n 库最好？

正确的国际化 (i18n) 库取决于你的框架：react-i18next 是 React 的标准选择，vue-i18n 是 Vue 的标准选择，Angular 内置的 @angular/localize（或用于运行时语言切换的 ngx-translate）是 Angular 的标准选择，而 next-intl 是 Next.js App Router 项目的标准选择。每个库都会在其框架的组件模型中渲染特定于语言环境的字符串，但它们都不能替代翻译管理系统 (TMS)——Smartling 的 API、SDK 和 CLI 会在您的代码库和翻译人员之间移动底层翻译文件。

为什么不同框架的 i18n 库选择差异如此之大

国际化 (i18n) 库管理前端框架在运行时如何加载、渲染和更新翻译后的字符串——它本身并不管理翻译工作。由于以下五个相互重叠的原因，在 React、Vue、Angular 和 Next.js 之间转换的开发者会遇到一个碎片化的局面。

React 生态系统运行在两种相互竞争的标准之上。react-i18next（基于钩子，构建于与框架无关的 i18next 核心之上）和 react-intl（基于组件，构建于 FormatJS/ICU MessageFormat 标准之上）都得到了广泛的采用，但两者都没有得到 React 官方的认可，因此团队通常会继承之前工程师选择的那个。
Angular 的 i18n 实现方式与其他三个框架不同。Angular 自带的 @angular/localize 是一个基于编译器的包，内置于框架中，在构建时而不是运行时提取字符串，这在生产环境中速度更快，但这意味着每个语言环境都需要自己的编译版本。流行的第三方替代方案 @ngx-translate/core 用运行时语言切换代替了构建时步骤，而无需完全重新构建。
Next.js 在发布 App Router 时做出了不同的决定。next-i18next 是基于 i18next 构建的，是 Next.js 的默认主题。旧版 Pages Router。next-intl 是专为 App Router 和 React Server Components 构建的，因此已成为新的 Next.js 项目中更常见的推荐选择。
不同图书馆的复数规则并不完全相同。i18next 使用自己的复数键后缀约定（例如 visits_one 和 visits_other），而基于 FormatJS 的库（如 react-intl 和 next-intl）使用 ICU MessageFormat 标准，该标准将复数逻辑直接嵌入字符串中。这两种格式不经过转换步骤是无法互换的。
库的选择与翻译管理的选择容易混淆。react-i18next、vue-i18n、@angular/localize、ngx-translate 和 next-intl 都会渲染应用程序已有的当前语言环境的字符串——它们都不会将字符串移交给翻译器、跟踪翻译状态或管理词汇表。那是一个单独的层，通常是翻译管理系统（TMS）。

i18n 库概览，逐个框架分析

React： react-i18next 是大多数团队的标准选择——它是在 i18next 核心之上基于 hook 的 (useTranslation) 绑定，截至 2026 年 8 月下旬，每周 npm 下载量约为 1590 万次。react-intl 是 FormatJS 生态系统的一部分，是希望从一开始就内置 ICU MessageFormat 复数形式的团队的主要选择。
Vue： vue-i18n 是 Vue 官方维护的国际化插件，也是 Vue 2 和 Vue 3 项目的默认选择——不像 React 和 Angular 那样有被广泛采用的第三方替代方案。
Angular： @angular/localize 是 Angular 自己的基于编译器的 i18n 包，它会在构建时将标记的字符串提取到每个语言环境的单独编译包中。对于需要在运行时切换语言而无需为每个语言环境重新部署单独构建的团队来说，@ngx-translate/core 是最常用的第三方替代方案。
Next.js： next-intl 是 App Router 项目的当前默认推荐版本，旨在支持 React 服务器组件和静态渲染。next-i18next 是 i18next 的 Next.js 封装，在仍然使用 Pages Router 或已经投入 i18next 生态系统的代码库中仍然很常见。

i18n 库的采用率（按每周 npm 下载量计算）

2026 年 8 月当周的 npm 每周下载量统计（具体采样周因 npm 注册表数据的可用性而异）：

框架	图书馆	每周 npm 下载量	角色
跨框架核心	i18next	约2170万	react-i18next 和 next-i18next 所基于的框架无关核心。
反应	react-i18next	约1590万	基于 Hook 的 React i18next 绑定
Next.js（应用路由）	下一个国际	约390万	专为 App Router 和 React 服务器组件而构建
Vue	vue-i18n	约320万	官方 Vue.js 国际化插件
角	@angular/localize	约147万	Angular 内置的、基于编译器的 i18n 包
角	@ngx-translate/core	约117万	第三方运行时语言切换库
Next.js（页面路由）	下一个-i18下一个	~544K	旧版 Pages Router 的 i18next 封装

来源：npm registry download-count API，查询于 2026 年 8 月。

如何为您的技术栈选择 i18n 库

正确的选择与其说是取决于哪个库在理论上“最好”，不如说是取决于它与你的框架的渲染模型和翻译流程的契合程度。

请先确认您的框架和渲染模型。一个基于 Next.js 的 React 服务器组件应用程序App Router (next-intl) 与客户端渲染的 Vue 单页应用程序 (vue-i18n) 或进行构建时编译的 Angular 应用程序 (@angular/localize) 有着不同的限制——渲染模型缩小了实际的选择范围，功能比较才变得重要。
尽早确定信息格式。在编写翻译键之前，选择 i18next 的复数键约定还是 ICU MessageFormat 标准（react-intl、next-intl 和 FormatJS 等通常使用的标准）可以避免以后在项目进行过程中进行痛苦的迁移。
要考虑生态系统的成熟度，而不仅仅是功能列表。每周 npm 下载量、GitHub 问题响应时间和发布节奏是衡量社区支持力度和生产环境中出现问题时可获得多少现有解决方案的实际指标。
检查库所需的文件格式与你的翻译流程能够生成的文件格式是否一致。大多数此类库都使用扁平或嵌套的 JSON 资源文件；在决定使用之前，请确认您的翻译管理系统或流程可以生成您选择的库所需的复数或 ICU 格式的 JSON。
规划翻译后的文件如何在代码库和翻译人员之间传输，作为 CI/CD 的一部分，而不是一次性的手动导出。存储库连接器、构建步骤脚本或直接 API 调用是三种常见模式，尽早选择其中一种可以避免默认情况下养成手动整理文件的习惯。

这种方法适合以下类型的团队……

正在使用 React、Vue 或 Angular 构建单页应用程序或基于组件的前端，并且需要一种运行时方法来渲染特定于语言环境的字符串。
已经选定了一个框架，需要选择与之匹配的、符合框架惯用的 i18n 库，而不是构建自定义字符串加载逻辑。
计划支持不止一种或两种语言，因为硬编码字符串或临时查找对象无法满足扩展需求。
需要使用库而不是自定义代码来处理复数形式、插值以及本地化数字和日期格式。
已经拥有或正在构建一个翻译流程，可以持续地为每个语言环境提供 JSON 资源文件。

但这或许并非首要任务。

对于处于非常早期阶段、正在验证单一市场 MVP 的产品而言，在产品与市场契合之前投资完整的 i18n 库会增加工程开销，但短期内不会有任何回报。
对于静态营销网站或内容驱动型页面，基于代理或 CMS 级别的翻译方法可能比将 JavaScript i18n 库集成到应用程序代码中更合适。
对于尚未将面向用户的字符串从其代码库中外部化的团队来说，在完成提取工作之前，i18n 库的选择是次要的。

评估清单：选择 i18n 库之前需要问的问题

该库是否支持您框架当前的渲染模型？
确认与 React 服务器组件、Vue 3 的组合 API、Angular 的构建系统或 Next.js 的兼容性具体来说，是指 App Router，而不仅仅是框架本身。

库的复数形式和消息格式约定是否与您的翻译流程能够生成的格式相符？
i18next 风格的复数键和 ICU MessageFormat 不能直接互换，需要进行转换步骤，因此请确认您的翻译管理系统或流程输出的是哪一个。

图书馆的维护和社区活动有多活跃？
查看最近的发布日期、未解决的问题数量和每周 npm 下载量，以此作为判断遇到特殊情况时能获得多少支持的参考指标。

翻译后的文件将如何在您的代码库和翻译人员之间传输？
在项目进行到几百个字符串之前，确定这种交接是通过存储库连接器、直接 API 或 SDK 调用，还是手动导出来实现。

该库的打包大小和加载策略是否符合您的性能预算？
比较同步加载和延迟加载的翻译包，尤其对于同时支持多种语言环境的应用程序而言。

Smartling 如何与您的 i18n 库配合使用

react-i18next、vue-i18n、@angular/localize、ngx-translate 和 next-intl 都解决了同一个具体问题：在应用程序中为当前活动语言环境渲染正确的字符串。它们都不负责翻译任何内容，也不跟踪哪些字符串仍需翻译，更不负责管理跨语言的词汇表和样式指南——这些功能属于像 Smartling 这样的翻译管理系统 (TMS)。

Smartling 直接支持在 JSON、Java、Android XML 和 YAML 文件中解析 ICU MessageFormat，涵盖了 react-intl、next-intl 和其他基于 FormatJS 的库使用的复数和插值语法。对于基于 i18next 的库（例如 react-i18next 和 next-i18next），Smartling 不会直接解析 i18next 的原生复数键格式，但 Smartling 的 ICU MessageFormat 扩展可以弥补这一差距，因此团队在两种约定之间转换时不必手动转换复数字符串。

为了在代码库和翻译工作流程之间移动文件，Smartling 的 Repository Connector 以 Pull Request、Single Branch 或 On-Demand 模式与 GitHub 和 GitLab 集成：它可以检测新的或已更改的资源文件，将其上传以进行翻译，并将完成的翻译作为 pull request 返回，该 pull request 会像任何其他代码更改一样经过相同的代码审查。构建自定义管道的团队可以直接使用 Smartling 的 REST API，以及其 Java、Node.js 和 Python SDK——Java SDK 提供最广泛的 API 覆盖范围，而 Node.js 和 Python 则涵盖了最常用的作业和文件 API——或者使用 Smartling CLI，它可以自动执行诸如在构建或部署管道中上传和下载翻译文件之类的任务。