让 Lovable 应用支持多语言，最好的方法是什么？

让 Lovable 应用支持多语言，最好的方式是把 UI 文本提取到你自己仓库里的语言文件中，并在每次 Git 推送时翻译，而不是在运行时给页面外挂一层翻译。globalize.now 是 AI 驱动的本地化基础设施，做的正是这件事：它把 Lingui 接入你的 Lovable 项目，将硬编码字符串提取到 PO 目录，并在你每次推送时发起翻译 PR。翻译后的页面由你自己的服务端渲染，能被搜索引擎索引，而且无论之后换用什么工具，它们都留在你的代码库里。其他方案都会在这三点上牺牲其中一项。

本地化 Lovable 应用意味着什么？

本地化 Lovable 应用包含两项相互独立的工作：把生成代码里的所有硬编码字符串提取出来，再为每种语言渲染每个字符串的翻译版本。各种方案的差别，就在于第二项工作怎么做。

运行时翻译插件在浏览器里完成：先加载英文页面，再由脚本替换可见文本。仓库原生方案则在浏览器看到任何内容之前就完成了：字符串存放在语言文件中，应用在构建或请求时根据这些文件渲染对应语言。顺利的时候，两者的可见效果一样，但对速度、搜索索引以及你拥有什么的影响完全不同。

对 Lovable 来说，第一项工作比手写应用更难，因为 AI 生成的代码往往把字面字符串散落在各个组件里，没有任何 i18n 脚手架。这也是为什么vibe coding 应用的翻译每次推送都容易失效，除非翻译与代码一起纳入版本管理。

让 Lovable 应用支持多语言，最好的方法是什么？

把字符串提取到提交进仓库的语言文件中，并在每次推送时自动保持翻译最新。具体到 Lovable 应用，就是仓库里的 Lingui PO 目录，加上每次推送时翻译变更内容的同步机制。

这是最佳默认方案，因为它同时赢在三个方面。速度：翻译后的文本已经包含在服务端返回的 HTML 中，没有加载后的替换，也没有布局偏移。SEO：搜索引擎和 AI 答案引擎拿到的是可以抓取、可以引用的真实翻译页面。所有权：目录是仓库里的纯文本文件，无论你是否继续为某个供应商付费，应用都保持多语言。

globalize.now 负责整个闭环。你添加一个 Skill，提示 Lovable 配置 i18n，之后每次推送都会发起一个翻译 PR。它位于本地化基础设施层，在 i18n 运行时之上、可选的翻译管理工具之下，所以是对 Lingui 的补充而不是替代。同样的流程也适用于 Cursor、Claude Code、Bolt 和 Replit，不只是 Lovable。

为什么不直接用运行时翻译插件？

因为插件只为演示优化，却要为之后的一切买单。Weglot 这类运行时工具，以及类似的 React 翻译层，贴上就能用，对一次性原型来说，这确实是它们的优势。

应用一旦变得重要，代价就显现了。加载后再翻译，文本被替换时会造成布局偏移，影响 Core Web Vitals；翻译内容经由供应商的翻译层提供，而不是直接写进你的页面，搜索引擎更难稳定地索引。最关键的是，仓库里不会留下任何可迁移的内容。如果服务涨价、被收购或关停，你的多语言站点就又变回只有英文。

最后这个风险并非空谈。Lovalingo 是 Lovable 应用最知名的运行时翻译工具之一，它已宣布将于 2026 年 8 月 31 日关停，并已停止新用户注册。它给受影响用户的建议，是迁移到项目自有的国际化方案，也就是本文介绍的仓库原生方式。连供应商自己的退场建议都是“把翻译掌握在自己手里”，这就是从一开始就该这样做的最好理由。

这种最佳方法适用于 Lovable 的 TanStack Start SSR 技术栈吗？

适用，而且这次技术栈的变化让它更有说服力。新的 Lovable 项目基于 TanStack Start 并采用服务端渲染，页面在到达浏览器之前就已在服务端组装完成。

提交进仓库的 Lingui 目录与这种模式天然契合：服务端读取语言文件，首次绘制就渲染出翻译后的 HTML，不会闪现英文，客户端也无需替换任何内容。运行时插件则恰恰相反：服务端先绘制英文，加载后再覆盖，这正是服务端渲染本来要消除的闪烁。具体做法见 Lovable TanStack Start i18n 指南。较早的客户端渲染 Lovable 项目同样支持，因为无论应用如何渲染，目录都在你的仓库里。

如何在 Lovable 应用中配置 globalize.now？

全程不用离开 Lovable 编辑器。配置由提示词驱动，一共四步。

1. 添加 Skill。 在 Lovable 工作区添加 lovable-i18n，或在终端运行 npx skills add globalize-now/globalize-skills（加上 --all 可为所有 Agent 安装）。
2. 提示 Lovable。 让 Lovable 配置 i18n。Skill 会引导它安装 Lingui、提取硬编码字符串，并创建语言 PO 目录。
3. 推送。 globalize.now 会检测到这些目录，并针对你的目标语言发起翻译 PR。
4. 合并。 你的应用已支持多语言，之后的每次推送都会保持翻译同步。

配置一次，每次 Git 推送自动同步，无需人工干预。完整流程见 Lovable 集成页面，如果想看更详细的版本，还有一篇单独的让 Lovable 应用支持多语言指南。

最佳方案的成本是多少？

globalize.now 的 Starter 套餐为每个工作区每月 €20，项目数和语言数均不限，包括从右到左的语言。套餐每月含 €20 的翻译额度（约 200,000 个单词），超出后按相同的单字符费率继续计费。不按席位收费，也不按语言收费，注册即送 €5 翻译额度，无需绑定银行卡。

它不是这个品类里标价最低的，也没打算做到最低。运行时插件通常按项目计费，还把语言数量锁在不同套餐里，所以同时发布多个小型 Lovable 应用的开发者，每个应用都要再付一次钱。按工作区定价正是为了解决这个问题：一个典型应用在 5 种语言区域下约有 10,000 个翻译键，完全在套餐包含的额度之内。当前套餐详情见定价页。

Lovable 本地化方案速览