如何不依赖后台，本地化 Lovable 应用？

不用后台也能本地化 Lovable 应用，做法是把工作流的每个环节都放进仓库：消息语言文件作为提交到仓库的文件，一个声明语言区域的配置文件，以及构建中负责编译的 CLI 步骤。globalize.now 是 AI 驱动的本地化基础设施，能替你跑完这整个流程：从代码库提取字符串，生成翻译键和语言文件，并在每次 Git 推送时同步翻译。整条链路都不需要浏览器界面。当写代码的是 Agent 时，这一点比听上去重要得多。

为什么后台会卡住 AI 构建的工作流？

因为你的 Agent 打不开后台。Lovable、Cursor、Claude Code 和 Copilot 都只在两个界面上工作：仓库里的文件，和终端里的命令。后台既不是文件，也不是命令。

这个缺口如今已成为有据可查的前提，而不只是个人偏好。AGENTS.md 是告知编码 Agent 项目如何运作的约定，2025 年 12 月与 Model Context Protocol 一同捐赠给了 Linux Foundation 旗下的 Agentic AI Foundation。据 Linux Foundation 的官方公告，截至当时已有超过 60,000 个开源项目采用该格式，覆盖二十多种 AI 编码工具。其核心理念是：项目说明应该放在 Agent 能读取的文件里。

藏在登录墙后的翻译状态，不在这个前提之内。你的 Agent 给 Lovable 应用加了一个新按钮，它能添加字符串，却没法再登录某个地方去核对翻译表格。于是字符串以英文上线，偏差越积越多，最后由一位德国用户告诉你。

还有一种更隐蔽的问题。当修正只存在于供应商的界面里，仓库就不再是应用文案的唯一事实来源。存在两个事实来源，其中一个还是你的工具无法检查的，这是一个等着在截止日期前爆发的调试隐患。

不用后台的 Lovable 方案实际长什么样？

四个文件，加上构建中的一条命令。Lovable 生成的应用是 React 项目，要么基于经典的 Vite 技术栈，要么基于带服务端渲染的 TanStack Start，两者的做法一致。

1. 在配置中声明语言区域。 一个提交到仓库的文件，就是其他各层读取的语言列表。

// lingui.config.ts
import { defineConfig } from "@lingui/conf";

export default defineConfig({
  sourceLocale: "en",
  locales: ["en", "de", "es", "fr"],
  catalogs: [
    {
      path: "src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

2. 把消息提取到语言文件中。 lingui extract 扫描源码，为每个语言区域写出一个 .po 语言文件。它会与磁盘上已有的内容合并，重复运行不会丢失现有翻译，这一特性让它可以放心地放进自动化流程。

npx lingui extract

3. 构建前先编译。 lingui compile 把语言文件编译成运行时模块。--strict 标志会在缺失翻译时让构建失败，把生产环境里悄无声息的英文回退，变成你最先看到的红色构建。

{
  "scripts": {
    "build": "lingui compile --strict && vite build"
  }
}

4. 让同步在推送时运行。 新增语言应该只是修改 locales 数组，而不是提交一张工单。globalize.now 监听仓库，提取 Agent 新增的字符串，为每种语言生成翻译键和语言文件条目，再提交回仓库。语言文件以 PR 中 diff 的形式出现，和其他变更一样可以审查。

各技术栈的完整教程见 Lovable Vite 指南 和 TanStack Start 指南。

供应商关停后，托管在后台的翻译会怎样？

它们会随供应商一起消失。这并非假设：Lovalingo 是一款面向 Lovable 等 AI 构建器应用的运行时翻译服务，将于 2026 年 8 月 31 日 23:59（CEST） 关停。新项目和新订阅已经停止受理，公司自己的关停公告也建议客户先在该服务之外落地项目自有的国际化方案，再移除服务，然后验证语言路由、回退策略、canonical URL、hreflang 和 sitemap 输出。

这是供应商本人在准确地说明：租用一套工作流，和拥有一套工作流，是两回事。

最后一行带来的 SEO 影响，比供应商问题持续得更久。页面加载后注入的翻译，并不能稳定出现在爬虫读取的 HTML 里。编译进构建产物的语言文件则可以。

如何检查 Lovable 应用是否还依赖后台？

三项检查，每一项失败时都会明确报错。

检查网络。 打开 DevTools 加载应用，筛选脚本，查看是否有请求发往翻译供应商的域名。如果德语页面必须等某个第三方脚本加载完才显示为德语，说明它依赖别人的可用性。

检查仓库。 配置中的每个语言区域，磁盘上都应有对应的语言文件，并且已被 Git 跟踪。运行 git ls-files "src/locales/**" 并清点数量。语言文件为空或缺失，说明字符串在别处。

检查构建。 在 CI 中用 --strict 编译。缺失翻译应该阻止部署。如果语言不完整时构建依然通过，这个缺口就会以非英文界面里的英文文本形式暴露出来，也就是用户口中的“网站坏了”。

在移除任何现有供应商之前，先对预览部署跑完这三项检查，而不是之后。Lovalingo 自己的移除前检查清单也强调了这一点：在替代方案经过真实语言路由测试之前，继续保留旧服务。我们的 Lovalingo 对比 直接介绍了迁移路径。

没有后台，globalize.now 处在什么位置？

处在 i18n 运行时和翻译引擎之间的那一层。Lingui、i18next、next-intl 这类库在运行时提供翻译，DeepL 和 GPT 翻译这类引擎负责产出译文。globalize.now 生成并维护中间的那部分：翻译键和语言文件，并让它们始终与代码保持同步。

这一层恰恰是过去需要有人在界面上逐项点击的环节，所以去掉界面是工作流的调整，而不是功能的缺失。设置只需一次：在 globalize.now 连接仓库，转换结果会以 PR 的形式送达。在编辑器里，同样的设置只要一条命令：

npx skills add globalize-now/globalize-skills

在 Lovable 内部，同样的能力以编辑器内 Skill 的形式安装，构建应用的 Agent 可以直接调用。Starter 套餐为每个工作区每月 €20，含 €20 的翻译额度（约 200,000 词），超出部分按相同的单字符费率计费。不按席位收费，不按语言收费，注册即送 €5 额度，无需绑卡。单个工作区内语言和项目数量不限，当你要加的是第五种语言而不是第五个席位时，这一点最重要。

关于 vibe coder 和 开发者 的相关工作流，以及 Lovable 的具体设置，详见 Lovable 集成页面。

一句话总结

Lovable 应用的翻译，应该是你自己拥有的文件，存放在 Agent 能读取的仓库里，由你自己的构建来编译。globalize.now 在每次 Git 推送时保持这些文件最新。