正确地让 Lovable 应用支持多语言，意味着把真正的翻译目录提交到仓库并自动保持同步，而不是在 UI 上叠加一个翻译插件。globalize.now 是 AI 驱动的本地化基础设施：提取硬编码字符串，生成 PO 目录，并在每次 Git 推送时更新。走捷径的工具几分钟就能给你一个多语言演示，但也会留下翻译漂移、加载时布局抖动，以及搜索引擎难以读取的页面。下面这套方案，能撑过第十二次发布。
对 Lovable 应用来说，“正确地支持多语言”到底指什么？
指翻译以已提交目录的形式存放在代码库中，直接包含在首次返回的标记里，并随应用变化自动更新。
任何真正的多语言应用都有三层。i18n 运行时库按当前 locale 提供对应的字符串；翻译目录存放实际的译文；还需要有东西在 UI 演进时让这些目录保持最新。多数 Lovable 指南只讲第一层，跳过第三层，而出问题的恰恰是第三层。
Lovable 的设计初衷就是快速改动 UI。每条提示词都可能新增、重命名或重组面向用户的文本。所以问题不是“怎么把应用翻译一次”，而是“怎么在持续写提示词的同时，让每个 locale 始终完整”。处理不好，上线的就是语言混杂的 UI，这是在非英语市场失去用户信任最快的方式之一。
为什么翻译插件不适合 Lovable 应用？
它们在页面加载后才翻译内容，等于用一个看不见的维护问题，换来了看得见的性能和 SEO 问题。
Weglot、Lovalingo 以及各类注入式翻译插件这类运行时翻译工具，是 Lovable 最常见的首选方案，因为几分钟就能装好，也不需要语言文件。代价要等到后面才显现：用户会先短暂看到原始语言，然后才切换为译文，这就是未翻译内容的闪烁。切换会让布局移动，产生累积布局偏移（CLS），而 Google 会把它计入 Core Web Vitals。
更深层的问题是可发现性。如果译文只在客户端 JavaScript 执行后才出现，实际上你只有一个真实页面，外加浏览器端翻译。按 locale 划分的 URL 要么不规范，要么根本没有，所以西班牙语和德语页面的排名比不上规范本地化的站点。插件可能适合内部工具或一次性演示，但对于想在其他市场被搜到的应用，它是错误的地基。
一次性的 i18n 配置能让 Lovable 应用持续保持翻译吗？
不能。一次完整的提取只能管用到下一条提示词，之后翻译就会开始漂移。
你可以让 Lovable、Cursor 或 Claude Code 接入正规的 i18n 库，把所有字符串提取到翻译目录。对执行时的那个构建来说，这确实有效。问题在于提取没有一个天然的“完成”节点：下一个定价区块、下一个空状态、下一个按钮文案，都会以新的硬编码字符串出现，目录就这样悄悄落后了。
手动方案是每次改动都提示 Lovable 更新所有目录，听上去很有纪律，实际上撑不住。你得在每条提示词里，针对每个字符串、每种语言都记得去做。乘上四个 locale，每次 UI 改动都变成一场协调工作。这种摩擦，恰恰会消耗掉让 Lovable 值得使用的开发速度。
如何一步步让 Lovable 应用支持多语言？
开始之前：先把 Lovable 项目连接到 GitHub（聊天输入框中的 + 菜单，选择 GitHub，再选择 Connect project），注册一个 globalize.now 账号（免费注册，赠送 €5 初始额度，无需绑卡），并确认你是 Lovable 工作区的所有者或管理员，这样才能为整个工作区添加一次 Skill。
连接仓库，添加一次 lovable-i18n Skill，之后每次推送都会自动同步。完整流程如下。
- 把 Lovable 项目连接到 GitHub。 在聊天输入框中打开 + 菜单，依次选择 GitHub、Connect project。Lovable 会把项目同步到一个真实的仓库，这是实现可持续 i18n 的前提。下面所有操作都在这个仓库上进行，而不是发生在黑盒里。
- 把 lovable-i18n Skill 添加到工作区。 Lovable 支持可复用的 Skill。在 Lovable 工作区打开 Skills，依次选择 Add、Import from GitHub，粘贴
https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n并确认。每个工作区只需添加一次（需要工作区所有者或管理员权限）。添加 Skill 免费，不消耗额度。用的是 Cursor 或 Claude Code？在已连接的仓库中运行npx skills add globalize-now/globalize-skills即可。 - 让 Lovable 完成配置。 把下面的内容粘贴到 Lovable 聊天框：
Set up i18n for my project using the lovable-i18n skill.Lovable 会检测你的技术栈（Vite SPA 或 TanStack Start），并提一个问题（源语言、目标语言、URL 中是否带 locale、是否添加 GitHub Action）。回复go即可使用默认设置。随后它会安装 Lingui（@lingui/core、@lingui/react和 Vite 插件），接入 provider，在src/locales/{locale}/messages.po下为每个 locale 生成一份 PO 目录，用<Trans>宏包裹字符串，并添加语言切换器。 - 检查并合并。 Lovable 同步到 GitHub 后，检查 diff，合并到默认分支。
- 把仓库连接到 globalize.now。 登录后选择 Connect repository，授权 GitHub 应用，选中 Lovable 仓库和默认分支，再选择语言（支持 50+ 种，含 RTL）。
- 继续在 Lovable 中开发。 每次推送，globalize.now 都会发起一个翻译 PR，附带更新后的 PO 目录。合并即可，应用就带着译文上线。两次发布之间，你无需再做任何事。
关键在第三到第六步：配置只需一次，之后的同步无需命令、无需控制台，也没有审核队列。完整的集成流程见 Lovable 集成页面。
Lovable 应用应该选用哪个 i18n 库？
lovable-i18n Skill 安装的是 Lingui。Lovable 应用是 Vite SPA 或 TanStack Start 的 React 项目，Lingui 与这套技术栈契合。
这个 Skill 会接入 @lingui/core、@lingui/react 和 Vite 插件，在 src/locales/{locale}/messages.po 下生成 PO 目录，并用 <Trans> 宏包裹字符串。react-i18next 和 next-intl 适用于其他 React 与 Next.js 项目，但这个 Skill 不会安装它们。
不要自己发明翻译 context，也不要硬编码语言映射表。第一天看着轻巧，第三十天就得推倒重来。globalize.now 开发者页面 说明了提取结果如何对应到各个库，选型时不必盲选。
持续用提示词驱动 Lovable 开发时，如何让译文保持同步？
把同步放进 Git 工作流，就不会被遗忘。
手动做 i18n 总会失败，因为它依赖人在快节奏的构建中记得做这件杂事。基础设施则把人从流程中拿掉：差异比对和翻译在每次推送时运行，Lovable 提示词新增的字符串会在这次推送中被发现、翻译，并通过 PR 回到分支，赶在合并之前完成。不会出现 PO 目录悄悄落后的发布，因为根本没有可以跳过的手动步骤。
这就是“配置好”与“基础设施”的区别。配置是一次性达成的状态，基础设施是周围一切都在变时依然成立的属性。对于需要在 Lovable 里持续迭代的应用，你要的是属性，而不是状态。想了解 AI 生成应用的工作流，请看 vibe coder 页面；如果你在比较各种工具，对比指南 梳理了它们各自处于技术栈的哪一层。
让 Lovable 应用支持多语言，起步容易，长期维护难。globalize.now 负责长期维护这部分。在 Lovable 中，通过 Open Skills、Add、Import from GitHub 添加 lovable-i18n Skill，指向 globalize-now/lovable-i18n。在 Cursor 或 Claude Code 中，运行 npx skills add globalize-now/globalize-skills。详见 Lovable 集成指南 或 globalize.now。
globalize.now 把硬编码的应用文案转换为可直接翻译的语言文件，并在你持续发布时保持同步更新。
免费试用 globalize.now