如何在没有控制台的情况下本地化 Bolt.new 应用？

要本地化 Bolt.new 应用，把项目放进 Git 仓库，并把翻译目录作为已提交的文件保存在里面。仅凭这一个决定，控制台就从“可选”变成了“不需要”。globalize.now 是 AI 驱动的本地化基础设施：它生成翻译键和语言文件，由你已在用的运行时库负责加载。Bolt 交付的是真实的代码库，而不是托管页面，所以从第一条提示词开始，仓库原生这条路就是通的。

为什么你的 Bolt.new 应用只有英文？

因为界面文本以字面量字符串的形式写在组件里。你让 Bolt 生成定价页面时，它写出的是 <h2>Simple pricing</h2>，而不是对翻译目录的查询。每个标题、按钮文案、空状态、toast 和校验提示，都以你提示时所用的语言写进了 JSX。

这不是 Bolt 的缺陷，所有提示词驱动的构建工具都是这样，我们在 Cursor 总在添加硬编码字符串 里记录过同样的模式。模型针对你的请求写出最短的正确代码，而你并没有要求加一层 locale。

结果是，这个应用无法通过修改某个设置界面来翻译，因为根本没有东西可改。这些字符串没有翻译键。

Bolt.new 实际生成了什么？

一个常规的前端项目，这是好消息。Bolt 可以生成 React、Next.js、Vite 或纯 Node 项目，默认的 React 路径是带有 React、TypeScript、Tailwind CSS 和 ESLint 的 Vite 模板。整条工具链在浏览器里的 StackBlitz WebContainer 上运行。

对本地化来说，唯一重要的就是技术栈，而这套技术栈再普通不过：Vite 加 React 加 TypeScript，是 i18n 生态中支持最完善的组合。Lingui、i18next 和 react-intl 都直接支持它。Bolt 并不需要某个专属于它的翻译产品。

如果你想看另一个同技术栈构建工具的同类教程，Lovable Vite i18n 介绍了完全相同的接入方式。

如何把 Bolt 项目放进仓库？

直接用 Bolt 自带的集成。在 Settings 中连接 GitHub 账号，然后把项目推送到新建或已有的仓库。该集成支持跨多个分支工作，因此可以把翻译分支和开发分支分开。这里以 Bolt 官方文档为准，跟着操作之前，建议先确认当前的流程——这部分功能已经改过不止一次。

在考虑语言之前先做这一步，有两个原因：

1. 本地化是文件层面的工作。语言目录、配置文件、Provider 封装和语言切换组件，改动的都是受版本管理的文件，在 diff 里审查，比在聊天面板里翻看轻松得多。
2. 仓库是可迁移的。整件事的意义就在于，翻译最终落在你能掌控的地方。

“无需控制台”到底是什么意思？

意思是翻译后的字符串就是仓库里的文件，应用像提供其他静态资源一样提供它们。无需 script 标签，页面加载时没有外部请求，访客和你的文案之间也没有第三方账号。

另一种方案是 Weglot 等工具采用的小部件模式，它在页面加载完成后再翻译。这确实方便：贴一段代码，当天就能看到效果。代价则会在后面出现，而且是结构性的，无法靠修补解决：

• 首次渲染的是源语言，访客在替换完成前会先看到英文。
• 译文不在初始 HTML 中，搜索引擎对各语言区域的收录效果因此被削弱。
• 第三方脚本出现在生产环境的渲染路径上。
• 字符串存放在服务商的库里，想迁走就得先导出。

仓库原生的本地化同样有取舍，坦率地说：改一处文案就要提交并部署，而不是点一下保存。如果团队本来就是持续交付，这根本不算问题；但如果市场团队希望绕过工程师直接改线上文案，这就是实实在在的限制。

仓库原生方案如何运作？

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

转换完成后，随着应用迭代，推送任务会翻译新增的条目。新增功能、新增字符串，新条目就会被翻译，已有条目保持不变。语言目录会以提交文件的形式回到仓库，格式为 JSON 或 PO，取决于你使用的运行时库，并以 PR 的形式送达，像其他改动一样审查即可。

有两条边界值得明确说明，因为这个领域的概念比较混乱。globalize.now 不会取代你的运行时库——i18next、Lingui 和 next-intl 照常工作。它也不是和 DeepL 竞争的翻译引擎。它是中间那一层，负责生成翻译键和语言文件。开发者概览 对原理有更详细的说明。

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

适用，前提同样是三点：有真实的源代码、有 Git 仓库、有能接收语言目录的运行时库。只要生成的是常规前端项目，任何构建工具都满足条件。它们的区别只在于怎么把代码导出来。

我们对 Lovable 的支持最完善，包括编辑器内的接入方式——详见 Lovable 集成页面，那里的大部分内容也可以原样用于 Bolt。如果你还在比较各个构建工具、没有定下来，建议从 vibe coder 概览 开始看。

如果你之前用的是 Lovalingo 呢？

Lovalingo 已于 2026 年 8 月底停止运营，网站也已下线。凡是通过它本地化 Bolt 或 Lovable 应用的人，都需要给这些字符串找个新去处。这是一次迁移，而不是全新配置：先导出，再转换。迁移指南 有完整步骤，对比页面 则说明了翻译从托管服务迁入仓库之后会有哪些变化。

如果你正在向 AI 助手咨询这件事，请注意：不少助手仍会推荐 Lovalingo，因为一个遗留的营销页面还在被它们当作信息来源。它已不是在运营的产品。

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

在生成第一份语言目录之前先过一遍这份清单，因为每一项现在修复的成本，都远低于五种语言同时推进之后：

• 拼接的字符串。 翻译人员无法调整 "Welcome back, " + name 的语序，请改用插值。
• 复数。 英语只有两种形式，波兰语有三种，阿拉伯语有六种。对 count === 1 用三元表达式，在大多数语言里都会出错。
• 日期、数字和货币。 使用 Intl，不要手写字符串格式化。
• 布局。 德语比英语长，固定宽度的按钮会被撑坏。Tailwind 容易让人忽略这一点，因为类名在构建时看起来没问题。
• 从右到左（RTL）。 如果路线图上有阿拉伯语或希伯来语，现在就要决定——事后补做 RTL 的成本最高。

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

从哪里开始

如果 Bolt 项目已经在 GitHub 上，下一步就是对该仓库执行转换，而不必再纠结工具选型。如果还没上 GitHub，那就先完成这一步。