Підготовка додатків до локалізації

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

В локалізації, як і всюди, легше попередити потенційні проблеми, ніж потім боротися з ними. Тому стаття буде складатися із двох частин: підготовка програмного продукту до локалізації та, власне, рекомендації щодо побудови самого процесу. Звичайно, що ці рекомендації не можуть претендувати на роль всеохоплюючих, бо в різних «жанрах» розробки ПЗ є свої особливості. Наприклад, локалізація комп’ютерної гри буде суттєво відрізнятися від локалізації електронного щоденник, яка, в свою чергу, буде дуже несхожою на локалізацію модуля автопілоту в літаку. Тому зупинимося на завданнях по локалізації порівняно простих програмних додатків/сайтів, до функціональності яких не ставиться «виключних» вимог.

З точки зору маркетингу, локалізація продукту — це ще один спосіб збільшити ареал розповсюдження продукту з метою розширення бази клієнтів або збільшення прибутку від продажів. Тому рано чи пізно, якщо ваш програмний продукт достатньо зрілий, від відділу R&D надійде таке побажання, а з ним і список «локалей». І тут починається найвеселіша частина кардебалету: інколи виявляється, що треба переписати добрий шматок коду, щоб хоч якось зліпити «бульдога з носорогом». А далі ще ж треба це все якось перекладати, перевіряти та підтримувати в актуальному стані. В результаті локалізація не вирішує проблем, а створює ще більше, що помітно відбивається на якості результуючого продукту та ступені задоволення ним кінцевих користувачів.

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

1) Коректна підтримка Unicode

Необхідно переконатися, що весь текст, видимий для користувача, закодований в Unicode. Для більшості сучасних інструментів це взагалі не проблема, проте любителі C, CPython, C++ повинні тримати це в голові. Також це перевірка стосується коректної обробки всього вводу, що може потенційно бути отриманий динамічно: з файлів, баз даних, викликів різноманітних API, консолі чи графічних елементів.

2) Вирівнювання графічних елементів

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

Важливо резервувати частину вільного місця з погляду на те, що, зазвичай, перекладений з англійської текст може бути на 30-50% довший, ніж оригінальний (для дуже коротких текстів, інколи, більше 200%).

3) Відсутність «hardcoded» ресурсів

Терміном «hardcoded» позначаються, здебільшого, стрічки або ресурси іншого типу, які задаються на етапі компіляції продукту і не можуть бути змінені без прямого втручання в код. Краще усі ресурси (стрічкові, зображення, звуки тощо) зберігати окремо від модуля з бінарним кодом.

Щодо формату даних ресурсів, то варто звернути увагу на стандарт для того чи іншого набору інструментів, за допомогою яких розробляється ваш додаток. Якщо таких рекомендацій нема або вони неповні, тоді варто придивитись до одного з популярних Open Source форматів, наприклад, GNU GetText чи XLIFF. Дані формати відомі досить давно, вони надають бібліотеки для інтеграції з популярними інструментаріями та підтримують необхідні для правильної локалізації речі.

Деякі універсальні функії, важливі при виборі формату ресурсів:
— Можливість присвоювати кожному елементові унікальний ідентифікатор;
— Можливість правильно обробляти множинні форми іменників та зберігати їх (див. нижче);
— Можливість правильно працювати з Unicode (UTF-8, UTF-16, UTF-32, LE/BE), лівосторонніми та правосторонніми варіантами письма;
— Наявність фреймворків для інтеграції з різними інструментаріями, утиліт для валідації, експорту та імпорту.

4) Множинні та інші спеціальні форми

Побудова стрічкових ресурсів повинна враховувати таку особливість, що для різних мов множинні форми іменників утворюються по різному, в залежності від числа, яке стоїть перед ними. Так, в англійській мові таких форм всього дві (1 minute, 10 minutes), в японській — одна (1分, 10分), проте в українській — три (1 хвилина, 2 хвилини, 10 хвилин). У деяких мовах є до шести таких форм. Ще бувають такі особливості як, наприклад, особливе закінчення дієслів в залежності від роду іменника в минулому часі, але це не настільки важливо як множинні форми, що зустрічаються в різноманітних додатках дуже часто.

5) Правильне форматування

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

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

Неправильно:

p1 = get_string(ID_MENU_ITEM_DELETE_PART1)
p2 = get_string(ID_MENU_ITEM_DELETE_PART2)
c.set_text(p1 + p2)

Краще:

p1 = get_string(ID_MENU_ITEM_DELETE_PART1)
p2 = get_string(ID_MENU_ITEM_DELETE_PART2)
formatter = get_string(ID_MENU_ITEM_FORMATTER)
c.set_text(formatter.format(p1, p2))

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

6) Оформлення ілюстрацій, звукових ефектів та вбудованого контенту

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

7) Супровідна документація

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

8) Життєвий цикл

Якщо в процесі своєї роботи додаток генерує email-повідомлення чи звіти, потребує взаємодії з сервісами третьої сторони (3-rd party services), потребує окремої програми для інсталяції та інтеграції, тоді варто задуматись також про локалізацію цієї інфраструктури, оскільки для кінцевого користувача ці всі, задавалось би, окремі компоненти, є ланками одного ланцюга, нерозривно пов’язаного з вашою аплікацією. І логічно буде припустити, що він очікує, що ці ланки також будуть «спілкуватися» з ним знайомою мовою.

9) Використання сторонніх сервісів

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU