i18n 做到一半？看看 globalize.now 会动什么、不会动什么。

如果你的仓库里已经接入了 next-intl、react-i18next、i18next 或 Lingui——磁盘上有语言文件夹，package.json 里有依赖，还有中间件或配置文件——你就不需要再用一个假定你从零开始的工具。globalize.now 是 AI 驱动的本地化基础设施。在 L1（已完成国际化）模式下，它会跳过具有破坏性的初始化脚手架，只做同步：读取源语言，在每次推送时对比其他语言，并通过 PR 提交补全的内容。本文说明这一模式会动什么、不会动什么，以及检测出错时该怎么处理。

为什么大多数 i18n 建议都默认你是从零开始？

i18n 工具的宣传文案仍然围绕“全新项目”场景：没装任何库，没有语言文件，也没做过提取。而大多数生产环境的代码库根本不是这样。

最近几周，三个互不相关的首次接触案例呈现出同样的情形：团队尝试过一次 i18n，做到一半能用，然后就停了——因为把它拆掉重来，比忍着这堆烂摊子还让人头疼。

如果你也是这样，这篇文章就是写给你的。

一个只做了一半国际化的代码库，实际是什么样子？

这些模式反复出现（细节已匿名处理）：

• 一个 Next.js + next-intl 应用，大部分组件使用 t()，但较早的路由仍是硬编码的英文，因为第一轮迁移从未完成。
• 一个 React + i18next 项目，语言文件虽然存在，但里面只有英文值——翻译永远排在下个季度。
• 一个 messages/ 目录，其中 en.json 内容完整，而 es.json 基本是空的。
• 布局里接了语言切换器，却时不时返回 404，因为路由只迁移了一半。

这些项目都不需要 globalize.now 推倒重来，需要的是它来把活干完。

首次运行时，globalize.now 会扫描哪些信号？

检测分两步进行，而不是一步。

首先，把 globalize.now 指向你的仓库。在应用中连接后，它会自动运行检测和一次性转换。如果你更想让 Agent 在本地完成这一步，可以安装 Skill——它会在 .claude/skills/ 中放入几个操作手册文件，仓库里的其他内容一概不动：

npx skills add globalize-now/globalize-skills

然后给你的 Agent 下指令——Claude Code、Cursor 或 Codex 均可。Agent 会读取已安装的 Skill，并用它们来扫描你的仓库：

Set up localization for my project

真正的检测就发生在第二步。Agent 会查找：

• package.json 依赖： next-intl、react-i18next、i18next、@lingui/core、@lingui/react、@lingui/macro，或任何 i18next-* 插件。
• 语言文件夹： 仓库根目录下的 messages/、locales/ 文件夹，或带有语言子文件夹的 src/i18n/。
• 现有的语言文件： en.json、en.po、en.yml、en.yaml，或你所用的库默认期望的语言文件。
• 框架特定的配置： i18n.config.ts、next-intl 中间件、lingui.config.js 或同类配置。

只要命中其中至少两个信号，项目就会被判定为 L1——即已完成国际化——此时安装流程会走分支，而不是执行完整的全新项目脚手架。更多细节见帮助中心：已有 i18n 的项目。

L1 模式下哪些内容不会被改动？

这是大家最关心的部分。在 L1 模式下，globalize.now 不会：

• 执行大范围的字符串提取，扫描组件中的硬编码字面量。
• 生成新的翻译键，或重新调整你已提交的键结构。
• 为尚未配置的语言创建语言文件脚手架。
• 插入语言切换器。已有的会保留，没有的我们也不会添加。
• 替你改写路由、中间件或框架配置。

你现有的 i18n 方案仍由你掌控，该模式下我们不会重构它。

检测完成后，L1 同步模式做什么？

L1 以同步为先。检测完成后：

1. 我们读取你现有的语言文件，了解当前的键结构，并确认哪种语言是源语言。
2. 你通过 globalize.now CLI 或 Web 应用连接 GitHub 仓库。
3. 每次推送到主分支，我们都会对比源语言文件与其他 locale 的差异。缺失的翻译由 AI 补全，并遵循你配置的术语表和风格指南。
4. 随后会生成一个包含更新后语言文件的 PR。你来审查并合并，我们绝不替你合并。

整个流程就是这样一个闭环。无需盯着翻译后台，无需手动导出，也无需来回转换文件格式。

对比 L0 的完整流程，见如何在 15 分钟内为 Cursor 构建的 Next.js 应用添加 i18n？——同一个产品，不同的接入路径。

如果界面只有一部分用了翻译调用怎么办？

这是迁移到一半时的常见状态：新页面使用 t()，旧页面仍然残留字面量。在同步模式之外，skills 流水线会把已有键的字符串视为锁定：只处理尚未接入的字面量，并保留现有的键。每周都在发版、迁移又进行到一半的团队，正是我们日志里典型的“混合 L1”用户。

想看 Agent 在复杂代码树上完成整体转换的案例，请参阅AI Agent 为真实的 monorepo 做国际化，会发生什么？。

如果安装流程还是生成了全套脚手架，该怎么办？

我们正在优化检测逻辑，错误的分支本不该被触发。但如果 npx skills add globalize-now/globalize-skills 已经生成了超过 100 个文件的 diff——重写了你的 locale 目录、加入了你没要求的切换器，或改动了路由——请不要提交。使用右下角的反馈组件，附上 package.json 依赖列表，并简要说明你的 locale 目录结构，我们可以手动把仓库归入 L1。自助式 --existing-i18n CLI 参数即将上线。

在本地恢复只需 git restore .，必要时再加 git clean -fd。没有任何内容被推送，也没有影响线上环境，Agent 只改动了你的本地分支。完整说明见globalize_skills 改动过多——发生了什么？。

为什么“试过 i18n，后来搁置了”成了如今的常态？

这不是口号，而是一种规律。六周内三次独立的首次接触，说的是同一件事：“试过，现在一团糟。”一个拥有数万用户的 Chrome 扩展遇到韩国流量激增，才启动了做到一半的 next-intl 迁移。一个用 Lovable 构建的应用在添加多语言支持时搞坏了自己的构建，最终被回滚。一个 vibe coding 出来的 React + Vite 仓库接入了 i18next，填了大约三分之一的键就停了。

完全干净、正在找库的 L0 代码库当然存在，但它不是瓶颈。真正的瓶颈是那些已经尝试过一次、如今没人愿意收拾残局的代码库。

L1 模式正是为这样的代码库而设计的。

价格是多少？

每月 €20，只有一个套餐，包含约 16,000 词（约 80 个典型应用页面）。注册即送 €5 翻译额度。无论你是 L0 全新项目，还是背着三年本地化技术债的 L1，价格都一样——我们按吞吐量和自动化程度计量，而不是看第一次提交有多乱。

接下来该读哪些文章和帮助中心文档？

• Cursor Next.js 应用的 L0 接入流程
• Monorepo 案例研究——Agent 实际改动了什么
• 为什么传统 TMS 工具难以适配现代 Git 原生技术栈
• 帮助中心：我已经有 i18n 了，globalize.now 能做什么？
• 帮助中心：globalize_skills 改动过多

为你的流量早已期待的语言做好上线准备——在 globalize.now 连接仓库，或了解 Git 推送自动化 如何融入现有团队的工作流。