现代应用有本地化难题，而问题不在翻译。
过去十年，本地化行业的重心一直放在翻译工作流上——帮团队管理译员、审校字符串、发布多语言内容的工具。
Phrase、Lokalise、Crowdin 和 Transifex 等工具非常擅长管理翻译。但它们都默认了一个关键前提：你的应用已经完成了国际化。现实中，大多数应用并没有。随着 AI 生成代码的兴起，这个缺口即将演变成大问题。
本地化工具忽略的隐藏 i18n 层是什么？
本地化和国际化常被混为一谈，但它们并不相同。
本地化（l10n）——把应用翻译成不同语言。
国际化（i18n）——改造代码库，让翻译成为可能。
国际化包括：提取 UI 字符串、生成翻译键、创建语言文件、支持复数规则、格式化数字和日期、支持从右到左的语言，以及杜绝硬编码的 UI 文本。大多数本地化工具都从这一步之后才开始工作，但在许多真实的代码库里，这一步根本没做过。
规范国际化的代码长什么样
在结构良好的应用里，UI 文本通过翻译键引用。
<button>{t("checkout.submit_order")}</button>
文本则存放在语言文件中：
/locales/en.json
{
"checkout.submit_order": "Submit order"
}
这样的结构让翻译工具和翻译引擎能够稳定运作。
大多数应用的真实面貌
现实中，许多应用是这样的：
<button>Submit order</button>
<h1>Welcome back</h1>
<p>Your payment was successful</p>
乍一看这没什么问题。但当它乘以数百个组件、数千个 UI 字符串，整个代码库就都默认 UI 只有英文。一旦想支持另一种语言，问题就会处处冒出来。
- 德语文本会长出约 30%，按钮因此溢出。
- 阿拉伯语需要从右到左的布局，整个界面随之错乱。
- 各语言的复数规则不同，提示语因此出现语法错误。
没有国际化架构，本地化很快就会演变成一场大规模重构。
AI 代码生成如何让本地化更难？
现代开发越来越依赖 AI 编码工具：Cursor、GitHub Copilot、ChatGPT、Replit、Lovable、Bolt。这些工具追求的是速度和能跑的 UI，而不是架构。
典型的生成代码是这样的：
<button>Submit</button>
<h2>Welcome back</h2>
<p>Your order has been confirmed</p>
在一个典型的 AI 生成项目里，你可能会发现：成百上千个硬编码的 UI 字符串、重复的界面文本、没有翻译键、没有语言文件、不支持复数。换句话说：demo 完美，本地化架构一塌糊涂。
这种模式可以预见：团队快速构建、上线、获得增长——然后才意识到：“整个 UI 都是硬编码的英文。”此时再加本地化，就得改动大半个 UI 代码库。
我们看到的真实模式
扫描小型 AI 生成的 SaaS 项目时，这个模式很快就会浮现。在我们分析的一个 React 原型项目中：312 个文件里有 1,284 个 UI 字符串，且没有任何国际化结构。例如：
<h1>Welcome back</h1>
<button>Start free trial</button>
<p>Your payment failed</p>
要加上本地化，团队得先：从数百个组件中提取 UI 字符串，引入翻译键，构建语言文件，重写 UI 逻辑——这之后才能开始翻译。我们在 AI 生成的项目中反复看到这个模式。
为什么传统本地化工具搞不定 AI 生成的代码？
大多数本地化工具是为翻译团队设计的，而不是为开发者。它们的工作流默认开发团队已经实现了：i18n 框架、翻译键、语言文件结构、字符串提取流水线。但现代代码库——尤其是 AI 生成的——往往完全缺少这个基础。于是团队面对的是一个意料之外的现实：在翻译任何内容之前，必须先重构整个 UI 层。
本地化技术栈中缺失的一层
如今的本地化技术栈通常是这样的：
但缺了关键的一环。真正需要发生的是：
缺失的这一层需要：扫描代码库、提取 UI 字符串、生成翻译键、构建语言文件、检测重复字符串、创建术语表。完成这些之后，翻译工作流才能真正开始。
为什么这个问题即将集中爆发
三大趋势正在交汇。
- AI 优先的开发方式。 越来越多的应用借助 AI 辅助编码构建，一些初创公司的代码库已经大部分由 AI 生成。为了快速上线，架构往往被放到次要位置。
- 独立开发者井喷。 每周都有成千上万的新 SaaS 产品上线，其中大多数以英文优先。
- 第一天起就面向全球用户。 即使是小型产品，也会很快吸引来自德国、巴西、印度、日本的用户。国际用户一出现，本地化就变得迫在眉睫，但架构通常还没准备好。
另一种思路
如果国际化可以自动完成呢？在 globalize.now 连接仓库，做的就是这件事。首次转换只在应用内运行一次，并回报检测到的结果：
✔ Found 128 UI strings
✔ Generated 92 translation keys
✔ Created /locales/en.json
✔ Updated 41 files
Done in 2.7s
该工具会：扫描代码库、提取面向用户的字符串、生成结构化的翻译键、创建语言文件、自动改写 UI 代码。把这样的代码：
<button>Submit order</button>
变成这样：
<button>{t("checkout.submit_order")}</button>
整个代码库瞬间就具备了可翻译的条件。
一个新品类：AI-Ready 本地化
下一代本地化工具不会从译员开始，而是从代码转换开始。工作流会更像这样：
当前本地化生态中最大的空白，就是自动完成第一步：让代码库做好面向全球用户的准备。
了解 globalize.now 如何为开发团队自动完成这件事。
想了解从 CAT 工具到 AI 原生工作流的演进脉络，请阅读 AI 时代本地化的三个阶段。
本地化的未来
过去，本地化是翻译问题；在 AI 开发时代，它正在变成代码架构问题。解决好这一层的团队，将定义未来十年全球化软件的构建方式。
globalize.now 把硬编码的应用文案转换为可直接翻译的语言文件，并在你持续发布时保持同步更新。
免费试用 globalize.now