Локалізація мобільного застосунку: де ламається англійська версія
Локалізація мобільного застосунку найчастіше ламається не на перекладі рядків, а на assumptions, зашитих у код. Розробник верстає екран під російський текст, де «Оформить заказ» займає 15 символів, а англійське «Proceed to checkout» — 19.
При фіксованій ширині кнопки або висоті рядка текст обрізається, кнопка виїжджає за межу контейнера, а на маленьких екранах ламається вся сітка.
Те саме з форматами дат: dd.MM.yyyy в англійській версії читається як MM/dd/yyyy, і «03.04» перетворюється з третього квітня на четверте березня — у звітах, бронюваннях і нагадуваннях це критична помилка.
Окремий клас проблем локалізації — відмінювання та множинні числа. У російській «1 товар, 2 товара, 5 товаров» — три форми, в англійській — дві (1 item, 2 items). Якщо в коді зашита логіка if (count === 1), англійська версія або покаже «1 items», або зламає лічильник на нулі.
Аналогічно з відмінками в шаблонах листів і пуш-повідомлень: підстановка імені в російське речення працює, в англійське — дає «Hello, Ivan Ivanov!» замість «Hi, Ivan».
Третя зона — верстка під інший шрифт і напрямок читання. Англійські рядки в середньому на 30% довші за російські за того самого сенсу, а перенесення слів працюють інакше: там, де російський текст акуратно лягає в два рядки, англійський вимагає трьох.
Якщо макет зверстаний під фіксовану висоту картки або банера, англійська версія або обрізає текст, або розтягує блок і ламає сусідні елементи.
Ми починаємо не з перекладу, а з аудиту коду на зашиті рядки, формати та логіку відмінювань — і тільки потім збираємо англійську версію. Розбираємо, як це закривається на кожному шарі.
Що дає коректна локалізація англійською
Конверсія на вході падає менше
Застосунок, де інтерфейс, тексти помилок і системні діалоги зібрані під одну мову, на англомовному ринку втрачає користувача ще до першої корисної дії.
Людина бачить незнайомі формулювання на екрані реєстрації або в запиті дозволу — і закриває застосунок, не дійшовши до цінності продукту.
Коли рядки, формати дат, валют і адрес приведені до локалі, шлях від встановлення до першої цільової дії стає передбачуваним: частка тих, хто дійшов до неї, зростає, а не впирається в мовний бар'єр.
Відтік після першого запуску знижується
Основна втрата відбувається в перші сесії: користувач не розуміє підказок, не знаходить потрібний розділ, спотикається об кривий переклад. Локалізація прибирає цю причину — тексти написані носієм мови під контекст екрана, а не перекладені порядково.
У результаті утримання на першому тижні вирівнюється: люди повертаються, бо інтерфейс поводиться так, як вони очікують від застосунку своєю мовою.
Повторні правки інтерфейсу більше не потрібні
Коли рядки винесені в окремі файли ресурсів, а не зашиті в код, додавання нової мови або правка формулювання не вимагає перезбирання логіки й повторного узгодження екранів.
Це знімає цілий клас задач: маркетинг змінює текст акції, підтримка уточнює формулювання помилки — без участі розробників. Інтерфейс перестає бути вузьким місцем, а команда не витрачає цикли на однотипні доопрацювання.
Англомовний ринок стає керованим
Локалізація — це не разовий переклад, а інфраструктура: єдиний глосарій, правила для чисел і дат, перевірка довжини рядків під реальні екрани. З нею вихід на новий регіон — це підключення мови, а не переписування продукту.
Ефект вимірний: зростання конверсії в цільових країнах, зниження відтоку після першого запуску та відсутність повторних правок інтерфейсу при кожному оновленні.
Підходи до локалізації: ручний, автоматизований, гібридний
Вибір режиму визначає не лише якість рядків, а й те, як команда житиме з цим далі: хто редагує тексти, як часто, що відбувається при оновленні макета. Нижче — три робочі схеми з їхніми реальними межами застосовності.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручна локалізація | Продукт із юридично значущими текстами, складною термінологією, коротким списком мов; є носій мови в контурі | Дорожче за часом на ітерацію, потребує процесу синхронізації правок із вихідною мовою |
| Автоматичний переклад | Швидкий вихід на новий ринок, інтерфейсні рядки без юридичного навантаження, багато мов при малому обсязі тексту | Не розрізняє контекст екрана, ламає довжину рядків і верстку, потребує обов'язкової вичитки перед публікацією |
| Гібридний підхід | Основний сценарій для продуктів зі зростанням: критичне перекладається вручну, решта — машиною з подальшим редагуванням | Потрібна розмітка рядків за пріоритетом і дисципліна оновлення пам'яті перекладів |
Ручна локалізація дає передбачуваний результат там, де помилка коштує дорого: платежі, згоди, юридичні формулювання.
Автоматичний переклад закриває обсяг — він не розрізняє рід, відмінок і контекст кнопки, тому рядки на кшталт «Надіслати» і «Надіслати заявку» на виході можуть збігтися, а верстка поїде через різну довжину фраз.
Гібридний підхід знімає це обмеження: рядки позначаються за критичністю, критичні йдуть перекладачеві, решта проходять машину й обов'язкову вичитку.
Пам'ять перекладів при цьому фіксує вже узгоджені терміни — при додаванні нової мови команда не перекладає продукт заново, а добирає те, чого не вистачає.
Як ми проводимо локалізацію: від аудиту до передачі
Локалізація — це не переклад рядків, а зміна збірки, яка зачіпає ресурси, верстку та логіку екранів. Тому ми ведемо її як інженерний процес із фіксованими етапами: на кожному є артефакт, який можна перевірити до переходу до наступного кроку.
- Аудит рядків. Збираємо всі текстові ресурси з коду та розмітки, включно з підписами, зашитими в логіку, форматами дат і чисел, текстами помилок і push-повідомлень. На виході — реєстр рядків із позначками, що перекладається, що залишається константою, а що потребує переробки: склеювання фраз через конкатенацію та жорстко задані відмінки під час локалізації ламаються першими.
- Проєктування словника. Формуємо глосарій термінів і єдиний стиль для англійської версії, щоб один і той самий термін не перекладався трьома способами на різних екранах. Заодно закладаємо запас за довжиною рядків: англійські підписи в середньому на чверть довші за вихідні, і це напряму впливає на верстку кнопок і табів.
- Налаштування пайплайну локалізації. Підключаємо файли перекладів до системи керування перекладами та до збірки так, щоб оновлення рядків не потребувало ручної правки коду. Далі нові рядки потрапляють до словника автоматично, а збірка підхоплює актуальну версію — розбіжностей між гілками не виникає.
- Перевірка верстки. Проганяємо екрани з англійськими рядками й дивимося, де текст обрізається, переноситься негарно або наїжджає на елементи. Правки вносимо в розмітку, а не підгонкою перекладу під вихідну довжину.
- Тестування на пристроях. Перевіряємо сценарії на реальних апаратах: зміна мови на льоту, формати дат і чисел, сортування списків, пошук, повідомлення. Окремо дивимося крайні випадки — довгі імена, відсутні рядки, поведінка під час перемикання мови під час роботи застосунку.
- Передача. Віддаємо словник, налаштований пайплайн та інструкцію, як додавати нові мови без перезбирання логіки. Далі команда замовника розширює локалізацію самостійно.
Такий порядок прибирає головну причину зривів — правки в переклад, коли проблема насправді у розмітці або в логіці екрана.
Що замовник отримує після локалізації застосунку
Локалізація — це не лише перекладені рядки. Після релізу англійської версії у команди залишається набір артефактів, за якими продукт розвивається далі без повторного «перекладацького спринту» на кожному оновленні.
- Файли локалізації — структуровані ресурси за мовами (рядки, формати дат, чисел, валют, одиниць вимірювання). Розділені за екранами та модулями, щоб правка однієї фрази не зачіпала інші.
- Глосарій термінів — узгоджений словник продуктових і доменних понять із перекладом і позначкою «не перекладати». Прибирає різнобій, коли той самий термін на різних екранах звучить по-різному.
- Схеми екранів із прив'язкою рядків — карта, де видно, який ключ відповідає за який елемент інтерфейсу. Новий рядок додається в потрібне місце, а не «куди-небудь».
- Регламент оновлення — порядок дій під час додавання тексту: хто вносить рядок, як він потрапляє у файли локалізації, які перевірки проходить до релізу.
- Інструкція для команди — короткий документ для розробників і контент-менеджерів: як працювати з ключами, що робити з довгими фразами, як перевіряти верстку після правок.
- Чек-ліст приймання — набір перевірок перед випуском: повнота перекладу, відсутність обрізаних написів, коректні формати та розкладка на реальних пристроях.
- Звіт за покриттям — частка перекладених і перевірених рядків за екранами. Видно, що залишилося, і не доводиться шукати пропуски вручну.
Ці артефакти передаються команді замовника разом із застосунком. Далі англійська версія оновлюється штатним порядком: правки йдуть через глосарій і регламент, а не через разовий переклад «з нуля».
Кейс: як англійська версія перестала ламати верстку
До нас звернувся застосунок сервісу доставки: російська версія працювала стабільно, а англійська після запуску викликала хвилю скарг.
На 40% екранів текст обрізався або наїжджав на сусідні елементи — кнопки виїжджали за межі картки, заголовки у два рядки перекривали іконки, а на екрані оформлення замовлення сума й підпис поля злипалися в один рядок. Користувачі не розуміли, що натиснути, і покидали кошик на останньому кроці.
Причина виявилася не в перекладі, а у верстці. Макети збиралися під російські рядки: фіксована ширина контейнерів, жорсткі висоти кнопок, перенесення, зашиті в розмітку. Англійські формулювання в середньому на 30-40% довші, і там, де російський текст уміщався, англійський уже ні.
Окремо додали проблему формати: дати, суми та розділювачі розрядів виводилися за однією схемою для всіх мов.
Ми почали з інвентаризації: пройшли по всіх екранах і зібрали список місць із фіксованими розмірами.
Далі перевели інтерфейс на самопідлаштовувані контейнери — висота за вмістом, перенесення рядків замість обрізання, обмеження за кількістю рядків лише там, де це усвідомлене рішення.
Формати дат і чисел винесли в окремий шар, який підставляє правила під вибрану мову, а не під регіон збірки.
Окремо прогнали макет на «довгих» мовах — німецькій і фінській, де рядки ще довші за англійські. Це дало запас: наступна локалізація не потребуватиме переверстки.
Для перевірки зафіксували автотести на скриншотах ключових екранів — вони ловлять обрізання й накладання до релізу, а не після скарг.
Результат: частка екранів з обрізаним текстом упала з 40% до нуля, а час випуску оновлень скоротився вдвічі — правки перестали впиратися в ручне підганяння кожного рядка під контейнер. Додавання нової мови тепер займає дні, а не тижні.
Duolingo
Чим відрізняється локалізація від інтернаціоналізації?
Інтернаціоналізація — це інженерна підготовка коду до багатомовності, локалізація — наповнення вже готового каркаса конкретною мовою. Різниця принципова: інтернаціоналізацію роблять один раз і на рівні архітектури, локалізацію — стільки разів, скільки мов ви додаєте.
Якщо код до багатомовності не підготовлений, кожна нова мова перетворюється на переписування екранів, а не на переклад рядків.
На етапі інтернаціоналізації з інтерфейсу виносять усі тексти в окремі файли ресурсів, прибирають склеювання фраз зі шматків і жорстко зашиті формати. Рядки отримують ключі, а не «живуть» прямо в розмітці екрана.
Окремо налаштовують форматування дат, чисел, валют і одиниць вимірювання — воно залежить від регіону, а не лише від мови, і підставляється за локаллю пристрою. Тільки після цього переклад стає заміною одного файлу ресурсів, а не правкою коду.
Локалізація починається там, де інтернаціоналізація закінчилася. Перекладачеві віддають не абзаци, а ключі з контекстом: де рядок з'являється, скільки місця займає на екрані, що означає.
Англійські фрази зазвичай довші за вихідні, тому верстку перевіряють на переповнення й обрізання, а не лише на сенс. Окрема робота — культурна адаптація: формати адрес, порядок імені та прізвища, іконки й жести, які в іншій культурі читаються інакше.
Практична ознака правильно проведеної інтернаціоналізації — додавання нової мови займає дні й не потребує участі розробників у правці екранів. Якщо ж кожна мова тягне за собою зміну коду, значить, підготовку було пропущено, і локалізація йде за найдорожчим сценарієм.
Тому ми завжди починаємо з аудиту коду на готовність до багатомовності, а вже потім беремося за переклад інтерфейсу.
Часті технічні сумніви при локалізації англійською
Локалізація англійською здається простою рівно до першого релізу: рядки винесені, файли перекладені, а на пристрої все одно випливають обрізані кнопки та «дивні» дати. Нижче — технічні сумніви, які найчастіше виникають у замовників, і як ми їх закриваємо.
Англійський текст коротший за український — навіщо переверстувати інтерфейс?
Коротший у середньому, але не скрізь: терміни на кшталт «Save changes» або «Notification settings» довші за звичні підписи й не вміщаються в кнопку фіксованої ширини.
Тому після перекладу проганяємо збірку з псевдолокалізацією — підставляємо подовжені рядки й дивимося, де текст обрізається або наїжджає на іконку. Правки вносимо в макет, а не «підганяємо» шрифт на око.
Чи потрібно підключати окремий шрифт під латиницю?
Зазвичай ні: системні шрифти платформ коректно відображають латиницю, кирилицю та діакритику. Проблеми починаються, якщо в проєкті кастомний шрифт без повного набору гліфів — тоді частина символів підмінюється і верстка «пливе». Перевіряємо покриття гліфів і за потреби розширюємо набір, а не змінюємо типографіку цілком.
Чому не можна просто віддати рядки перекладачеві й вставити назад?
Тому що частина рядків — не текст, а логіка: відмінювання, порядок слів у реченні, формати чисел і дат. Англійська вимагає іншого порядку та розділювачів — «1,234.56» замість «1 234,56», місяць перед днем у датах.
Ми виносимо такі значення в параметри локалі, щоб формат підставлявся системою, а не хардкодився в рядку.
Як ви працюєте з правками від носіїв мови?
Носій бачить готовий екран, а не таблицю рядків, — тому правки надходять предметні: тон, термінологія, невдалі формулювання. Кожну правку фіксуємо в системі перекладів з контекстом екрана, щоб при наступному релізі вона не загубилася й не відкотилася. Так словник продукту залишається узгодженим між релізами.
Обговоримо ваше завдання з локалізації мобільного застосунку
Щоб оцінка була предметною, а не «приблизною», на вході потрібні чотири речі: поточний стан застосунку, перелік екранів під локалізацію, обсяг тексту й верстки та вимоги до англійської мови. З цим набором ми повертаємося з планом робіт і строками, а не із загальними словами.
Що варто підготувати до розмови
- Платформи та поточна збірка — які версії в проді, чи є вже задел під мультимовність або рядки вшиті прямо в код.
- Перелік екранів — які розділи перекладаємо англійською мовою: онбординг, каталог, оплата, повідомлення, налаштування.
- Обсяг тексту — приблизна кількість рядків і знаків, включно з підказками, помилками, листами та пушами.
- Верстка та графіка — де текст вшитий у зображення, де кнопки фіксованої ширини й не переживуть подовження рядків.
- Дані та формати — дати, числа, валюти, одиниці вимірювання, які змінюються при переході на англійську мову.
- Магазини та правила — опис застосунку, скриншоти, ключові слова для карток у сторах.
- Доступи — репозиторій, тестові збірки, акаунти магазинів, якщо локалізацію потрібно довести до публікації.
Розмова займає небагато часу: ви описуєте завдання, ми ставимо уточнювальні питання щодо екранів і рядків. Далі — оцінка за етапами, склад робіт і порядок викладки.
Обговоримо ваше завдання з локалізації мобільного застосунку — напишіть, що вже зроблено і які екрани потребують уваги.
