Налаштування плюралізації рядків у мобільному додатку

Уявіть: ви запускаєте додаток з українською локалізацією, а користувач бачить «2 товарів» замість «2 товари». Знайома ситуація? Ми, команда мобільних розробників з п'ятирічним досвідом, стикалися з цим десятки разів. Правильна плюралізація — не примха, а вимога публікації в сторах і основа довіри користувачів. В англійській всього дві форми: one та other. В українській — чотири: one, few, many, other. Ігнорування цього — гарантований баг при локалізації на будь-яку слов'янську мову. Наше рішення спирається на стандарт CLDR (Common Locale Data Repository), який підтримується всіма сучасними фреймворками. За нашими даними, впровадження плюралізації на старті проекту знижує кількість багів локалізації на 80%, а економія на виправленні цих помилок може досягати 70% бюджету на локалізацію. Отримайте консультацію щодо впровадження плюралізації у вашому проекті вже сьогодні.

Які проблеми вирішує правильна плюралізація?

Граматичні помилки в UI. Некоректні закінчення (наприклад, «5 користувачів» замість «5 користувачів» в українській) знижують довіру до продукту. Проблеми з публікацією в сторах: суворі правила вимагають коректної локалізації, інакше відхилення релізу. Зайві трудозатрати: якщо спочатку не закласти плюралізацію, переписувати код під кожну нову мову — дорого та ризиковано.

Чому CLDR — єдиний правильний стандарт?

CLDR надає універсальний набір правил для всіх мов. Використання самописних умов на основі оператора % призводить до багів для дробових, від'ємних чисел та нуля. Наприклад, CLDR для української мови для чисел 0, 0.5, 1.5, 2.1 повертає 'other', а не 'few'. Нативне рішення (plurals.xml / stringsdict) вп'ятеро надійніше за самописну if-логіку — виключає баги для нестандартних чисел.

Приклади форм для української мови за CLDR

Як реалізувати плюралізацію на кожній платформі?

Android. Використовуйте файл res/values-uk/plurals.xml:

<plurals name="items_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.items_count, count, count). Перший count — для вибору форми, другий count — підстановка в %d. Часта помилка: передати лише один аргумент — тоді число в рядок не підставляється.

iOS. Створіть Localizable.stringsdict (формат plist) з ключем та вкладеними правилами. Структура включає NSStringLocalizedFormatKey та категорії за CLDR. Для Swift-пакетів з Xcode 15+ використовуйте String Catalog — візуальний редактор plural forms.

Виклик: String(format: NSLocalizedString("items_count", comment: ""), count) — автоматично вибере потрібну форму.

Flutter. Пакет intl надає метод Intl.plural():

Intl.plural(
  count,
  zero: 'немає товарів',
  one: '$count товар',
  few: '$count товари',
  many: '$count товарів',
  other: '$count товару',
  locale: 'uk',
);

Або через ARB-файли з генерацією flutter gen-l10n — опишіть плюралізацію в app_uk.arb з ICU-синтаксисом.

React Native. Використовуйте i18next з плагіном i18next-icu або нативний Intl.PluralRules (доступний з RN 0.70+). Вручну: new Intl.PluralRules('uk').select(count) повертає 'one'/'few'/'many'/'other', за яким вибираєте форму з об'єкта перекладів.

const pluralRules = new Intl.PluralRules('uk');
const form = pluralRules.select(count);
const translations = {
  one: `${count} товар`,
  few: `${count} товари`,
  many: `${count} товарів`,
  other: `${count} товару`,
};
console.log(translations[form]);

Порівняння підходів

Як протестувати плюралізацію на граничних значеннях?

Обов'язково перевірте числа 0, 1, 2, 5, 21, 1.5, -1. Для української мови 21 відноситься до форми 'one', а 1.5 — до 'other'. Для кожної мови ці значення свої. Напишіть модульні тести, які прогоняють всі граничні числа та перевіряють, що повертається правильна форма. Використовуйте таблицю CLDR для автоматичної генерації тестових наборів.

Типові помилки та їх вирішення

