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

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

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

З точки зору маркетингу, локалізація продукту — це ще один спосіб збільшити ареал розповсюдження продукту з метою розширення бази клієнтів або збільшення прибутку від продажів. Тому рано чи пізно, якщо ваш програмний продукт достатньо зрілий, від відділу 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, подумайте про рівноцінну їх заміну, якщо ви робите локалізацію для Китаю, де вони недоступні через Великий Китайський Файрвол. Також є ще декілька країн, де популярні на заході сервіси заблоковані з тих чи інших причин. Так що ніколи не буде зайвим невелике дослідження на цю тему та реалізація потенційного запасного сценарію в коді.

25 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
коректно відображати дати, числа, грошові одиниці та інші речі
Тут, краще, у всіх можливих місцях, використовувати міжнародні стандарти і не морочити собі голову. Якщо дата — то ISO8601, якщо час — то 24годинний день, якщо одиниці виміру — то система СI, якщо валюта — то ISO 4217, якщо запис чисел — то, знову ж, система СІ (123 456.78)

Звісно, є такі штуки як «2 хвилини тому» чи часові пояси — тут не відвертишся.
Але підтримувати штуки аля AM/PM, чи числа у вигляді 123,456’78 — то занадто.

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

24 годинний час та «12 USD» в штатах сприймаються нормально, на скільки я знаю.
А вот з імперськими одиницями — тут біда ... так як ціна за фут чи фунт в 2-3 рази менші за ціну за метр чи кілограм. А номінувати більшу ціну — маркетологічно не круто.
А, в цілому, на метричну систему, штати вже більше 100 років як офіційно перейшли en.wikipedia.org/wiki/Mendenhall_Order

24-годинний в Штатах то переважно military.

это проще всего отдать на откуп системе через «Региональные настройки» (в Windows) или их аналоги.

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

Зачем вы используете слово «додаток», являющийся некорректным переводом с русского «приложение», которое в свою очередь — перевод «application»? «Додаток» — это attachment, application — «застосунок».

«attachment» в контексті email краще, як на мене, перекладати як «вкладення».
А «додаток» як переклад «application» звучить, як на мене, простіше та краще, ніж «застосунок».

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

А взагалі, не знаю чия була ідея розмежовувати поняття «program» та «application».
Application — це аля «примочка» до операційної системи, яка не є самостійною програмою???

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

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

А если локализируеться компьютерная игра, напрмер, где весь контент это картинки, аудио, видео, как тут быть?

Я особисто в таких оказіях, як локалізація гри, участі не брав, — думаю тут є люди, що можуть більше про це розказати. Але в загальному, судячи з прочитаного, усі тексти, які є в звукових діалогах та надписи повинні також дублюватися як стрічкові ресурси. Спочатку перекладаються ці стрічкові ресурси, причому не просто перекладаються, а з врахуванням, по-перше, особливостей конкретного ігрового світу, а по-друге, особливостей ігрової термінології в даній країні, і, частково, термінології ОС. Далі, коли переклади готові, актори озвучування (зазвичай, це native speakers), вичитують ці тексти і роблять запис. Так само і з картинками — зазвичай, вихідні зображення зберігають в векторних або піксельних форматах з розширеною метаінформацією (PSD/CDR/etc). Той же Photoshop та Corel дозволяють застовоувати досить прусунуту автоматизацію. Тобто, дуже спрощено це виглядає так, що скрипт проходиться по всіх цих файлах та заміняє оргінальні стрічки на локалізовані і потім конвертує самі файли у вихідний формат (BMP, PNG, etc). Далі іде вичитка, того, що вийшло в результаті (ігровий інтерфейс), у стрічкові ресурси вносяться необхідні правки, та ітерація повторюється до переможного кінця:).

Годно, спасибо. И Даше привет! ))
Продолжение ис вэри вэлкам)

Только мне кажется, что вы начали немного не с того.
Главный вопрос: откуда локализация-то?
То бишь, (возьмем для простоты только текстовую) кто переводит / адаптирует текст? В каком виде это потом поступает в дев? Как это происходит? Есть ли промежуточные этапы типа legal / compliance review?
На каком этапе готовности фичи её локализация добавляется, и кем?

