Localization Testing: як забезпечити якість продукту на глобальному ринку

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Вітаю, спільното! Я Ольга — Consultant, Lead Software Test Engineer у GlobalLogic. Мій загальний досвід в IT більш ніж 15 років. Зараз я працюю на проєкті, де існує локалізація більш ніж на 50 мов. І за понад 7 років роботи ми з командою встигли зібрати чималу колекцію цікавих кейсів, несподіваних багів і болючих (але корисних) уроків.

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

Що таке Localization Testing

Локалізація — це значно більше, ніж просто переклад тексту в застосунку. Це адаптація продукту до певної культури, регіону, законодавства, традицій та мовних норм. Відповідно, Localization testing — це не про перевірку перекладу. Це про повагу до культури та правильний користувацький досвід. Це комплексний тестовий процес, який гарантує, що продукт виглядає природно та органічно для користувача з будь-якої країни. Хороша локалізація — та, яку не помітно. Коли користувач навіть не здогадується, що продукт створювався не під його ринок.

Давайте розберемо на прикладі En-US, En-Uk або En-Ca. Здавалось би, англійська і англійська, навіщо такий розподіл. Наведу кілька прикладів: навмисно беру одну з найбільш розповсюджених мов, щоб показати, що можна пропустити навіть у такому легкому кейсі.

Порівняльна таблиця локалей

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

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

Довгі слова, що не вміщуються у дизайн (redlines, cut off)

Дуже часто застосунок розробляється спочатку для англійської мови як міжнародної, а потім локалізується. Але не всі мови таки лаконічні як англійська, і слова можуть просто не вміщатися на кнопках. Або ж загалом текст не вміщується на сторінку, й ми стикаємось з redlines and cut off. Є мови, де окремі слова можуть бути надзвичайно довгими, бо вона дозволяє «склеювати» багато частин в одне слово:

• Ескімосько-алеутські (інупіак, інуктітут). Наприклад: tusaatsiarunnanngittualuujunga — «Я не можу дуже добре чути».
• Маорі та інші полінезійські мови.
• Абхазька, кабардинська (Кавказ) — складна морфологія дозволяє утворювати довгі слова.
• Фінська має дуже довгі, складні слова, як-то: lentokonesuihkuturbiinimoottoriapumekaanikkoaliupseerioppilas.
• Угорська має багато суфіксів і префіксів, наприклад: megszentségteleníthetetlenségeskedéseitekért.
• Німецька — довгі складні іменники, адже їх можна нескінченно поєднувати: Donaudampfschifffahrtsgesellschaftskapitän.
• Норвезька: minoritetsladningsbærerdiffusjonskoeffisientmålingsapparatur(технічний термін).

У результаті — кнопки «ламаються», текст обривається, UI попливе.

Проблема italic (курсиву) в «oriental languages»

У китайській, японській, корейській (CJK) немає традиції курсиву. Він є європейською типографічною особливістю. У CJK-алфавітах символи складаються з ієрогліфів, які не передбачають варіацій наклону. А тому:

• Italic виглядає так само як normal.
• Або стає некрасивим/нерозбірливим.
• Або шрифт просто не підтримує курсив, і браузер/система створює псевдо-italic (скошування), що виглядає погано й дивно для носіїв такої мови.

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

У нашому випадку було прийнято рішення заміняти курсив в орієнтал мовах на виділення кольором, оскільки за вимогами необхідно було зберегти форматування для всіх культур так само як в en-US інстансах.

Right to Left (RTL) мови це окремий біль

RTL (Right-to-Left) мови — це мови, у яких текст читається і пишеться справа наліво (Арабська, Іврит, Перська (Farsi), Урду, Пушту). Right-to-Left мови — це завжди великий обсяг ручної перевірки, де потрібна дуже велика концентрація та уважність. Нижче я наведу основний чек-лист, що потрібно перевіряти для RTL локалізацій.

• Вирівнювання в таблицях. В HTML/CSS потрібно враховувати dir="rtl«.
• Порядок колонок у таблицях потрібно інвертувати.
• Курсор повинен розміщуватись ліворуч після символу.
• Елементи інтерфейсу мають відображатися «дзеркально»:
  • меню праворуч;
  • scrollbar зліва (якщо потрібно);
  • каруселі, слайдери мають працювати у зворотному напрямку.
• Напрямок стрілок потребує інверсії.
• Розташування днів тижня також потребує інверсії.
• Перевіряємо, що іконки «дивляться в правильному напрямку» (дзеркально в порівнянні з англійською версією).

• Якщо є картинки — може виникнути необхідність віддзеркалити їх:

• Уважно перевіряйте змішування RTL і LTR. Важливо пам’ятати, що такі елементи як числа, назви брендів або терміни англійською чи українською мовами мають зберігати свій природний напрямок читання (LTR).

Особливості сортування та пошуку

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

• У турецькій мові існують дві різні літери «i», які відрізняються регістром і крапкою:
  • мала літера i з крапкою;
  • велика літера İ з крапкою;
  • мала літера ı без крапки;
  • велика літера I без крапки.

Пошук по слову «İstanbul» може не знаходити «istanbul» без правильної локалізації.

