没有后台面板，怎么本地化 Base44 应用？

要本地化 Base44 应用，先用 Base44 提供的双向同步把应用连接到 GitHub，再把翻译目录作为已提交的文件保存在该仓库里。Base44 会在编辑器和仓库之间镜像每一处改动，所以语言文件一进入 main 分支，就成了应用的一部分。globalize.now 是 AI 驱动的本地化基础设施：它生成翻译键和语言文件，由项目里的运行时库负责加载。运行时路径上没有任何控制台，页面加载后也没有任何东西再去翻译它。

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

因为界面文本以字面量字符串的形式写在组件里。你让 Base44 生成预订页面时，它把 <h2>Your bookings</h2> 直接写进 React 组件，而不是去查翻译目录。每个标题、按钮文案、空状态、toast 和校验提示，都以你提示时所用的语言写进了 JSX。

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

让 Base44 “把应用翻译成德语”同样治不了根。你得到的，要么是模型查看过的那几个页面的德语副本，要么是它当场临时编出来的一个小型 strings 对象。下一条提示词写出的新文本又是英文，因为项目里没有任何约束要求文本必须走翻译目录。

Base44 实际生成了什么？

一个基于 Vite 的标准 React 项目。Base44 自己的项目结构文档展示了你在 Code 标签页和已连接仓库里看到的目录布局：src/pages 下每个路由一个文件，Home.jsx 对应 /，Settings.jsx 对应 /settings；src/components 存放可复用的组件，其中 ui/ 文件夹是预置组件；src/api、src/hooks、src/lib 和 src/utils 存放 SDK 客户端、hooks 和辅助函数。

对本地化来说，有两个目录尤其重要。functions/ 存放后端逻辑，每个函数一个 TypeScript 文件，这些文件会生成用户能读到的文本：错误响应、邮件、生成的文档。entities/ 以 JSON schema 文件的形式存放数据模型，而在双向同步下，实体由 Base44 管理，不在仓库里。

所以，Base44 应用有两类字符串可以由翻译目录覆盖，即 React 客户端和后端函数，另有一类无法覆盖，即实体里的数据。最后这一类下文还会再谈。

如何把 Base44 应用放进仓库？

Base44 自带连接功能。在编辑器里打开 Dashboard，点击 GitHub 图标，然后连接。你需要在自己的 GitHub 账号或组织下授权 Base44 Builder 应用，选择它可以访问的仓库，并为应用新建一个仓库。此后，仓库和编辑器会双向保持一致。

Base44 文档里有两条规则，决定了后面的所有做法。第一，同步是自动的：你在 Base44 里做的改动，包括 AI 根据提示词做的改动，都会直接提交到仓库，没有推送这一步，也没有手动推送的按钮。第二，回流的通道是 main 分支。合并到 main 的内容会出现在 Base44 应用里，master 或其他任何默认分支名都不受支持。合并之后，点击 Publish，新版本才会对用户上线。

双向同步需要 Builder 或更高级别的套餐，而且只有应用所有者才能完成首次连接。如果你的账号配置过旧版的单向 Export to GitHub 集成，GitHub 面板里有一个链接，可以先断开它，再用双向同步重新连接；单向导出永远不会把内容带回编辑器，而本地化恰恰需要这个方向。

在本地开发时，克隆仓库，运行 npm install，安装 Base44 CLI，再用 base44 login 和 base44 link 把克隆下来的代码关联到对应的应用。base44 dev 会让前端对接本地后端运行。把本地分支合并到 main，就会同步回 Base44。

对 Base44 应用来说，“无需控制台”是什么意思？

意思是翻译后的字符串不会存放在托管服务里，应用不必在运行时调用它，你也不必从中导出。它们就放在 src/locales/de.json 里，与 src/pages/Home.jsx 相邻，随同一批提交进行版本管理，在同一批 PR 里评审，并通过同一次 Publish 点击部署上线。

换成其他形态，在 Base44 上各有各的代价。在浏览器里翻译页面的运行时挂件不会改动源码，仓库里的应用依旧是英文的，而且每位访客在页面加载时都要承担翻译带来的延迟。自带编辑器的托管翻译工具把“事实来源”放在了仓库之外，于是 Base44 构建的双向同步，同步的是一份并不包含这些语言的代码库。这两种做法都在你和文本之间多塞了一个系统，而这些文本本来就存放在你拥有的文件里。

仓库原生的方式，则按同步机制的设计用法来用。目录是文件，文件会被提交，提交的文件会进入 main，main 会回到编辑器。整条流水线就是这样，其中没有任何一环是专为本地化设计的。