Если есть команда локализаторов, носителей языка и т.д., многое из описанного вами должно диктоваться как раз ими. У них наверняка должен быть свой процесс и свои тулы, часто проприетарные (тот же традос), и тогда вам при подготовке надо будет находить взаимный баланс.

Основной посыл вашей статьи — сделать всё «резиновым», чтобы легко модифицировалось. Ну как бы ок, все согласны. Но, если локализация только начинает рассматриваться, значит, продукт молодой и начинает завоевывать рынок.
Делать «резиновым» почти всегда означает делать в разы дольше. Насяльника на это согласится? Или всё-таки херак-херак и в продакшн, и никогда потом рефакторинг, чтобы таки сделать как следует?

Привіт Даші передав:)

А тепер щодо суті питання: так якраз і йдеться про те, що не потрібно чекати поки команда локалізаторів розпочне диктувати що і як робити. Я до цього повернуся в наступній статті, але як ви думаєте, локалізатори будуть щасливі, коли їм дадуть перекладати сорс-файл .java або .js із купою стрічкових констант, або .xls/.doc? А на скільки буде щасливий потім девелопер, коли йому скажуть вручну скопіювати з перекладеного документа стрічки для кожної з локалей? А потім ще десять раз їх виправити після верифікації (proofreading)? Оце дійсно займе в рази більше часу.

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

IMHO, такі речі немає навіть змісту обговорювати з «насяльником», — вони вже мають бути визначені на етапі проробки архітектури, як правила хорошого тону. Сподіваюсь, ми тут говоримо про розробників, які дійсно турбуються про якість, i «херак-херак» не наш варіант ;-).

Локализацией обычно занимаются либо специально обученный отдел, либо сторонние переводчики, при активном участии одного или нескольких разработчиков/менеджеров проекта, иногда и куа тоже привлекаются. Бывает, что компания совсем маленькая и тогда переводом может заниматься и сам разработчик. Или вот есть интересная схема, когда перевод делает сторонний переводчик не за деньги, а за лицензию для программы.
Процесс обычно идёт итерационно, в соответствии с процессом разработки. Т.е. сделали часть, перевели, добавили ещё строк — перевели, и т.д. В конце (перед релизом) зачастую ещё идёт вычитка/тестирование всех переводов.
По крайней мере так происходит у иностранных компаний, с которыми доводилось работать в рамках проекта.

Очень много осталось «за кадром». А как же инсталляция с учетом различных языков ОС (привет Win XP)?
Если веб приложение, то все проверяется на всех браузерах или есть регрессия? и в зависимости от чего принимается решение о том, что и на чем тестить? А если это настолькое приложение? А если мобильное?
Как у вас проходит тестирование самой локализации? Какие инструменты используете. Как, например, строится повторная проверка после внесения изменений? все перепроверяете или есть какой-то элемент регрессии? Как проверяете, что, например на датском языке (там, где непонятно, что написано) какие-то строчки полностью видны?
Кто обрабатывает ресурсы с локализацией?
Бывает ли такое, что изменение ресурсов влечет за собой неработоспособность кода?
Есть ли какая-то автоматизация, и если есть, то как она устроена?

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

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

Я, конечно, не на вашем месте, но если бы был, то начал как раз с проблем, которые появляются при тестировании. Потом идентифицировать проблемы и рассказать как раз как их митигировать или совсем избежать. А так ваша статья с какими-то советами, которые непонятно откуда взялись. А сам процесс не описан. А ведь самое интересное — это то, что не было описано. Согласен в поинтами от Andy D

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

Как проверяете, что, например на датском языке (там, где непонятно, что написано) какие-то строчки полностью видны?

в идеале это встроенный в тулзу для локализации визуальный редактор, где и проверить влезла ли надпись, и изменить размер элемента в случае чего можно.

«Додатків» ?
Застосунків.

Google: додатки prnt.sc/chwp3i
LG: програми prnt.sc/chwpj9

Спасибо, толково!

Подписаться на комментарии