Localizing React Native apps from start to end

Novak compares FBT with i18next, using examples for static text, plurals, variables, and styled text. FBT generates translation IDs, keeps strings searchable in source code, and has a smaller bundle size, but its community and file format support are limited. i18next has a larger community and many plugins, though its handwritten keys can hide the original text and its bundle is larger.

Novak recommends translation platforms such as Crowdin, Phrase, and Lokalise over email or spreadsheets. He explains how translators use translation memory to reuse prior work, machine translation to draft strings, term bases to protect names such as Apple, and quality checks to catch typos and missing parameters. Screenshots and design context help translators understand where strings appear.

Concatenating fragments such as an error label and a missing field can produce sentences that do not work in other languages. Novak argues that repeating complete messages can be worthwhile for translation quality. To catch missing strings, he points to TypeScript checks, fallbacks, and component tests.

Novak recommends keeping native and JavaScript translations aligned so user interface text and system menus do not appear in different languages. On iOS, developers can add locales and translations in project settings and change an app's language in device settings. Android 13 introduced per-app language preferences, and React Native 0.70 made Intl APIs available in Hermes on iOS and Android, with some features potentially needing polyfills.