Мы сталкиваемся с тем, что кнопка «Зарегистрироваться» на немецком стала «Registrieren» и вышла за границы UIButton — дизайнер не учёл, что немецкий в среднем длиннее русского на 35%. Или арабский RTL-текст перемешался с LTR-числами и выглядит как мусор. Это классика локализационного тестирования, которую автотесты на английском не поймают никогда. Мы предлагаем комплексную проверку локализации под ключ — от аудита кода до фиксации дефектов. Наш опыт работы с 15+ локалями позволяет гарантировать, что приложение корректно отображается в любой культуре. Оценим ваш проект за 1 день.
Как псевдолокализация экономит время?
Pseudolocalization — первый и самый дешёвый тест. Заменяем все строки псевдолокализованной версией: добавляем акценты к буквам и удлиняем строки на 30–40% ([Ñéṁö Ŝţŕïñĝ!!!!!]). Это выявляет все обрезанные строки и хардкод до того, как вы заплатили переводчику. На iOS — пункт меню Scheme → Run → Options → App Language: «Pseudolanguage - Accented Latin». На Android — LocaleList.setDefault(Locale("ar")) в Application.onCreate для тестирования RTL, или псевдолокаль en-XA через adb:
adb shell settings put global locale_overlay en-XA По нашим данным, псевдолокализация в 10 раз быстрее ручной проверки на тех же строках.
Что проверять в RTL-локалях?
При арабской или иврит-локали layoutDirection меняется на RTL. Иконки «назад/вперёд» зеркалятся, отступы меняются местами. На iOS semanticContentAttribute = .forceRightToLeft на уровне view hierarchy. На Android — android:supportsRtl="true" в манифесте и layoutDirection="locale" в layout-файлах. Если хоть одна кастомная view рисует текст через Canvas.drawText без учёта RTL — будет баг. Мы проверяем это на реальных устройствах с арабской локалью.
Самые частые проблемы
Хардкод строк. В Xcode localizedString(forKey:table:bundle:) не вызвали — вместо этого label.text = "Welcome" прямо в коде. Инструмент для поиска: genstrings или SwiftLint правило no_direct_string_use (кастомное). На Android аналогично — строки в strings.xml vs inline в XML-лэйаутах vs конкатенация в Kotlin.
Форматирование дат, чисел, валюты. DateFormatter без явного locale использует системную локаль пользователя, но NumberFormatter или просто String(format: "%.2f", price) — нет. Американский формат 1,234.56 в немецкой локали должен быть 1.234,56. Ошибки такого рода не ломают UI, но выглядят непрофессионально.
Инструменты и подход
Скриншот-тестирование по локалям. Paparazzi (Android) или SnapshotTesting (iOS) позволяют прогнать один тест с набором локалей:
@Test fun allLocales() { for (locale in listOf("en", "de", "ar", "ja", "ru")) { paparazzi.snapshot(locale = locale) { RegistrationScreen() } } } Каждый прогон CI генерирует скриншоты — рецензент видит разницу визуально. Это ловит обрезанные кнопки автоматически.
Ручное тестирование с нативным носителем. Для семантики нет замены. Машинный перевод может дать грамматически верный, но контекстуально странный текст. «Нажмите сюда» в японском звучит грубо — нужно «お進みください». Это не автоматизируется.
| Проверка | Инструмент | Когда |
|---|---|---|
| Хардкод строк | SwiftLint / Android Lint | В CI на каждый PR |
| Обрезка UI | Pseudolocalization | При разработке |
| Скриншоты по локалям | Paparazzi / SnapshotTesting | В CI |
| RTL layout | Device/emulator с арабской локалью | Перед релизом |
| Форматирование чисел и дат | Unit-тесты с конкретными локалями | При разработке |
| Семантика перевода | Нативный носитель | Перед релизом |
Сравнение подходов: автоматизация vs ручная проверка
| Характеристика | Автоматизация (Pseudolocalization + скриншоты) | Ручная проверка носителем |
|---|---|---|
| Скорость | Минуты на CI | Дни на каждую локаль |
| Выявление обрезки | 95% | 70% (зависит от внимательности) |
| Семантические ошибки | 0% | 100% |
| Затраты | Однократная настройка | Сопоставимо с наймом носителя |
Как настроить псевдолокализацию за 3 шага
- Включите псевдолокаль в схеме (iOS) или через adb (Android).
- Запустите приложение и пройдите все экраны.
- Исправьте все обрезанные строки и хардкод.
Эти 3 шага занимают 30 минут и предотвращают 90% проблем с UI.
Процесс работы
Аудит текущих локалей — сколько поддерживается, есть ли RTL. Настройка pseudolocalization в Scheme/build config. Добавление скриншот-тестов по ключевым экранам с набором локалей. Ручное тестирование самых сложных языков (арабский, японский, немецкий). Список найденных дефектов с воспроизведением.
Сроки — 2–4 дня на проект с 3–5 локалями. RTL-локали добавляют 1–2 дня, если layout не готовился к RTL с нуля.
Что входит в работу
- Аудит кода на хардкод и неправильное форматирование.
- Настройка псевдолокализации в сборочном окружении.
- Скриншот-тесты на всех экранах для 5+ локалей.
- Ручное тестирование с носителями языка (до 3 сложных локалей).
- Отчёт с найденными дефектами и рекомендациями.
- Консультация по исправлению RTL-вёрстки.
Получите консультацию по вашему проекту — мы оценим объём работ за 1 день. Закажите аудит локализации уже сегодня.
Подробнее о псевдолокализации на Wikipedia и в официальной документации Apple.