Continuous Localization – ефективна організація процесу локалізації
Це продовження попередньої статті про підготовку додатків до локалізації. Тут ми розглянемо наступний етап — коли перший реліз уже позаду, у нас уже є користувацька аудиторія, і відділ маркетингу ми хотіли б цю аудиторію розширити.
Вибір мови
Більшість додатків/сайтів, про які буде йти мова, з самого початку базуються на англійській локалі. Це не просто наслідок того, що переважна більшість інструментів для їхньої розробки представлені на цій мові, або через історичні причини, але й, дивлячись прагматично, через те, що дуже велика частина потенційно платоспроможних користувачів розмовляє англійською. Велика Британія, США, Австралія, Нова Зеландія — це тільки початок списку країн, де англійська мова є державною (або дуже поширеною), і які знаходяться досить високо в рейтингу загального благополуччя.
Може бути, що додаток не слідує цьому правилу, наприклад, якщо він розробляється для використання в державних органах або має якусь дуже вузьку спеціалізацію в межах однієї країни. Просто, потім потрібно мати на увазі, що локалізація такого «особливого» додатку обійдеться дорожче і часу займе більше, оскільки, зазвичай, переклад ведеться у напрямку «англійська мова → всі інші мови», і, відповідно, перекладачів з англійської на інші мови (та навпаки) велика кількість, і ставки оплати, в середньому, у них за переклад нижчі. Якщо ж інтерфейс початково не на англійській, то доведеться спочатку робити переклад на цю мову, а потім вже з англійської на інші.
Для кого ж робити локалізацію в першу чергу? Тут відповідь повинен дати відділ R&D. Зазвичай, аналіз статистики використання продукту, відгуків користувачів та оглядачів, аналіз ринків дозволяють дати приблизну картину. Щодо мого персонального досвіду, то «середньозважений» TOP-10 мов, для яких варто робити локалізацію «на старті», буде виглядати так:
— Іспанська
— Німецька
— Французька
— Японська
— Португальська (Бразилія)
— Італійська
— Російська
— Голландська
— Датська
— Шведська
Китайська мова (спрощений варіант) теж могла б входити в цей список, враховуючи те, що кожен шостий землянин володіє нею, але тамтешній ринок програмного забезпечення має багато особливостей. Тому, якщо дуже хочеться робити і цю локалізацію, краще спочатку порадитися з людьми, які знайомі з місцевою ментальністю та законами.
Стратегія перекладу
Тепер, коли ми визначилися зі списком мов, необхідно обрати стратегію перекладу. Тут, зазвичай, можливо кілька опцій. Дехто має перекладачів в штаті компанії, дехто довіряє зовнішнім компаніям, а дехто віддає ресурси в опенсорс. Тут усе залежить від бюджету та політики компанії — універсальних варіантів не існує. Проте, для всіх цих варіантів важливим є процес інтеграції процесу локалізації з процесом збірки (та тестування) продукту. Якщо цей процес організований не зовсім правильно, то локалізація стане вічним тягарем. І тут будуть корисними ось такі поради:
— Обирайте досвідчених перекладачів. Переконайтеся, що люди, які будуть виконувати переклад, мають достатньо досвіду та хороше портфоліо. Дуже бажано, щоб вони були native speaker’ами, а також були добре знайомі з тим оточенням, в якому працює ваш додаток чи сайт. Тобто, якщо це програма для Mac OS, то перекладачі повинні мати досвід роботи з програмами для Mac. Якщо це сайт, то бажано, щоб вони були знайомі з базовою веб-термінологією і слово «cookie» асоціювали не тільки з печивом.
— Використовуйте глосарії. Будь-який професійний перекладач під час роботи користується глосаріями. Глосарії — це такі словники спеціальних термінів та, можливо, їх перекладів. Бажано, щоб у вас уже існував такий документ перед «здачею» додатку в локалізацію. Не обов’язково додавати в нього все підряд, але хоча б базова термінологія там має бути присутня. Mac OS та Windows, для прикладу, мають свої глосарії як для спеціальної термінології, так і для перекладів, які доступні, відповідно, в Apple Downloads Area for Developers та на сайті MSDN. Зазвичай, глосарії рекомендується зберігати в стандартизованому форматі TBX.
— Використовуйте TMS. Один з найважливіших інструментів в роботі перекладача — це Translations Management System (TMS). TMS є одним з підвидів CRM для менеджменту програмних ресурсів. В цій системі централізовано зберігаються усі оригінальні ресурси та відповідні їм перекладені, ведеться облік проробленої роботи, є можливості оновлення ресурсів, функція пам’яті (Translation Memory), імпорту, експорту, пошуку, інтеграції з іншими системами та багато чого іншого. Прикладами таких систем можуть служити Trados, WordBee, SDL, Crowdin. Ці системи вміють багато, але магії там немає — вони будуть працювати з тими ресурсами, які їм надає замовник. Ідеально, коли формат цих ресурсів підтримується TMS «з коробки» і не потребує додаткових кроків для конвертації. Тоді і робота виконуватиметься швидше, і небажаних помилок при конвертації буде менше. Це основна причина, щоб не «винаходити велосипед» у вигляді власного формату ресурсів, а використати той, який рекомендується для використання у вашому наборі інструментів.
Процес локалізації
В загальних рисах процес локалізації ресурсів виглядає так:
1) Від замовника отримується оригінальний файл(и) зі стрічковими ресурсами.
2) Даний файл(и) заливається в TMS. Також, при потребі, відбувається оновлення файлу, якщо попередня його версія уже існує в системі. В разі якщо формат ресурсів не підтримується в TMS «напряму», то перед заливкою відбувається конвертація в сумісний формат. В найгіршому випадку ресурси переносяться вручну.
3) TMS відповідальна за генерацію локалізованих ресурсів, що базуються на оригінальній локалі. Також вона повинна зберігати переклади для тих стрічок, що не змінилися в новому файлі.
4) Далі перекладачі приступають до перекладу «своїх» локалей. В процесі перекладу TMS повинна надавати доступ до глосаріїв, контекстної інформації, глобальної пам’яті (Translation Memory), а також виконувати базову верифікацію перекладених стрічок. Під «базовою верифікацією» мається на увазі їх валідація на предмет, в першу чергу, відповідності форматних специфікаторів, пробільних символів, переносів стрічок та інші. Якщо система не вміє виконувати це автоматично, то доведеться використовувати інші інструменти для верифікації або створювати власні. Детальніше про це нижче.
5) В процесі у перекладачів можуть виникнути питання до значення того чи іншого слова або усієї стрічки через відсутність контексту. В таких випадках вони будуть звертатися до менеджера, щоб отримати ці описання та додавати їх в TMS для кожної окремої стрічки. Такі описання суттєво допомагають при перекладі, особливо коли він одночасно ведеться на кілька мов. Контекст, доданий один раз, буде доступний всім іншим перекладачам, що працюють над цим ресурсом.
6) Інколи, якщо перекладач вважає доцільним, він і сам буде додавати контекстну інформацію, особливо при «вичитці» (proofreading) інтерфейсу, або експортувати терміни в глосарій.
7) Після того, як переклад завершений, результуючі ресурси експортуються з TMS, проходять конвертацію, якщо це необхідно, та надсилаються замовникові.
Знаючи цей алгоритм, можна відразу передбачити, чим можна допомогти перекладачам. Перш за все, за допомогою коментарів в ресурсах можна позначити ті стрічки, які потребують особливого перекладу чи не потребують його взагалі (це ще й здешевить локалізацію), потребують додаткової контекстної інформації або мають наперед визначені обмеження по довжині чи формату. Бажано, щоб усіма перекладами займалась одна і та ж сама компанія, якщо це аутсорс. Якщо ж перекладами займаються люди в різних географічних локаціях, то для досягнення оптимальної якості необхідно організувати між ними обмін досвідом. В ідеалі — надати всім перекладачам доступ до TMS, глосаріїв та допомагати їх при пошукові контекстної інформації.
Валідація ресурсів
Наступним важливим етапом локалізації є валідація ресурсів. Досвід показує, що до критичних збоїв та проблем в локалізованій версії додатку найчастіше призводять:
— Балансування специфікаторів формату. Є стрічка “%s of %d left”. Якщо її переклали як “Із %d залишилось %s” чи “%s залишилось”, тоді ми майже гарантовано отримали критичний збій aka crash на виході. Що тут найгірше — ми його побачимо тільки під час виконання програми, коли, власне, буде застосоване форматування. Нам пощастило, якщо TMS вміє «помічати» такі проблеми і попереджувати про них перекладача, але часто не все так ідеально, як хотілось би. Дана проблема має два шляхи вирішення — використовувати тільки форматери, які працюють з шаблонами, наприклад “{count} of {all_items} left”. Тоді, навіть якщо перекладач щось наплутав, додаток не буде збоїти, а, натомість, покаже «сирий» шаблон чи його частину. Другий варіант — проводити валідацію перекладених ресурсів самостійно за допомогою скрипта. Тут стануть у пригоді стандартні утиліти для роботи з файлами ресурсів, які дозволяють побудувати з цих ресурсів структури, що легко інтерпритуються програмно. До речі, переклад типу “Із %2$d залишилось %1$s” буде цілком коректним і працюватиме як задумано.
— Неправильні припущення програміста про формат стрічок. Маємо стрічку “License status:\n\n%s”, і програміст вираховує за допомогою шаблону регулярного виразу або простим пошуком першого входження позицію подвійного символу переносу стрічки, а потім форматує текст, що знаходиться перед ним. Цілком імовірно, що перекладач не буде знати про цю особливість, і в перекладеному файлі воно буде виглядати як “Стан ліцензії:\n%s”. В результаті, в кращому випадку, форматування просто не відбудеться, а в гіршому — додаток «впаде» через ланцюжок невірних припущень. Рішення — не робити ніяких припущень щодо структури стрічок або явно вказувати ці вимоги в коментарях до цієї стрічки в файлі ресурсів.
— Передача «локалізованих» структур. Припустимо, що в ресурсах є стрічка, яка формує посилання: «example.com/?s=%d». Підстановка в таке посилання цифри в арабській локалі призведе до того, що вона стане невалідною, хоча в будь-якій європейській локалі все буде виглядати прекрасно. А все тому, що в арабській локалі цифри виглядають зовсім по-іншому. Тут кінцевий результат ще залежить від вибраного інструмента, але це не відміняє необхідності бути знайомим з такими особливостями роботи функції форматування.
Застосування перекладеного
Після завершення перекладу робиться перше застосування перекладених ресурсів. Дана процедура дозволяє відразу побачити проблеми в коді при роботі з локалізованими ресурсами, виявити «hardcoded» стрічки та прорахунки при дизайні інтерфейсу. Досить часто для перевірки цих речей використовують псевдолокалізацію. Це коли файли ресурсів наповнюють випадковими сполученнями символів в Unicode, зберігаючи при цьому специфікатори формату. Така операція має мінімальну грошову вартість (оскільки не потрібно платити за переклад), але її значення для якості локалізованого продукту важко переоцінити, якщо вона пророблена вчасно.
Після того, як перша збірка з локалізованими ресурсами пройшла базове тестування та в ній більше не виявляється критичних збоїв, її необхідно відправити перекладачам на вичитку (proofeading). Цей етап дозволяє перекладачеві ознайомитись з вашим додатком, краще вникнути в предметну область та отримати необхідний контекст, що в результаті дуже позитивно відбивається на якості перекладу. Після завершення вичитки та внесення необхідних правок імпорт ресурсів необхідно повторити. Зазвичай, вичитку роблять після завершення найпершого перекладу, а також, якщо в продукт були внесені значні зміни чи вийшла нова major-версія.
При отриманні локалізованих ресурсів від перекладачів та інтеграції їх з продуктом важливо не переплутати файли для різних мов, тому цю операцію бажано максимально автоматизувати. Ідеальний варіант — це коли експорт та імпорт ресурсів в/з TMS відбувається без участі людини. Так, якщо TMS підтримує REST API, то сервер безперервної інтеграції (CI Server) може автоматично для кожної нової збірки надсилати оновлені ресурси для перекладу та оновлювати існуючі, як тільки це знадобиться. У нас в Wire існує така практика, що ресурси експортуються автоматично кожен раз, коли є нова внутрішня збірка (гілка Development), та імпортуються, коли збирається продукт для внутрішнього використання, бета-користувачів та для релізу. TMS сама відслідковує наявність нових стрічок для перекладу та надсилає сповіщення перекладачам.
Сервер для збірок також має можливість блокування збірки, якщо при імпорті виявляється, що не всі ресурси повністю перекладені. Загалом, таким чином реалізовується принцип Continuous Localization (цей термін використовують в своїй практиці багато компаній, наприклад, Evernote), коли локалізація продукту готова майже в будь-який момент часу і розробники мало задумуються про її існування. Така стратегія, також, дозволяє оптимізувати тестування проміжних версій додатку, оскільки внутрішні та бета-користувачі використовують локалізовані збірки та роблять звіти про потенційні проблеми чи недоліки в інтерфейсі.
Автоматизація тестування збірок
Щодо автоматизації тестування локалізованих збірок, то моя думка така, що тут ще потрібно два рази подумати, перед тим, як розпочинати цей процес. Перш за все, необхідно переконатись, що локатори усіх елементів незалежні від їхніх текстів. Будувати та підтримувати окрему версію фреймворку для кожної локалі буде занадто накладно. Автоматизовувати є зміст тільки базові сценарії, щоб впевнитись, що додаток їх проходить без збоїв. Такі речі, як неточний переклад або «порізані» стрічки все одно ніяка автоматизація не помітить, — краще залишити дану верифікацію бета- та внутрікорпоративним користувачам.
