Lovalingo、Weglot 与 globalize.now 对比：Lovable 应用该怎么本地化？

对 Lovable 应用来说，真正要做的选择是运行时翻译还是已提交的翻译。Lovalingo 和 Weglot 在页面加载后于浏览器中注入翻译；globalize.now 则在你的仓库中生成语言文件，并在每次推送时保持同步。globalize.now 是 AI 驱动的本地化基础设施：它从 AI 生成的代码中提取硬编码字符串，生成目录文件脚手架，并以 PR 的形式返回翻译好的目录，无需手动导出，也没有审核队列。本文从工作原理、SEO、安装方式和成本四方面对三者做对比。

Lovalingo、Weglot 和 globalize.now 究竟是怎么工作的？

它们分属两个阵营：运行时插件和已提交的目录文件。

Lovalingo 是一个 React 运行时库。你安装 @lovalingo/lovalingo，并用 provider 包裹应用；它在浏览器中检测内容并翻译，生成 locale URL 和 hreflang，还会加入语言切换组件。Weglot 同样是运行时层：一段 JavaScript 代码翻译你现有的站点，并通过子目录或子域名提供多语言版本，翻译编辑在 Weglot 自己的界面中完成。两者翻译的都是渲染后的页面，而不是你的源码。

globalize.now 位于更底层，是本地化基础设施。lovable-i18n Skill 会安装 Lingui，在 src/locales/[locale]/messages.po 为每个 locale 生成 PO 目录文件，用 <Trans> 宏包裹字符串，并添加一个 GitHub Action。连接仓库后，每次推送都会比对出新增字符串，并开一个包含更新后目录文件的 PR。翻译以真实文件的形式保存在你的仓库里，而不是某个厂商的运行时中。如果你想了解更广泛的方案类别，我们的 vibe coder 本地化指南 讲解了同样的取舍。

运行时翻译和已提交的目录文件有什么区别？

运行时翻译发生在浏览器中；已提交的翻译发生在你的构建阶段。

运行时插件先发布你的英文应用，再在页面渲染后替换文本。添加起来很快，也无需改动构建，但翻译内容是在用户查看时于客户端生成的。已提交目录文件的方案，则把字符串提取到语言文件中，作为代码库的一部分，翻译后的文本会被编译进应用输出的标记里。这些文件归你所有，保存在版本控制中，即使换工具也会随仓库一起迁移。

这也是 AI 构建的应用翻译容易漂移的原因。每次向 Lovable 下达指令都可能新增硬编码字符串，而运行时覆盖层只能捕获页面加载时看到的内容。把提取环节接入推送流程，才能让目录文件始终保持最新。我们在 为什么 Lovable 应用的翻译每次推送都会出问题 中讨论过这种失效模式。

翻译多久能上线？

同一次推送后的几分钟，对比最长一天。

运行时服务必须先处理你的站点，才能提供其他语言——Lovalingo 自己的应用提示，翻译和页面最多需要 24 小时才能上线。使用 globalize.now 时，翻译在推送时即刻进行：你一推送新字符串，它就开一个包含更新后目录文件的 PR，通常只需几分钟，翻译后的标记与引入它的代码在同一个周期内发布。对于每天都在迭代的 Lovable 应用，区别在于：合并时每次改动都已翻译完成，还是落后一天。

Lovable 应用的 SEO，哪种方案更好？

已提交的目录文件比运行时注入更可靠地被索引。

搜索引擎排名依据的是服务端返回的 HTML。当翻译在页面绘制后才于客户端注入时，爬虫往往只能看到原始的英文页面，各语言区域的索引也因此受损。Weglot 通过在子目录或子域名上渲染各语言并生成 hreflang 来缓解这一问题，但其官方指引也指出，hreflang 是在子目录或子域名集成下生成的，纯 JavaScript 方案不行。Lovalingo 同样会生成 hreflang 和 locale URL，但翻译文本依然是在运行时拼装的。

使用 Lingui、已提交的 PO 目录文件并配合 locale 路由，每种语言都是独立且可抓取的页面，翻译后的标记在浏览器执行任何脚本之前就已存在。对于希望在非英语搜索中被找到的 Lovable 应用，这种差异会随时间不断放大。同时，也不会出现未翻译文本的闪现，更不会因文本延迟替换而产生布局抖动，Core Web Vitals 指标也能保持良好。

在 Lovable 项目中，它们各自如何安装？

三者的入口各不相同：provider、代码片段，或 Skill。

Lovalingo 是 npm 安装，再加一个包裹应用的 provider。Weglot 是一个 script 标签加一个 API 密钥，在 Weglot 的界面中配置。globalize.now 则作为工作区 Skill 直接在 Lovable 编辑器内安装：

# In Lovable: Skills → Add → Import from GitHub
https://github.com/globalize-now/lovable-i18n

然后直接向 Lovable 下达指令：

Set up i18n for my project using the lovable-i18n skill.

Lovable 会检测你的技术栈（Vite SPA 或 TanStack Start），安装 Lingui，生成目录文件脚手架，包裹字符串，并添加 GitHub Action。你在 globalize.now 连接仓库、选择目标语言，然后合并即可。如果你是在 Cursor 或 Claude Code 中构建同一个仓库，请在已连接的仓库中运行 npx skills add globalize-now/globalize-skills 以获取完整套件。完整的操作流程见 Lovable 集成页面。

Lovalingo、Weglot 和 globalize.now 各自的定价是多少？

三者的计量方式不同：访客数、词数和字符数。

Lovalingo 提供最多 500 访客的免费层，之后改为按访客数定价。Weglot 提供 2,000 词和一种语言的免费额度，之后 €15/月含 10,000 词和一种语言，€29/月含 50,000 词和三种语言；其词数上限是固定配额，而非每月刷新的额度池。globalize.now 每个工作区 €20/月，其中包含每月 €20 的翻译额度（约 20 万词），超出部分按相同的每字符费率按 token 计费。不按席位、不按语言数量收费，项目数不限，注册即赠 €5 额度，无需绑定银行卡。

实际结论是：运行时免费套餐是测试小型站点摩擦最小的方式；而按字符计量、不收席位费和语言附加费的工作区套餐，在应用不断增加语言和页面时，成本更可预测。选计量方式要看应用实际怎么增长。想了解各工具更详细的功能对比，请看我们的对比页。

你的 Lovable 应用该怎么选？

看你更看重什么：叠加翻译的速度，还是翻译内容的所有权与可索引性。

如果想在一个下午内给线上站点接入多语言，又不在意非英语搜索排名，可选择 Lovalingo 或 Weglot 这类运行时插件。如果希望翻译保存在你的仓库里、以可索引的分语言页面发布，并且在你继续向 Lovable 提需求时自动保持最新，就选 globalize.now。前者是页面之上的翻译层，后者是代码库之下的本地化基础设施。对于打算拓展到多个市场的应用，自己掌握翻译目录和 SEO，通常是更有利的位置。

globalize.now 以提交到仓库的翻译目录来处理 Lovable 的 i18n。在工作区添加 lovable-i18n Skill，在仓库中运行 npx skills add globalize-now/globalize-skills，或到 globalize.now 了解工作原理。