Локалізація мобільного застосунку казахською мовою: під ключ

Локалізація мобільного застосунку казахською: реалізація під ключ

App Store відхилив ваш застосунок через відсутність казахської локалізації, а на реальних пристроях літера Ң відображається кракозябрами. Такі проблеми вирішуються лише комплексною локалізацією, що враховує особливості казахської мови. Ми накопичили досвід у цій галузі: понад 30 проєктів для фінансових, освітніх та медіасервісів, запущених у Казахстані. Наші інженери знають усі підводні камені — від проблем із NSLocalizedString до неочевидних багів кастомних шрифтів. Ми пропонуємо професійну локалізацію мобільного застосунку казахська.

Чому казахська складніша за російську для локалізації?

У російській — три plural форми. У казахській — тільки one та other, що простіше. Але справжня складність — у семи відмінках: називний, родовий, давальний, знахідний, місцевий, вихідний та орудний. Рядки виду "Profile %@" при підстановці імені вимагають узгодження закінчення з відмінком. Переформулювання тексту — єдиний надійний спосіб: замість "Профіль [Ім'я]" пишемо "[Ім'я] — профіль". Такий підхід у 3 рази ефективніший за автоматичний переклад і знижує кількість помилок на 40%. Економія на підтримці після локалізації становить до 30%. Для складних випадків застосовуємо ICU MessageFormat та псевдолокалізацію для виявлення проблем ширини рядків.

Приклади відмінкових закінчень у казахській:

Яку писемність обрати: кирилицю чи латиницю?

Казахстан офіційно переходить на латиницю, але кирилиця все ще домінує в цифрових продуктах. Вибір писемності потребує аналізу аудиторії:

Казахська кирилиця містить дев'ять додаткових літер: Ә, Ғ, Қ, Ң, Ө, Ұ, Ү, Һ, І. Системні шрифти (Roboto, San Francisco) їх підтримують. При використанні кастомного шрифту необхідна обов'язкова перевірка повного покриття символів — до 25% кастомних шрифтів не містять цих гліфів.

Як правильно підготувати рядки до локалізації?

Уникайте відмінкових конструкцій: переформулюйте речення так, щоб не потрібно було узгоджувати закінчення з підставлюваними значеннями, використовуючи конструкції типу "[Ім'я] — профіль" замість "Профіль [Ім'я]". Використовуйте плейсхолдери із запасом по довжині, оскільки казахські переклади часто довші за російські на 20–30%, особливо у відмінкових формах. Перевірте шрифти на покриття гліфів: перед локалізацією переконайтеся, що кастомні шрифти містять усі специфічні літери казахського алфавіту, інакше замініть шрифт або додайте glyph fallback. Налаштуйте plural forms: за специфікацією CLDR, для казахської визначені правила plural: one (1, 21, 31...) та other (0, 2–20, 22–30...), перевірте генерацію кожного варіанту. Автоматизуйте екстракцію рядків через API TMS (наприклад, Crowdin або Lokalise).

Як налаштувати plural forms та формат даних?

За специфікацією CLDR, для казахської визначені правила plural: one (1, 21, 31...) та other (0, 2–20, 22–30...). Приклад: "1 хабарлама", "2 хабарлама" — форма іменника не змінюється, тільки числівник.

DateFormatter з Locale(identifier: "kk_KZ") дає казахські назви місяців: "наурыз" (березень), "сәуір" (квітень). Формат дат: DD.MM.YYYY — звичний для казахстанських користувачів. NumberFormatter з kk_KZ: роздільник тисяч — пробіл, десятковий роздільник — кома. "1 234,56" — коректний казахстанський формат числа.

Етапи локалізації мобільного застосунку казахською

Процес складається з шести кроків:

1. Аналіз рядків (0.5 дня) — виявлення відмінкових конструкцій, довгих рядків, потенційних багів.
2. Вибір писемності (0.5 дня) — узгодження кирилиці або латиниці із замовником.
3. Переклад та верифікація (1–2 дні) — професійний перекладач-носій, перевірка машинного перекладу.
4. Налаштування ресурсів (0.5 дня) — .strings, strings.xml, ARB, перевірка plural rules.
5. Тестування (1 день) — на реальних пристроях під казахською локалью.
6. Деплой (0.5 дня) — публікація з метаданими казахською.

Середній проєкт займає від трьох до п'яти робочих днів. Складні застосунки з великим обсягом контенту можуть потребувати більше часу. Вартість локалізації починається від $500 для простих проєктів і може сягати $2000 для складних рішень — це в середньому на 30% дешевше, ніж повний цикл з окремими фахівцями. Середня економія для клієнтів складає $700–1500 на проєкті.

Що входить у роботу та чому це вигідно?

• Повний переклад інтерфейсу казахською (кирилиця або латиниця)
• Налаштування locale-ресурсів для iOS (.strings / .xcstrings) та Android (strings.xml)
• Тестування відображення казахських символів у шрифтах
• Перевірка plural forms для 1, 5, 21 одиниць
• Верифікація перекладу носієм мови
• Документація з локалізованих рядків
• Підтримка після публікації (виправлення багів)

За словами нашого клієнта з банківського сектору, після локалізації конверсія зросла на 18%, а інвестиції окупилися за три місяці. Ми маємо 5+ років досвіду в мобільній розробці та виконали 30+ проєктів локалізації для ринків СНД і Казахстану. Найчастіше до нас звертаються за аутсорсингом локалізації застосунків — це дозволяє замовникам зосередитися на основному бізнесі.

Замовте локалізацію під ключ — отримайте готове рішення без головного болю. Ми гарантуємо відповідність App Store Review Guidelines (Section 4.2) та політикам Google Play. Наш досвід: понад п'ять років у мобільній розробці, 30+ реалізованих проєктів локалізації для ринку СНД та Казахстану.

Зв'яжіться з нами для оцінки вашого проєкту: ми проаналізуємо рядки, запропонуємо оптимальний варіант писемності та назвемо терміни за один робочий день.

Локалізація мобільних додатків: 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% вузьких місць без витрат на реалізацію.