Локалізація мобільного додатка узбецькою: де ламається
Випуск додатка на новий ринок рідко впирається в сам переклад — узбецький текст замовляють у носія і отримують за пару тижнів.
Ламається інше: вшиті рядки інтерфейсу розкидані по екранах, частина підписана прямо в розмітці, частина продубльована однією й тією ж фразою в двох-трьох місцях, і перекладач править тільки ті файли, які йому передали.
Зверху додаються тексти з сервера: підказки, повідомлення про помилки, назви розділів приходять з відповідей бекенду і живуть за своїм графіком.
При випуску на узбецький ринок виникає розбіжність текстів між збірками — в одній платформі формулювання вже оновлено, в іншій залишилося колишнім, а частина рядків просто не знайшла перекладу і відкотилася на англійську.
Ціна такої схеми видна на другій-третій ітерації: правку вносять в одному місці, а замовник знаходить старий текст ще в трьох; підтримка перекладів додатка перетворюється на ручне перенесення рядків з таблиці в код перед кожним випуском, і черговий реліз виходить із застарілими формулюваннями, бо переклад прийшов після заморозки гілки.
Розбираємо, як це закривається: єдине джерело рядків, звернення за смисловими ключами замість літералів, окремий шар для серверних текстів і порядок, за якого переклад перестає блокувати випуск.
Що дає локалізація: вимірюваний результат для продукту
Локалізація узбецькою — це не лише переклад рядків. Коли мова стає повноцінною локаллю, тексти живуть у файлах ресурсів із ключами, а не в коді і не в таблицях із перекладачем.
З цього моменту ефект вимірюється в конкретних величинах: терміни оновлень, частка звернень до підтримки щодо формулювань, кількість правок на випуск.
Швидкість випуску та передбачуваність верстки
Правка одного формулювання раніше йшла через переклад, ручну вставку і повторне складання — кілька днів на цикл.
Тепер значення підтягуються з файлів локалізації, а перевірка на пропущені ключі та на довжину рядка виконується автоматично до складання, тому нове формулювання йде в App Store разом із найближчим оновленням.
Узбецька латиниця довша за англійську, тому кнопки та заголовки перевіряються на реальних рядках, а не на англійських заглушках: обрізаний текст і зайві переноси ловляться до випуску, а не за відгуками користувачів.
Менше правок і звернень до підтримки
Частка звернень до підтримки щодо текстів падає, коли терміни зафіксовані в глосарії, а підписи кнопок збігаються з тим, що людина очікує прочитати.
Кількість правок на випуск знижується: повторювані формулювання використовуються повторно з пам'яті перекладів, а не перекладаються заново під кожне складання.
Вартість підтримки перекладів перестає зростати разом із кількістю оновлень — перекладається лише дельта нових рядків, а форми множини, формати дати та роздільників закриті окремим набором тестів.
Способи реалізації перекладу інтерфейсу: порівняння варіантів
Варіантів локалізації додатка кілька, і вони не взаємозамінні. Вибір визначається тим, як часто змінюються тексти, хто їх править і чи потрібні ринку власні сценарії, а не лише інша мова. Нижче — технічні альтернативи, між якими реально обирають перед стартом перекладу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ресурсні файли перекладів | Тексти стабільні, мов дві-три, переклади готові до релізу | Правка рядка вимагає нового складання та повторної перевірки в магазинах |
| Зовнішня платформа керування перекладами | Мов багато, тексти правлять редактори, потрібна історія змін | Потрібен зв'язок зі складанням, частина рядків усе одно залишається в коді |
| Тексти з сервера | Часті правки, сезонні блоки, різні пропозиції по ринках | Без мережі перекладу немає — потрібен запасний набір і збережені дані |
| Окреме складання під ринок | Відрізняються не лише мова, а й розділи, сценарії оплати, порядок екранів | Кожен реліз перевіряється окремо, зростає обсяг регресу |
| Поетапний переклад ключових екранів | Тексту багато, терміни стислі, потрібно перевірити попит на ринку | Змішаний інтерфейс на старті, потрібен облік неперекладених рядків |
Як вибрати варіант під продукт
На практиці схема майже завжди комбінована: навігація та постійні підписи живуть у ресурсних файлах перекладів, змінювані блоки приходять із сервера, а окреме складання потрібне там, де розходяться самі сценарії.
Для узбецької на старті зазвичай беруть поетапний переклад — спочатку шлях до оплати та ключові екрани, потім решту. Обов'язкова умова — запасна мова-джерело: неперекладений рядок показує осмислений текст, а не порожнечу.
Етапи роботи: від аудиту інтерфейсу до передачі складання
Локалізація узбецькою — не заміна рядків у файлі ресурсів. Узбецька буває в латинській і кириличній графіці, а перекладені фрази змінюють довжину: підпис вилазить за кнопку, довгий складений термін ламає сітку екрана. Тому етапи локалізації додатка починаються з аудиту текстів інтерфейсу, а не з перекладу.
- Аудит текстів інтерфейсу. Збираємо всі рядки: підписи, підказки, повідомлення про помилки, порожні стани, сповіщення — включно з тими, що залишилися тільки в макетах.
- Схема ключів перекладів. Приводимо рядки до єдиних ключів і глосарію: одна сутність називається однаково на всіх екранах, ключ не змінюється при правці тексту.
- Переклад і вичитка носієм. Перекладає носій із продуктовою лексикою; терміни узгоджуємо заздалегідь, інакше «кошик» на різних екранах стане трьома різними словами.
- Графіка та мова за замовчуванням. Визначаємо латиницю чи кирилицю, логіку вибору мови за налаштуваннями пристрою та відкат на російську замість порожніх рядків.
- Інтеграція та перевірка верстки. Підключаємо ресурси до обох платформ і проганяємо кожен екран на довгих рядках: де можна — переносимо, де не можна — скорочуємо текст, а не шрифт.
- Тестування та передача складання. Проходимо вхід, оплату, замовлення та сповіщення узбецькою, перевіряємо зміну мови на ходу; віддаємо складання, глосарій, схему ключів та інструкцію щодо нових рядків.
Приймання локалізації
Приймання йде за списком екранів: неперекладених рядків немає, терміни збігаються з глосарієм, підписи не обрізані, дати й числа в узбецькому форматі. Зауваження фіксуємо списком, правимо і показуємо повторно — у публікацію складання йде тільки після закриття всіх пунктів.
Що залишається у замовника: файли перекладів, схеми, регламенти
Локалізація не закінчується перекладом рядків. Після приймання у замовника залишається робочий комплект артефактів, з яким його команда оновлює тексти самостійно, без звернення до нас на кожній правці.
Файли, схеми та профілі
- Файли перекладів — ресурси за мовами з єдиною структурою ключів: узбецький набір лежить поруч із вихідним, додавання нового рядка не ламає інші мовні версії.
- Словник термінів додатка — закріплені переклади продуктових понять, назв кнопок і статусів, щоб один і той самий термін не звучав по-різному на сусідніх екранах.
- Схема проходження рядків — карта: де рядок задано в коді, який ресурс його перекриває, що бачить користувач при непідтримуваній мові і на який набір іде відкат.
- Профілі мов — мова за замовчуванням, порядок вибору та правила підстановки для регіонів; підключення нової мови зводиться до додавання набору ресурсів.
Регламенти та документація
- Регламент оновлення текстів — хто вносить правки, в якій гілці, як рядки потрапляють у складання і що вважається втратою перекладу при злитті.
- Документація з локалізації — правила іменування ключів, обмеження за довжиною рядків під конкретну верстку, порядок перевірки перед релізом.
- Звіт перевірки — частка перекладених рядків за кожною мовою та знайдені розбіжності з прив'язкою до екрана.
Кейс: як ми прибрали розбіжності текстів між платформами
Замовник — сервіс доставки з додатками на двох платформах і веб-кабінетом. Узбецька версія трималася на ручній роботі: рядки були вшиті прямо в код екранів, частина перекладів велася в таблицях, частина — в Crowdin у підрядника.
Розбіжності знайшлися на 96 екранах із 240 — близько 1 800 рядків: на одній платформі кнопка називалася «Buyurtma berish», на іншій — «Buyurtma», а у веб-кабінеті текст відставав на два тижні.
Нове формулювання доїжджало до користувача 18–20 днів: правка в коді, дві перевірки, складання та модерація в магазинах додатків.
Ми зібрали єдиний каталог перекладів із ключами виду checkout.button.submit, контекстом для перекладача та розбивкою по екранах, а складання стало підтягувати актуальні рядки автоматично.
Що саме переносили
Інвентаризацію вели не за файлами, а за екранами — так видно пропуски та дублі:
- підписи кнопок, полів і заголовків екранів;
- тексти помилок і сповіщень;
- формати дати, часу та роздільників розрядів;
- назви категорій і статусів замовлення;
- шаблони повідомлень і листів.
Через два місяці звернення до підтримки зі скаргами на незрозумілий або невідповідний текст впали з 250–270 до 60–70 на місяць.
Час випуску оновлення з новими формулюваннями скоротився з 18–20 днів до 2–3, і пішов цілий клас помилок: правку більше не можна внести в одному місці, а в двох інших не помітити.
Що робити, якщо продукт уже випущено, а переклад потрібен зараз?
Випущений додаток із вшитими в екрани рядками — звичайна ситуація, і вона не вимагає переписувати логіку. Інтерфейс, навігація та бізнес-правила залишаються як є: нова мова додається поверх, бо текст для користувача і код, який ним керує, — різні шари.
Ми починаємо з інвентаризації: збираємо підписи, кнопки, підказки, тексти помилок, листи та push-повідомлення, службові статуси, що приходять із сервера. Усе це виноситься в словники «ключ — значення», де ключ описує роль рядка, а не його поточний вміст.
Головна робота — не переклад, а винесення рядків з коду та верстки. Поки текст лежить усередині екрана, його не можна ні перекласти, ні поправити без нового складання.
Ми розставляємо посилання на словники по всіх місцях виведення, включаючи спливаючі повідомлення та динамічні шаблони, і залишаємо одну резервну мову, на яку додаток відкочується, якщо ключ чомусь не знайдено.
Так зникає клас помилок, коли в новій мові раптом з'являється порожня кнопка або англійська заглушка посеред екрана.
Окремо вирішуємо питання графіки: узбецька існує в латинському та кириличному написанні, і від цього залежить і обсяг перекладу, і верстка.
Зазвичай основним беруть латинський варіант, а кирилицю підключають як другий словник із вибором у налаштуваннях телефону або всередині додатка.
Для локалізації після релізу критична зворотна сумісність перекладів: ключі не видаляються, а позначаються застарілими, нові додаються з готовим текстом резервної мови, а форми множини задаються за правилами мови, а не за правилами вихідної.
Що з уже опублікованими версіями? Рядки, винесені в словники, можна оновлювати віддалено — користувач отримує нову мову, не чекаючи складання в магазині.
А от назва додатка, опис, скріншоти та системні підписи оновлюються тільки разом із версією, тому їх ми готуємо заздалегідь і супроводжуємо регресом по всіх локалях: довгі рядки, переноси, обрізані підписи в кнопках. Далі — як це розкласти за етапами без зупинки продукту.
Часті сумніви: довжина рядків, шрифти, формати дат
Узбецька — аглютинативна мова: слово «прив'язується» афіксами і подовжується в півтора-два рази проти англійської. Якщо рядок не обмежений за шириною, кнопки розпирає, а підписи в два рядки ламають верстку.
Окрема тема — шрифти: кириличний набір вимагає гарнітури з повним покриттям глифів, інакше текст від'їжджає в системний фолбек і вибивається з макета.
Нижче — питання, які найчастіше піднімають до старту робіт.
Скільки рядків насправді потрібно перекладати?
Ресурси додатка — це не лише видимі екрани. У вибірку потрапляють пуш-повідомлення, тексти помилок, листи, описи в магазині додатків, системні запити доступу. На практиці обсяг рядків зростає в півтора рази проти видимого інтерфейсу, і ми закладаємо це в план одразу.
Що робити з текстами, які приходять із сервера?
Частина контенту формується на стороні сервера, і її не можна покласти в ресурси додатка. Такі тексти локалізуємо за заголовком вибраної локалі, а шаблони підстановки та відмінки переносимо в серверні словники.
Фолбек на базову мову залишаємо, щоб при пропущеному ключі користувач бачив осмислену фразу, а не порожній блок.
Як перевірити якість, якщо носія немає в штаті?
Спочатку проганяємо псевдолокалізацію: всі рядки подовжуються штучно, і ми бачимо, де верстка не тримає довжину. Потім зворотний переклад ключових екранів і звірка форматів дат і чисел — порядок дня, місяця та роздільника розрядів в узбецькій локалі відрізняється від звичного. Вибіркову вичитку носієм закладаємо окремим етапом.
Потрібно підтримувати і латиницю, і кирилицю?
Так, обидва набори глифів живуть у додатку одночасно, а перемикач між ними не прив'язаний до системної локалі — користувач обирає сам.
Це означає окремі ключі ресурсів на кожен варіант, перевірка обох наборів на всіх екранах і заборона на склеювання рядків із частин: зібрана фраза не перекладається коректно.
Чи можна поправити переклад після релізу?
Можна, якщо рядки винесені в ресурси і версіонуються. Правки в інтерфейсі йдуть із найближчим оновленням, а тексти на сервері змінюються без перескладання додатка. Кожна зміна проходить рев'ю і потрапляє до спільного словника глосарію, щоб терміни не розходилися між екранами.
Обговоримо задачу: що надіслати для оцінки обсягу перекладу
Щоб повернутися з оцінкою обсягу перекладу та планом робіт із локалізації, а не з уточнювальними питаннями, нам достатньо вихідних даних від замовника. За ними ми рахуємо реальну кількість рядків, а не «приблизно за екранами», і розкладаємо роботу на етапи.
- Файли локалізації в тому вигляді, в якому вони лежать у проєкті — рядкові ресурси Android і iOS. За ними видно обсяг, дублі та рядки, які збираються динамічно і вимагають окремого розбору.
- Список екранів або доступ до тестового складання: допомагає відокремити видимий текст від службових значень — ідентифікаторів, ключів, технічних підписів, які перекладати не потрібно.
- Глосарій продукту та терміни предметної області: назви розділів, тарифів, статусів заявки. Без нього один термін отримує три різних переклади на різних екранах.
- Рішення щодо алфавіту: узбецька на латиниці та кирилиці — це дві повноцінні гілки тексту, і від вибору залежить і обсяг, і структура рядкових файлів.
- Правила відображення даних: дати, суми, роздільники розрядів, формат телефону та адреси. Значення за замовчуванням майже завжди вимагають узгодження з вашою стороною.
- Тексти поза додатком: опис і заголовки в магазинах додатків, шаблони сповіщень, листи, написи на зображеннях і екранах першого запуску.
- Контактна особа з боку замовника, яка узгоджує терміни, та орієнтир за датами релізу — під них ми вибудовуємо етапи.
Опишіть задачу та передайте те, що вже є: частина даних зазвичай дозбирається по ходу. Повернемося з оцінкою обсягу перекладу, планом робіт із локалізації та складом етапів — із зазначенням, що потрібно від вас на кожному з них.
