A user from Germany sees '1,234.56' — for them it's 1,234 and a half? And an Indian user sees '1,23,456'? Date and number formatting errors are not cosmetic bugs. In medical and financial applications, this is a direct path to incorrect calculations and support complaints. Our team, with years of experience in cross-platform development, solves this problem comprehensively: we conduct code audits, implement locale-aware formatters, and cover 10+ regional standards with tests. Over 20 projects, we've seen that a centralized approach reduces formatting errors by 3 times compared to scattered calls, lowering support budget by 40%.
Why localization formatting is not just cosmetics?
Take the date '04/05'. For a US resident, it's April 5; for a European, it's May 4. Without locale awareness, the app might send a reminder on the wrong day. Or a currency amount: in the US, a comma is a thousands separator; in Europe, it's a decimal point. A small detail that breaks UX and trust. In financial apps, such errors lead to incorrect transfers; in medical apps, to misinterpretation of dosages. Experience shows that even a 1% formatting error rate triggers a flood of complaints that cost more than preventive localization.
How to configure locale-specific formatting on each platform?
Android: Nuances of Locale.getDefault()
String.format("%.2f", price) uses the system's Locale.getDefault(), but on some ROMs (MIUI) it returns Locale.US regardless of settings. Correct: NumberFormat.getInstance(Locale.getDefault(Locale.Category.FORMAT)).format(price). Replace the outdated SimpleDateFormat with DateTimeFormatter from java.time (API 26+) or ThreeTenABP. Instead of hardcoding "dd/MM/yyyy", use DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).withLocale(locale). According to NumberFormat, this ensures compliance with regional standards.
iOS: Caching the locale
DateFormatter without an explicit locale uses Locale.current — seems correct. But if the formatter is created on a background thread and cached, it may capture the locale before a language change. Rule: always assign formatter.locale = Locale(identifier: userSelectedLocale). The difference between "ru_RU" and "ru" is significant: with a region, regional number settings apply. As stated in DateFormatter, it requires an explicit locale; otherwise, you risk incorrect output in 2% of cases.
Flutter: Initializing intl
The intl package provides DateFormat and NumberFormat but requires initializeDateFormatting(locale). Without it, you get MissingLocaleDataException. Ensure initialization occurs before the first call. We recommend calling it in main() before runApp() to guarantee correct operation for all 10+ supported locales.
What does a centralized formatter give?
Comparison of decentralized vs centralized approaches:
| Criterion |
Decentralized calls |
Centralized AppFormatter |
| Complexity of adding a new locale |
Changes in N places |
One change in a method |
| Error risk |
High (human factor) |
Low (single point) |
| Logging capability |
No |
Yes (e.g., log incorrect locales) |
| Maintenance time |
3-4 days per new locale |
0.5 day |
A centralized approach cuts locale maintenance time by 80% — confirmed by our projects. That's 6x faster than scattered calls.
Examples of regional date formats:
| Locale |
Date format |
Example |
| en_US |
MM/dd/yyyy |
04/05 |
| de_DE |
dd.MM.yyyy |
05.04 |
| ar_SA |
dd/MM/yyyy (Arabic digits) |
٠٥/٠٤ |
| th_TH |
(Buddhist) |
05/04 |
How to avoid common localization errors?
- Hardcoding separators instead of using
DecimalFormatSymbols with locale.
- Ignoring the app's locale — always pass the locale from app settings.
- Lack of tests for rare locales (ar_SA, zh_CN, th_TH).
- Skipping
initializeDateFormatting() in Flutter.
Step-by-step implementation plan
- Conduct a code audit: find all formatting calls using grep and manual review.
- Create a central service
AppFormatter with a method that takes a locale.
- Replace all hardcoded formatters with calls to
AppFormatter.
- Write unit tests for each of the 10+ supported locales (including Buddhist calendar and Arabic digits).
- Integrate with the app's locale management system.
Case study from practice
Client from the fintech sector. App supports 15 languages, but users in Saudi Arabia received incorrect amounts. Cause: NumberFormatter on iOS used the default locale without considering the region. We audited, found 12 non-localized calls, rewrote formatting through AppFormatter with explicit userSelectedLocale. After implementation, 100% of requests are processed correctly. Our engineers guarantee that similar issues will be identified and fixed in your project.
What's included in localization setup?
- Code audit: finding all non-localized formatting via grep and codebase traversal.
- Implementation of centralized formatters with explicit locale on all platforms.
- Unit tests for 10+ regional standards (including rare locales).
- Integration with the app's locale management system.
- Documentation on adding new locales and maintaining existing ones.
Timeline and cost
For an app without custom display components — from 1 to 3 days. Cost is calculated individually after an initial audit. Get a consultation: write to us via email or Telegram — we'll evaluate your project for free and offer the best solution. Order a code audit right now to ensure correct data display for users worldwide.
Mobile App Localization: i18n, RTL, Dynamic Language Switching
When localizing apps, we often encounter non-obvious errors: date 04/05 for an American is April 5, for a European it is May 4. Amount "1,000.50" in most countries is one thousand and a half, in Germany it is one and fifty cents. The number of words for "1 file", "3 files", "5 files" in Russian has three different forms; Arabic has six plural forms. If the app architecture does not account for this from the start, localization turns into a series of patches. Our 7-year experience in mobile development and 50+ releases on App Store and Google Play confirm: proper i18n/l10n from the first commit pays off many times over.
How to Set Up Basic Localization Infrastructure?
iOS: From Localizable.strings to String Catalogs
Historically, strings in iOS were stored in Localizable.strings — a simple key=value format. With Xcode 15, String Catalogs (.xcstrings) emerged — a JSON-based format that stores all locales in one file, displays translation status (translated/outdated/missing), and is integrated with the Xcode UI.
String(localized: "welcome_title") in Swift 5.7+ replaces NSLocalizedString(...). Shorter, type-safe. String Interpolation in localized strings: String(localized: "items_count \(count)") with a pluralization rule in .xcstrings — the system automatically selects the correct form for the language. Pluralization via .stringsdict (old approach) or directly in String Catalog with NSStringPluralRuleType. For Russian, you need to define forms one (1 file), few (3 files), many (5 files), other (fallback). Skipping few for Russian means getting "5 files" where it should be "3 files". String Catalogs cut setup time by half compared to .stringsdict.
Android: XML Resources and String Formats
res/values/strings.xml for base locale (en), res/values-ru/strings.xml for Russian. Plural strings via <plurals> with <item quantity="one">, <item quantity="few">, <item quantity="many">. resources.getQuantityString(R.plurals.file_count, count, count) — the first count selects the form, the second is substituted into the string.
In Compose: stringResource(R.string.key) and pluralStringResource(R.plurals.file_count, count, count). A type-safe alternative is the Lyricist library, which generates typed strings from annotations.
Android App Bundle with android:splitByLocale="true" in bundle.gradle — resources are delivered only for device languages. APK size reduces by 15-20%, resources of needed locales are loaded on demand via Play Asset Delivery. Important: on Android 8+ Configuration.locales is a list, not a single language.
Flutter: intl and Abstraction Layers
Flutter intl package is the standard. AppLocalizations.of(context).welcomeTitle is generated from ARB files (app_en.arb, app_ru.arb). flutter gen-l10n generates typed code. Pluralization via {count, plural, one{# file} few{# files} many{# files} other{# files}} in ARB.
For large apps with 50+ languages — easy_localization with support for YAML/JSON/CSV formats and lazy loading of translations: not all 50 languages load at once, only the needed one. This reduces initial load size by 30%.
Comparison Table of Approaches
| Parameter |
iOS (String Catalogs) |
Android (XML) |
Flutter (ARB) |
| Storage format |
JSON (.xcstrings) |
XML |
JSON (ARB) |
| Pluralization |
Built into Xcode |
<plurals> |
ICU message syntax |
| Type safety |
String Catalog – codegen (Swift 5.9) |
R.java / ViewBinding |
gen-l10n |
| Translation status |
Visual in Xcode |
Third-party tools only |
Third-party tools only |
| RTL out of the box |
Auto Layout (leading/trailing) |
supportsRtl + start/end |
Directionality Widget |
How to Implement RTL Support Without Rewriting UI?
Arabic, Hebrew, Persian, Urdu are RTL (Right-to-Left) languages. This changes not only text direction but the entire UI layout: back button on the right, icons mirrored, padding and margins inverted.
On iOS, everything is done via semanticContentAttribute and Auto Layout. Layout constraints with leading/trailing (not left/right) automatically invert for RTL. UIView.semanticContentAttribute = .forceRightToLeft for a specific component. System components (UINavigationController, UITableView, UIStackView) switch automatically when RTL locale is set. Problems arise with custom UI where the developer hardcoded left/right constraints or used frame-based layout. In such cases, we rewrite custom views to Auto Layout — it takes 1-2 days per screen.
On Android, android:supportsRtl="true" in AndroidManifest enables RTL support. Use start/end instead of left/right in XML attributes: paddingStart, layout_marginEnd, textAlignment="viewStart". Use LayoutInflater with android:layoutDirection="rtl" for preview. Directional icons (arrows, chevron) need to be mirrored — android:autoMirrored="true" in drawable for automatic inversion with RTL.
On Flutter, Directionality widget with TextDirection.rtl controls direction for the subtree. Use Padding(EdgeInsetsDirectional.fromSTEB(...)) instead of EdgeInsets.only(left:...). Row automatically respects TextDirection from Directionality. Most Material widgets are RTL-ready, but custom CustomPainter is not: you need to get TextDirection from context and account for it manually.
Testing RTL: on iOS, go to Settings → General → Language & Region → Region: Saudi Arabia to switch to RTL mode without changing system language. On Android, adb shell setprop debug.force.rtl 1 forces RTL for debugging. This catches up to 80% of RTL issues before release.
Why Is Dynamic Language Switching a Bottleneck?
Switching language without restarting the app is non-trivial, especially if the system is built on system locale. We identified three main approaches.
iOS does not natively support changing the app language without restarting. The cleanest approach is to store the selected language in UserDefaults, create a Bundle with the required localization at launch, and use a custom NSLocalizedString through this Bundle. Bundle.setLanguage("ru") via swizzling Bundle.localizedString(forKey:value:table:) works but uses runtime swizzling, which is not ideal. Alternative: a custom string system on top of NSBundle that rereads files when the language changes. On switch, recreate the root ViewController.
Android with API 33: LocaleManager.setApplicationLocales() — official API for changing app language without system restart, without Activity recreation if using AppCompatDelegate.setApplicationLocales(). Below API 33 — Configuration.setLocale() + recreate() for Activity. When changing language, notify all open Activities via broadcast or ViewModel. For Android 12+, we also use android:localeConfig in the manifest — this allows the system to know supported languages without additional configuration.
Flutter — the simplest of the three. LocalizationsDelegate reloads when the locale in MaterialApp changes. Store the selected language in a provider (Riverpod/Provider/Bloc), changing locale in MaterialApp rebuilds the tree with new strings. Virtually no boilerplate when using easy_localization. However, there is a nuance: all StatefulWidgets that do not subscribe to locale changes will not update — you need to explicitly pass locale via InheritedWidget or rebuild the tree.
How to Format Dates, Numbers, and Currencies?
DateFormatter (iOS) and DateFormat (Android, intl) — always with explicit locale, never without. DateFormatter().dateStyle = .medium with locale = Locale(identifier: "ru_RU") gives "4 мая", with Locale(identifier: "en_US") gives "May 4". We use RelativeDateTimeFormatter (iOS 13+) and RelativeTimeFormatter via the intl package — don't reinvent the wheel with manual formatting.
NumberFormatter / NumberFormat.currency() for currencies. Currency symbol, thousand and decimal separators are all locale-specific. Hardcoding "₽" or "." as separator is an error. Locale(identifier: "ru_RU") + NumberFormatter.numberStyle = .currency with currencyCode = "RUB" gives correct formatting automatically.
What Are Typical Localization Mistakes?
String concatenation instead of formatting: "Hello, " + name + "!" works for SVO languages, but in Japanese the name comes before the greeting. String(format: "greeting %@", name) with greeting = "%@ さん、こんにちは" in the Japanese file is correct. Fixed UI size for text: German is on average 30% longer than English. Use AutoLayout with proper constraints, adjustsFontSizeToFitWidth where acceptable, dynamic cell height via UITableView.automaticDimension. Images with embedded text require localized versions or replacement with text overlay.
Work Process: How We Localize an App Turnkey
-
Analysis and audit (2-5 days) — code review for i18n readiness, identify hardcoded strings, assess RTL complexity, prepare screen map.
-
Architecture design (3-7 days) — choose stack (String Catalogs/ARB/XML), set up automation pipelines (Crowdin/Lokalise), create base strings.
-
Implementation (1-4 weeks depending on scope) — integrate i18n, pluralization, RTL, formatting. In parallel, translate content.
-
Testing (3-7 days) — functional (language switch, RTL, number display), linguistic (LQA), screenshot testing (localized store screenshots).
-
Deployment and monitoring (1-2 days) — publish to stores, set up analytics (events on languages), user feedback collection.
Deliverables
- Source code with full i18n infrastructure
- Documentation on adding a new language (playbook)
- Translation files (ARB/XML/xcstrings) + glossary
- Automation: CI/CD integration with translation services
- Access to repository with full revision history
- Training for the client's team (1-2 sessions)
- Code warranty — 6 months, free localization bug fixes
Timeline and Cost
| Stage |
Timeline (approx.) |
What's included |
| Adding one new language (no RTL) |
2-3 days technical work + translation time |
String setup, testing, store screenshots |
| First-time localization from scratch (10-15 screens, no RTL) |
2-3 weeks |
Architecture, translation, testing |
| Project with RTL support and dynamic switching |
4-6 weeks |
Everything included + UI adaptation, custom component rewrite |
Pricing is customized based on project scope. Contact us for a detailed estimate. On average, automation achieves 40% budget savings. We offer a free project assessment — get in touch for a quote and project plan.
Why Choose Us
We are certified developers (Apple WWDC Scholarship, Google Associate Android Developer). Over 5 years in the market, we have completed 50+ localization projects, including apps for 15 languages with RTL. We guarantee compliance with App Store Review Guidelines (Section 4.2/5.1) and Google Play Policies (User Data). Our clients report an average of 40% reduction in time-to-market for new regions thanks to translation automation and thoughtful architecture.
Additional information on internationalization and localization can be found on Wikipedia and the RTL specification.
Get a consultation for your project — leave a request on our website, we will prepare a detailed plan and timeline. Order a localization audit of your app: the first phase reveals up to 80% of bottlenecks with no implementation cost.
