Ми стикаємося з тим, що кнопка «Зареєструватися» німецькою стала «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.