Globalization: What It Is, i18n and Multilingual Support in Apps

What is Globalization (i18n) and Why Do You Need It?

Globalization (abbreviated as i18n — 18 letters between "i" and "n") is the architectural preparation of an application to work with any language and region. The key rule of i18n: no string of text should be hardcoded in the source code. Instead, strings are extracted into resource files, and the code accesses them by keys. When adding a new language, you only need to add a translation file — the code remains unchanged. This distinguishes i18n from localization (l10n), where the strings themselves are translated.

Business case — globalization expands the market. According to Common Sense Advisory (2023), over 70% of users prefer to purchase in apps in their native language. Localization into 10 languages increases the potential audience by 80%. Without i18n, each expansion to a new language requires code changes, slowing time-to-market and increasing costs by 5–10 times. Proper i18n architecture allows supporting 40+ languages with minimal costs.

i18n components include: string externalization, pluralization (for 1/2/5+), date and number formatting (DateFormatter/SimpleDateFormat), RTL language support (Right-to-Left), locale-specific sorting (Collator), regional symbols (thousand separators, decimal points). At IT Sectr, we implement i18n at the architecture stage rather than adding it post-factum — this saves up to 60% of time during subsequent localization.

Internationalization in iOS: NSLocalizedString and XLIFF

NSLocalizedString is the primary Swift macro for working with translations. Format: NSLocalizedString("key", comment: "description for translator"). The macro automatically substitutes the string from Localizable.strings for the current device locale (NSLocale.preferredLanguages). If no translation is found for the key, the key itself or the development language value (usually en) is returned. Apple recommends using meaningful keys rather than English strings as keys.

// Localizable.strings (en)
// "welcome_title" = "Welcome!";
// Localizable.strings (ru)
// "welcome_title" = "Welcome!";

// Swift code — unified for all languages
titleLabel.text = NSLocalizedString(
    "welcome_title",
    comment: "Welcome screen title"
)

// Plurals via Localizable.stringsdict
// 
// <dict>
//     <key>items_count</key>
//     <dict>
//         <key>NSStringLocalizedFormatKey</key>
//         <string>%#@items@</string>
//         <key>items</key>
//         <dict>
//             <key>one</key>
//             <string>%d item</string>
//             <key>few</key>
//             <string>%d items</string>
//             <key>many</key>
//             <string>%d items</string>
//         </dict>
//     </dict>
// </dict>

// Using plurals
let items = 5
let label = String.localizedStringWithFormat(
    NSLocalizedString("items_count", comment: ""), items
)

XLIFF is a translation exchange format between developers and translators. Xcode exports an XLIFF file (Editor → Export for Localization) containing all strings for translation. The translator works with XLIFF in CAT tools (Trados, memoQ, Smartcat). After translation, XLIFF is imported back into Xcode (Editor → Import Localizations). XLIFF automatically updates all .lproj directories. This is the standard localization workflow for iOS apps in production.

SwiftUI and i18n

SwiftUI works with NSLocalizedString through the Text initializer. Text in SwiftUI is automatically internationalized: Text("welcome_title") looks up the translation in Localizable.strings just like NSLocalizedString. For plurals, use Text("%d items", count: items). SwiftUI supports date formatting through Text(date, style: .date) — it automatically uses Locale.current. Apple recommends SwiftUI for new projects as internationalization is more transparent in it.

Internationalization in Android: strings.xml and RTL

Android i18n is built on the resource system. Strings are placed in res/values/strings.xml for the default language (usually English). For each language, a separate directory is created: res/values-ru/strings.xml (Russian), res/values-de/strings.xml (German), res/values-fr/strings.xml (French). Android automatically selects strings based on the device system language (Locale.getDefault()). If an exact locale is not found, the base (values/strings.xml) is used.

// res/values/strings.xml (English, default)
<resources>
    <string name="welcome_title">Welcome!</string>
    <string name="items_count">%d item(s)</string>
</resources>

