Аудит і тестування локалізації мобільних додатків

Тестування локалізації мобільного застосунку: типові збої

Локалізація ламається не в перекладі, а у верстці: рядок польською або німецькою довший за вихідний на третину, і кнопка з фіксованою шириною перетворює його на «Підтвер…».

Обрізаний текст в інтерфейсі — найчастіший збій локалізації, і він небезпечний тим, що сенс губиться саме на дії: підтвердження, оплата, видалення. Псевдолокалізація, де рядки штучно подовжують до перекладу, знаходить такі місця раніше, ніж у проєкт прийдуть реальні мови.

Неперекладені рядки живуть там, де їх не видно у файлах ресурсів: підказки системних дозволів, сповіщення, листи, описи в магазині застосунків, повідомлення про помилки від серверних сервісів.

Такий текст спокійно проходить перевірку вихідною мовою і спливає лише в користувача, тому перевірка мовних версій включає обхід не лише екранів, а й усього, що надходить ззовні застосунку.

Формати дат, чисел і одиниць — другий клас відмов. 03/12 читається як березень або грудень залежно від локалі, кома проти крапки в десяткових дробах ламає введення в полях, а правила множини для російської (1 товар, 2 товара, 5 товаров) не закриваються простою підстановкою числа.

Арабська та іврит додають дзеркальну розкладку: іконки, стрілки та індикатори прогресу мають розвертатися разом із текстом.

Тестування локалізації мобільного застосунку йде за матрицею «екран × мова × пристрій»: найвужчий і найширший екран, великий системний шрифт, свідомо довгі рядки, розкладка справа наліво.

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

Що дає аудит перед релізом: ефект у термінах і дефектах

Регулярний аудит локалізації переводить мовні дефекти з розряду «знайшов користувач» у розряд «знайшла перевірка».

Час приймання версії скорочується з двох-трьох днів ручного вичитування кількома мовами до кількох годин прогону перевірок і розбору звіту — при цьому перевіряється не лише переклад, а й верстка інтерфейсу: обрізання рядків у кнопках, перенесення, порядок елементів у розкладках із письмом справа наліво.

Головне джерело проблем — регрес мовних версій. Рядки змінюються під час доопрацювання основної гілки, і мовна версія мовчки втрачає частину перекладу: форми множини для мов, де їх кілька, відмінювання, форматування дат і розділювачів розрядів. Без перевірки на кожній збірці такий дефект потрапляє в публікацію і спливає вже у відгуках.

Окрема ціна — терміни випуску релізу. Мовний дефект знаходять після публікації, і цикл «заявка → виправлення → повторне приймання» в App Store зсуває дату випуску на дні, а якщо реліз уже узгоджено з просуванням — на тиждень. Перевірки перед відправленням на модерацію прибирають цей клас простоїв повністю.

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

Способи перевірки: ручний прогін, автотести, гібридний підхід

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

Коли екранів десятки, а мов п’ять і більше, ручний прохід перед кожним релізом перестає масштабуватися — перевіряльник встигає пройти одну-дві мови, решта виходять у реліз без перевірки.

Зворотна крайність — автотести на продукті з щотижневою правкою верстки: їх доводиться підтримувати частіше, ніж вони встигають окупитися.

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

Ручний прохід запускають під час додавання мови, великих правок інтерфейсу та перед значущими релізами, автоматичний — на кожну зміну. Регрес із локалізації проходить хвилинами, а зусилля команди йдуть туди, де машина поки безсила.

Етапи впровадження: від аудиту до передачі команді

Локалізація не перевіряється одноразово: рядки змінюються кожним релізом, частина правок надходить уже після вичитування, а нові мови додаються по одній.

Тому етапи впровадження перевірки вибудовуємо послідовно — від інвентаризації рядків до регламенту, який команда замовника далі веде сама.

Як вибудована послідовність

1. Інвентаризація рядків. Збираємо всі ресурси локалізації: файли рядків, текст у розмітці й коді, пуш-повідомлення, листи, описи в магазинах застосунків. На виході — карта, де видно обсяг за кожною мовою та точки правок.

