Якщо новенького аналітика попросити оцінити, скільки часу в нього займе написання вимог по локалізації вже створеного продукту для іншої країни, - у відповідь можна почути щось на кшталт:
“нууу... тижня має вистачити...”, або, навіть: “а я тут до чого? Це ж робота перекладачів!”
Що буде далі - не важко передбачити: замовник виділяє тиждень, наш аналітик починає та… програє! І не дивно, бо одна сторона під локалізацією розуміє лише переклад, у той час як інша очікує, що продукт буде виглядати та працювати саме так, як звикли жителі тієї країни, для якої ми його готуємо.
І такі очікування цілком логічні, адже за визначенням:
Локалізація програмного продукту - це його адаптація до культури та законодавства іншої країни.
Тому переклад - це лише частина великої роботи. У вимогах до локалізації зазвичай ховається багато так званих “обов’язкових функцій” з моделі Кано: функцій, про які замовник навряд чи згадає на інтерв’ю, але буде дуже розлючений, якщо не знайде їх у готовому рішенні.
Ми - Катерина Носенко та Олеся Іванова - працюємо бізнес-аналітиками в компанії Astound Сommerce. Компанія займається впровадженням e-commerce рішень для клієнтів у різних куточках земної кулі. Тож за час нашої роботи тут ми набули значного досвіду розгортання продукту на ринки різноманітних країн і хочемо поділитися цим досвідом з вами.
В цій статті ми навели список компонентів системи, які з великою ймовірністю мають бути адаптовані до правил іншої країни. Такий чекліст допоможе вам уникнути численних підводних каменів процесу локалізації та та відокремити функціональність для глобального ринку від специфічної - для конкретного регіону.
Для більш наглядної структури список поділимо на три групи:
вимоги до конфігурації продукту;
вимоги до зовнішнього вигляду продукту;
бізнес-правила та юридичні обмеження, що є специфічними для даної країни.
Вимоги до конфігурації продукту
Товари та ціни на них
Важливо перевірити, чи може користувач іншої країни придбати ті самі товари, що зараз представлені у нас на платформі, чи асортимент має бути різним?
Наприклад, в Італії за законом автокрісла можна продавати лише в комплекті зі спеціальним датчиком, який подає сигнал на смартфон батькам, якщо дитина відстібнулася, або якщо температура в автівці занадто висока чи низька. Тож наявні товари мають бути адаптовані під цю вимогу, наприклад, можуть бути створені відповідні комплекти з крісла та пристрою.
Алкоголь заборонений для продажу в багатьох арабських країнах, тож, якщо в асортименті є алкогольні вироби, їх необхідно сховати, якщо користувач обрав таку країну.
Якщо вам пощастило і товари ті ж самі, - ціни на них можуть значно різнитися, навіть в тій самій валюті. Прикладом можуть бути алкогольні та тютюнові вироби: через різні законодавчі обмеження вони можуть бути набагато дорожчими в певних країнах.
Способи оплати
В кожній країні є свій набір звичних методів оплати для місцевих жителів. Північна Америка традиційно користується картами та PayPal, європейці полюбляють оплату частинами (Klarna) та післяплату (Afterpay), а в Об'єднаних Арабських Еміратах звикли до Cash on delivery (оплата кур’єру готівкою після того, як отримувач перевірив замовлення). Щодо азійського регіону, то покупці віддають перевагу альтернативним способам оплати: крім відомих китайських гігантів WeChat та AliPay, тут широко використовують локальні мобільні гаманці, функції оплати через соціальні мережі та платіжні термінали.
Доставка
Зазвичай використовують три типи доставки продуктів користувачу:
Доставка додому;
Доставка в магазин або пункт видачі;
Доставка через електронні канали зв’язку (е-мейл, чат тощо).
Але варто звернути увагу на дані, які має надати користувач, щоб отримати свій продукт без перешкод, - вони можуть бути різними в залежності від країни та способу доставки.
Податки
Іншим важливим моментом є оподаткування. Навіть якщо ви не розробляєте систему бухгалтерського обліку, ця тема навряд чи вас омине.
Як мінімум, в різних країнах може бути різна ставка ПДВ, до того ж, деякі класи товарів (наприклад, товари для малюків) залежно від країни можуть мати іншу ставку або взагалі бути звільнені від ПДВ. Система має це враховувати та розрахувати кінцеву вартість відповідно. В деяких країнах розрахувати податок настільки важко, що варто одразу розглянути можливість застосування для цього стороннього рішення.
У Сполучених Штатах та деяких провінціях Канади ПДВ немає взагалі, замість нього утримується податок на продаж (Sales Tax), при цьому система розрахунку залежить від штату/провінції. Тож кінцеву суму до сплати можна розрахувати лише після того, як споживач надасть свою повну адресу.
Налаштування аккаунту
При проєктуванні рішення для нового регіону обов’язково слід з’ясувати, що робити з користувачами, що вже існують в системі. Чи повинні вони мати можливість входити під своїми обліковими записами на сайт іншого регіону, чи сайти будуть сепаровані один від одного і кожен матиме свою базу користувачів? Якщо використовуємо спільну базу, то варто обговорити можливості та обмеження, які стосуватимуться роботи наявних користувачів в іншому регіоні.
Процес реєстрації
Якщо у вас В2С продукт, то варто подумати, як користувачі будуть в ньому реєструватись.
В деяких країнах достатньо класичного логіну та паролю, але для більшості треба додавати логін через соціальні мережі - список, власне, дуже залежить від країни. Крім знайомого нам фейсбуку, твіттеру дуже популярним є логін через WeChat, AliPay, Line та ще купа екзотичних соціалок і чатів, про які в Україні навіть не чули. В Китаї також дуже популярним способом створення аккаунту є верифікація через мобільний телефон.
Працюючи над процесом реєстрації не забудьте подумати також над можливістю видалити аккаунт та всі дані про нього: в багатьох країнах право користувача на повне видалення персональних даних закріплено законодавчо.
Рис 1. Логін за допомогою QR коду
Вимоги до зовнішнього вигляду продукту
Звісно ж, найскладніша частина адаптації продукту до нового регіону - це конфігурація бекенду, але ж і зміни, які стосуються суто зовнішнього вигляду, можуть несподівано додати головного болю розробникам. Нижче ми наведемо основні моменти, на які варто звернути увагу.
Формат дати, чисел, валюти
Що буде розділювачем дати - слеш чи крапка? Що пишемо спочатку місяць чи день? - такі приклади нам давно відомі.
Але є і більш екзотичні: наприклад, в Таїланді зараз не 2021 рік, а 2564! І тайці, дійсно, використовують своє літочислення дуже активно, григоріанський календар застосовується лише для туристів, тож, якщо вже адаптувати продукт під локальний ринок - варто це врахувати.
Щодо валюти, знов таки, десь звикли писати символ валюти, десь - назву, десь символ ставлять після числа (як-от в Україні - 10 грн), десь - перед ним ($10), десь є пробіл між сумою та значком валюти, десь вони пишуться як одне ціле.
Звісно, що такі особливості не є критичними для функціонування продукту (і так зрозуміють), але ми ж хочемо зробити все якісно! Тож варто звертати увагу і на такі “дрібниці”.
Довжина слів та напрямок друку
При перекладі на іншу мову варто подивитись, яка в цій мові середня довжина слів. Так, “найдовшими” серед європейських мов вважаються французька та німецька, - переклад на них з англійської займає на 15-20 відсотків більше місця, ніж оригінальний текст. Тож варто перевірити всі “вузькі” місця, - такого типу несподіванки особливо люблять ховатися в мобільних додатках.
Слова в мовах, що використовують ієрогліфи (японська, китайська), навпаки, значно коротші, але при цьому висота ієрогліфів більша і цим також не можна нехтувати, - більш того, інколи навіть доводиться переробляти окремі вікна під таку специфіку.
Рис 2. Приклад японського інтерфейсу
До речі, щодо зміни інтерфейсів: а як вам арабська з написанням справа наліво? Оце вже точно джек-пот, без вдосконалення вікон тут не обійтися!
Формат адреси та валідація введених даних
Якщо при реєстрації чи замовленні користувач має надати свою адресу, то варто пам’ятати, що її формат також може відрізнятись. Це стосується:
Кількості полів. Наприклад, десь, як-от в Україні, будинок йде окремим полем, десь - як частина рядка адреси.
Необхідності полів. Наприклад, штат в США чи провінція в Канаді є обов’язковою частиною адреси, область в українській адресі можна не вказувати (хоч люди звикли це робити, тож поле частіше присутнє), а в Німеччині це поле не використовується взагалі, тому користувачі будуть здивовані, якщо його не прибрати.
Послідовності полів. Наприклад, в Японії адресу пишуть “від більшого до меншого”, тобто спочатку країна, потім префектура, місто, район і так далі. Але лише якщо пишемо японською мовою! Бувають випадки, коли японську адресу потрібно записати не ієрогліфами, а латиницею - порядок змінюється на протилежний, вже знайомий нам по адресах США та більшості країн Європи - “від меншого до більшого”.
Ну і звісно ж, якщо на формі використовується валідація полів, то правила мають враховувати формати, які використовуються в країні. Найчастіше це стосується формату телефонних номерів та поштового індексу.
Рис 3. Приклад японської адреси записаною ієрогліфами та латиницею
Бізнес-правила та юридичні обмеження
Дуже важливо розпитати представників юридичного департаменту локальних замовників про закони, якими регулюється бізнес в їх країні.
Наприклад, в Сполучених Штатах діє Закон про громадян з обмеженими можливостями (The Americans with Disabilities Act), який диктує вимоги до зовнішнього вигляду та поведінки сайтів і додатків.
Рис 4. Вимоги ADA в дії на сайті нідерландського бренду білизни
В роботі з європейським замовникам необхідно дотримуватись регламенту щодо захисту персональних даних осіб (General Data Protection Regulation). Згідно з цим законом, якщо будь-які персональні дані (включаючи кукі, GDPR їх теж відносить до персональних даних) зберігаються в продукті, ми маємо отримати явний дозвіл на зберігання та пояснити, як саме ці дані можуть бути використані.
А якщо наш замовник з Німеччини, то на додаток маємо ще і BDSG (локальна адаптація GDPR), що додасть головного болю організаторам маркетингових розсилок.
Щодо роботи з користувачами з Російської Федерації, - варто пам’ятати про закон, що вимагає зберігати персональні дані громадян на території РФ, перед тим, як передавати їх іншим системам. Тож доведеться перебудовувати не лише програмне рішення, а й інфраструктуру і, як правило, без допоміжних сервісів не обійдеться.
Висновки та рекомендації
Від вдалої адаптації рішення на ринку іншої країни чи регіону світу залежатиме успішність, прибутковість і навіть репутація бізнесу. Тож варто приділити достатньо часу на аналіз не тільки економічних, юридичних питань, але й культурних особливостей та традицій жителів конкретної країни. Підсумовуючи вищесказане, хочемо порадити наступне:
Не довіряйте оманливій легкості задачі по адаптації рішення до нової країни або регіону. Досліджуйте і вчасно знаходьте усі підводні камені, які можуть виникати в процесі роботи. Шаблон з групами питань, які варто охопити під час аналізу вимог, вам в цьому допоможе.
Будьте в курсі базових особливостей роботи бізнес-домену вашого клієнта в новій країні. Для цього отримайте максимум доступної інформації з відкритих джерел та дані, що допоможуть вам проаналізувати різні підходи до адаптації продукту в новому регіоні.
Не соромтеся ставити, “дитячі” питання, адже “найгірше питання - не задане”. Часом доволі банальні дрібниці чи відкриття можуть вплинути на хід усього проєкту і змінити логіку роботи вашого продукту.
Дякую!
Дякую, дуже вдала стаття щодо неочевидних речей в розробці вимог до локалізації.
Від себе додам пару моментів з якими мав справу: 1) Вимоги до зовнішнього вигляду: окрім довжини і напрямку написання слід звернути увагу на можливість використання для обраної мови: множини, відмінків та наявності родів(чол., жін., та ін.). 2) Для відображення формату часу, дат, валют можна скористатись безкоштовною бібліотекою moment js.
3) Окрім «європейського» GDPR, у Сполучених Штатах набирає поширення «каліфорнійський» закон про захист споживчих прав (California Consumer Privacy Act (CCPA)).
4) В залежності від сфери діяльності продукти/веб-сайти можуть/мусять містити «артефакти» пов’язані з дозволами, обмеженнями (наприклад, ігрові обмеження, щодо віку на кшталт PEGI, ESRB, USK тощо) щодо використання в тому чи іншому регіоні.