Реалізація локалізації мобільного застосунку українською мовою
Ви інтегрували в застосунок переклад рядків через strings.xml або Localizable.strings — і все працює англійською. Але як тільки доходить до української, починаються сюрпризи. Числівники: '1 повідомлення', '3 повідомлення', '5 повідомлень' — стандартна плюралізація потребує чотирьох форм. Відмінки: 'замовлення Івана' проти 'замовлення Марини'. Довгі слова: 'Політика конфіденційності' замість 'Privacy Policy'. А ще RTL-нейтральний layout починає поводитися непередбачувано. Нещодавно клієнт із фінтех-сектору зіткнувся з тим, що після локалізації кнопка 'Submit' перетворилася на 'Надіслати' і вилізла за межі екрана на iPhone SE. Ми вирішили цю проблему за два дні, застосувавши автолейаут та динамічну висоту. Ми — команда мобільних розробників із 10+ років досвіду — вирішуємо такі задачі під ключ, гарантуючи коректну локалізацію українською мовою. Пройшли сертифікацію Apple та Google, маємо понад 15 проєктів з українською локалізацією. Оцінимо ваш проєкт безкоштовно.
Як правильно обробити плюралізацію в Android та iOS?
Українська мова використовує шість форм множини для іменників залежно від числа. Android підтримує це нативно через <plurals> в strings.xml:
<plurals name="notification_count"> <item quantity="one">%d повідомлення</item> <item quantity="few">%d повідомлення</item> <item quantity="many">%d повідомлень</item> <item quantity="other">%d повідомлення</item> </plurals> У коді: resources.getQuantityString(R.plurals.notification_count, count, count).
На iOS використовується String(localized:) з .init(format:) та NSLocalizedString, які підтримують CLDR plural rules через .stringsdict. Формат .stringsdict більш громіздкий, але працює коректно з NSString.localizedStringWithFormat. У React Native застосовуються i18n-js або react-i18next з returnObjects: true. Без явної підтримки plurals доводиться писати helper вручну. Нативний механізм плюралізації (Android <plurals> / iOS .stringsdict) у 2 рази точніший за кастомні рішення, особливо для чисел 21, 31 тощо.
Підстановка з узгодженням («Привіт, %@» → «Привіт, Іване») досить проста з іменованими плейсхолдерами. Проблема виникає при узгодженні: «замовлення Івана» vs «замовлення Марини» — закінчення різне. Для таких випадків або переформульовуємо рядок без узгодження, або додаємо окремі ключі для різних форм.
Чому український текст ламає UI?
Українські слова в середньому довші за англійські еквіваленти на 20–40%. «Settings» → «Налаштування» — нормально. «Notifications» → «Сповіщення» — довше. «Privacy Policy» → «Політика конфіденційності» — майже вдвічі. Фіксована ширина кнопок, truncation замість wrap, іконки з hardcoded відступами — все це ламається при локалізації. Перевіряємо UI в псевдолокалізації на етапі розробки: аccountability → [аccoutàbïlïтý~~] — виявляє проблемні місця до перекладу. Xcode підтримує Pseudo-localization в схемі (Application Language: Double-Length Pseudolanguage). Це економить до 50% часу на правках верстки.
Що робити з клавіатурою та введенням?
Для полів введення українською: keyboardType та returnKeyType не змінюються, але autocapitalizationType варто перевірити — українська автокапіталізація іноді веде себе інакше. spellCheckingType з українським словником доступний на iOS та Android системно, вмикається автоматично при виборі мови.
Порівняння підходів до плюралізації
| Платформа | Механізм | Кількість форм | Приклад коду |
|---|---|---|---|
| Android | <plurals> в strings.xml |
4 (one, few, many, other) | getQuantityString() |
| iOS | .stringsdict з CLDR |
4+ (one, few, many, other) | NSLocalizedString() + stringsdict |
| React Native | i18n-js або react-i18next |
Залежить від плагіна | i18n.t('key', {count}) |
Із трьох варіантів Android та iOS забезпечують вбудовану підтримку українських правил, тоді як React Native потребує додаткової бібліотеки. Для великих проєктів рекомендуємо нативні рішення.
Що входить у локалізацію українською мовою?
| Етап | Опис | Термін |
|---|---|---|
| Аудит рядків | Виявляємо всі рядки UI, включаючи приховані (toast, errors) | 0.5 дня |
| Переклад рядків | Переклад + перевірка plurals та відмінків | 1 день |
| Налаштування локалі | Адаптація форматів дат, чисел, валют під uk_UA |
0.5 дня |
| UI-тестування | Перевірка переповнень, обрізань, псевдолокалізація | 1 день |
| Підсумкове тестування | Тест на пристроях з українською локаллю | 0.5 дня |
Загальний термін — від 2 до 4 робочих днів для застосунку з 200–500 рядками. Для експорту рядків використовуємо формат XLIFF, який підтримується всіма основними платформами. При публікації в App Store обов'язково дотримуйтесь розділу 5.1 App Store Review Guidelines, що стосується локалізації.
Як ми гарантуємо якість?
Використовуємо автоматизоване тестування з XCTest/Espresso на псевдолокалізованому UI, перевіряємо plurals на граничних значеннях (0, 1, 2, 3, 10, 21, 100). Для iOS — .stringsdict обов'язковий, для Android — <plurals> з правильними quantity. Наш досвід: понад 15 проєктів, сертифіковані спеціалісти. Згідно з документацією Apple, використання .stringsdict критичне для коректної плюралізації. Отримайте консультацію — оцінимо ваш проєкт безкоштовно та підберемо оптимальний план.
Типові помилки при локалізації українською
- Ігнорування
stringsdict/plurals — призводить до помилок «1 повідомлення». Завжди використовуйте системні механізми. - Фіксована ширина кнопок — для української використовуйте
wrap_content(Android) абоsizeThatFits(iOS). - Неправильні формати дат —
DateFormatterзuk_UAдає «26 березня 2026», а не «03/26/2026». - Забуті системні рядки —
Cancel,OK,Save— їх теж потрібно локалізувати черезNSLocalizedStringабоstrings.xml. - Посилання на сторонні сервіси — якщо в застосунку є веб-в'ю або кнопки «Зателефонувати», перевірте, що підтримується українська мова.
Що далі?
Зв'яжіться з нами для консультації: ми запропонуємо оптимальне рішення для вашого проєкту. Отримайте попередню оцінку термінів та бюджету протягом одного дня.