Lovalingo 关停前，如何导出我的翻译？

现在就向 Lovalingo 申请数据留存导出，然后把翻译包转换为 PO 目录，提交到你自己的仓库。Lovalingo 正在为活跃项目准备导出文件，在服务于 2026 年 8 月 31 日 23:59（CEST）关闭之前，可通过 [email protected] 获得支持。globalize.now 是 AI 驱动的本地化基础设施：它会读取你抢救出来的字符串，在仓库中生成语言文件，并在每次 Git 推送时保持同步，所以这是你最后一次需要做的翻译导出。

8 月 31 日 Lovalingo 关闭后，我的翻译会怎样？

除源语言外，其他语言都会停止渲染，因为翻译文本从一开始就不在你的应用里。Lovalingo 是一个运行时层：你的 Lovable 应用以英文发布，由它们的服务按访客替换文本。服务一停，替换也就停了。

关闭条款已公布在 Lovalingo 的服务关闭页面上。新项目和新订阅已经停止开放。活跃项目可使用至 2026 年 8 月 31 日 23:59（CEST）。账单收款已暂停，活跃项目的保留导出正在准备中。

这个截止日期其实是数据的截止日期。过了这个时间点，既没有可供导出的服务，也没有可以求助的支持邮箱。如果你的应用现在靠法语或德语获得流量，除非提前导出，否则产出这些翻译的工作成果会就此消失。

如何把翻译数据从 Lovalingo 中导出？

申请保留导出，并与源码仓库一起妥善保存。根据关闭页面的说明，导出内容包含项目的可用配置、路由、翻译包、覆盖项和完整性证明：运行时掌握的关于你各语言的一切信息。

1. 申请导出。 活跃项目的导出文件正在准备中。如果你的项目还没收到，请发邮件至 [email protected]，说明需要为你的项目交付导出文件。
2. 同时保存两样东西： 导出文件，以及当前源码仓库的快照。导出文件描述翻译内容，仓库则是这些翻译所属的应用。
3. 先别卸载 Lovalingo。 其官方指引也建议，在替代方案通过生产检查之前保持安装。切换期间，两套系统可以并行运行。

翻译包是最关键的部分。它保存了每个 locale 实际的翻译字符串，以及你在 Lovalingo 控制台中做的所有手动覆盖。覆盖项最容易被忽略：这些改动只存在于 Lovalingo 中，无法用任何机器翻译引擎重新生成。

如何把 Lovalingo 翻译包转换为仓库自有的目录？

把翻译包转换为 gettext PO 目录并提交。PO 是纯文本，在 Git 中 diff 清晰，也是 Lingui 为 React 应用编译所用的格式，覆盖 Lovable 生成的两种技术栈：经典的 Vite SPA，以及较新的默认方案 TanStack Start SSR。

运行时翻译包通常是每个 locale 一份键值映射。转换只需一个小脚本，算不上一个项目：

// convert.mjs — JSON bundle → PO entries
import fs from "node:fs";

const locale = process.argv[2]; // e.g. "de"
const bundle = JSON.parse(fs.readFileSync(`bundles/${locale}.json`, "utf8"));

const po = Object.entries(bundle)
  .map(([source, translated]) =>
    `msgid ${JSON.stringify(source)}\nmsgstr ${JSON.stringify(translated)}\n`)
  .join("\n");

fs.writeFileSync(`src/locales/${locale}/messages.po`, po);

具体字段名因导出内容而异，运行前请先核对你的导出文件。但原则不变：输入源字符串，输出 msgid/msgstr 键值对，每个 locale 一个 .po 文件，提交到 src/locales/ 下。

如果不想手写转换脚本，Lovalingo 迁移指南 介绍了托管迁移方案，并且在关闭窗口期内，Lovalingo 迁移用户可享三个月免费用量。

如何把抢救出来的目录接入我的 Lovable 应用？

在 Lovable 工作区添加 lovable-i18n Skill，然后让 Lovable 配置 i18n；该 Skill 会让 Lingui 适配你的技术栈，并读取你已提交的 PO 目录。在 Lovable 编辑器之外，可以用下面的命令安装同样的配置：

npx skills add globalize-now/globalize-skills

具体的接入细节取决于你使用的技术栈。2026 年 5 月之前生成的应用大多是经典的 Vite SPA；较新的应用默认使用带 SSR 的 TanStack Start。两种情况都有专门的教程：Lovable Vite 应用的 i18n 和 Lovable TanStack Start 技术栈上的 i18n。Lovable 集成页面 完整介绍了该 Skill 的全部工作流程。

此后，Lovalingo 过去在运行时解决的维护问题，改由你的仓库来解决。你新增的字符串会在每次推送时被提取、翻译，并作为翻译 PR 提交。定价为每个工作区每月 €20，其中包含每月 €20 的翻译额度（约 200,000 词），超出部分按 token 计量，单字符费率相同：不按席位收费，也不按语言收费，所以添加第六种语言和第二种语言成本一样。专为不想再操心语言文件的 vibe coder 打造。

移除 Lovalingo 之前应该测试什么？

先在生产条件下测试替代方案；移除是最后一步，而不是第一步。Lovalingo 自己给出的移除前流程就是一份很好的检查清单，也可以直接对应到使用已提交目录的方案：

• 直接访问 locale URL。 每种语言都应有对应的真实路由（/de/、/fr/），强制刷新也能正常加载，而不只是靠客户端切换。
• 缺失键与回退。 在本地删除一条翻译，确认应用会回退到源字符串，而不是渲染空白。
• 每个 locale 的 SEO 元数据。 逐个语言检查标题、描述、canonical URL、hreflang 配对和 sitemap。服务端渲染的 locale 路由无需执行 JavaScript，爬虫就能看到这些内容，详见让 Lovable 应用支持多语言的指南。
• 最后才移除小组件。 使用已提交目录的版本通过测试后，再移除 Lovalingo，并重新跑一遍检查。

这次切换还有一个不起眼的好处：清单上的任何一项，都不会因为供应商调整套餐而出现回归。目录现在是你 Git 历史中的文件。

这次导出只是一次性的抢救。globalize.now 让它成为最后一次：配置一次，之后每次 Git 推送都会自动提取、翻译并提交你的目录。