Native SDK strings — auth button labels, sheet chrome, loader accessibility text — follow the device locale by default via bundled expo-localization. No setup is required:
Code
Explicit locale
Pass a locale when your app manages language itself (for example, an in-app language picker) so SDK strings stay in sync with the rest of your UI:
Code
i18next, react-i18next, and expo-localization are bundled with the UI package for SDK localization — you don't install them unless you want expo-localization for your own app screens.
What locale does and doesn't affect
locale controls native SDK UI copy only:
| Surface | Localized by locale? |
|---|---|
| Auth button labels, native sheet headers, loader accessibility strings | Yes |
| Bible content and in-WebView UI (reader chrome, picker labels, footnotes) | No — remains English |
Bible translation selection (versionId, version picker) | Separate concern |
Two boundaries worth knowing:
- In-WebView UI stays in the Web SDK's default language (English). The Bible reader, pickers, and footnotes render Web SDK UI inside WebViews, and the SDK does not bridge
localeinto that layer. - App locale is not Bible language. Which Bible translation renders is controlled by
versionIdand the version picker, never derived fromlocale. A user can run your app in Spanish and read the Berean Standard Bible (BSB) in English — or vice versa.
Last modified on