• Використання лише one та many без урахування few для слов'янських мов — баги для чисел 2, 3, 4.
• Неправильний порядок аргументів у Android — число не підставляється, якщо передано лише один параметр.
• Ігнорування дробових чисел (наприклад, 1.5) — без CLDR форма 'other' не застосовується.
• Самописна if-логіка на операторі % — при додаванні нової мови доведеться переписувати умови.

Наше рішення повністю виключає ці помилки завдяки строгому слідуванню CLDR та автоматизованому тестуванню на граничних значеннях.

Що входить у роботу

1. Аудит поточної кодової бази та перекладів.
2. Розробка схеми плюралізації для всіх цільових мов.
3. Впровадження нативних рішень (plurals.xml, stringsdict, ARB, i18next).
4. Написання тестів для граничних випадків (0, 1, 2, 5, 21, 1.5).
5. Документація та навчання команди.

Наша команда має п'ятирічний досвід у мобільній розробці та реалізувала 30+ проектів з локалізацією. Ми гарантуємо коректну роботу plural forms на всіх пристроях. Вартість впровадження окупається в перші місяці після публікації завдяки зниженню баг-репортів.

Терміни: від чотирьох годин (аудит + заміна хардкоду) до двох днів (якщо плюралізація в кількох мовах та кастомні компоненти). Зв'яжіться з нами для аудиту вашого проекту — ми запропонуємо оптимальне рішення. Замовте консультацію вже сьогодні, щоб уникнути багів локалізації.

Локалізація мобільних додатків: i18n, RTL, динамічне перемикання мови

При локалізації додатків ми часто стикаємося з неочевидними помилками: дата 04/05 для американця — це 5 квітня, для європейця — 4 травня. Сума «1,000.50» в більшості країн — тисяча з половиною, в Німеччині — один і п'ятдесят центів. Число слів для «1 файл», «3 файли», «5 файлів» в українській — три різні форми; арабська має шість форм множини. Якщо архітектура додатку не враховує це з самого початку, локалізація перетворюється на серію патчів. Наш 7-річний досвід у мобільній розробці та 50+ релізів в App Store і Google Play підтверджують: правильний i18n/l10n з першого коміту окупається багаторазово.

Як налаштувати базову інфраструктуру локалізації?

iOS: від Localizable.strings до String Catalogs

Історично рядки в iOS зберігалися в Localizable.strings — простий key=value формат. З Xcode 15 з'явилися String Catalogs (.xcstrings) — JSON-based формат, який зберігає всі локалі в одному файлі, відображає статус перекладу (перекладено/застаріло/відсутній) та інтегрований з Xcode UI.

String(localized: "welcome_title") в Swift 5.7+ замінює NSLocalizedString(...). Коротше, типобезпечніше. String Interpolation в локалізованих рядках: String(localized: "items_count \(count)") з правилом плюралізації в .xcstrings — система автоматично вибере потрібну форму для мови. Плюралізація через .stringsdict (старий підхід) або прямо в String Catalog з NSStringPluralRuleType. Для української потрібно визначити форми one (1 файл), few (3 файли), many (5 файлів), other (fallback). Пропустити few для української — означає отримати «5 файлів» там де має бути «3 файли». String Catalogs скорочують час налаштування вдвічі порівняно з .stringsdict.

Android: XML resources та рядкові формати

res/values/strings.xml для базової локалі (en), res/values-uk/strings.xml для української. Plural strings через <plurals> з <item quantity="one">, <item quantity="few">, <item quantity="many">. resources.getQuantityString(R.plurals.file_count, count, count) — перший count вибирає форму, другий підставляється в рядок.

В Compose: stringResource(R.string.key) та pluralStringResource(R.plurals.file_count, count, count). Типобезпечна альтернатива — бібліотека Lyricist, яка генерує типізовані рядки з анотацій.

Android App Bundle з android:splitByLocale="true" в bundle.gradle — ресурси доставляються тільки для мов пристрою. APK зменшується на 15-20%, ресурси потрібних локалей довантажуються через Play Asset Delivery. Важливо: на Android 8+ Configuration.locales — список, не одна мова.

Flutter: intl та шари абстракції

