不会。只要翻译 PR 合并到 Lovable 正在同步的那个分支，就不会破坏 Lovable 的 GitHub 同步。Lovable 同一时间只编辑一个分支，并把已合并的提交拉回项目，所以翻译 PR 对它来说只是该分支上多了一个提交。globalize.now 是 AI 驱动的本地化基础设施，以 PR 的形式把翻译交付到你的仓库，这意味着两个系统只在一次普通的 Git 合并中相遇，别无其他交集。真正会出问题的情况有限且有据可查，本文逐一梳理。

Lovable 的 GitHub 同步到底是怎么工作的？

它是双向的，而且只针对单个分支。Lovable 文档说明，它一次只编辑并同步一个分支，默认是仓库的默认分支，通常是 main。你在 Lovable 中的改动会提交到该分支，推送到 GitHub 上该分支的提交则会被拉回 Lovable。

只要有工具在 Lovable 之外向仓库写入，下面两个细节就很重要。

拉取依赖一条通知。 Lovable 收到 GitHub 的推送通知后才会更新项目。按同一份文档，如果这条通知没有送达，该次推送的提交就不会出现在 Lovable 中。文档给出的解法是再推送一个提交，触发一次新的通知。如果你合并了翻译 PR，编辑器里却仍然是英文，先查这一点。

同步分支可以更换。 项目的 GitHub 设置里有分支选择器。在那里创建的分支会从当前活跃分支派生，而不是自动从 main 派生。切换之后，Lovable 编辑并同步的就是新分支。此后合并到 main 的内容，在合并进 Lovable 所在分支之前，编辑器都看不到。

这一节只记一句话：翻译 PR 必须合并到分支选择器所显示的那个分支。

GitHub 拒绝 Lovable 的推送时会发生什么？

Lovable 不会丢弃改动，而是把它暂存到名为 lovable-sync 的分支。按 Lovable 文档，当 GitHub 因冲突或分支保护规则拒绝推送时就会这样处理，随后你通过常规审查流程把 lovable-sync 合并到受保护分支即可。

还有一道相关的保险：如果 Lovable 正在同步的分支在 GitHub 上被删除，Lovable 会把项目切换到名为 lovable-fallback 的新分支。另外，删除仓库本身会断开连接并停止同步，而重命名仓库则不会。

这些都不是翻译特有的问题，而是任何第二个写入方在 Lovable 周围都应遵循的行为。翻译 PR 就是一个守规矩的第二写入方：它以可审查 PR 的形式到来，从不直接推送到受保护分支。

翻译 PR 处在流程中的哪个位置？

介于 Lovable 的提交和你的合并按钮之间。在一个已安装 lovable-i18n skill 的 Lovable 项目里，流程如下，同时 Lovable 知识库中的指令规则 会确保新字符串持续被包裹。

  1. Lovable 编写功能，并用 Lingui 宏包裹新字符串，然后提交到同步分支。
  2. GitHub 工作流把被包裹的字符串提取到 src/locales/ 下的 PO 目录文件中，并把同步结果提交回仓库。Lovable 没有终端，所以提取必须在 GitHub 中运行，而不是在编辑器里。
  3. 转换是一次性的，在应用中完成：你连接仓库，globalize.now 一次性转换代码库，并以 PR 的形式交付翻译目录。之后，推送任务会翻译新增的目录条目，并同样以 PR 的形式交付翻译后的目录文件。
  4. 你把 PR 合并到同步分支。Lovable 拉取合并提交，应用随即渲染出新语言。

注意缺了什么：Lovable 里没有导入步骤，不用从网页后台导出，也没有在运行时加载翻译的插件。翻译后的文件就是仓库里的普通文件，这正是无需后台即可本地化 Lovable 应用 的核心思路，具体的连接步骤见 Lovable 集成页面。

Lovable 和翻译 PR 会冲突吗？

会，就是普通 Git 意义上的冲突，而且只要 PR 的存活时间短，就很少发生。冲突的前提是：从分出分支到合并之间，两个写入方修改了同一文件的相同行。

唯一现实的重叠点是 PO 目录文件。Lovable 新增字符串时，会在每个 src/locales/*/messages.po 末尾追加一条翻译为空的新消息，应用因此回退到源文本。翻译 PR 填充的，则是它创建时目录里已有消息的译文。如果 Lovable 在文件末尾追加新消息，而 PR 修改的是同一文件中靠前的条目，Git 会毫无怨言地合并两者。如果两者改了同一条目，就会出现冲突标记。

三个习惯可以缩小这个窗口。

翻译 PR 一打开，当天就合并。 一个 PR 搁置一周，期间 Lovable 又交付十个功能，只有这种情况才会让冲突变得繁杂。

不要手动编辑目录条目上的引用注释。 提取工作流会重新生成 #. 和 #: 行，所以解决冲突时，保留带译文的条目即可，注释交给下一次提取运行重写。

合并前先让过期分支追上最新进度。 如果 PR 分支已经落后，先更新它：

git fetch origin
git checkout <translation-branch>
git merge origin/<synced-branch>

解决 Git 标出的冲突，推送，然后合并。由于目录文件是文本，每条消息又是独立的一块，你要解决的冲突几乎总是某一个条目，而不是整个文件。

分支保护会带来什么变化？

它会多一道审查，而审查本来就是既定模型。以 PR 形式交付的翻译，要通过分支上设置的所有必需检查和审批。Lovable 自己的推送如果被受保护分支拒绝，会落到 lovable-sync，你通过同样的审查流程合并它。两条路径相互独立，谁也不会阻塞谁。

如果你保护了默认分支，又让 Lovable 编辑它，就要做好定期合并 lovable-sync 的准备；这是 Lovable 文档中记载的行为，不是翻译带来的问题。如果觉得烦，可以为 Lovable 的提交者放宽保护规则，或在项目设置中把同步分支切换为专用分支。无论哪种方式，都要让翻译 PR 指向 Lovable 正在同步的分支。

为什么用运行时翻译插件时没有这个问题？

因为它们从不写入你的仓库。Lovalingo 已于 2026 年 8 月 31 日停止服务，它在浏览器里翻译渲染后的页面，所以仓库里没有语言文件，也没有需要合并的 PR。通过迁移指南 转向提交式翻译目录的团队，是第一次把 Lovable 的 GitHub 同步当作双写入方系统来面对。

这是一次取舍，而且是值得的：译文归你所有，可版本管理、可被索引，而不是在渲染时临时租用。代价是你得清楚 Lovable 当前在哪个分支上。要让 Lovable 应用保持翻译同步，还有另一半问题，即翻译目录落后于代码，详见为什么每次发布翻译都会失效。如果你的应用还把内容存在数据库里，那一层在仓库之外，Lovable 应用中的数据库内容本地化 对此有专门讲解。

让两个写入方共用一个分支

查看项目 GitHub 设置中的分支选择器，把翻译 PR 合并到该分支，并把 lovable-sync 当作待办事项，而不是错误。如果你在 Lovable 中构建应用，希望翻译工作有人代劳而不是自己维护，vibe coder 页面 提供了整体介绍，定价 则单独成页。

globalize.now 把硬编码的应用文案转换为可直接翻译的语言文件，并在你持续发布时保持同步更新。

免费试用 globalize.now