Як навчити веб-додаток говорити на 100 мовах: особливості локалізації



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

Ідея написання цієї статті виникла після MoscowJS митапа, на якому я говорив про те, як відбувається процес локалізації в компанії Badoo. Але в цій статті я хотів би розповісти трохи детальніше про особливості локалізації на прикладі веб-додатків, про те, які існують рішення для локалізації і чому в Badoo пішли своїм шляхом. Всім небайдужим — ласкаво просимо під кат.

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

Наступне питання, на який потрібно дати відповідь: чому локалізація важлива? А вона важлива в першу чергу для користувачів і клієнтів, адже кожен з них повинен відчувати себе комфортно, використовуючи ваш додаток. Наприклад, резиденти якої-небудь країни, навіть якщо вони добре знають англійську мову, воліють робити покупки на рідній мові. Більшість з них також воліє користуватися послугами служби підтримки рідною мовою. Якщо ми візьмемо Європу, в якій близько 50 країн, то практично в кожній з них будуть свої регіональні особливості відображення дат, чисел або валюти. А якщо ми розширимо нашу аудиторію на весь світ, то з'являються такі країни, як Китай, Іран, Афганістан або Саудівська Аравія, в яких запис тексту йде справа наліво або зверху вниз, а самі числа записуються за допомогою індо-арабських або перських цифр.

Особливості мов
На які особливості мови варто звернути увагу в першу чергу, якщо прийнято рішення впроваджувати локалізацію? В першу чергу варто звернути увагу на відображення дати і часу в звичному для них форматі. У нижченаведеної таблиці відображені декілька залежностей формату від країни. Як ви бачите, у більшості країн формат різний.
Формат Приклад дати Країна
рррр.ММ.дд 2016.09.22 Угорщина
рррр-ММ-дд 2016-09-22 Польща, Швеція, Литва, Канада
рррр/ММ/дд 2016/09/22 Іран, Японія
дд.ММ.рррр 22.09.2016 Росія, Словенія, Туреччина, Україна
д/М/рррр 9/22/2016 США
Формат запису часу також залежить від країни. Наприклад, в США, Канаді, Австралії, Новій Зеландії використовується 12-годинний формат часу (англійська система), в іншому світі — 24-годинний формат (французька система).

Наступною особливістю є формат чисел і відображення валюти. Як видно з таблиці нижче, тисячний і десятковий роздільник може виглядати як кома, крапка або пробільний символ. А положення знака валюти може відрізнятися не тільки в різних мовах, але і в різних країнах. Наприклад, такі країни, як Німеччина та Австрія, що говорять на одній мові, але грошовий формат мають різний.
Приклад Локаль Країна
123 456,79 € uk Росія
€123,456.79 en-US США
123.456,79 € de-DE Німеччина
€ 123 456,79 de-AT Австрія
Особливий інтерес викликає традиційна запис числівників в Китаї. У китайській мові числа діляться на розряди іншим чином, ніж, наприклад, російською. Ми звикли розбивати великі числа на групи по кількості тисяч, китайці ж — за кількістю десятків тисяч. Наприклад, число 150.000.000 ними буде записано як 1亿5000万. Крім того, китайці дуже сильно вірять в «числові забобони» і до нумерології ставляться серйозно і вдумливо. Наприклад, число 4 звучить аналогічно слову «померти», і китайці намагаються його уникати. У багатьох готелях ви не знайдете номерів з числом 4, а іноді навіть і 4-го поверху. Теж саме стосується, наприклад, банківських рахунків: мрія простого китайця завести собі номер з вісімкою — символом багатства і процвітання.

Крім того, проблемою може стати англійська система заходів, яка використовується в США, М'янмі та Ліберії. Чому це важливо: варто згадати супутник «Марс клімат орбітер», який підлетів до Марса і впав на нього, так як команди на космічному обладнанні використовували силу в ньютонах, а програмне забезпечення на Землі — фунт-силах. За весь час польоту ніхто не запідозрив помилку. У підсумку вона коштувала $ 125 млн. Так що не забувайте відображати результати в звичних для користувачів заходи.

