游离在产品之外的本地化
把一个原生 App 推向十个市场，本地化就变成十个工程。每个市场各有一套字符串目录、一轮为更长德语或更密中文重排的版式，以及各自独立的商店详情页与截图。新增阿拉伯语或希伯来语，意味着把每个页面改为从右到左重排，再重新过审。多说一种语言的代价，是一次全新的发版周期。
小程序运行时把本地化的最小单位翻转了：语言资源包随包体一起分发，运行时在启动时以及每次语言切换时解析最合适的那份。一份构建就能用英文、中文、西班牙文、葡萄牙文或阿拉伯文向用户问好——同一份程序在支持这些语言的每个宿主上无需改动即可运行。
包体内 i18n 到底是什么
运行时提供一层本地化能力：开发者按语言打包翻译资源、声明回退链，运行时为用户偏好语言选出最匹配的版本。以微信 @miniprogram-i18n 核心运行时为例，它提供带 t(key)、setLocale 与回退语言（fallback locale）的翻译引擎，缺失文案会优雅降级而非空白。支付宝的 IAPMiniProgram SDK 更进一步：它适配 SDK 自带 UI、小程序元信息与包内内容，并支持阿拉伯语自动从右到左布局方向。
这与 Web 国际化是同一套纪律——W3C 的从右到左指南与 MDN 的 Intl API——但运行时把它统一施加在超级 App 之内，而不是让每个团队各自搭一套管线。
差距在哪里体现
| 环节 | 原生 App | 小程序运行时（包体内 i18n） |
|---|---|---|
| 字符串目录 | 每个市场单独构建 | 一份包体内的语言文件 |
| RTL（阿拉伯/希伯来） | 重排 + 重新过审 | 运行时自动翻转布局方向 |
| 新增语言 | 新一轮发版 | 加入语言包，无需重建 |
| 回退策略 | 每屏手动处理 | 声明的回退链 |
| 宿主支持 | 各商店单独上架 | 同一包体，多个宿主 |
结果是：进入一个市场变成内容工作，而不是工程计划——丢进一份语言包，解析与方向由运行时接管。
为什么「内置」胜过「外挂」
包体内的本地化层意味着开发者一次写好产品，把语言当作数据来发布。它还意味着回退链（精确匹配、同语系变体、默认语言）由运行时强制保障，缺失翻译永远不会让某个页面崩掉。同一个包体在支持声明语言的每个宿主上都能正确渲染，不会出现各商店分叉。
Cross Mini App 如何落地
Cross Mini App 为程序提供内建本地化层的运行时：语言包、回退链与 RTL 处理都随包体分发，一份构建即可触达全球受众。你只需撰写一次内容，运行时用用户所属的语言与方向向他们问好。你不再为新增市场重建 App，而是把语言当作数据来添加。
这就是「十个本地化发版」与「一个面向所有人说话的程序」之间的区别。
