Запустив додаток, отримав перші відгуки з Польщі і Німеччини - “Translation is broken”, “Дата відображається неправильно”, “Кнопка обрізана”. А ти думав, що просто переклав текст через DeepL і все готово. Давай розберемося, чому цей підхід не працює і як зробити локалізацію правильно - від strings у коді до описів в App Store.
Локалізація - це не те саме що переклад¶
Локалізація (l10n) - адаптація додатку для конкретного ринку. Не лише текст, а весь користувацький досвід: формати дат і чисел, валюта, напрямок читання (RTL для арабської та іврит), культурно доречні зображення, локальні вимоги до конфіденційності.
Просто переклад тексту - це тільки половина роботи. Ось чому:
- Дата 03/15/2026 в США - 15 березня. В Україні той самий запис виглядає як помилка формату або 3 грудня
- Ціна “$29.99” для американського ринку стає “27,49 €” для Німеччини - з комою замість крапки і символом після числа
- Жест “thumbs up” - позитив в Європі, образа в частині Близького Сходу
За даними дослідження Centus, 87% споживачів не купують на сайтах лише англійською. Ринок локалізаційних послуг досяг $71.7 млрд у 2024 році і росте на 7% щороку. Для мобільних ігор якісна локалізація дає зростання завантажень на 200-300% у нових ринках, для e-commerce - конверсія в покупку зростає на 150%.
Всього 8 мов - англійська, китайська, іспанська, французька, німецька, японська, португальська, арабська - покривають 80% онлайн-купівельної спроможності планети. Не треба локалізувати під 40 мов одразу, але перші 3-5 - вже суттєво розширюють аудиторію.
Strings - технічна основа локалізації¶
Все починається зі strings - рядків перекладу, які зберігаються окремо від коду. Це перший і головний принцип: ніякого хардкоду тексту безпосередньо в коді.
iOS: .strings, .stringsdict і .xcstrings¶
На iOS є три формати, які еволюціонували з часом:
.strings (класичний формат)
Прості пари ключ-значення, зберігаються в папках *.lproj:
/* Кнопка підтвердження */
"confirm_button" = "Підтвердити";
"welcome_message" = "Привіт, %@!";
Кожна мова - окрема папка: en.lproj/Localizable.strings, de.lproj/Localizable.strings, uk.lproj/Localizable.strings. Простий формат, але не підтримує множину і метадані.
.stringsdict (для множини)
XML-формат для рядків з числами, де форма слова залежить від кількості. Необхідний коли треба “1 повідомлення / 3 повідомлення / 5 повідомлень” - і це ще порівняно просто.
.xcstrings (Xcode 15+, сучасний стандарт)
Введений в Xcode 15, JSON-формат об’єднує переваги .strings і .stringsdict в одному файлі. Підтримує множину, варіанти для різних пристроїв, коментарі перекладачам, стан перекладу (new / translated / reviewed / stale). Міграція через Editor → Convert to String Catalog в Xcode 15 - займає кілька хвилин. Саме на нього варто переходити для нових проектів.
Android: strings.xml¶
На Android всі рядки зберігаються в res/values/strings.xml:
<resources>
<string name="confirm_button">Підтвердити</string>
<string name="welcome_message">Привіт, %s!</string>
<plurals name="messages_count">
<item quantity="one">%d повідомлення</item>
<item quantity="few">%d повідомлення</item>
<item quantity="many">%d повідомлень</item>
</plurals>
</resources>
Переклади кладуться в res/values-de/strings.xml, res/values-uk/strings.xml тощо. Система автоматично підбирає потрібний файл залежно від локалі пристрою.
Проблема множини: складніше, ніж здається¶
В англійській мові два варіанти: “1 message” і “2 messages”. Але:
- Українська і російська: 4 форми (1, 2-4, 5+, плюс спеціальна для 11-14)
- Арабська: 6 форм
- Японська та китайська: 1 форма (немає граматичної множини)
Pluralization isn’t just about singular vs plural - it’s a complex linguistic feature that varies significantly across languages. Arabic has 6 plural forms, while Japanese has only 1. Your localization framework needs to handle all of these cases correctly.
Тому “You have ” + count + ” messages” (конкатенація рядків) - провальний підхід. Порядок слів у реченні різний для різних мов, і розбитий рядок неможливо перекласти граматично правильно. Правильно: один ключ з ICU-форматом або plurals, і перекладач сам вписує всі потрібні форми.
Store descriptions: App Store і Google Play - два різних підходи¶
Після того як додаток технічно готовий до локалізації, треба подбати про “вітрину”.
Apple App Store¶
App Store підтримує 40 локалей і вимагає ручного завантаження всіх метаданих для кожної мови - автоматичного перекладу немає.
Що локалізується в App Store:
| Поле | Обмеження | Важливість |
|---|---|---|
| App Name | 30 символів | Критична - впливає на ASO |
| Subtitle | 30 символів | Висока - видно одразу |
| Promotional Text | 170 символів | Можна міняти без нового релізу |
| Description | 4000 символів | Висока - SEO і конверсія |
| Keywords | 100 символів | Критична - ASO ранжування |
| Screenshots | 3-10 штук | Критична - перша точка контакту |
Ключова помилка: перекладати keywords дослівно. Як пишуть у AppLaunchpad, треба rebuild your keyword list from scratch for each country - щоб відображати як користувачі реально шукають в тій мові. Дослівний переклад ключових слів - це успадкувати чужі SEO-помилки замість знайти власні позиції.
Скріншоти - найважливіший елемент конверсії. Більшість користувачів не читають опис, але гортають скріншоти. Локалізовані скріншоти з текстом і культурно релевантними зображеннями дають значно вищий CTR ніж generic.
Google Play¶
Google Play підтримує 70+ мов і має деякі відмінності:
| Поле | Обмеження |
|---|---|
| App Name | 30 символів |
| Short Description | 80 символів |
| Full Description | 4000 символів |
| Screenshots | до 8 штук |
Google Play дозволяє автоматичний переклад описів - але це відправна точка, не фінальний результат. Автоматичні переклади буквальні і губляться нюанси важливі для конверсії.
Одна важлива деталь: App Store і Google Play визначають локалізацію додатку не з тексту опису, а з того, які локалі і переклади ти завантажив через App Store Connect і Play Console. Писати в описі “available in 10 languages” - марна трата символів.
Mінімальна і повна локалізація store¶
Minimum Viable Localization (MVL) - 1-2 тижні: тільки store metadata (назва, опис, keywords, скріншоти). Мета - запустити в новому ринку і зібрати перший фідбек без повної локалізації всього додатку.
Повна локалізація - 4-8 тижнів: metadata + всі рядки інтерфейсу + QA тестування на реальних пристроях.
In-app content: що ще потрібно локалізувати¶
Strings і store descriptions - лише частина. У реальному додатку є ще кілька шарів.
Onboarding¶
Перші екрани після встановлення - критичний момент для утримання. Якщо onboarding виглядає як машинний переклад або незрозумілий - 60-70% нових користувачів йдуть вже на першому тижні.
Але навіть якісний переклад onboarding’у - недостатньо. Value proposition яка резонує в США (“Save time, save money”) може не зачіпати в Японії де цінується надійність і безпека. Це вже культурна адаптація, а не просто переклад.
Push notifications¶
Push-нотіфікації локалізуються двома способами:
- Локалізовані ключі (рекомендовано для iOS): в payload вказується
loc-key, і iOS сам підставляє переклад з.stringsна пристрої - Серверна локалізація: бекенд відправляє готовий текст залежно від мовних налаштувань користувача
Крім тексту важлива культурна адаптація: час відправки (те що добре в 9 вечора в США - неприйнятно в 3 ночі за місцевим часом), тон (в Японії уникають прямих закликів), контент (промо “Black Friday” - тільки там де цей день є).
In-app purchases і підписки¶
Apple дозволяє локалізувати назву і опис кожного in-app purchase через App Store Connect API. “Premium Plan” англійською звучить нейтрально, але локалізована назва підвищує конверсію в платіж.
Ціни також потрібно адаптувати - і це не просто конвертація курсу. Apple і Google мають tier-системи для різних ринків. Ціна $4.99 в США відповідає ¥680 в Японії не за курсом, а за purchasing power parity.
Системні повідомлення і помилки¶
“Error 404”, “Network error” - це теж контент який бачить користувач. Англійські помилки в локалізованому додатку одразу створюють відчуття незавершеності. Локалізуй всі user-facing повідомлення - помилки, підказки, tooltip-и, порожні стани (“No results found”).
Типові помилки при локалізації¶
Хардкод рядків у коді¶
// Неправильно
label.text = "Завантаження..."
// Правильно
label.text = NSLocalizedString("loading_label", comment: "Loading indicator text")
Хардкодений текст перекладач просто не знайде. Це найпоширеніша помилка в проектах де локалізацію “додали пізніше”.
Конкатенація рядків¶
// Неправильно - не можна перекласти
label.text = "Ви маєте " + String(count) + " повідомлень"
// Правильно
label.text = String(format: NSLocalizedString("messages_count", comment: ""), count)
Порядок слів у реченні різний в різних мовах. Якщо розбити рядок на частини і склеїти - переклад буде граматично неправильним незалежно від якості перекладача.
Відсутність контексту для перекладачів¶
Рядок "OK" може бути кнопкою підтвердження видалення, підтвердження покупки або закриття модального вікна - і в кожному випадку переклад може відрізнятися. Без скріншоту або коментаря перекладач гадає навмання.
Нерахування на розширення тексту¶
Різні мови займають різну кількість місця порівняно з англійською:
| Мова | Середнє розширення |
|---|---|
| Німецька | +30-40% |
| Французька | +15-20% |
| Іспанська | +15-25% |
| Японська | -40% (компактніша) |
| Китайська | -30% |
Кнопка “Save” (4 символи) стає “Speichern” (9 символів) або “Зберегти” (8 символів). Якщо UI не адаптовано під розширення - текст обрізається або кнопка деформується.
RTL без підтримки¶
Для арабської, іврит і перської мови не лише текст іде справа наліво - увесь layout має дзеркально відобразитися. Кнопка “Назад” переходить у правий кут, іконки міняються місцями. iOS і Android надають API для цього, але розробники часто забувають перевірити RTL-режим.
Як пише Phrase у своєму блозі:
RTL support isn’t just about flipping text direction - it’s about mirroring the entire UI, including icons, progress bars, and animations. When targeting Arabic or Hebrew speakers, test your app in RTL mode before release.
Інструменти для локалізації мобільних додатків¶
Ручне ведення файлів перекладу - робочий підхід для 1-2 мов. Для 5+ мов і CI/CD потрібен TMS (Translation Management System).
| Інструмент | Ціна | Сильні сторони |
|---|---|---|
| Lokalise | від ~$120/міс | Мобільні SDK, over-the-air оновлення |
| Crowdin | від $25/міс, безкоштовно для open-source | 700+ інтеграцій, GitHub/GitLab sync |
| Phrase | від ~$100/міс | TM, глосарії, QA-чекери |
| SimpleLocalize | є безкоштовний tier | Простота, CLI, CI/CD |
Ключові фічі при виборі:
- Over-the-air updates: оновити переклади без публікації нового релізу в App Store/Google Play
- GitHub/GitLab integration: автоматичний sync файлів при кожному коміті
- Context: скріншоти або live preview для кожного ключа - перекладач розуміє де і як буде відображатися рядок
- Plural editor: зручний редактор форм множини для кожної мови
За даними автотесту Crowdin vs Lokalise, Crowdin має перевагу для open-source і проектів з великою кількістю GitHub-інтеграцій, Lokalise - для продуктових команд де важлива мобільна SDK і over-the-air.
Як організувати процес: continuous localization¶
Локалізацію не треба “додавати після того як додаток готовий” - це антипатерн. Правильний підхід - continuous localization, паралельно з розробкою.
Рекомендований workflow¶
- i18n з першого дня: виніс всі рядки в resource файли, налаштував форматування дат/чисел через ICU/NSDateFormatter, перевірив RTL layout з самого початку
- Підключив TMS: налаштував sync з репозиторієм через GitHub Action або webhook - нові ключі автоматично потрапляють до перекладачів
- Підготував контекст: для кожного ключа додав скріншот або опис де цей рядок з’являється
- Замовив переклад: machine translation як чернетка + людський post-editing для публічних текстів (store description, onboarding)
- QA на реальних пристроях: перевірив всі мови, RTL, truncation, дати/числа, in-app purchases
- Запуск і моніторинг: дивишся на відгуки і ratings в нових локалях - вони покажуть де щось пропущено
Увага: machine translation для технічних strings (системні повідомлення, повідомлення про помилки) - нормально. Але onboarding, store description і маркетингові тексти потребують людського перекладача або хоча б якісного post-editing - саме тут конверсія.
FAQ¶
Яка різниця між i18n і l10n?¶
i18n (internationalization) - технічна підготовка коду: виніс рядки в resource файли, налаштував форматування, підтримка RTL. Це робиться раз і назавжди розробником.
l10n (localization) - адаптація для конкретного ринку: переклад рядків, адаптація скріншотів, локальні ціни, культурна адаптація. Це постійний процес для кожної нової мови.
З яких мов починати локалізацію?¶
Орієнтуйся на дані свого продукту і ринку. Для English-продукту зазвичай перший крок - Spanish, French або German: великі ринки, близька культура, добрі перекладачі. Для пострадянських продуктів якщо вже є Ukrainian або Russian - далі зазвичай English, потім Polish або German.
8 мов покривають 80% купівельної спроможності - не треба локалізувати під 40 одразу.
Чи можна використовувати тільки машинний переклад?¶
Для технічних strings і системних повідомлень - так, якість DeepL або GPT-4 достатня. Але для store description, onboarding і маркетингових текстів потрібен людський перекладач або post-editing. Машинний переклад в критичних точках конверсії знижує довіру і CTR.
Скільки коштує локалізація мобільного додатку?¶
Залежить від обсягу і кількості мов. Орієнтовно для однієї мови:
- Тільки store metadata: $150-400
- MVL (metadata + критичні strings): $300-800
- Повна локалізація середнього додатку: $800-3000+
TMS-інструменти: Crowdin від $25/міс, Lokalise від $120/міс.
Чи треба локалізувати push-нотіфікації?¶
Так, і не лише текст. Push у неправильний час (через різницю часових поясів), з агресивним тоном для ринків де це неприйнятно, або з нерелевантним контентом - пряма дорога до unsubscribe і uninstall. Особливо це критично для Японії і Кореї де тон комунікації дуже відрізняється від американського.
Що робити якщо в App Store відхилили скріншоти для локалізованої версії?¶
Перевір App Store Review Guidelines для конкретної країни і адаптуй скріншоти відповідно. Для деяких ринків (Китай, Саудівська Аравія) вимоги до контенту суттєво відрізняються від загальних правил.