如何把 lovable-i18n skill 添加到 Lovable 工作区？

从 GitHub 添加：依次打开 Settings、Skills、Add、Import from GitHub，然后让 Lovable 指向 globalize-now/lovable-i18n 仓库。Lovable 会下载、校验并发布到工作区，所有项目都能使用。globalize.now 是 AI 驱动的本地化基础设施：它生成翻译键和语言文件，由应用里的运行时库提供服务。Skill 让这一切无需离开 Lovable 编辑器就能完成，也是整条路径中完全没有控制台的原因。

Lovable Skill 究竟是什么？

Skill 是在工作区层级一次性存放的简短具名手册，由三部分组成：一个固定不变的小写名称、一段告诉 Lovable 何时加载它的描述，以及 Lovable 在适用时遵循的 markdown 指令。

关键特性是 Skill 按需加载。工作区知识库则不同——它始终在上下文中，编码规范和品牌规则适合放在那里。Skill 只在请求与其描述匹配时才进入对话，所以一个工作区可以存放许多各有专攻的 Skill，互不拖累无关任务。

你可以在聊天输入框中输入 / 并选中它来主动调用，也可以让 Lovable 在提示词匹配时自动应用。可以把 Skill 理解为“怎么做”，把提示词理解为“做什么”。

它们还具备可移植性。Lovable 使用与 Anthropic Agent Skills 规范相同的 SKILL.md 结构，所以为一个工具编写的 Skill 无需改写就能导入另一个。这对本地化并不是小事：在 Lovable 中搭建 i18n 的同一套指令，可以直接用于你之后在 Claude Code 或 Cursor 中打开的仓库。

为什么 Lovable 应用只有英文？

因为生成的代码里没有语言区域层，无法提供其他语言。你让 Lovable 做一个定价页，它会把标题直接以字面量写进组件，语言就是你提示词所用的语言。每个按钮、空状态、toast 和校验消息都是这样落地的。

之后再让 Agent“翻译整个应用”，只会得到半成品：它恰好检查过的屏幕被替换了，而你接下来开发的功能又会以英文出现。我们在为什么 Lovable 的翻译会漂移 中详细记录过这种反复出现的问题，机制至今没变——Agent 解决的是眼前的提示词，而不是背后的架构。

解法是结构性的，而且是一次性的：给字符串分配翻译键，把译文放进文件，让运行时从文件读取。Skill 正适合承载这项工作，因为它是一份固定的手册，而不是一条你得措辞两次才能说对的提示词。

lovable-i18n Skill 会安装什么？

Lingui v6，PO 目录位于 src/locales/[locale]/messages.po，用 Trans 宏提取文案，附带语言切换组件和一个 GitHub Action。它会检测项目所用的技术栈并据此生成脚手架——无论是 Vite SPA 还是 TanStack Start，Lovable 都会生成这两种。

这个栈检测比听上去重要得多。Lovable 默认生成的技术栈已切换为支持服务端渲染的 TanStack Start，而客户端渲染的 SPA 与服务端渲染的应用，正确的 i18n 接入方式并不相同。服务端渲染的情况我们在 TanStack Start 指南 中单独讲过；Skill 会自动选对路径，你不必知道自己拿到的是哪一种。

它不会安装的，是对我们的运行时依赖。目录文件就在你的仓库里。哪怕明天你移除了 globalize.now，只要提交了 PO 文件，Lingui 应用依然能渲染它已有的所有语言。

如何导入这个 Skill？

共四步，每个工作区只需做一次。

1. 将 Lovable 项目连接到 GitHub。 使用聊天输入框中的 + 菜单，选择 GitHub，再点击 Connect project。目录文件需要一个真实的仓库来存放。
2. 导入 Skill。 依次进入 Settings、Skills、Add、Import from GitHub，填入 https://github.com/globalize-now/lovable-i18n。SKILL.md 位于仓库根目录，这正是 Lovable 在你提供整个仓库 URL 时所期望的结构。如果 Skill 位于更大的 Skills 仓库的子目录中，使用 tree 或 blob URL 同样可行。
3. 添加 globalize MCP。 打开 Connectors，选择 Custom MCP，添加 https://api.globalize.now/mcp。执行到登录步骤时，Skill 会引导你完成。
4. 向 Lovable 下达指令。 让它使用 lovable-i18n Skill 和 globalize MCP 来配置 i18n 并翻译应用。

