Зауважте: коли мов стає більше двох, прямолінійна локалізація перестає працювати: пропущені рядки, зламані plurals, неправильне форматування дат. Наша команда — 7+ років досвіду в мобільній розробці та понад 30 проєктів з мультимовністю — знає, як спроєктувати i18n-інфраструктуру, яка масштабується без болю. Грамотна архітектура окупається на третій мові: кожна наступна мова потребує на 60% менше зусиль, а бюджет на переклади скорочується на 40–50%. Наприклад, для проєкту з 5 мовами автоматизація через TMS заощаджує до $3000. Отримайте консультацію — ми оцінимо ваш проєкт.
Архітектура i18n: від простого до правильного
iOS
Стандарт — Localizable.strings + .stringsdict для plurals + XLIFF для обміну з перекладачами. String(localized:) API (Swift 5.5+) — найкращий спосіб, оскільки підтримує interpolation, plural rules та comment для перекладача в одному виклику:
let message = String(localized: "notifications.count \(count)", comment: "Number of unread notifications in tab bar") Для великих проєктів з 1000+ рядками — String Catalog (.xcstrings, Xcode 15+). Він замінює розрізнені .strings файли єдиним JSON-файлом з вбудованим diff та попередженнями про неперекладені рядки. String Catalog працює в 2 рази швидше за Localizable.strings при додаванні нових мов. Apple рекомендує String Catalog для нових проєктів.
Android
strings.xml в res/values/ (базовий) + res/values-{lang}/ для кожної мови. plurals в тому ж файлі. Для параметричних рядків — іменовані аргументи:
<string name="welcome_user">Ласкаво просимо, ARG!</string> ARG замість %s — обов'язково при множинних аргументах, оскільки порядок слів у різних мовах різний.
React Native
react-i18next — де-факто стандарт. Namespace-и для розбивки по модулях, lazy loading для економії трафіку. Plural forms через i18next-icu з ICU Message Format — коректно обробляє українські, російські, польські правила.
Flutter
flutter_localizations + intl пакет. ARB-файли — стандарт. flutter gen-l10n генерує type-safe Dart-класи, виключаючи помилки:
Text(AppLocalizations.of(context)!.notificationCount(count)) Plural forms описуються в ARB через ICU syntax.
Порівняння підходів до i18n
| Платформа | Формат рядків | Plural forms | Інтеграція з TMS |
|---|---|---|---|
| iOS | .strings / .xcstrings | .stringsdict | XLIFF / API |
| Android | strings.xml | XLIFF / API | |
| React Native | .json / .po | i18next-icu | API |
| Flutter | ARB | ICU syntax | API |
Усі платформи підтримують автоматичну синхронізацію через TMS, що знижує ручну працю на 90%.
Динамічна зміна мови
Системна локаль — не завжди те, що потрібно. iOS підтримує вибір мови через CFBundleLocalizations + зберігання в UserDefaults. Android — AppCompatDelegate.setApplicationLocales() (AndroidX) або ручна заміна Resources.updateConfiguration(). При зміні мови перестворюйте всі форматтери з новою locale.
Plural forms: зведена таблиця
| Мова | Кількість форм | Складність |
|---|---|---|
| Англійська | 2 (one/other) | Низька |
| Українська | 3 (one/few/many) | Середня |
| Російська | 3 (one/few/many) | Середня |
| Польська | 4 (one/few/many/other) | Висока |
| Арабська | 6 форм | Дуже висока |
| Китайська | 1 форма | Немає |
ICU Message Format обробляє всі ці варіанти автоматично. Ручне розгалуження — антипатерн.
Чому автоматизоване керування перекладами краще за ручне?
Ручний експорт/імпорт XLIFF — основне джерело помилок. Автоматизований пайплайн через TMS (Phrase, Lokalise, Crowdin) синхронізує рядки між кодом і перекладачами без файлового обміну. Автоматизація у 3 рази швидша за ручний XLIFF та економить до 60% часу на кожній новій мові.
Як правильно організувати plural forms для складних мов?
Використовуйте готові рішення фреймворку: iOS .stringsdict, Android plurals, Flutter ICU в ARB, React Native i18next-icu. Вони беруть на себе коректні правила для будь-яких мов. Не пишіть власні switch — це зламається на польській (4 форми) або арабській (6).
CI/CD та якість перекладів
Інтегруємо перевірки в пайплайн:
- Lint для рядків: twine (iOS), android-strings-lint — знаходять пропущені переклади, невикористані ключі, неекрановані спецсимволи
- Screenshot тести: fastlane snapshot (iOS) або screengrab (Android) — автоматично роблять скріншоти на всіх мовах, регресію UI помітно одразу
- Translation Management System: Phrase, Lokalise, Crowdin — синхронізують рядки між кодом і командою перекладачів
Що входить в роботу
- Документована архітектура i18n під вашу платформу
- Інтеграція з TMS та автоматична синхронізація
- Налаштований CI/CD пайплайн з лінтерами та скріншот-тестами
- Навчання команди додаванню нових мов та роботі з перекладами
- Гарантія якості перекладів та сумісності з усіма платформами
Що ви отримаєте в результаті
- Готова інтеграція з TMS та автоматична синхронізація
- Налаштований CI/CD пайплайн з лінтерами та скріншот-тестами
- Навчання команди додаванню нових мов та роботі з перекладами
Процес роботи
- Аудит поточної архітектури та виявлення больових точок (2–3 години)
- Проєктування i18n-інфраструктури під платформу (iOS, Android, Flutter, React Native)
- Винесення всіх рядків у ресурси з підтримкою plurals та інтерполяції (1–2 дні на першу мову)
- Інтеграція TMS та налаштування автоматичної синхронізації (1 день)
- Налаштування CI/CD лінтерів та скріншот-тестів для контролю перекладів (1 день)
- Навчання команди та документація (0.5 дня)
Строки
Орієнтовні строки: від 3 до 10 робочих днів залежно від платформи, кількості мов та готової інфраструктури. Вартість розраховується індивідуально. Отримайте консультацію — ми оцінимо ваш проєкт.