i18n
i18n for an Expo app, compared: i18next, Lingui, or none - Expo Go support and what each option installs.
Hey - here's how i18n works in ReadyNative. This category decides how your copy gets translated - and, importantly, it doesn't decide how your screens are written.
The contract is src/lib/i18n.ts: i18n.t(key, vars) and useT(), where keys are the English
source strings and placeholders are {{name}}. That surface exists with or without a library
(core ships a shim), so a screen reads identically under every option and adding translations
later is a setup call rather than a refactor. The real modules add src/locales/*.json, the
device language through expo-localization, a language override persisted under
readynative:language, an I18nProvider at order 60 and, with --with-examples, the /examples/i18n picker. Swap with
bun run setup --i18n <option>.
- i18next - the default. Pick it for the bigger ecosystem: plurals, formatters, translators who already know the format.
- lingui - pick it for ICU messages and a catalog CLI (
bun run i18n:extract). - none - the shim. English only, zero dependencies.
Options
One option per category - --i18n <option> picks it:
bun run setup --i18n i18next