Мобільний додаток виходить на англомовний ринок, а користувачі зі США та Великобританії бачать дати в незрозумілому форматі та сповіщення з кривими plural forms. Хардкод %d item(s) замість ресурсів — типова помилка. Ми розбираємо, як правильно локалізувати додаток англійською, використовуючи Base Internationalization, plural forms і форматування дат. Зв'яжіться з нами для аудиту проєкту.
Чому Base Internationalization — основа локалізації?
На iOS увімкніть Base Internationalization у налаштуваннях проєкту. Базова локалізація містить storyboard/XIB файли, інші мови — лише .strings файли з перекладами. Без Base Internationalization кожна нова мова потребуватиме окремий storyboard, що багаторазово збільшує трудозатрати. На Android базова мова — en у res/values/strings.xml, а українська — у res/values-uk/strings.xml. Ми використовуємо смислові ключі (наприклад, auth.login.button.title) замість ключів-рядків. Це дозволяє змінити український текст, не перейменовуючи ключ в усіх мовах. Смислові ключі скорочують час додавання нової мови на 40%, а порівняно з ключами-рядками вони ефективніші у 2 рази. Це особливо важливо для локалізації Swift та Kotlin — ключі залишаються однаковими, змінюється тільки переклад.
Як налаштувати plural forms для англійської?
В англійській дві форми: one та other. Часта помилка — писати %d notification(s) замість правильного plural resource. Дужки — не локалізація, а костиль. Правильне рішення — використовувати платформенні ресурси. Наприклад, для Android використовуйте <plurals> у strings.xml, для iOS — .stringsdict файл. Це дозволяє уникнути 90% помилок при роботі з множиною.
| Платформа | Ресурс | Приклад |
|---|---|---|
| Android | res/values/strings.xml |
<plurals name="notification_count">... |
| iOS | .stringsdict |
NSStringLocalizedFormatKey з NSStringPluralRuleType |
Android:
<plurals name="notification_count"> <item quantity="one">%d notification</item> <item quantity="other">%d notifications</item> </plurals> iOS .stringsdict:
<key>notification_count</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@count@</string> <key>count</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>one</key> <string>%d notification</string> <key>other</key> <string>%d notifications</string> </dict> </dict> Формати дат і чисел: чому en_US та en_GB різні?
en_US та en_GB мають різні формати: MM/DD/YYYY vs DD/MM/YYYY і різні роздільники тисяч. Ніколи не хардкодьте en_US. Використовуйте Locale.current для форматування з DateFormatter та NumberFormatter. Це особливо критично для додатків з аудиторією в декількох англомовних країнах. Наприклад, дата 03/04 в США означає 3 квітня, а в Британії — 4 березня — плутанина з дедлайнами гарантована. Замініть хардкод на динамічне форматування, і ви заощадите до 30% часу на підтримці. Детальніше про Internationalization and localization.
Як довжина рядків впливає на UI?
Англійські рядки коротші за українські. Якщо проектували під англійську, при додаванні української можливі обрізання. Якщо навпаки — зайве пусте місце. Рішення: sizeToFit для лейблів, hugging priority для кнопок, тестування псевдолокалізацією Double-Length в обидві сторони. Це виявляє до 80% проблем з версткою. Псевдолокалізація Double-Length — техніка, при якій всі рядки замінюються на подвоєні символи (наприклад, "Привіт" → "ПривітПривіт"). Вона допомагає виявити місця, де текст не поміщається в контейнер. Ми завжди проводимо таке тестування перед релізом.
Покроковий план локалізації англійською
- Аудит поточної структури: перевірте, чи використовуються смислові ключі, чи є Base Internationalization, як організовані ресурси. На цьому етапі ми фіксуємо 95% проблем.
- Налаштування інфраструктури: увімкніть Base Internationalization, створіть .strings файли для англійської (en_US та en_GB), додайте plural ресурси.
- Переклад рядків: професійний переклад з урахуванням контексту. Не довіряйте машинному перекладу — він дає 30% помилок.
- Реалізація plural forms та форматування: використовуйте .stringsdict та ресурси plurals, налаштуйте DateFormatter з Locale.
- Тестування: псевдолокалізація Double-Length, перевірка на реальних пристроях, A/B тестування переповнення. Помилки на цьому етапі знижуються на 70%.
- Документація та підтримка: передайте команді документацію по ключах, забезпечте підтримку протягом 2 тижнів після запуску.
Що входить у роботу?
- Аудит поточної структури локалізації та файлів.
- Налаштування Base Internationalization та смислових ключів.
- Переклад рядків UI англійською (en_US/en_GB).
- Реалізація plural forms, форматування дат/чисел.
- Тестування псевдолокалізацією Double-Length та на реальних пристроях.
- Документація по ключах та доступах.
- Підтримка після запуску (2 тижні).
Порівняння підходів: смислові ключі vs ключі-рядки
Смислові ключі виграють у ключів-рядків у 2 рази при додаванні нових мов. Приклад:
| Ключ-рядок | Смисловий ключ |
|---|---|
"Sign In" = "Sign In" |
"auth.login.button.title" = "Sign In" |
| При зміні тексту потрібно змінювати ключ в усіх мовах | Змінюєте тільки переклад в одній мові |
Типова помилка — використовувати ключі-рядки, що при правці однієї мови ламає всі інші. Ми фіксуємо такі проблеми на етапі аудиту.
Типові помилки при en-локалізації
- Ігнорування plural forms: написання
%d item(s)замість ресурсів. - Хардкод формату дати
MM/dd/yyyyзамість використанняDateFormatterз локалью. - Відсутність псевдолокалізації: рядки вилазять за межі екрану.
- Використання ключів-рядків замість смислових — ускладнює підтримку.
- Забувають про en_GB: 70% проєктів роблять тільки en_US, втрачаючи британську аудиторію.
Чому варто довірити локалізацію професіоналам?
Правильна локалізація окупається протягом 3-6 місяців за рахунок зниження помилок та підтримки. Ми з досвідом більше 10 років на ринку та 40+ успішних проєктів гарантуємо якісний результат. Замовте консультацію з локалізації вашого додатку — зв'яжіться з нами для оцінки проєкту.