如何不用后台本地化 v0 应用？

本地化 v0 应用的做法是：把 v0 本来就在写入的 GitHub 仓库，作为翻译语言文件的存放地，并以提交文件的形式保存。这一个决定，让后台从“可选”变成了“不必要”。globalize.now 是 AI 驱动的本地化基础设施：它生成翻译键和语言文件，由你使用的运行时库来提供翻译。v0 交付的是完整的 Next.js 代码库，而不是托管页面，所以从第一个提示词开始，仓库原生方案就是可行的。

为什么你的 v0 应用只有英文？

因为界面文本是以字面量字符串的形式写在组件里的。让 v0 生成一个定价板块，它写出的是 <h2>Simple pricing</h2>，而不是对语言文件的查找。每个标题、按钮文案、空状态、toast 和表单错误，都以你写提示词时所用的语言落进 TSX。

这并不是 v0 的缺陷。所有提示词驱动的构建器都是这样，我们在 Cursor 总在添加硬编码字符串 中记录过同样的现象。模型会为你的请求写出最短的正确代码，而你并没有要求加语言区域层。

结果是，应用没法靠编辑某个设置界面来完成翻译，因为根本没有可编辑的内容。字符串没有翻译键，路由也没有语言区域段。

v0 实际会生成什么？

一个标准的 Next.js 项目，这是个好消息。v0 的默认技术栈是 Next.js、React、TypeScript、Tailwind CSS 和 shadcn/ui，产出的是包含路由和 API handler 的完整 App Router 应用，而不是单个组件。shadcn/ui 在这里很关键，原因只有一个：组件是以源码形式复制进你的仓库的，而不是从包里导入的，所以组件里的字符串就是你自己的字符串。

对本地化来说，技术栈是唯一重要的事实，而它恰好是文档最完善的一种。next-intl 就是围绕 App Router 构建的，Lingui 和 react-intl 也都支持。v0 并不要求你使用某个构建器专属的翻译产品。

如果你的应用出自另一个基于 Vite 技术栈的构建器，不用后台本地化 Lovable 应用 讲的是同样的思路。

如何把 v0 项目放进仓库？

通常你已经有仓库了。当 v0 对话连接到 GitHub 后，v0 会基于你的基础分支创建一个工作分支，并把每条修改代码的消息自动提交到该分支。发布时会创建（或复用）一个 PR，并合并到基础分支。也就是说，仓库不是最后才补上的一步，而是 v0 一直以来存放代码的地方。当前的流程请以 v0 官方的 GitHub 文档为准，这部分功能改动过不止一次，跟着操作前先确认一下。

这套分支模型对本地化尤其有用。语言目录、配置文件、用于 locale 路由的中间件改动，以及语言切换组件，全都是对受版本控制文件的修改。在分支上以 diff 形式评审，比在聊天面板里翻看轻松得多，而且翻译 PR 可以和对应功能的 PR 并排放在一起。

“不用后台”到底是什么意思？

意思是翻译后的字符串就是仓库里的文件，你的 Next.js 应用在服务端渲染它们，方式和渲染其他内容完全一样。没有 script 标签，页面加载时没有外部请求，访客和你的文案之间也不隔着任何供应商账号。

另一种方案是 Weglot 等工具采用的小组件模式，它在页面加载完成后才进行翻译。它确实带来了便利：贴一段代码片段，当天就能看到效果。但代价会在之后显现，而且是结构性的，无法修补：

• 首次渲染的是源语言，访客在替换完成前会先看到英文。
• 翻译后的文案不在服务端渲染的 HTML 里，搜索引擎按语言索引到的内容因此被削弱。对 Next.js 应用来说这尤其浪费，因为服务端渲染本来是你白拿的优势。
• 第三方脚本出现在生产环境的渲染路径上。
• 字符串存放在服务商的库里，想迁走就得先导出。