开始之前，有两点限制需要了解。创建、编辑、删除和导入自定义工作区 Skill 仅限工作区所有者和管理员——编辑者可以查看并调用所有 Skill，但无法添加。此外，在 Settings 中添加 Skill 不消耗额度；之后使用它的那条消息，与其他构建消息按相同标准计费。

包含完整 URL 的分步说明见 Lovable 集成页面。

这是哪个 MCP？又不是哪个 MCP？

这是最容易混淆的地方，搞反了会白白浪费一下午。

Lovable 提供两种方向相反的 MCP。位于 mcp.lovable.dev 的 Lovable MCP server 让外部 Agent——ChatGPT、Claude、Cursor、VS Code——可以从别处创建和编辑你的 Lovable 项目。聊天连接器（在 Connectors 中以 Custom MCP 方式添加）则正好相反：它让 Lovable Agent 在你构建时调用外部工具。

globalize MCP 属于第二种。你是在授权 Lovable Agent 创建本地化项目、翻译目录文件并连接仓库，而无需另开一个产品来完成这些事。Lovable 官方文档也明确区分了这两者，说明不少人都会在这里踩坑。

实际影响是：如果你发现自己正把一个 URL 粘贴到 Claude 或 Cursor 里才能跑通，那就是用错了入口。这里的所有操作都在 Lovable 编辑器内完成。

首次配置之后会发生什么？

Skill 生成脚手架，变更同步到 GitHub。像审查其他改动一样审查它——Lingui 配置、PO 目录、用 Trans 宏包裹字符串的组件改动、语言切换组件——然后合并到默认分支。

此后，转换就完成了。这是一次性的应用内转换：你连接仓库，globalize.now 对代码库转换一次，生成目录。之后，每次推送都会翻译新增的目录条目，并以 PR 的形式交付给你合并。你照常向 Lovable 下达指令；新字符串会进入目录，而不会作为未翻译的字面量不断堆积。

没有导出步骤，没有导入步骤，也没有需要有人逐条审批字符串的界面。想看更完整的论述，请阅读 无需控制台，本地化 Lovable 应用。

为什么用 Skill，而不是翻译插件？

因为插件和目录文件产出的东西不同，而只有后者真正属于你。

运行时插件——也就是 Weglot 的模式——会注入 JavaScript，在页面加载后于浏览器中改写文本。结果是先闪现一下英文、字符串长度变化导致布局抖动，而且索引里只有一个英文页面，翻译发生在客户端，爬虫未必能稳定抓取到。它适用于任何网站，这是它真正的卖点，对于你无法控制代码的营销页面，也是个合理的选择。

提交到仓库的目录文件则是相反的取舍。它需要访问代码，而你恰好有权限，作为交换，翻译后的标记直接由你自己的仓库渲染，每种语言对应一个可被索引的页面。Lovalingo 专为 Lovable 采用了运行时模式，并已 于 2026 年 8 月 31 日关停；如果你正在迁出，迁移指南 介绍了如何导出已有内容。这次关停也恰恰是基于文件方案最有力的论据：Git 历史中的 PO 目录，不依赖于某家公司是否还存在。

如果你想看面向结果、而非聚焦实现机制的完整流程，请从 让 Lovable 应用支持多语言 开始。想在动手前了解成本，定价页面 列出了当前套餐。

一次添加，长期受益

导入是一次性的工作区操作，而且免费。此后，i18n 就和其他功能一样，直接在聊天输入框里提需求即可，翻译结果以你自己拥有的文件形式交付。