2. Схема перевірок. Для кожної групи рядків фіксуємо, що саме перевіряємо: довжину відносно вихідної, обрізання в інтерфейсі, порядок слів, формати чисел і дат, множинні форми, відповідність глосарію.

3. Критерії приймання. Домовляємося, що вважаємо дефектом, а що — допустимим відхиленням, і в якому вигляді приймається звіт. Без цього суперечку про невдале формулювання не закрити.

4. Автоматичні прогони. Частину перевірок підключаємо до збірки: незаповнені рядки, неузгоджені підстановки та вихід за глосарій зупиняють збірку до ручного етапу.

5. Пілот і калібрування. Проганяємо схему однією мовою та набором екранів, рахуємо частку хибних спрацювань, уточнюємо правила — так ручний прохід не розтягується.

6. Приймання на релізному кандидаті. Ручний прохід за ключовими сценаріями на реальних пристроях зі збільшеним системним шрифтом — там обрізання та перенесення вилазять найчастіше.

7. Передача регламенту. Віддаємо карту рядків, набір правил, шаблон звіту та інструкцію з додавання нової мови.

Пакет передачі: конфігурації, схеми, політики доступу

Результат аудиту локалізації — не звіт «на згадку», а робочий пакет передачі: конфігурації, схеми й регламенти, за якими ваша команда далі перевіряє переклади сама.

Усе складається в репозиторій проєкту й версіонується разом із кодом, тому пакет не застаріває після зміни підрядника чи звільнення інженера.

• Конфігурація перевірок — правила щодо порожніх і неперекладених рядків, дублів ключів, розбіжностей у підстановках і переповнення елементів інтерфейсу; запускається однією командою локально та на складальному сервері.
• Карта екранів — таблиця «екран → елемент → ключ рядка → мови → статус»: видно, які місця закриті автоматикою, а які залишилися на ручну перевірку.
• Матриця локалей — мови з напрямом письма, форматами дат, чисел і порядком сортування; нові локалі додаються за цією ж схемою, без перебудови процесу.
• Політики доступу — хто з команди, перекладачів і підрядників править файли перекладу, хто лише пропонує правки та як зміни потрапляють в основну гілку.
• Схема зберігання рядків — де лежать ресурси за платформами, які формати обміну підтримуються і як один рядок перевикористовується в кількох екранах.
• Регламент релізу — короткий чек-ліст перед публікацією: прогін конфігурації перевірок, підтвердження правок перекладачем, фіксація стану рядків під конкретну версію.

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

Кейс: аудит локалізації скоротив відмови після оновлення

Що було до аудиту

Застосунок замовника виходив вісьмома мовами, а переклад приїздив одним файлом за пару днів до збірки. У німецькій та арабській локалях обрізалися кнопки й заголовки карток, дати та суми залишалися у форматі вихідної мови, частина інтерфейсу взагалі йшла англійською.

Дефекти знаходили користувачі: у відгуках у Google Play з’явилися згадки про кривий переклад, а підтримка отримувала звернення через плутанину в кроках оплати. Оцінити масштаб було нічим — збірка одна, логи за локалями не розрізнялися, перевіряли однією мовою та одним пристроєм.

Що змінили

• Псевдолокалізація: рядки штучно подовжували до перекладу — обрізання у верстці видно до роботи перекладачів.
• Автотести інтерфейсу за локалями: знімки екранів порівнювалися з еталоном, розходження вище порогу позначалося дефектом.
• Глосарій: терміни, відмінки, правила множини та звернення до користувача.
• Формати дат, чисел і розділювачів — через системні засоби локалі, а не рядкові шаблони.
• Матриця пристроїв і розмірів екрана, включно з режимом справа наліво та великим системним шрифтом.
• Набір перевірок приймання версії, прив’язаний до релізної гілки.

Метрики до і після

Перші два спринти пішли на розбір накопичених розходжень, далі частка дефектів тримається на новому рівні: їх ловлять на збірці, а не після публікації. Реліз перестав залежати від того, хто сьогодні дивився конкретну локаль.