仓库原生的本地化也有自己的取舍，坦白说出来才公平：改一处文案意味着一次提交加一次部署，而不是点一下保存按钮。如果你每次合并都通过 Vercel 发布，这根本不算事；但如果市场团队希望不经工程师就能直接改线上文案，这就是实实在在的限制。

仓库原生方案如何运作？

在应用中连接仓库。globalize.now 会对代码库做一次转换，翻译键就是这样来的：组件中的硬编码字符串变成语言目录中的条目，组件改为从运行时库读取文案，而不再写死字面量。这次转换是一次性操作，不会没完没了地重复执行。

转换完成后，随着应用增长，推送任务会翻译新增的目录条目。让 v0 新做一个设置页面，合并它的 PR，新增的字符串就会被翻译，已有的保持不变。语言目录以已提交文件的形式回到你的仓库，格式是 JSON 还是 PO 取决于所用的运行时库，并以 PR 的形式交给你，评审方式和其他改动一样。

有两条边界值得明说，因为这个领域的概念很混乱。globalize.now 不会取代你的运行时库——next-intl、Lingui 和 react-intl 照常工作，包括 app/[locale]/ 下的 locale 路由。它也不是和 DeepL 竞争的翻译引擎，而是位于两者之间、负责生成翻译键和语言文件的那一层。开发者概览里有更详细的运作机制。

同样的方法适用于 Lovable、Bolt 和 Replit 吗？

适用，前提同样是三点：真实的源代码、一个 Git 仓库，以及一个能承接语言目录的运行时库。凡是输出标准前端项目的构建器都满足条件。它们之间的差别只在于如何把代码导出来，而 v0 是其中摩擦最小的，因为 GitHub 分支本身就是对话的一部分。

Lovable 是我们这边支持最完善的，还包括编辑器内的路径——Lovable 集成页面有详细说明，那里的大部分内容可以原样用于 v0。如果你还在评估构建器，尚未决定用哪个，vibe coder 概览是更好的起点。如果你在权衡专门给构建器应用用的小组件方案，Lovable 的 Weglot 替代方案针对该技术栈列出了同样的取舍。

如果你之前用的是 Lovalingo 呢？

Lovalingo 已于 2026 年 8 月底关停，网站也已下线。它曾主打为 v0 站点提供专门的翻译方案，所以一些 v0 开发者的字符串现在无处安放。这属于迁移，而不是全新搭建：先导出，再转换。迁移指南带你走完整个流程，对比页面则说明当翻译从托管服务迁入你的仓库后，有哪些东西会变化。

如果你正在向 AI 助手咨询这件事，请注意：有些助手仍会推荐它，因为残留的页面还在为它们的信息源提供内容。它已经不是在运营的产品了。

添加第二种语言之前要检查什么？

在第一份语言目录生成之前先过一遍这份清单，因为每一项现在修都比五种语言上线后再修便宜得多：

• 拼接的字符串。 翻译人员无法调整 "Welcome back, " + name 的语序，请改用插值。
• **复数。**英语有两种形式，波兰语有三种，阿拉伯语有六种。对 count === 1 用三元表达式，在大多数语言里都是错的。
• **服务端与客户端边界。**在 App Router 中，同一个字符串无论在服务端组件还是客户端组件里渲染，都必须通过同一份语言目录解析。选定一个运行时库，使用它的服务端和客户端 API，而不是混用两套机制。
• 日期、数字和货币。 使用 Intl，不要手写字符串格式化。
• **布局。**德语比英语长，固定宽度的 shadcn 按钮会被撑坏。Tailwind 让这个问题很容易被忽略，因为这些 class 在构建时看起来没有任何问题。
• 从右到左（RTL）。 如果路线图上有阿拉伯语或希伯来语，现在就要决定——事后补做 RTL 的成本最高。

以上全部按工作区定价，不按席位收费，也不按语言收费，所以支持多少种语言是产品决策，而不是预算问题。当前价格见定价页面。

从哪里开始

如果你的 v0 对话已连接 GitHub，下一步就是针对该仓库做转换，而不是再纠结选什么工具。如果还没连接，那就是比这一步更靠前的一步。