Коли з форматом дат і чисел розібралися, можна переходити до особливостей перекладів. І найбільш очевидна проблема — це відмінювання іменників після числівників. Як ми знаємо, в російській мові існує три форми множини (plural forms), в той же час в англійській їх всього дві. Але існують мови, в яких таких форм може бути шість. Наприклад, за цією посилання ви знайдете таблицю форм для кожної мови.
Українська мова Англійська мова
У вас 1 подарунок Singular You have 1 gift
У вас 5 подарунків Plural You have 5 gifts
У вас подарунка 2 Few
Далі можна виділити цілий блок — особливості перекладів. Тут існує достатня кількість особливостей, які потрібно враховувати.

1. Перекладати фрази і пропозиції. Їх не можна ділити на складові, так як послідовність слів у різних мовах може бути різною.


Наприклад, візьмемо таку фразу: 8,283 out of 15,311 people you liked!
Для англійської мови вона виглядає наступним чином:
<b>{{num_voters_yes_maybe}}</b> out of <b>{{num_voters_total}}</b> {{people}} liked you!

А ось в японському це ж пропозицію вже виглядає іншим чином:
<b>{{num_voters_total}}</b>{{people}}<b>中{{num_voters_yes_maybe}}</b>人があなたを気に入っています!

Як видно з цього прикладу, в японській мові зворотна послідовність слів. Тому, як часто багато роблять, не просто так написати
'Сторінка' + pageNum + ' з ' + total

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

Англійська
You got an award on <span>{{award_date}}</span>

Словацька
М: Toto ocenenie si získal <span>{{award_date}}</span>
Ж: Toto ocenenie si získala <span>{{award_date}}</span>

3. Переклад рядків має залежати від контексту. Перекладач повинен знати зміст усього речення, фрази або абзацу, інакше він може неправильно зрозуміти і некоректно перевести. Наприклад, таку пропозицію як "You can save this {{item}}" може мати різний переклад: «Ви можете врятувати/зберегти цей {{item}})». В ідеалі перекладач повинен не тільки бачити набір рядків для перекладу, але і зображення області, де дана рядок знаходиться.

4. Повторне використання ресурсів перекладу може бути небезпечним. Наприклад, «Зберегти» (файл) і «Зберегти» (настройки) в деяких мовах можуть мати різні назви. Або таке слово як thread може бути переведено як «потік», а може бути переведено як «нитка».

Ось, мабуть, ми визначили найбільш популярні особливості, які зустрічаються при локалізації веб-додатків. Але це ще далеко не все, що може зачіпати локалізація, тому що сюди можна віднести і особливості дизайну (наприклад, японський і китайський вимагає збільшеного шрифту, в деяких мовах довжина тексту буде в 2 рази більше, ніж, наприклад, в англійській); кольорову палітру (червоний і зелений колір у різних культурах означають протилежні речі, наприклад, червона галочка в японському означає, що ви зробили щось не так); використовувані зображення (так-так, в Азії непогано б показувати азіатів, а в Європі — європейців) і багато інші аспекти, які характерні для тієї чи іншої країни і культури. Все це виходить уже за рамки статті, але про це варто пам'ятати.

А тепер заглянемо в інтернет і подивимося, а які існують інструменти для клієнтської локалізації?

Способи локалізації на клієнті
Розвиток інтерфейсів і впровадження складної бізнес-логіки вже вимагало від розробників вирішувати багато проблем локалізації на клієнті. Можливості інтернаціоналізації, які до певного моменту надавав ECMAScript, були досить мізерними, тому стали з'являтися бібліотеки, такі як Closure, Globalize, YUI, Moment.js або ж якісь власні рішення у кожного з розробників. Всі вони розширювали можливості ECMAScript і заповнювали прогалини в інтернаціоналізації, але рішення мали різний програмний інтерфейс і певні обмеження, пов'язані, наприклад, з порівнянням рядків. Так, в грудні 2012 року, з'явився стандарт ECMA-402, який повинен був спростити життя фронтенд-розробникам при інтернаціоналізації додатків. Але чи дійсно це так? Давайте подивимося, що зараз пропонує нам цей стандарт.

ECMAScript Internationalization API

Це стандарт, який описує програмний інтерфейс ECMAScript для адаптації до лінгвістичних і культурних особливостей мов або країн. Робота відбувається через об'єкт Intl, який надає функції форматування чисел (Intl.NumberFormat), дат (Intl.DateTimeFormat) і порівняння рядків (Intl.Collator). На даний момент поддерживается усіма сучасними браузерами. Останній браузер, який нещодавно додав підтримку, був Safari, для застарілих браузерів можна використовувати полифилл.

