Crowdin 刚刚发布了 i18n Agent Skill。我们从 3 月起就有了。

Crowdin 在 8 月发布了一个 agent skill，能把 JavaScript 应用从硬编码字符串一路带到接入 Crowdin 项目，上周他们又发布了一段演示视频。我们很高兴看到这一幕。globalize.now 是 AI 驱动的本地化基础设施，我们的 agent skill 从 3 月起就在做这件事；而一家成立于 2008 年的公司走到了同样的设计上，恰恰说明这个问题是真实存在的。

这也是坦诚对比两种思路的好时机，因为它们的终点截然不同。他们的终点，是你的文件躺进一套还得由你来运维的翻译管理系统；我们的终点，是一个已经包含翻译的 PR。

Crowdin 到底发布了什么？

四个新的 agent skill、一个重写的 CLI，以及一个把它们和 MCP server 打包在一起的插件。9 月 4 日发布的 8 月更新日志 列出了 i18n-setup、glossary-generation、crowdin-cli 和 github-action。它们加入了 Crowdin 自 2 月起陆续添加到 crowdin/skills 的上下文类和 API 查询类 skill 中。

CLI 5.0 是这次发布里工程含金量最高的部分。它从 Java 迁移到了 TypeScript，以单个二进制文件分发，并输出 JSON 供 Agent 读取。Crowdin 称它“为 AI Agent 而生”，这话不算夸张。

重头戏是 i18n-setup。9 月 16 日，Crowdin 发布了一段 七分钟的视频，演示它在 Claude Code 中处理一个小型示例站点。

谁先发布了什么？

这取决于怎么算，所以我们翻了这三个仓库的提交历史。Lingui 在 1 月发布了最早的 agent skill。最早能在仓库里完成 i18n 配置并包裹硬编码字符串的 skill 是我们的，时间是 3 月 29 日。

功劳该记的要记：Crowdin 的 MCP server 比我们公司成立得还早，他们的 skills 仓库也比我们早了五周。不过那些早期的 Crowdin skill 只教 Agent 写翻译上下文，改动应用代码是后来的事。我们的配置和字符串包裹 skill 始于 3 月 29 日，贯穿整个流程的编排器始于 4 月 5 日。Crowdin 对应的 skill 在 8 月 28 日才落地，比 Lingui 添加它所依赖的 setup skill 晚了两周，骨架也是一样的：检测、决策、配置、包裹。

我们把这看作对设计思路的肯定，而不是抄袭的证据。只要接受前提，这就是最自然的形态；视频开头讲的正是这个前提：“产品也许已经可以上线，但这不代表它已经为翻译做好了准备。”我们 3 月的第一篇文章里就提出过同样的观点。

这三家之外，还有其他厂商也把 i18n 交给了 Agent，所以我们并不主张自己是全球第一。

Crowdin 的 i18n-setup skill 做了什么？

它在你自己的编码 Agent 里跑完七个阶段，并在仓库里维护一份可恢复的检查清单。skill 文件 结构清晰，演示视频也与之吻合。

1. 检测。 扫描仓库，识别框架和已有的 i18n 库。
2. 决策。 询问你想要的语言，以及采用引导模式还是非引导模式，然后写入 plan.md。
3. 配置。 安装并配置 Lingui。如果你已有 i18n 库，则沿用现有的。
4. 包裹。 标记面向用户的字符串，并提取 PO 文件。
5. 连接。 用 CLI 创建 Crowdin 项目并上传文件。这一步需要你的 Crowdin 令牌。
6. 上下文。 阅读每个字符串周围的代码，为译员写一条备注，并建议一份初始术语表。
7. CI。 安装 GitHub 工作流，让新字符串进入 Crowdin，翻译结果再同步回来。

视频略过了一个细节：Crowdin 的 skill 自己并不执行第 3、4 阶段。它的清单把这两步交给了 Lingui 自己的 skill，你需要把它作为第二个插件安装。Crowdin 自己的工作从第 5 阶段才开始。

有些设计确实周到。Agent 看不到你的令牌值，遇到有歧义的地方，skill 也会停下来询问。局限同样写在文件里：全新安装只支持 Lingui，范围限于 JavaScript 和 TypeScript；已经在用 i18next、next-intl 或 vue-i18n 的项目只能走仅连接路径；它会拒绝 Create React App，也不会帮你在不同库之间迁移。

它把什么留给了你？

翻译，以及让翻译真正发生所需的一切。再看一遍这七个阶段：没有一个会产出翻译后的字符串。

