Як збудувати з нуля процес локалізації продукту

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

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



Головні складності у налагодженні процесу локалізації полягають у тому, що, по-перше, треба включити у взаємодію безліч відділів і команд, а, по-друге, постійно адаптувати процес до мінливих дат продуктових релізів. У цьому допоможе правильний вибір і інтеграція двох систем — управління роботою команди (Wrike або якась ще) і TMS (translation management system — система для керування перекладами).

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

До того, як ви почнете
Хто бере участь у процесі?
Як контролювати якість?
Як вписати локалізацію в поточні робочі процеси?
І наостанок

До того, як ви почнете
Перш ніж приступити до справи, слід відповісти на кілька питань.

Наскільки локалізація вплине на продажі?
Для відповіді на це питання проводять спеціальні дослідження — як перекладацькі агентства, так і консалтингові компанії.

Так, наприклад, за даними дослідження Common Sense Advisory, 52,4% респондентів роблять покупки тільки на тих сайтах, де інформація представлена на їх мові. Більше 60% покупців у Франції і Японії кажуть, що купують товари тільки в таких інтернет-магазинах. Люди з елементарним англійською або взагалі без знання мови зроблять покупку на англомовному сайті в 6 разів менше, ніж їхні співвітчизники з вільною англійською.

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

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

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

Якщо англійська у вас вже є, то наступним стандартним набором вважається FIGS (по перших буквах входять в нього мов: французька, італійська, німецька, іспанська. Ці мови дадуть вам вихід на ринки найбільш розвинутих європейських країн (багато з яких — з відносно низьким проникненням англійської), а також на велику частина Латинської Америки. Якщо ви хочете включити ще й досить велику Бразилію, можна додати бразильський португальський. А от мови Північної Європи (голландська, фінська, скандинавську групу) на першому етапі в загальному випадку можна відкласти. Вартість перекладу на них дорожче, а рівень проникнення англійської у відповідних країнах досить високий.

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

Хто бере участь у процесі?
Отже, припустимо, ми визначилися, що локалізація потрібна, і вибрали, на які мови будемо її робити. Далі питань буде більше.

Наступний етап — визначити, що саме перекладати, адже крім самого інтерфейсу продукту, user experience також входять довідкові матеріали, відео, опитування, пости з блогу, рекламні матеріали та багато іншого. В обговорення доведеться залучити всі відділи компанії, пов'язані із залученням та утриманням клієнтів — продукт-менеджери, маркетинг, продажі, PR, як мінімум, тому що про існування багатьох важливих текстів ви можете навіть не підозрювати.



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

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

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

1. Найважливіше переклад інтерфейсу.
2. Потім — email и, прес-релізи, все, що має жорсткий дедлайн.
3. Нижче за пріоритетом документація, супровідні матеріали.

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

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

Як контролювати якість?
Перевірку локалізації практично будь-якого типу контенту можна розділити на дві частини — функціональну та лінгвістичну.

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

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

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

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

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

Як вписати локалізацію в поточні робочі процеси?
Підготовка до локалізації починається з календаря релізів, який (в ідеальному світі) створюють і підтримують продакт-менеджери і який найкраще зберігати в загальному доступі в системі управління проектами. Насправді ПМ — ключова людина, який спочатку може вплинути на свою команду і всіх, хто пов'язаний з релізом, таким чином, що менеджеру по локалізації потрібно тільки встигати приймати і виконувати завдання від усіх залучених відділів.

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

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

Варто продумати штатний робочий процес потрапляння нових рядків інтерфейсу на переклад: після релізу або коли фіча ще в розробці? Чи потрібно для цього інженерів і готові витрачати достатньо часу?

Потім варто продумати інтеграції всіх місць зберігання текстів (система контролю версій, блог, система автоматизації імейлів, довідковий центр, Google Adwords, платформа для лендингов) з системою управління перекладами. В ідеальному випадку всі оновлення потрапляють в TMS автоматично, або простим натисненням кнопки.

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



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

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

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

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.