Як писати софт для всього світу

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



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

Зберігайте видимі для користувача рядка окремо
Безумовно найважливіше (і саме ігнорована) правило підготовки до локалізації — відділення всіх видимих для користувача рядків коду, який використовує їх.

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

Текст у додатках ніколи не повинен бути структурно прив'язаний до логіки додатків. Короткі рядки завжди повинні бути доступні для змін без шкоди для роботи програми або іншого функціональності.

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

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

Це, звичайно, додасть роботи при створенні графічного представлення тексту користувачеві, але є безліч способів зробити це правильно.

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

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

Завжди використовуйте встановлені міжнародні стандарти зберігання даних. Наприклад, користуйтеся E. 164 для телефонних номерів, ISO-8601 — для тимчасових міток, ISO 639.2 — для мов, ISO 3166 — для країн і tz database — для часових поясів.

Уникайте ASCII, використовуйте Unicode
У минулому розробники, створювали виключно софт для англомовних ринків, спокійно впроваджували в свій код прийоми, які працювали тільки при використанні кодування ASCII. Наприклад, зміна одного біта в алфавітному символі з ASCII переключало його регістр з нижнього на верхній. Однак з тих пір потреби світу давно перевищили можливості ASCII, і тепер Unicode прийнятий як правильний спосіб кодування текстових даних і підтримки міжнародних символів.

Навіть при деякій сумісності Unicode з ASCII кращим способом уникнути проблем з кодуванням рядків залишається дотримання цих правил:
  • ніколи не допускайте кодування символів у ASCII;
  • ніколи не покладайтеся на те, що один байт дорівнює одному символу;
  • завжди використовуйте підтримують Unicode шрифти і бібліотеки.
На щастя, деякі з найбільш популярних на сьогоднішній день мов програмування, таких як Java, C#, Objective-C, містять вбудовану підтримку Unicode в строкових типах. Їх використання перетворює рішення проблеми міжнародних символів звичайна справа.

Навіть якщо додаток повністю підтримує Unicode, ймовірно, воно зберігає дані в базі даних, і погана логічна структура даних може легко зруйнувати всю відмінно виконану в коді роботу по сумісності з міжнародними кодуваннями. Наприклад, в базі даних SQL Server короткі рядки повинні зберігатися в типах nvarchar, а в MySQL краще всього використовувати utf8mb4.

Детальніше про Unicode можна прочитати в хорошою вступної статті Джоеля Спольски.

Враховуйте, що текст не завжди читається зліва направо
Найпоширеніше розходження у відображенні тексту — написання справа наліво, як в арабській мові та івриті.



У веб-застосунку основні проблеми, які виникають при перекладі читаються справа наліво мови, можна вирішити простим зміною CSS-властивості direction для всієї системи.

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

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

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

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

Наприклад, уявімо собі веб-додаток для замовлення квитків на концерти. Припустимо, вже написаний тест, щоб перевірити, чи може користувач з несправжнім ім'ям «Іван Іванов» забронювати собі місце і переконатися, що його ім'я правильно відображається на квитку, який він отримає після оплати. Додавання простого тесту, який змінює ім'я користувача «Іван-假会河 Іванов-沖鈈批» і відстежує, щоб ті ж символи відобразилися на квитку після оплати, дозволить переконатися в тому, що підтримка міжнародних символів працює і в програмі, і в базі даних. Цей простий підхід (іноді званий «псевдолокализацией») дозволяє розробникам перевірити, чи підтримує їх додаток передачу та зберігання рядків з міжнародними символами, без необхідності замовляти повний професійний переклад продукту або ґрунтовних мовних знань у самих розробників.

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

Охватывайте глобальні можливості
Розробка софта, готового для міжнародного використання, не настільки складна, як може здатися або якою вона колись була. Слідуючи цим простим правилам і роблячи трохи більше роботи спочатку, ви можете створювати програмні продукти, згодом придатні для використання на набагато більших ринках, ніж ви планували. А значить, ваш корисний продукт стане доступнішою!

Ми ж в Alconost завжди раді допомогти вам з професійної локалізацією вашого софта — швидко і якісно.

Джерело: Хабрахабр

0 коментарів

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