Localization that lives outside the product
Ship a native app to ten markets and localization becomes ten projects. Each market gets its own string catalog, its own layout pass to absorb longer German or denser Chinese text, and its own store listing and screenshots. Adding Arabic or Hebrew means re-flowing every screen for right-to-left, then re-certifying the build. The cost of speaking another language is a new release cycle.
A mini-program runtime flips the unit of localization. The locale bundles travel inside the package, and the runtime resolves the right one at launch and on every locale change. One build can greet a user in English, Chinese, Spanish, Portuguese, or Arabic — and the same program runs unchanged across every host that supports those locales.
What in-package i18n actually is
The runtime provides a localization layer: developers bundle translation resources per locale, declare a fallback chain, and the runtime picks the best match for the user's preferred language. The WeChat @miniprogram-i18n core runtime, for example, exposes a translation engine with t(key), setLocale, and a fallback locale so missing strings degrade gracefully instead of rendering blank. Alipay's IAPMiniProgram SDK takes this further: it adapts SDK-provided UI, program metadata, and in-package content, and it supports Arabic with automatic right-to-left layout direction.
This is the same discipline as web internationalization — W3C's right-to-left guidelines and MDN's Intl APIs — but the runtime applies it uniformly inside the super-app instead of leaving each team to wire up their own pipeline.
Where the gap shows up
| Step | Native app | Mini-program runtime (in-package i18n) |
|---|---|---|
| String catalog | Per-market build | Bundled locale files in one package |
| RTL (Arabic, Hebrew) | Re-flow + re-certify | Runtime flips layout direction |
| New language | New release cycle | Add locale bundle, no rebuild |
| Fallback | Manual per screen | Declared fallback chain |
| Host support | Per-store listing | Same package, many hosts |
The result is that entering a market is a content task, not an engineering program: drop in a locale bundle, and the runtime handles resolution and direction.
Why bundled beats bolted-on
An in-package localization layer means a developer writes the product once and ships languages as data. It also means the fallback chain — exact match, same base language, default — is enforced by the runtime, so a missing translation never breaks a screen. The same package renders correctly on every host that supports the declared locales, with no per-store divergence.
How Cross Mini App applies it
Cross Mini App gives programs a runtime with a built-in localization layer: locale bundles, a fallback chain, and RTL handling travel inside the package, so one build reaches a global audience. You author your content once; the runtime greets each user in their language and direction. You stop rebuilding the app to add a market and start adding languages as data.
That is the difference between ten localized releases and one program that speaks to everyone.
