Language
Supported locales (target)
| Code | Name | Native | Direction |
|---|---|---|---|
| en | English | English | LTR |
| ar | Arabic | العربية | RTL |
| fr | French | Français | LTR |
Surface-by-surface status
Customer app (React Native)
PlannedApproach: i18n-js + locale JSON files bundled with the app
Screens use literal strings today. Migration: wrap all strings in t('key'), ship en/ar/fr JSON, add RTL flip for ar.
Merchant app (React Native)
PlannedApproach: i18n-js + locale JSON files bundled with the app
Same migration shape as customer app. Owner/sub-merchant copy needs both translations.
Agent app (React Native)
PlannedApproach: i18n-js + locale JSON files bundled with the app
Titles and primary CTAs (Cash-In, Cash-Out, Settlement, Sub-Agent) covered first.
Super-admin web (Next.js)
PlannedApproach: next-intl
Operator UI. English-first is acceptable for now; locale switch added when there is a real second-language operator.
Backend outgoing notifications (push / SMS / email)
PlannedApproach: User.preferredLanguage + locale-keyed PushNotificationTemplate rows
Already partial: PushNotificationTemplate.variables JSON can carry per-locale title/body; the notification dispatcher needs a small lookup by user.preferredLanguage with fallback to 'en'.
Why no live editor here
Live edits to app translations from a backend admin panel introduce cache, OTA, and review risk for a mobile app — every change becomes a moving target between sessions and devices, with no audit trail of which copy a user actually saw. The industry-standard pattern is to ship locale JSON inside the app bundle and gate updates through the same code review + release path as the rest of the UI.
For backend-rendered copy (SMS, email, push), the locale-keyedPushNotificationTemplatealready exists and is editable from the Push Notification page — once we land the small dispatcher tweak that readsuser.preferredLanguageand falls back to English, operators can author Arabic and French template copy from there.