Чим відрізняється перевірка перекладу від приймальних прогонів?

Перевірка перекладу відповідає на питання, чи правильно написано текст; приймальні прогони — чи правильно поводиться застосунок у цьому мовному середовищі.

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

Приймальні прогони — це перевірка верстки та поведінки інтерфейсу: чи не обрізався заголовок, чи не роз’їхалася кнопка від довгого підпису, чи не поїхали відступи.

Окреме завдання — дзеркалювання для письма справа наліво: змінюються напрям тексту, порядок елементів і напрям жестів. Плюралізація та сортування списків теж перевіряються тут, тому що правила мови живуть у коді, а не у файлі перекладу.

Помилки форматування даних видно лише на живому прогоні: порядок дати й часу, розділювачі розрядів, порядок імені та прізвища, відмінювання числівників.

Окремий клас — екрани, де замість перекладу підставляється вихідна мова: це проявляється під час перемикання мови всередині працюючого застосунку, а не під час першого запуску з локаллю пристрою.

Різниця підходів задає порядок робіт. Спочатку закривають текстовий шар — правка в ресурсах не потребує перезбірки та повторного прогону. Потім іде приймальний прогін на кожному цільовому мовному середовищі: встановлення, перший запуск, покупка, перемикання мови на ходу. Успішний прогін на одній локалі не гарантує, що те саме місце не зламається на іншій.

Збірки та формати: часті питання перед стартом

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

Частина текстів надходить із сервера — ви їх теж покриваєте?

Так, інакше аудит закриває половину сценаріїв. Серверні відповіді та значення перемикачів не лежать у файлах локалізації: перед перевіркою підмінюємо мову, очищаємо кеш і заново прогріваємо стенд — інакше побачимо стару мову й запишемо хибний дефект. Окремо звіряємо формат дат, чисел і валют, які надходять уже готовими.

У якому порядку йдуть прогони?

Спочатку базова мова — ловимо регрес верстки без впливу перекладу. Потім повна зміна мови на пристрої, далі псевдолокалізація з подовженими рядками: вона показує, де текст обрізано або перенесення ламає кнопку.

Мови з письмом справа наліво перевіряємо останніми — там змінюється напрям інтерфейсу, а не лише текст.

Правки внесли — перевіряти все заново?

Повторна перевірка точкова. Перевіряємо екрани, яких торкнулася правка, і шукаємо змінений рядок по всьому застосунку: один ключ часто використовується в кількох місцях. Якщо правка в загальному рядку або шаблоні — розширюємо вибірку до сусідніх розділів.

Обговоримо задачу: що потрібно для оцінки та плану

Щоб повернутися з оцінкою обсягу та планом робіт, а не із загальними словами, нам потрібна збірка й розуміння, які ринки для вас пріоритетні.

Нижче — те, що ми зазвичай запитуємо під час першої розмови: якщо чогось немає, частину даних відновимо самі за кодом і тестовими обліковими записами.

• Перелік локалей і пріоритет ринків — від нього залежить, скільки мовних гілок перевіряємо вручну, а скільки закриваємо псевдолокалізацією та регулярними перевірками.
• Файли локалізації у вихідному вигляді (.strings, .xml, .json, XLIFF, ARB) і глосарій — за ними видно, де переклад уже розійшовся з інтерфейсом.
• Тестова збірка й доступи: облікові записи, стенди, тестові платіжні сценарії, канал внутрішнього розповсюдження збірок.
• Карта екранів із пріоритетом: реєстрація, оплата, оформлення замовлення, сповіщення — їх перевіряємо першими й докладніше.
• Обмеження за довжиною рядків і правила оформлення дат, чисел, одиниць вимірювання, адрес і телефонів.
• Вимоги до стилю й тону тексту, а також хто на вашому боці затверджує спірні формулювання.
• Релізний графік: до якої дати потрібен звіт і чи є вікно на виправлення до публікації.
• Які дефекти локалізації траплялися раніше і що вже перевіряли — щоб не дублювати роботу.

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