globalize.now 与 i18next 对比
globalize.now 和 i18next 解决的是不同的问题。i18next 是开源的国际化库，在运行时加载翻译，处理复数规则、插值和语言切换。globalize.now 是本地化基础设施，在开发阶段运行：提取硬编码字符串、生成翻译键、创建语言文件，并在每次 Git 推送时保持翻译同步。
这不是二选一。i18next（或 next-intl、react-intl、Lingui）解决的是运行时如何获取和格式化字符串；globalize.now 解决的是代码持续演进时，这些字符串如何以键和语言文件的形式进入版本控制。如果仓库已经很规整，直接用你喜欢的运行时即可；如果还不规整，先运行 globalize.now，让运行时拿到一致的输入。
想了解 Next.js 的分步接入，请参阅 Next.js 集成指南.
如果……，请选择 i18next
i18next 是一个开源的 JavaScript 国际化库，在运行时加载翻译，并处理复数规则、格式化和语言切换。
以下情况更适合选 i18next：
- 翻译键和语言文件已经就绪，你需要一套成熟的运行时 API。
- 你需要在浏览器或服务端使用复数处理、命名空间和懒加载。
- 集成由工程师自己负责，且没有遗漏的结构性 i18n 工作。
如果……，请选择 globalize.now
globalize.now 是 AI 驱动的本地化基础设施：自动从 AI 生成的代码库中提取硬编码 UI 字符串，生成翻译键和语言文件，并在每次 Git push 时保持翻译同步——无需手动导出，没有审核队列，告别 i18n 技术债。
这些情况适合选 globalize.now：
- AI 辅助编码留下的字面量仍然嵌在 JSX 或模板里。
- 在任何运行时库发挥作用之前，你需要先有自动提取和 Git 推送同步。
- 你需要用 Agent Skill 搭建 next-intl、Lingui 等多种技术栈，而不只是 i18next。
功能对比（概览——具体细节请以各厂商官网为准）。
| 功能 | globalize.now | i18next |
|---|---|---|
| 运行时加载翻译与复数规则 | 否 | 是 |
| 应用外壳中的语言切换 | 否 | 是 |
| 自动从代码中提取用户可见的字面量 | 是 | 否 |
| 翻译键生成与去重 | 是 | 否 |
| 在仓库中创建语言文件 | 是 | 否 |
| 每次 Git 推送自动同步 | 是 | 否 |
| 以 Git 为中心的自动化，无需手动导出 | 是 | 部分 |
| 面向 Cursor、Claude Code、Copilot 的 CLI / Agent Skill | 是 | 部分 |
| 兼容 next-intl、Lingui 等技术栈，而不只是 i18next | 是 | 不适用 |
| 需要在应用代码中完成工程接入 | 部分 | 是 |
| 在官网公开标注起步价 | 部分 | 是 |
- * 运行时加载翻译与复数规则: 备注： 由 i18next 负责，不属于 globalize.now。
- * 在官网公开标注起步价: 备注： i18next 核心为开源；托管服务另有差异，请以最新页面为准。
i18next 更合适的场景
如果工程师已经把 UI 文本拆分到资源文件中，你主要需要的是好用的 API、插件和生态集成，就选 i18next。翻译目录就绪之后，它正是该用的那一层。
globalize.now 更合适的场景
如果应用仍在渲染硬编码的英文，而团队需要在不中断功能开发的前提下，借助自动化把字面量转换为翻译键，就选 globalize.now。每次 Git 推送都会自动处理，新增的 UI 文本不会绕过翻译目录。
globalize.now 如何与 i18next 搭配使用
建议有意识地搭配使用：由 globalize.now 生成并同步语言 JSON 文件，再用 i18next 在客户端或服务端 bundle 中加载这些资源。globalize.now 不绑定任何库，提取结果可靠之后，团队可以自由选择最适合自己技术栈的运行时。
常见问题
globalize.now 是 i18next 的替代品吗？
不是。i18next 仍然是负责加载和格式化消息的运行时库，而 globalize.now 负责在 AI 生成的 UI 不断变化时，自动完成消息在 Git 中的创建与更新。你可以在能让词条目录始终准确的自动化流程之后，或与之并行使用 i18next。两者处理的是不同层面的问题，经常互补。
两个都需要吗？
如果生产环境要提供多语言内容，就需要运行时库；如果词条目录之外仍有字面量，就需要基础设施层面的自动化。很多团队用 globalize.now 维护文件，再用 i18next 读取。如果你已经手动完成了提取，那么在下一批硬编码字符串出现之前，单用 i18next 可能就够了。
globalize.now 能配合 next-intl 使用吗？
可以。globalize.now 不绑定任何库：Agent Skill 会根据你的框架，搭建 next-intl、Lingui 或其他方案。i18next 只是因为生态丰富，被问得最多。选择契合你架构的运行时，globalize.now 则专注于基于 Git 的自动化。
globalize.now 支持哪些运行时库？
Skill 覆盖常见技术栈，例如搭配 next-intl 的 Next.js App Router、Lingui，以及开发者指南中记录的 React 方案。目标始终一致：把稳定的键和语言文件提交到 Git，并在推送时同步。新的 Skill 上线后，请以开发者页面上的最新支持矩阵为准。
能从单用 i18next 迁移到 globalize.now 加 i18next 吗？
可以。先让自动化盘点字面量并建议键，无需拆掉 i18next。语言文件生成并接入后，继续用 i18next 作为加载器。相比推倒重来，这种方式风险更低。预期会是一系列增量 PR，而不是一夜之间的大改动。
globalize.now 能做到而 i18next 做不到的是什么？
它会扫描代码、提取用户可见的字符串、生成键、写入语言文件，并在翻译更新时创建 PR——默认每次 Git 推送都会触发。i18next 只负责使用资源，不管功能迭代时这些文件如何与 JSX 保持一致。这个对齐问题，正是 globalize.now 自动化解决的。
i18next 能做到而 globalize.now 做不到的是什么？
i18next 负责复数规则、插值、命名空间、懒加载，以及运行中的应用里语言的实时切换。这些问题属于客户端或服务端 bundle，而不是 Git 自动化服务。职责各有分工：基础设施维护文件，i18next 负责渲染。
应该先装 i18next，还是先运行 globalize.now？
如果你已经在提供本地化 bundle，就继续使用 i18next 作为运行时。如果字面量仍然绕过词条目录，就先运行 globalize.now，让键和 JSON 文件就位，再去调优 i18next 插件。稳妥的顺序是：先自动化提取和 Git 同步，再让 i18next 加载生成的资源。这样可以避免翻译那些在版本控制中尚不稳定的字符串。