Ma)(imuM bio photo

Ma)(imuM

Ще той дідько ;)

Email Google+ Github Stackoverflow Livelib Steam

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

Підготовка

Для початку треба створити та підтвердити екаунт на github. Також можна пройти чудовий курс знайомства з git від codeschool. Ну і звичайно ж знайти цікаву і корисну програму на github у якій відсутня українська локалізація.

Чудовий сайт для знайомства з git.

Виявлення та обробка файлів

а сторінці обраної вами програми у файлі README.md може бути ціла секція документації в якій не забувають і про локалізацію (часто розділ Contributing). Якщо є – ваше щастя. Слідуйте інструкціями і у вас все вийде. Якщо цього нема – також прогляньте секції Wiki та Issues на предмет такої інформації або запустіть пошукового гіганта – можливо вже хтось займався локалізацією. Варіант “написати розробникам” напряму – гарна ідея. Думаю вони будуть раді і вам допоможуть.

Readme з інформацією про локалізацію в Brackets.

Якщо нічого не вийшло – шукаємо теку де зберігаються локалізації вручну. Це може бути тека з назвою lng, l18n, lang, translations або будь-яка інша, що містить файли схожі на файли перекладу. Самі файли перекладу зазвичай у назві містять код мови: en, de, es, uk… Один з цих файлів ми будемо використовувати в якості шаблону для нашого перекладу. Я зазвичай беру англійський (оригінальний). Ви ж можете взяти польський або інший, якщо ця мова вам ближча та існує уже як переклад. Виділяємо весь текст та копіюємо вміст до буфера обміну.

Далі створимо шаблон-заготовку для нашого перекладу – аналогічний файл для нашої мови зважаючи на формат іменування. Цей файл покищо не буде містити перекладу. Якщо імена файлів містять код мови типу en.js, de.js… то відповідний файл локалізації буде мати назву uk.js. Для en_US відповідно uk_UA. Для створення файлу в github передбачено кнопку “+” вгорі екрану. Якщо потрібно вкласти файл у теку, попередньо розділимо слешем “/” підтеку та назву файлу.

Файл-заготовка для перекладу.

До цього файлу вставляємо наші дані з буфера обміну та збежемо. При цьому github створить форк – копію проекту на момент створення файлу та нову гілку (branch). У git гілки створюють зазвичай для розробки конкретного функціонального блоку. У нашому випадку це українська локалізація. Цю гілку можна назвати ukrainian_l18n аби з назви було зрозуміло для чого вона призначена. Якщо ж ви просто створили файл у оригінальному проекті (як я описав вище) то github автоматично створить гілку з назвою patch-1.

Переклад

Тут все більш-менш зрозуміло. Переходимо на гілку створену вище (patch-1?), беремо нашу заготовку та перекладаємо рядки оригіналу на українську. Перекладати це можна прямо файлі “вручну” або за допомогою спеціальних систем спільного перекладу, що дозволяють зберігають ключові терміни, бачити переклади схожих рядків, тощо. Багато таких сервісів дозволяют перекладатись open source програмам задарма. Найбільші з них такі: transifex.com, getlocalization.com, а також від наших братів з Тернополя – crowdin.com. Останню рекомендую не тільки тому, що вона наша “православна”, а й тому що воно й найбільш функціональна на мій погляд. Словом для цієї системи варто робити окремий огляд.

Збереження

Припустимо ви завершили переклад і вичитку. Що робити далі? Зберігати зміни в нашу гілку. Якщо ви використовували веб-інтерфейс – просто збережіть файл. Якщо використовували консоль – закомітьте зміни файлу. Все. Зміни на сервері. Перевірте чи не порушилась структура файлу. Якщо все гаразд – заходимо на наш репозиторій та створюємо pull request. Параметрами pull request є 2 гілки – гілка з вашими змінами та гілка в яку ті змінити ви хочете внести. Також є опис – тут варто вказати що саме ви змінили (англ.мовою не забувайте). Pull request’ом ми ніби кажемо до власників репозиторію:

Агов, панове! Я ось зробив крутий функціонал (переклав програму українською). Він знаходиться в моїй гілці A і я хочу інтегрувати його у основну гілку Б.

Тепер чекаємо на те, щоб координатори “зілляли” зміни і все стало “комільфо”. Також перед тим як вони почнуть розглядати ваші зміни – pull request може перевірятись автоматичним ПЗ типу Travis-CI. Це ПЗ перевіряє чи ваші коміти не приводять до неможливості компілювання програми та тестує встановленими тестам. Якщо бачите помилки перевірки pull request – шукайте синтаксичні помилки в коді.

Через деякий час координатори або внесуть зміни, або вкажуть що треба доробити/переробити (як було зі мною) в будь-якому разі ви отримаєте сповіщення. Мій pull request вже знаходиться тут.

На останок

Ось як виглядає Brackets після злиття моєї гілки з основною. Кілька дрібних вад залишилось, але користуватись тепер набагато приємніше.

Вигляд Brackets після локалізації.

Після цього я не втримався і локалізував ще кілька найпопулярніших розширень. :)

Звучить дивно, але спочатку в мене практично нічого не вийшло з github. Виглядало дуже складно і я не міг зрозуміти що там і до чого. Мені не подобалось. Але потім я зрозумів філософію і все стало на своїм місця. Весь фокус в тому, щоб не втрачати жодної зміни і при цьому бути стабільним. Якось я залив файли по ftp на сервер. Вніс зміни (тільки на сервері) з іншого комп’ютера. Потім знову вніс інші зміни і на своєму комп’ютері і перезаписав вміс що був на сервері зовсім забувши про те що локальні і серверні файли відрізняються. Таким чином я втратив 6 годин свого часу на те аби зробити те все знову. З git би такого ніколи не сталось тому що кожен коміт в ньому завжди зберігається і мені б просто не дозволили внести “конфліктні зміни”.

Git - цікава і корисна річ. :)