// res/values-ru/strings.xml (Russian)
<resources>
    <string name="welcome_title">Welcome!</string>
    <plurals name="items_count">
        <item quantity="one">%d item</item>
        <item quantity="few">%d items</item>
        <item quantity="many">%d items</item>
    </plurals>
</resources>

// Kotlin code
textView.text = getString(R.string.welcome_title)

// Plurals
val items = 5
textView.text = resources.getQuantityString(
    R.plurals.items_count, items, items
)

// RTL support in code
textView.textDirection = View.TEXT_DIRECTION_LOCALE
// Manifest: supportsRtl="true"

RTL (Right-to-Left) — support for languages where text is read right-to-left (Arabic, Hebrew, Urdu, Farsi). Android supports RTL through the android:layoutDirection and android:textDirection attributes. In the manifest, specify android:supportsRtl="true" — and Android will automatically mirror the layout. NavDrawer, back/forward icons, text alignment should work both ways. In code, use View.LAYOUT_DIRECTION_LOCALE and Gravity.START/END instead of LEFT/RIGHT.

Localized Resources

Android Resource Qualifiers allow localizing not only strings but also images (res/drawable-ru/), layouts (res/layout-ru/), animations, colors. For Arabic and Hebrew, separate layouts with mirrored element placement are needed — use res/layout-ar/ (Arabic). Android also supports regional variants: values-rUS, values-rGB, values-de-DE. Qualifiers can be combined: values-ldrtl-ru — Russian for RTL displays.

Regional Formats: Dates, Numbers, Currency in iOS and Android

Dates and time — one of the key aspects of i18n. Different regions use different formats: Russia — DD.MM.YYYY, USA — MM/DD/YYYY, Japan — YYYY.MM.DD. Using a fixed format (yyyy-MM-dd) for display to the user is a mistake. In iOS, use DateFormatter with Locale(identifier: locale), in Android — DateFormat.getDateInstance(DateFormat.SHORT, locale). For voice assistants and AI search, dates should be in ISO 8601 internally.

Numbers and currency — different regions have different separators: 1,234.56 (USA) vs 1.234,56 (Russia), 1 234,56 (France). iOS: NumberFormatter with .locale = locale. Android: DecimalFormat with DecimalFormatSymbols(locale). For currencies: format ¥1,234 (Japan) vs $1,234.56 (USA) vs 1 234,56 ₽ (Russia). Never concatenate currency and number manually — use NumberFormatter.currencyCode and .currencySymbol.

Sorting (Collation) — alphabetical sorting differs across languages. In Spanish, "ch" comes after "c". In Swedish, "ä" is at the end of the alphabet. In German, "ß" is sorted as "ss". iOS: LocalizedComparison (String.localizedCompare). Android: Collator.getInstance(locale). Never use compareTo() for strings displayed to the user — it uses Unicode Code Point order, which does not account for regional rules.

Best Practices for Mobile App Internationalization

Architectural principles — start i18n from the first commit. Every string in code should go through a wrapper function (tr("key")) that doesn't exist until i18n is set up — this forces developers to externalize strings immediately. Don't use English strings as keys — when the English wording changes, all translations need updating. Use meaningful keys: "profile.title", "settings.language.label".

Pseudolocalization — a testing technique for i18n before actual translation. Replace each Latin letter with diacritic characters (á, é, ñ, ü) to check encoding, add a [XXX] prefix to check for string truncation. Xcode: run schemes — "Double-Length Pseudolanguage" pseudo-language. Android: Developer Options — Force RTL layout direction, System font scale up to 200%. Pseudolocalization finds 80% of i18n problems without involving a translator.

IT Sectr i18n checklist — before release we check: (1) no hardcoded strings in code (exception: logs), (2) plurals work correctly for all languages, (3) dates/numbers are formatted through Locale API, (4) layout displays correctly on RTL languages, (5) strings are not truncated at maximum scaling, (6) pseudolocalization revealed no errors, (7) all languages declared in stores have a complete set of translations.