Flutter intl пакет — стандарт. AppLocalizations.of(context).welcomeTitle генерується з ARB-файлів (app_en.arb, app_uk.arb). flutter gen-l10n генерує типізований код. Pluralization через {count, plural, one{# файл} few{# файли} many{# файлів} other{# файла}} в ARB.

Для великих додатків з 50+ мовами — easy_localization з підтримкою YAML/JSON/CSV форматів та lazy loading перекладів: не всі 50 мов завантажуються одразу, тільки потрібна. Це знижує розмір початкового завантаження на 30%.

Порівняльна таблиця підходів

Як реалізувати RTL-підтримку без переписування UI?

Арабська, іврит, перська, урду — мови RTL (Right-to-Left). Це змінює не тільки напрямок тексту, а й всю розкладку UI: back button справа, іконки дзеркально, паддінги та марджини інвертуються.

На iOS все робиться через semanticContentAttribute та Auto Layout. Layout constraint-и з leading/trailing (не left/right) автоматично інвертуються при RTL. UIView.semanticContentAttribute = .forceRightToLeft для конкретного компонента. Системні компоненти (UINavigationController, UITableView, UIStackView) перемикаються автоматично при RTL-локалі. Проблеми виникають з кастомними UI, де розробник жорстко використав left/right констрейти або frame-based layout. Ми в таких випадках переписуємо кастомні в'ю на Auto Layout — це займає 1-2 дні на екран.

На Android android:supportsRtl="true" в AndroidManifest включає RTL-підтримку. start/end замість left/right в XML-атрибутах: paddingStart, layout_marginEnd, textAlignment="viewStart". LayoutInflater з android:layoutDirection="rtl" для прев'ю. Іконки з напрямленістю (стрілки, шеврон) потрібно дзеркалювати — android:autoMirrored="true" в drawable для автоматичного інвертування при RTL.

На Flutter Directionality віджет з TextDirection.rtl керує напрямком для піддерева. Padding(EdgeInsetsDirectional.fromSTEB(...)) замість EdgeInsets.only(left:...). Row автоматично враховує TextDirection з Directionality. Більшість Material віджетів RTL-ready, але кастомні CustomPainter — ні: потрібно отримувати TextDirection з context та враховувати вручну.

Тестування RTL: на iOS Settings → General → Language & Region → Region: Saudi Arabia перемикає в RTL режим без зміни мови системи. На Android adb shell setprop debug.force.rtl 1 форсує RTL для налагодження. Це дозволяє виявити до 80% проблем RTL до релізу.

Чому динамічне перемикання мови — вузьке місце?

Перемикання мови без перезапуску додатку — нетривіальне завдання, особливо якщо система побудована на системній локалі. Ми виділили три основні підходи.

iOS не підтримує зміну мови додатку без перезапуску нативно. Найчистіший підхід — зберігати вибрану мову в UserDefaults, при запуску створювати Bundle з потрібною локалізацією, використовувати кастомний NSLocalizedString через цей Bundle. Bundle.setLanguage("uk") через swizzling Bundle.localizedString(forKey:value:table:) — працює, але це runtime swizzling, що не ідеально. Альтернатива: власна система рядків поверх NSBundle, яка перечитує файли при зміні мови. При перемиканні — перестворити кореневий ViewController.

Android з API 33: LocaleManager.setApplicationLocales() — офіційний API для зміни мови додатку без перезапуску системи, без рекреації Activity якщо використовувати AppCompatDelegate.setApplicationLocales(). До API 33 — Configuration.setLocale() + recreate() для Activity. При зміні мови потрібно повідомити всі відкриті Activity через broadcast або ViewModel. Для Android 12+ ми також використовуємо android:localeConfig в маніфесті — це дозволяє системі дізнатися підтримувані мови без додаткової конфігурації.

Flutter — найпростіший з трьох. LocalizationsDelegate перезавантажується при зміні locale в MaterialApp. Зберігаємо вибрану мову в провайдері (Riverpod/Provider/Bloc), зміна locale в MaterialApp перебудовує дерево з новими рядками. Практично без бойлерплейту при використанні easy_localization. Однак є нюанс: всі StatefulWidget, які не підписані на зміну локалі, не оновляться — потрібно явно передавати локаль через InheritedWidget або перестворювати дерево.

Форматування дат, чисел, валют

DateFormatter (iOS) та DateFormat (Android, intl) — завжди з явним locale, ніколи без нього. DateFormatter().dateStyle = .medium з locale = Locale(identifier: "uk_UA") дасть «4 травня», з Locale(identifier: "en_US") — «May 4». Ми використовуємо RelativeDateTimeFormatter (iOS 13+) та RelativeTimeFormatter через intl пакет — не винаходьте велосипед з ручним форматуванням.

NumberFormatter / NumberFormat.currency() для валют. Символ валюти, роздільники тисяч та дробової частини — все locale-специфічно. Хардкодити «₴» або «.» як роздільник — помилка. Locale(identifier: "uk_UA") + NumberFormatter.numberStyle = .currency з currencyCode = "UAH" дасть правильне форматування автоматично.

Типові помилки при локалізації

Конкатенація рядків замість форматування: "Hello, " + name + "!" працює для SVO-мов, але в японській ім'я йде перед зверненням. String(format: "greeting %@", name) з greeting = "%@ さん、こんにちは" в японському файлі — правильно. Фіксований розмір UI під текст: німецька в середньому на 30% довша за англійську. AutoLayout з правильними констрейнтами, adjustsFontSizeToFitWidth там де допустимо, динамічна зміна висоти комірок через UITableView.automaticDimension. Зображення з вбудованим текстом вимагають локалізованих версій або заміни на text overlay.

Процес роботи: як ми локалізуємо додаток під ключ

1. Аналітика та аудит (2-5 днів) — рев'ю коду на i18n-готовність, виявлення хардкоду, оцінка RTL-складності, підготовка карти екранів.
2. Проектування архітектури (3-7 днів) — вибір стеку (String Catalogs/ARB/XML), налаштування пайплайнів автоматизації (Crowdin/Lokalise), створення базових рядків.
3. Реалізація (1-4 тижні залежно від обсягу) — впровадження i18n, плюралізації, RTL, форматування. Паралельно — переклад контенту.
4. Тестування (3-7 днів) — функціональне (зміна мови, RTL, відображення чисел), лінгвістичне (LQA), скріншотне тестування (локалізовані стор-скріншоти).
5. Деплой та моніторинг (1-2 дні) — публікація в сторах, налаштування аналітики (події на мови), зворотній зв'язок від користувачів.

Що входить в deliverables

• Вихідний код з повною i18n-інфраструктурою
• Документація з додавання нової мови (playbook)
• Файли перекладів (ARB/XML/xcstrings) + глосарій
• Автоматизація: CI/CD інтеграція з сервісами перекладів
• Доступ до репозиторію з повною історією змін
• Навчання команди замовника (1-2 сесії)
• Гарантія на код — 6 місяців, безкоштовні фікси багів локалізації

Строки та вартість

Вартість розраховується індивідуально на основі обсягу коду, кількості мов та складності RTL. В середньому економія бюджету за рахунок автоматизації досягає 40%. Ми оцінюємо проект безкоштовно — зв'яжіться, щоб отримати кошторис та план робіт.

Чому варто обрати нас

Ми сертифіковані розробники (Apple WWDC Scholarship, Google Associate Android Developer). За 5 років на ринку реалізували понад 50 проектів з локалізацією, включаючи додатки для 15 мов з RTL. Гарантуємо дотримання App Store Review Guidelines (Section 4.2/5.1) та Google Play Policies (User Data). Наші клієнти відзначають скорочення часу виходу на нові ринки в середньому на 40% за рахунок автоматизації перекладів та продуманої архітектури.

Додаткову інформацію про інтернаціоналізацію та локалізацію можна знайти в Wikipedia та специфікації RTL.

Отримайте консультацію по вашому проекту — залиште заявку на сайті, ми підготуємо детальний план та строки. Замовте аудит локалізації вашого додатку: перший етап показує до 80% вузьких місць без витрат на реалізацію.