• У скандинавських мовах: å, ø, ä, ö — окремі літери абетки, які стоять в кінці алфавіту. Стандартні алгоритми сортування без локалі можуть помилково поставити ці літери між a—z, порушуючи природний порядок. Пошукові системи мають враховувати, що å ≠ a, ä ≠ a, ø ≠ o. Пошук «Ålesund» без правильної локалі може не знаходити записи.
• Німецький пошук має правильно обробляти ß як ss.
• Французька: é, è, ê — окремі символи, важливі для сортування словників.

Практичні наслідки для QA:

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

Часові пояси timezone

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

• Визначення часової зони користувача.
• Літній/зимовий час.
• Змішані часові зони у багатокористувацьких системах.
• Різні робочі тижні.
  • Саудівська Аравія: неділя—четвер.
  • Ізраїль: неділя—четвер.
  • Афганістан: субота—четвер.
• Часові пояси з частковими зсувами.
  • Індія: UTC+5:30.
  • Непал: UTC+5:45.
  • Австралія: UTC+9:30.
  • Ньюфаундленд (Канада): UTC—3:30.

Проблеми у тестах та автоматизації. Тести падають, якщо:

• середовище має інший timezone;
• дата зафіксована як Date.now() без normalization;
• моковані дати не враховують DST;
• сервіси повертають час у різних форматах (UTC, local machine).

Культурні та контекстні помилки

Iконки або символи, які мають негативні конотації:

• 👍 у деяких країнах Близького Сходу вважається грубим жестом.
• 👌 у Бразилії — непристойний знак.
• Рука з долонею («п’ятірка») може бути образливою в Греції.
• Сова у деяких країнах Африки — символ смерті.
• Хрест, зірка Давида, півмісяць — небажані у будь-яких контекстах поза релігійним.
• Зображення Будди на сувенірах — образливо в Таїланді.

Приклади, що не підходять конкретній аудиторії:

У глобальній рекламі iPhone 17 Air показано, як користувач тримає телефон між великим та вказівним пальцем (пінч-жест). Але в офіційних корейських рекламних матеріалах цей жест був видалений. За даними корейських медіа, це пов’язано з тим, що жест «пінч-руки» в деяких корейських онлайн-спільнотах може мати підтекст приниження до чоловіків («남혐» — «misandry») і викликати негативну реакцію.

Особисто я зтикнулась з тим, що перекладачі-локалізатори майже повністю змінили контент у дитячому навчальному застосунку. Адже контекст, який розуміє дитина в одній країні, не буде зрозумілим в іншій. Як приклад: дитина з Індіі не скаже, які овочі потрібні для борщу, а дитина в Україні — не знає, що потрібно для Кхічрі.

А також варто враховувати різницю в датах свят (День подяки в США і Канаді святкується у різні дні), форми звертання (пан/месьє/сан/місіс) та культурні особливості, як-то кольори, символи, формулювання, етикет комунікації, локальні вимоги. Наприклад, білий колір символізує удачу в західних країнах, але в азіатській культурі він асоціюється з трауром.

Рекомендації для локалізаційного тестування

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

Тут є ще один цікавий і неочевидний момент. Мови, які виглядають «незвично» для нашого ока — зокрема ті, де використовується так звана в’язь або складні графеми, — надзвичайно складно перевіряти на cut-off або візуальні дефекти. Порахувати кількість «паличок» чи «гачечків» у таких мовах практично неможливо, особливо коли йдеться про великі обсяги контенту чи динамічні тексти. У таких випадках найкраща практика — домовлятися про peer review з носіями мови або перекладачами, які добре знають особливості письма, читабельність і візуальне сприйняття тексту. Це дозволяє виявити проблеми, які автоматизовані перевірки або не-нейтив QA просто не помітять.

• Реальні пристрої важливі: тестування краще проводити на реальних локалізованих пристроях і в емуляторах, щоб відслідкувати відмінності у відображенні шрифтів, напрямку тексту (LTR/RTL), масштабуванні UI.
• Перевірка ключових форматів: обов’язково включати перевірку дати, часу, валюти, чисел, форматів адрес, поштових індексів, а також локальних стандартів вимірювань.
• Чек-листи та тест-кейси: дуже зручно використовувати чек-листи для базових перевірок і створювати спеціальні тест-кейси для локальних особливостей або складного функціоналу.
• Перевірка культурних та юридичних нюансів: звертати увагу на свята, кольори, іконки, діалоги та формулювання, які можуть мати різні конотації у конкретних регіонах.
• Тестування інтеграцій: перевіряти, щоб локалізація коректно працювала у всіх інтегрованих сервісах. Наприклад, платіжних системах, календарях, сторонніх віджетах.
• Верифікація від користувача: по можливості залучати реальних локальних користувачів або тестувальників, які добре знають культуру та мову, щоб помітити потенційно проблемні моменти.
• Документування результатів: всі знайдені проблеми, навіть дрібні, фіксувати у тестовій документації з конкретними прикладами, щоб розробники могли швидко внести виправлення.

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

Якщо у вас є власні цікаві кейси, нестандартні ситуації чи корисні поради — діліться в коментах, буде цікаво почитати!

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.