为什么 Lovable 应用的翻译每次发布都会失效

在 Lovable 中做多语言，实际会发生什么

你提示 Lovable 新增一个定价板块。Lovable 生成组件、接入页面并发布，英文 UI 随之更新。而你的 messages.po 语言文件仍停留在旧内容。法语用户看到的是旧文案，德语用户看到的是英文。直到有真实用户反馈，才会有人发现。

这不是 Lovable 的 bug，而是结构性的错位。Lovable 追求快速交付 UI，而 i18n 要求每次改动都追踪所有面向用户的字符串在每个 locale 语言文件中的状态。这两个目标本身就是冲突的。

字符串提取是持续性的问题，不是一次性的。Lovable 的每次提示词都可能产生新字符串，每次迭代都可能改动已有内容。没有哪个节点能让你说“提取已经完成”。

---

为什么常见的补救办法都不奏效

一次性提取能解决问题吗？

不能。你可以在初次构建完成后跑一遍字符串提取，得到干净的 PO 语言文件。这在下一次提示词之前都有效。之后，你就得在几十个组件和几十份语言文件之间手动比对差异。西班牙语 messages.po 语言文件里漏掉一个字符串，西班牙语用户就会在一个已翻译的页面中间看到英文——这就是所谓的混合语言 UI，也是最容易损害用户信任的体验之一。

运行时翻译工具够用吗？

Weglot 这类运行时翻译工具，或通过 JavaScript 注入的翻译组件，解决的是另一个问题。它们在页面加载后才翻译内容，用户会先看到零点几秒的原语言，译文才出现。除了体验不佳，这还会产生可测量的累积布局偏移（CLS）——Google 用它作为页面排名的 Core Web Vitals 信号。你是在拿一个看不见的维护问题，换来一个看得见的性能问题。

直接提示 Lovable 更新语言文件行不行？

Lovable 确实可以写入 PO 语言文件，只要你开口要求。问题在于：你得记得每次提示词、每个字符串、每个 locale 都去要求它。每多一种语言，心智负担就叠加一层。乘以四个 locale，每个 UI 提示词都变成一套四步协调流程。这种摩擦，恰恰会磨掉当初让 Lovable 值得使用的开发速度。

---

Lovable 的 i18n 流程是怎样一步步垮掉的

这个规律出现得足够稳定，已经有了清晰的轮廓：

1. 初始配置——你添加了多语言支持，一切正常，所有内容都已翻译，心情不错。
2. 最初几次发布——你记得手动更新 PO 语言文件。有点烦，但还撑得住。
3. 提速阶段——发布越来越快，PO 语言文件开始滞后。你告诉自己回头再补。
4. 混合语言上线——非英语市场的用户开始看到夹杂英文的页面，工单随之而来。你花了整整一个发布周期，只为到处找字符串。
5. 重构税——每个新功能都背上了纯英文版本里不存在的隐性 i18n 成本，发布节奏被拖慢。

写“如何在 Lovable 中做多语言”教程时，没人提重构税。教程只演示初始配置，不会告诉你第 12 次发布时会发生什么。

---

解法：把 i18n 接入 Git 推送流程

正确的架构思路是彻底去掉手动步骤。如果每次推送都自动更新翻译，维护问题就消失了。提取流程自己会跑，你就不可能忘记运行。

工作流如下：

1. 把 Lovable 项目连接到 GitHub。 点击聊天输入框里的 + 菜单，选择 GitHub，再点击 Connect project。
2. 把 lovable-i18n Skill 添加到工作区。 在 Lovable 工作区打开 Skills，依次点击 Add、Import from GitHub，粘贴 https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n 并确认。每个工作区只需操作一次（需要工作区所有者或管理员权限）。
3. 让 Lovable 完成配置。 在 Lovable 聊天中粘贴：Set up i18n for my project using the lovable-i18n skill. Lovable 会检测你的技术栈（Vite SPA 或 TanStack Start），并提出一个问题（源语言、目标语言、URL 中是否带 locale、是否添加 GitHub Action），回复 go 即可使用默认值。它会安装 Lingui，在 src/locales/{locale}/messages.po 生成 PO 语言文件骨架，用 <Trans> 宏包裹字符串，并添加语言切换器。
4. 检查并合并。 Lovable 同步到 GitHub 后，检查 diff，合并到默认分支。
5. 把仓库连接到 globalize.now。 登录，连接仓库，授权 GitHub 应用，选择你的 Lovable 仓库和默认分支，再选择语言（50 多种，含从右到左的语言）。
6. 继续在 Lovable 中开发。 每次推送都会触发 globalize.now 提交一个包含最新 PO 语言文件的翻译 PR，合并后应用就带着翻译上线。

关键在于：配置完成后，连接和同步这两步无需你再做任何事。不用运行命令，不用查看后台，不用审批翻译队列。Lovable 生成的组件中的新字符串，会在推送时被捕获、翻译，并在你合并分支之前以 PR 的形式回到仓库。分步配置说明见 Lovable 集成页面。

---

这对你的 Lovable 工作流意味着什么

你不需要放弃 Lovable。整套架构的前提就是 UI 会持续变化——这正是它的意义所在。Lovable 生成 UI 并运行 lovable-i18n Skill，globalize.now 负责同步。

Lovable 生成组件，并在需要 i18n 时应用该 Skill；globalize.now 在每次推送时检查产物。无论你发布得多快，用户看到的始终是完整翻译的 UI。

globalize.now 的 vibe coder 页面 详细介绍了这套配置如何适配 AI 构建的应用。如果你已经在运行基于 Lovable 构建的 Next.js 或 React 应用，开发者页面 涵盖了技术集成路径。

对于已经在管理多个 Lovable 项目的团队，globalize.now 按工作区定价，不按语言收费，也不按字符串提取次数收费——应用规模增长，同步成本也不会上涨。

---

维护负担是真实存在的，而且会不断累积。在 Lovable 中添加 lovable-i18n Skill（在工作区打开 Skills，依次点击 Add、Import from GitHub）。详见 Lovable 集成指南 或 globalize.now。