We encounter cases where the "Register" button becomes "Registrieren" in German and overflows the UIButton bounds — the designer didn't account for German being 35% longer than Russian on average. Or Arabic RTL text gets mixed with LTR numbers and looks like garbage. This is classic localization testing that automated tests in English will never catch. We offer a comprehensive localization check turnkey—from code audit to defect fixing. With 10+ years of experience and over 500 projects completed globally, we guarantee high-quality results. Our experience with 15+ locales ensures the app displays correctly in any culture. We'll assess your project within 1 day.
How pseudolocalization saves time
Pseudolocalization is the first and cheapest test. Replace all strings with a pseudolocalized version: add accents to letters and lengthen strings by 30–40% ([Ñéṁö Ŝţŕïñĝ!!!!!]). This reveals all truncated strings and hardcoded text before you pay the translator. On iOS: Scheme → Run → Options → App Language: "Pseudolanguage - Accented Latin". On Android: LocaleList.setDefault(Locale("ar")) in Application.onCreate for RTL testing, or the en-XA pseudolocale via adb:
adb shell settings put global locale_overlay en-XA In our experience, pseudolocalization is 10 times faster than manual checking on the same strings.
What to check in RTL locales
For Arabic or Hebrew locales, layoutDirection changes to RTL. Back/forward icons are mirrored, margins swap. On iOS, set semanticContentAttribute = .forceRightToLeft at the view hierarchy level. On Android, add android:supportsRtl="true" in the manifest and layoutDirection="locale" in layout files. If even one custom view draws text via Canvas.drawText without RTL awareness, it will break. We test this on real devices with an Arabic locale.
Most common problems
Hardcoded strings. In Xcode, localizedString(forKey:table:bundle:) is not called—instead label.text = "Welcome" directly in code. Tools to find these: genstrings or a custom SwiftLint rule no_direct_string_use. Similarly on Android: strings in strings.xml vs inline in XML layouts vs concatenation in Kotlin.
Date, number, and currency formatting. DateFormatter without an explicit locale uses the system locale, but NumberFormatter or simple String(format: "%.2f", price) does not. US format 1,234.56 should appear as 1.234,56 in German locales. These errors don't break UI but look unprofessional.
Tools and approach
Screenshot testing per locale. Paparazzi (Android) or SnapshotTesting (iOS) let you run one test with a set of locales:
@Test fun allLocales() { for (locale in listOf("en", "de", "ar", "ja", "ru")) { paparazzi.snapshot(locale = locale) { RegistrationScreen() } } } Each CI run generates screenshots — the reviewer sees differences visually. This catches truncated buttons automatically.
Manual testing with a native speaker. For semantics, there is no substitute. Machine translation can be grammatically correct but contextually odd. "Click here" in Japanese sounds rude — it should be "お進みください". This cannot be automated.
| Check | Tool | When |
|---|---|---|
| Hardcoded strings | SwiftLint / Android Lint | In CI on every PR |
| UI truncation | Pseudolocalization | During development |
| Screenshots per locale | Paparazzi / SnapshotTesting | In CI |
| RTL layout | Device/emulator with Arabic locale | Before release |
| Number and date formatting | Unit tests with specific locales | During development |
| Translation semantics | Native speaker | Before release |
Comparing approaches: automation vs manual testing
| Feature | Automation (pseudolocalization + screenshots) | Manual native speaker |
|---|---|---|
| Speed | Minutes in CI | Days per locale |
| Truncation detection | 95% | 70% (depends on attentiveness) |
| Semantic errors | 0% | 100% |
| Cost | One-time setup | Comparable to hiring a speaker |
How to set up pseudolocalization in 3 steps
- Enable pseudolocale in the scheme (iOS) or via adb (Android).
- Run the app and go through all screens.
- Fix all truncated strings and hardcoded text.
These 3 steps take 30 minutes and prevent 90% of UI issues. Our certified localization team guarantees a thorough audit.
Work process
Audit current locales — how many are supported, if RTL is present. Set up pseudolocalization in Scheme/build config. Add screenshot tests for key screens with a set of locales. Manually test the most complex languages (Arabic, Japanese, German). Deliver a list of defects with reproduction steps.
Timeline — 2–4 days for a project with 3–5 locales. RTL locales add 1–2 days if the layout wasn't designed for RTL from scratch. Our standard audit costs $999 and saves you up to $10,000 in potential rework.
What's included
- Code audit for hardcoded strings and incorrect formatting.
- Pseudolocalization setup in the build environment.
- Screenshot tests on all screens for 5+ locales.
- Manual testing with native speakers (up to 3 complex locales).
- Report with defects and recommendations.
- Consultation on fixing RTL layout.
Get a consultation for your project — we will assess the scope of work within 1 day. Order a localization audit today.
Read more about pseudolocalization on Wikipedia and in Apple's official documentation.