Великий плюс цього стандарту в тому, що його розробляли за підтримки Google, Microsoft, Mozilla, Amazon, і, як нам обіцяють, він буде розвиватися. Будуть додані можливості форматування рядків з урахуванням форм множини і підлоги, парсинг чисел і багато іншого. Шкода, що відбувається це все досить повільно. Наприклад, сам стандарт був затверджений ще в 2013 році, а підтримка найпопулярнішими браузерами була реалізована тільки в 2016. А поки що функціонал об'єкта Intl досить обмежений і не надає можливості для переказів. Тому доводиться використовувати сторонні рішення або полифилл для ще не затвердженого формату.

Плюси:
  • нативна реалізація в браузері;
  • висока продуктивність;
  • не вимагає завантаження додаткових ресурсів;
  • форматування рядків з різними локалями без підвантаження JavaScript-ресурсів;
  • розвиток стандарту ECMAScript 2017 Internationalization API.
Мінуси:
  • для застарілих браузерів необхідна завантаження полифилла;
  • залежність від системи. Деякі локалі можуть не підтримуватися клієнтом;
  • можуть бути різні результати в різних браузерах.
Приклади ECMAScript Internationalization API

var mFormat = new Intl.NumberFormat("ru", {
style: "currency",
currency: "GBP"
}).format(1234567.93);
console.log(mFormat); // 1 234 567,93 £

var nFormat = new Intl.NumberFormat('ru').format(1000.15);
console.log(nFormat); // "1 000,15"

var utc = new Intl.DateTimeFormat("en-US", {
timeZone: "utc",
hour: "numeric",
minute: "numeric"
});
console.log(utc.format(new Date())); // 2:38 PM

Трохи більше прикладів можна подивитися тут.

Як ви можете помітити, що багато чого ще в стандарті не реалізовано, не враховані всі особливості, з якими стикаються розробники веб-додатків. Тому, як я писав вище, багатьом доводиться або шукати вже готові рішення, або розробляти свої власні. На даний момент рішень досить багато, і у кожного є свої достоїнства і недоліки. Якщо звернутися до Google, то при пошуку в перших результатах i18next, FormatJS, Globalize, jQuery.i18n та інші. Деякі з цих бібліотек пропонують свої власні рішення, інші намагаються йти по стандарті ECMA-402. Візьмемо для прикладу дві бібліотеки, які нам видає в перших результатах пошуку Google і подивимося, що вони вміють.

i18next

Як стверджує розробник, це дуже популярна бібліотека для інтернаціоналізації як на клієнті, так і на сервері (node.js). Для неї існує безліч плагінів, утиліт, вона інтегрується з різними фреймворками. Надає інтерфейс для перекладачів, в який ви можете завантажувати файли, але, на жаль, він вже платний. В ній дійсно багато чого реалізовано, і бібліотека продовжує розвиватися, що, звичайно, тішить. Але вона не слід специфікації ECMA-402 і має свій структурний формат для повідомлень, а не ICU Message syntax. Крім того, для форматування чисел і дат потрібно завантаження moment.js або numeral.js. Відповідно, вам доведеться завантажити в проект ще і ці бібліотеки і до них додати ще локалі для потрібних мов.

Плюси:
  • підтримка багатьох особливостей мови;
  • можливість завантаження ресурсів з бекенду;
  • додаткові плагіни і різні утиліти;
  • розширення для популярних фреймворків, шаблонизаторов.
Мінуси:
  • вимагає завантаження ресурсів (i18next 35кб + moment 20кб + необхідні локалі);
  • не слід стандарті ECMA-402;
  • платний інтерфейс для перекладачів.
Більш детальну інформацію по роботі з бібліотекою і більше прикладів можна знайти на офіційному сайті.

Format JS

Format JS — це модульна колекція JavaScript-бібліотек для інтернаціоналізації. Вона ґрунтується на стандартах ECMA-402, ICU, CLDR і має інтеграцію з безліччю фреймворків та шаблонизаторов, наприклад, такими як Dust, Ember, Handlebars. Дана бібліотека при необхідності або завантажує полифилл для роботи з інтернаціоналізацією, або ж використовує можливості браузера. Крім того, вона підтримує роботу як на клієнті, так і на сервері.

Плюси:
  • модульність;
  • використовує можливості ECMA-402 або полифилл;
  • розширення для популярних фреймворків, шаблонизаторов.