这是有意为之。skill 文件把自动翻译列为默认关闭的附加项，并明确要求“未经请求，绝不对全新项目做机器翻译”。即使你选择启用，Agent 也只能套用翻译记忆库，而新项目的记忆库是空的。只有当你的 Crowdin 账号里已经有引擎或提示词时，才允许进行机器翻译或 AI 翻译。

skill 跑完后，你就拥有了一个 Crowdin 项目，而且你得懂 Crowdin。想要 AI 翻译，得打开个人资料，用你自己的 API key 或给 Crowdin 余额充值来启用服务商，再创建提示词。然后在编辑器里运行预翻译，或在 CLI 里用刚创建的提示词 ID 运行，或者打开项目级的自动翻译设置。接下来还要考虑审批，然后是构建，最后是下载。

这一切都可以自动化，前提是你已经知道这些设置在哪。问题就在这里：Agent 做完了开发者看得懂的部分，然后把你交给一个为本地化经理设计的产品。在 Crowdin 自己的演示里，演示者拿到中文字符串的方式，依然是打开编辑器、点击机器翻译，再用 CLI 把结果拉回来。

Crowdin 的 MCP server 也没有补上这个缺口。文档里列出的工具集都是在已有项目内工作，我们在文档中没有找到预翻译或创建项目的工具。这只是对文档的阅读，并非对每个工具的实测。

globalize.now 有何不同？

i18n 转换和翻译是同一个任务，结果是一个 PR。不用在旁边再配置什么项目，因为根本没有“旁边”。

默认路径在应用内完成。你注册账号，连接 GitHub 或 GitLab，选一个仓库。接着由一次扫描决定后续动作：如果还没有 i18n，我们先搭好基础；如果你已在用 next-intl、react-i18next、i18next 或 Lingui，我们直接接入现有方案，不动你的文件结构。你确认方案后，转换和翻译会在我们云端克隆的仓库上并行运行，并落在独立的分支上。在你合并之前，默认分支不会被改动。

首次转换只做一次。此后，每当你推送新的源字符串，推送任务就会翻译它们，并把结果以 PR 的形式提交。

如果你更想留在编辑器里，同样的任务也可以从一条提示词启动。我们的 Claude Code 集成 及其背后的 skill 会替你连接仓库。我们之前也写过为什么我们提供 skill 而不是 SDK。

Crowdin 的七个阶段跑在你的 Agent 上，所以消耗的是你的 token。我们的转换跑在我们这一侧。而且，在 Lovable 里做出应用、从没打开过终端的人，也能走完我们的流程——只要流程以导出环境变量开头，就做不到这一点。

这并非瞬间完成。小型仓库几分钟，大型代码库可能需要一小时甚至更久。你仍然需要看方案、审 PR，这本来就该如此。

Crowdin i18n-setup 与 globalize.now 逐步对比

什么情况下应该选 Crowdin？

产品由人来翻译的时候。如果你有内部语言专家、翻译机构或志愿者社区，就需要翻译记忆库、术语表、上下文内编辑器、审校环节和供应商管理。这就是翻译管理系统，Crowdin 自 2008 年起一直在做，而我们并不打算做成那样。

Crowdin 还支持一些我们目前不支持的格式，包括 XLIFF、ARB、.xcstrings 和 Android XML，它的 skill 也能接入 vue-i18n 项目。如果你的主要产品是原生移动应用，请先确认这一点。

完整对比页深入比较了定价模式和适用团队。

老牌厂商也推出这个，为什么值得关注？

因为它为一场争论画上了句号。Lingui、Crowdin 和我们现在达成了共识：由 Agent 准备代码，由开发者审批方案而不是亲自动手，而且这件事应该发生在编写应用的编辑器里。

我们仍有分歧的是后面的事。Crowdin 的答案是通往控制台的更好入口；我们的答案是，大多数用 Cursor、Claude Code 或 Lovable 交付产品的团队根本不想要控制台。他们想要的是当天就让应用支持德语，之后每加一个按钮，就收到一个 PR。

对任何主打 Agent 的厂商，都可以问一个简单的问题：Agent 干完之后，我下一步得去哪？如果答案是一个要重新学习的新产品，那 Agent 只是一扇前门；如果答案是你的 Pull requests 标签页，那它就是整座房子。

在你自己的仓库上试试

重现 Crowdin 的那个测试：拿一个有硬编码字符串的小应用，看一小时后你走到了哪一步。连接仓库，确认方案，审阅 PR。试用无需绑卡。想先看价格，定价在这里。