Lovalingo 即将关停：2026 年 Lovable 应用的最佳替代方案

最好的 Lovalingo 替代方案，是一个不会再次关停的方案：把翻译提交到你自己的仓库，而不是再从另一个运行时服务租用。globalize.now 是 AI 驱动的本地化基础设施，正是为 Lovable 应用做这件事：在你的仓库中生成 Lingui 目录，并在每次 Git 推送时同步。Weglot、LocalizeJS 这类运行时插件接入更快，但它们复制了刚刚出问题的那种依赖。本文对比各种现实可行的方案，帮你在 8 月 31 日截止前做出选择。

---

Lovalingo 为什么关停？你的应用会怎样？

Lovalingo 将于 2026 年 8 月 31 日 23:59（CEST）关停。由于它在运行时翻译，当晚起它提供的所有翻译都会从访客面前消失。该服务由 Tempo AI LLC 运营，已通过全站横幅宣布关停：新项目和新订阅已停止受理，账单收款已暂停，客户数据的留存导出正在准备中。关停之前，仍可通过 [email protected] 联系支持。

目前没有指定继任者。最能说明问题的是 Lovalingo 自己的迁移指引：它建议用户在移除插件之前，先实现由项目自己持有的国际化方案。换句话说，厂商自己也认为，解法不是再换一个插件。

这次关停之所以是彻底失效，而不只是不方便，原因如下。运行时插件把你的翻译存放在它的服务器上，并在英文页面加载后，在访客的浏览器中替换文本。你的代码库里什么都没有。服务器一旦下线，应用就立刻变回纯英文，连导出的途径都没有了。如果你的多语言 SEO 依赖插件生成的语言版本，这些版本也会从索引中消失。完整的干净移除清单见 Lovalingo 关停迁移指南。

---

Lovable 应用有哪些最佳的 Lovalingo 替代方案？

现实可行的路径有五条，可分为两大阵营：把翻译放进你仓库的工具，以及在运行时把翻译“租”给你的工具。

globalize.now 是 Lovable 应用的最佳 Lovalingo 替代方案吗？

如果你想拥有自己的翻译，答案是肯定的，因为它正是为 Lovalingo 关停指引所推荐的方案而设计的：由项目自己持有的国际化。你在 Lovable 工作区添加 lovable-i18n Skill，并提示 Lovable 配置 i18n。结果是：仓库中使用 Lingui，并提交 PO 目录，在 Lovable 现在生成的 TanStack Start 技术栈上进行服务端渲染。这意味着搜索引擎可以索引真实的语言区域 URL，翻译前也不会闪现英文。此后，globalize.now 会在每次推送时自动开一个翻译 PR，无需任何手动步骤。

定价为每个工作区每月 €20，包含每月 €20 的翻译额度（约 20 万词），超出部分按相同的单字符费率按 token 计费。不按席位收费，也不按语言收费，起步即送 €5 额度，无需绑定信用卡。Lovalingo 迁移用户目前可享三个月免费用量，详见迁移指南。

有一点要说在前面：你的 Lovable 项目需要开启 GitHub 同步，因为翻译目录存放在仓库里。这也正是关键所在。与 Lovalingo、Weglot 的三方完整对比中有更深入的分析。

Weglot 是好的 Lovalingo 替代方案吗？

Weglot 是最接近一对一替换的选择，而问题恰恰在这里：它沿用的，正是刚刚让你栽跟头的运行时模式。它很成熟，出现在 Lovable 官方的多语言指南里，可视化配置也很快。但它在英文页面加载之后才翻译，套餐按翻译词数分档，翻译存放在 Weglot 的系统里，而不是你的仓库里。从 Lovalingo 迁到 Weglot，等于重建了同样的依赖，然后祈祷这家厂商比上一家活得久。

应该从 Lovalingo 换到 Lokalise 吗？

只有在你有人工译员、需要审校流程时才值得考虑，因为 Lokalise 处在完全不同的层面。它面向团队管理译员工作流，采用按席位收费的套餐，目标客户是企业而非独立开发者。它也不会替你省掉底层工作：在译员平台有东西可管之前，你的 Lovable 应用仍然需要正确的 i18n 接入（键、目录、语言区域路由）。对大多数 Lovable 开发者来说，它比实际需求重得多。

LocalizeJS 能替代 Lovalingo 吗？

LocalizeJS 是 Lovable 本地化领域最活跃的新玩家，但它和 Lovalingo、Weglot 属于同一类运行时方案。它发布了专门的 Lovable 文档，显然在这个细分领域持续投入。但结构上的取舍没有变：翻译发生在页面加载之后，访客看到哪些语言，取决于厂商的在线状态和能否持续存在。把它当作租赁来评估，因为它本质上就是租赁。

Paraglide 或 Intlayer 能替代 Lovalingo 吗？

可以，前提是你愿意自己接入 i18n。两者都是支持 TanStack Start 的开源库，一切都放在你的仓库里，你完全拥有所有内容，也没有任何 SaaS 介入。代价是提取、翻译和后续同步都要你自己来：Lovable 每生成一个新字符串，都需要你去发现、加键并翻译。如果你乐意搞这套底层接线，这是一条扎实的路。如果你想要所有权，又不想自己接线，这正是 globalize.now 为 vibe coder 补上的缺口。

---

该选哪个 Lovalingo 替代方案？

按你想拥有什么来选，而不是按接入有多快来选。

• 想要经得起厂商更迭的翻译，以及 Google 能索引的语言区域 URL：通过 globalize.now 的 Lovable 集成使用已提交的翻译目录。
• 想要最快的可视化替换，并接受再次租用：选 Weglot 或 LocalizeJS，但要清楚代价。
• 有人工译员和审校要求：在完善的 i18n 接入之上叠加 Lokalise，而不是用它取代 i18n 接入。
• 想要零厂商依赖，也不介意自己接线：选 Paraglide 或 Intlayer，手动接入。

无论选哪个，都要在 8 月 31 日前决定。关停之后，就没有可迁移的导出内容了。

---

如何在 8 月 31 日前迁移出 Lovalingo？

简而言之：保存好数据，干净地移除插件，再配置由项目自己持有的 i18n。

1. 趁 Lovalingo 服务还在运行，下载你的数据留存导出文件。
2. 移除 Lovalingo 脚本及其注入的所有语言切换元素，避免关停后仍有失效代码被发布。
3. 配置由项目自己持有的国际化方案。在 globalize.now 中，就是在 Lovable 工作区添加 lovable-i18n Skill，并提示 Lovable 配置 i18n；之后会自动生成已提交的翻译目录，并在每次推送时同步。
4. 重新检查多语言 SEO：带 hreflang 的真实语言区域路由，取代插件生成的语言版本。

分步迁移指南会带你走完以上每一步，并附完整清单。

厂商来来去去，仓库里的文件却一直都在。globalize.now 一次性配置好已提交的翻译目录，并在每次 Git 推送时同步，所以这个领域里的下一次关停公告，就是别人的迁移难题了。