Мінуси:
  • вимагає завантаження ресурсів при необхідності;
  • не всі можливості для переказів.
Наприклад, текст для перекладу в ICU форматі буде мати такий вигляд:

{ gender: select,
female {{
count, plural,
=0 {У неї немає яблук}
=1 {У неї всього одне яблуко}
one {У нього # яблука}
few {У неї # яблука}
other {У неї # яблук}
}}
other {{
count, plural,
=0 {У нього немає яблук}
=1 {У нього всього одне яблуко}
one {У нього # яблука}
few {У нього # яблука}
other {У нього # яблук}
}}
}

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

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

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

На всі ці питання і особливості мов нам довелося звернути увагу, коли Badoo виходив на міжнародний ринок. У ті вже далекі часи, навіть якщо схожі системи для локалізації й існували, то вони не задовольняли всім нашим вимогам, і, само собою, нам довелося розробити свою систему для локалізації (про який ми вже писали на Хабре, а також рассказывали про особливості верстки багатомовних додатків). Дана система повинна була добре інтегруватися в наш спільний процес, бути прозорою і не затримувати процес розробки (так як, наприклад, ми «релизимся» два рази в день, і нам дуже важливо, щоб нові продуктові ідеї швидко опинялися в продакшн-оточенні). Крім того, їй необхідно було мати можливість працювати не тільки з вебом, але і з усіма іншими нашими платформами, такими як iOS, Android, Windows Phone, а також використовуватися для email розсилок.

З появою загального формату спілкування між нашими клієнтами і сервером (далі — протокол), або, як ми це називаємо, «апификацией», багато текстів стали приходити з сервера. Цей підхід для нас виявився зручним, так як не треба зберігати великі обсяги переказів на клієнті і завдяки такому підходу ми, наприклад, можемо проводити AB-тестування лексем або ж створювати такі лексеми, які залежать від дії користувача. Кожен клієнт також може зберігати потрібні переклади у себе. Рішення, де зберігати переклади — клієнта або сервера, приймає команда, відповідальна за розробку протоколу. Якщо якісь переклади оновлюються, то кожен клієнт може запросити нові (так як переклади часто оновлюються, а нові релізи з'являються в магазинах додатків з певною періодичністю). Такий механізм ми називаємо Hot Lexem update.

Як видно з малюнка вище, у процесі локалізації у нас зайняті не тільки клієнтські розробники і перекладачі, але і безліч інших команд. Наприклад, команда MAPI, як я писав вище, проектує протокол і вирішує, де будуть зберігатися переклади. Команда BackOffice надає зручний інтерфейс для перекладачів, перекладачі, само собою, роблять переклади, а команди SRV (серверні розробники) або Frontend (клієнтські розробники) генерують і відображають потрібний переклад. Крім того, коли ми створили таку систему, то на її основі нам вдалося створити коллоборативную систему переказів (https://translate.badoo.com/), в якій можуть брати участь і наші користувачі. І вони дуже допомагають нам робити переклади з урахуванням місцевих особливостей кожної країни.

Висновок
Цілком зрозуміло, що процес локалізації будь-якого додатку — це досить серйозна і кропітка робота, тому що вона зачіпає різні команди проекту, а не тільки розробників і перекладачів. І в кінці цієї статті я хочу ще раз звернути вашу увагу на основні, на мій погляд, моменти при локалізації додатків:

  1. Локалізація — досить складна процедура для впровадження «згори». Якщо вона вам знадобиться, то повинна бути закладена в проект з самого початку.
  2. Ресурси локалізації повинні бути незалежними від програми.
  3. Локалізація поширюється не тільки на рядки, і це теж має бути враховано при проектуванні.
  4. Зробіть вашу систему зручною не тільки для розробників, але і для перекладачів, автоматизуйте процес переказів.
  5. Якщо не впевнені в якості перекладу, краще взагалі не перекладіть текст.
  6. Намагайтеся враховувати культурні особливості кожної країни і мови.
  7. Дизайни, макети, колірна гамма, використовувані зображення повинні бути піддані локалізації.
Мабуть, з цієї теми у мене все. Сподіваюся, що ви почерпнули для себе якісь нові тонкощі процесу локалізації. Якщо ж у вас є свій цікавий досвід, то поділіться ним і зауваженнями в коментарях. Make web great again!

В'ячеслав Волков, frontend розробник, Badoo
Джерело: Хабрахабр

0 коментарів

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