仓库原生方案如何运作？

在应用里连接仓库，运行一次转换。转换会找出组件和后端函数里的字面量字符串，为它们生成翻译键；如果项目里还没有运行时库，就接入 i18next 或 Lingui 之类的库；最后向你的仓库提交一个 PR，里面包含源语言目录和首批目标语言。这个 PR 就是全部交付内容：像评审其他改动一样在 GitHub 上评审它，合并到 main，Base44 就会把它镜像进编辑器。

之后由推送任务负责翻译新增的目录条目。你向 Base44 提示新功能，同步把它提交后，源语言目录里新增的翻译键会被翻译，并以 PR 的形式交付。合并，点击 Publish，功能就以所有语言上线了。你的提示习惯无需任何改变，应用在运行时也不会调用任何外部服务。

同样的方案已经在 Lovable、Bolt、v0 和 Replit 上跑通，机制完全一致，因为这四个工具交给你的都是常规的前端项目。Lovable 教程对目录结构讲得最详细，Bolt 指南涵盖了没有原生同步的构建工具该如何导出，针对 Lovable 经典技术栈的 Vite 指南在代码层面与 Base44 生成的 React 和 Vite 产物最接近。如果你还在比较各个构建工具，尚未选定其一，不妨从 vibe coder 概览看起。

哪些字符串存在于后端函数里？

凡是由服务端生成、用户会读到的文本都算：函数返回的校验错误、它发出的邮件的主题行、它生成的 PDF 正文、通知文案。这些字符串从不以 JSX 的形式出现，所以前端目录里没有它们，运行时挂件也看不到它们。

做法与客户端相同：从传入的请求中读取目标 locale，在函数端加载该 locale 的目录，并与客户端共用同一套键命名空间，这样同一条消息在 UI 和 API 响应里含义一致。由于 functions/ 目录就在仓库里，转换会像对待其他源码一样处理这些文件，目录文件就放在它们旁边。

实体里的内容怎么办？

这是 Base44 特有的边界。实体是你的数据模型，由 Base44 内部管理，在双向同步下不属于仓库的一部分。产品名称、服务描述或帮助文章这类记录是数据，不是界面文本，任何翻译目录都不会包含它们。

数据内容需要在实体本身增加语言维度：一个语言区域字段，或每种语言一个字段，并让查询按访客的语言区域读取。这套做法和我们在 Lovable 应用中的数据库内容 里介绍的一样，它是你在 Base44 实体编辑器里做的数据模型决策，而不是本地化工具的决策。尽早规划，因为给已有记录的实体补加语言字段，比在新实体上直接加要费事得多。

如果你之前用的是 Lovalingo 呢？

Lovalingo 已于 2026 年 8 月底停止服务，它公布的使用场景里，除了 Lovable、v0 和 Bolt，也包括 Base44。凡是通过它本地化过 Base44 应用的人，都得为这些字符串找个新去处。这属于迁移，而不是全新搭建：先导出，再转换。迁移指南会带你走完整个流程，对比页面则说明翻译从托管服务迁入你的仓库后有哪些变化。

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

确认同步是双向的，而不是旧版导出。在 Base44 里打开 GitHub 面板，检查它是否显示已连接仓库；如果面板里出现 “Looking for the old setup?” 链接，说明你用的是单向方式，需要重新连接。

确认默认分支是 main。Base44 只会把这个分支镜像回编辑器，合并到其他分支的 PR 永远到不了编辑器。

看看有没有运行时库。如果你曾让 Base44 添加过多语言支持，它可能已经加了 i18next 或一个手写的 context；转换会保留现有的实现，并向它供给翻译内容。

在添加第二种语言的记录之前，先决定实体内容的语言字段加在哪里。这部分，翻译目录帮不上忙。

检查路由。Base44 的页面基于文件路由，URL 里是否加 locale 前缀是只需做一次的路由决策，它决定搜索引擎如何识别各个语言版本。语言切换器与 hreflang 指南介绍了各种选择，这些经验可以直接套用。

从哪里开始

如果还没开启，先在 Base44 里启用 GitHub 双向同步，确认分支是 main，然后在应用里连接仓库。第一个 PR 会转换整个代码库。之后就只剩合并、点击 Publish，你要的语言就上线了。Lovable 集成页面介绍了同样的流程，针对的是提供编辑器内接入方式的构建工具，其中大部分内容可以原样用于 Base44。