Виклики й рішення в локалізації застосунків

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

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

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

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

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

Трохи перебільшений, але загалом класичний сценарій:
1
Клієнт. У мене тут застосунок є, хочу додати локалізацію п’ятьма мовами.
Розробник. Зараз подивимось.
2
Розробник. Готово. Ось експорт контенту в іксельці, віддавайте на переклад.
3
Перекладач. Чекайте-но, тут має бути інший порядок слів, а тут що цей тег означає?
Клієнт. Ой ну не знаю, спитаю в розробників.
4
Клієнт. Тут перекладачі питають...
Розробник. Який порядок слів? Не розумію, мій код працює. [розводить руками]
5
Клієнт. Вигадайте щось.
Перекладач. [чеше потилицю]
6
Користувач. Якийсь у вас поганий переклад, мабуть гугл-транслейт.
Перекладач. [вибух мозку]

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

Належна підготовка — запорука успіху

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

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

Якщо ви раніше не стикалися з цією темою, то правомірно можете спитати: так а що там такого відмінного?

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

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

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

Порівняймо хоча б українську з англійською в Австралії, Великобританії та США.

Відмінності регіональних стандартів у різних країнах на прикладі української та англійської мов.

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

Передбачити і реалізувати все це значно ефективніше й дешевше ще на етапі проєктування програми.

Що найперше йде не за планом

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

Найбільш яскраві випадки:

• коли дата відображається в неправильному форматі;
• коли дні тижня і назви місяців написано з великої літери тощо.

Наприклад: 5 Січень 2024 або Січень 5, 2024 замість 5 січня 2024 р.

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

Чи варто використовувати прапори

Невеличка порада щодо перемикання мов. Дослідження показують, що використання прапорів негативно впливає на досвід користувачів. Наприклад, який прапор використовувати для англійської мови: Великобританії, США чи Австралії? А як щодо німецької: взяти прапор Німеччини, Австрії чи Швейцарії?

Узагалі, ця рекомендація більше стосується вебсайтів, оскільки в мобільних застосунках вибір мови обумовлюється мовою ОС. Але загалом найкраща практика — використовувати для перемикання мов саме відповідні назви, тобто English, Deutsch, Español, Українська тощо.

Як це все вмістити

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

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

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

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

Підхід до зберігання

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

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

• В Android-застосунках для зберігання тексту використовуйте ресурси рядків (string resources) у файлах XML.
• В iOS-застосунках для цього призначено файли Localizable.strings.

Контекст у локалізації застосунків, або як розгледіти слона

Найвідповідальніший і найскладніший етап у локалізації застосунків — це переклад елементів інтерфейсу користувача. Як він відбувається?

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

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

Робоче середовище перекладача

Що тут можна зробити?

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

Друге (часом трохи складніше і не завжди ефективніше, але точно допомагає) — це надати перекладачам доступ до застосунку або скриншоти його екранів.

Динамічний контент і до чого тут граматика

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

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

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

Візьмімо таке речення: {{ completedSteps }} of {{ totalSteps }} steps completed. Тут усе просто і зрозуміло: Виконано {{ completedSteps }} з {{ totalSteps }} кроків. Жодної двозначності. Так само, як і тут: %1$s of %2$s (%1$s з %2$s) чи тут %1$s hour, %2$s minutes, %3$s seconds (%1$s год %2$s хв %3$s с).

Загалом із числовим динамічним контентом менше проблем, ніж із текстовим.

Підставлення імен користувачів, наприклад у такому реченні теперішнього часу: You can’t edit breakout session assignments because {0} is editing them локалізується без проблем, а от із минулим часом уже стає цікаво: {0} stopped streaming. Якщо користувач Артемій, то має бути {0} зупинив потокове передавання, а якщо Аліса — {0} зупинила потокове передавання.

Взагалі використання форми чоловічого роду як стандартного звертання до всіх — ще та дилема. Але в цій статті не про фемінітиви чи гендери як такі, тож просто скажу, що питання вирішується лише «милицею» шляхом додавання до фрази слова «користувач». Тож маємо: Користувач {0} зупинив потокове передавання.

Назви, які можна взяти в лапки, не створюють проблем: Failed to update {{name}} connector. — Не вдалося оновити з’єднувач «{{name}}».

А ось для прикладу кілька ребусів:

• %1$@, %2$@ of %3$@ pinned to sidebar
• You moved %1$@, current position %2$@ of %3$@ pinned list
• Do you want to request control of {0}{{0}}’s{1} {{1}}?

Та найбільшу з усіх проблему становлять рядки, коли змінна передбачає підстановку іншого тексту, як-от: Do you want to start this scheduled {{meetingType}}?, де meetingType: meeting, event, training або webinar.

Це величезна проблема з двох причин. По-перше, в українській мові це іменники різного роду. А по-друге, у реченні вони мають з’явитися не в називному відмінку. Тобто мало би бути: Чи хочете ви розпочати цю заплановану нараду / цю заплановану подію / це заплановане навчання / цей запланований вебінар?

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

І тут немає жодного обхідного маневру. Такий рядок просто неможливо перекласти точно, природно і граматично правильно, тож або цю частину коду застосунку треба переписати, або в перекладі отримаємо щось на кшталт: Чи хочете ви розпочати: нарада / подія / навчання / вебінар (заплановано)?

Це, до речі, реальний приклад в одному з проєктів у нашій компанії. Ми неодноразово піднімали з клієнтом питання щодо наслідків у якості перекладу, і на якийсь час це працює, але наступає момент, коли все повторюється.

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

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

В англійській є лише дві форми: 1 user і 2+ users. В українській (російській, польській і деяких інших мовах) три: 1 користувач, 2–4 користувачі, 5+ користувачів. І щоб у локалізованих застосунках вам не муляло очі 2 користувачів, відповідний запис потрібно розширити.

Наприклад: {count, plural, =1{Minute} other{Minutes}} — {count, plural, =1{хвилина} few{хвилини} many{хвилин} other{хвилини}}.

Така структура дає необхідну гнучкість під час перекладу і сприяє успішній локалізації, навіть із зашитим у тегах текстом: {count, plural, =0 {Select blocked groups} =1 {# group selected} other {# groups selected}} — {count, plural, =0 {Виберіть заблоковані групи} =1 {Вибрано # групу} few {Вибрано # групи} many {Вибрано # груп} other {Вибрано # групи}}.

Приклад невдалої локалізації в Instagram для iOS.

Як щодо стандартизації

Щоб спростити роботу над перекладом у багатомовних проєктах, існує спеціальний платформонезалежний формат, що має назву XLIFF.

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

Приклад структури файлу у форматі XLIFF.

Як упевнитися, що все ок

Мені часто траплялися ситуації, коли системний підхід і всі зусилля зводилися нанівець через відсутність локалізаційного тестування або небажання залучити до нього лінгвістів-нейтівів.

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

Приклад розширення тексту в локалізованому українською і російською мовами інтерфейсі мобільного застосунку.

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