← Довідка про переклади символів LC_TIME | Переклади: як це робиться?

Періоди життя дистрибутивів та програм

Щоб було зрозуміліше, про що йдеться, наведемо приблизний графік виходу KDE

Крок 1:
- Початок циклу випуску: тиждень 0
  - Відповідальні за випуск оголошують список можливостей, які буде реалізовано протягом випуску.
  - Визначається перелік бібліотек, які буде випущено.
  - У відповідних списках листування оприлюднюється оголошення про підготовку випуску.
- Оцінка можливостей: тиждень 3
  - Розробники оцінюють можливість відкладення наступного кроку.
    Результатом обговорення може бути зміна оголошення про випуск.
Крок 2:
- Заморозка бібліотек: тиждень 4
  - Додавати нові можливості у основні бібліотеки забороняється.
  - Визначається список програм, які буде випущено.
  - Нове оголошення про випуск.
- Оцінка можливостей: тиждень 7
  - Розробники оцінюють можливість відкладення наступного кроку.
    Результатом обговорення може бути зміна оголошення про випуск.
Крок 3:
- Заморожування програм: тиждень 8
  - Заморожування будь-яких додавань коду до основних бібліотек, окрім виправлення помилок.
  - Забороняється додавати нові можливості до основних програм.
  - Тестовий випуск у бінарному форматі та форматі архіву з кодом.
  - Визначається список бібліотек випуску.
  - Створюється оголошення про випуск.
- Оцінка можливостей: тиждень 11
  - Розробники оцінюють можливість відкладення наступного кроку.
    Результатом обговорення може бути зміна оголошення про випуск.
Крок 4:
- Готово для перекладу: тиждень 12
  - Заморожування будь-яких додавань до коду основних програм, окрім виправлення помилок.
  - Тестовий випуск (бета) у формі коду з можливістю перекладу.
  - Створюється оголошення про випуск.
  - Створюється документ з переліком змін!
- Оцінка можливостей: тиждень 15
  - Розробники оцінюють можливість відкладення наступного кроку.
    Результатом обговорення може бути зміна оголошення про випуск.
Крок 5:
- Підготовка до випуску: тиждень 16
  - Вимикання показу повідомлень зневаджувального характеру.
  - Перевірка коду на залишки зневаджувальних операцій.
  - Випуск попереднього варіанта середовища без перекладу.
  - Копіювання trunk SVN до tags.
  - Відкриття всіх частин для остаточних змін.
  - Оприлюднення оголошення про випуск у відповідних списках листування.
  - Остаточний переклад, підготовка до пакування.
  - Створення повідомлення для засобів масової інформації.
- Оцінка можливостей: тиждень 18
  - Розробники оцінюють можливість відкладення наступного кроку.
    Результатом обговорення може бути зміна оголошення про випуск.
Крок 6:
- Випуск: тиждень 18
  Випуск призначається на вихідні.
  - Завершення перекладу у SVN.
  - Останній попередній варіант стає варіантом остаточного випуску. Ніяких змін до нього, порівняно з попереднім кроком не вноситься. Створюється відповідна копія у tags/ SVN.
  - Архіви з випуском доступні для пакування (лише відповідальним за пакування особам).
  - Сповіщення у список листування перекладачів.
  - Інформування супровідників дзеркал FTP щодо наступного випуску та оновлення файла mirrors.html.
Крок 7:
- Завершення випуску: тиждень 19
  Понеділок через тиждень після Кроку 6.
  - Оголошення на сайтах новин.
  - Відкриття доступу до бінарних пакунків та пакунків з кодом для всіх зацікавлених на сервері ftp.
  - Випуск здійснено.
  - СВЯТО!!!!

Всі пристойні програми, середовища та дистрибутиви мають подібні графіки.

Коли перекладати? Звичайно, можна відкласти все на час, коли переклад буде заморожено (виправлятимуться лише явні помилки), але якщо об’єм перекладу великий (у повному списку повідомлень сховища перекладів KDE 1700000 слів англійською, якщо ви перекладатимете їх, ця цифра значно зросте (у перекладах українською більше символів)). Тому, якщо ваша команда з перекладу не відрізняється великою кількістю активних учасників, варто почати підготовку до випуску у перший же день після попереднього випуску.

Розклади випуску KDE:

Автори програм та встановлення з ними зв’язку

Раніше ми згадували про те, що іноді виникає потреба у встановленні зв’язку з автором (чи авторами) програми щодо того, що ви перекладаєте. Ви можете повідомити про друкарські помилки у початковому тексті, попросити надати контекст (щоб переклад став однозначним), вказати авторові, що потрібно додати форми множити, попередити про те, що деякі речення у повідомленнях розбито на головоломні окремі повідомлення (puzzle), ну і, звичайно ж, вам слід буде надіслати авторам створений вами переклад.

Очевидно, вам слід зв’язуватися з авторами, якщо потрібно щось поміняти у коді самої програми (на основі якого створюється і з яким об’єднується ваш перекладений файл PO), щоб мати змогу правильно перекласти повідомлення. Але іноді, навіть якщо ви вдало переклали повідомлення, варто все ж попросити про певні зміни. Наприклад, якщо вам вдалося зрозуміти сенс складного повідомлення лише після ознайомлення з кодом програми, вам варто попросити авторів додати контекст до файла PO, навіть якщо вам він вже не потрібен. Крім того, можливі випадки поділу автором повідомлення таким чином, що переклад стає кострубатим після з’єднання у ціле повідомлення.

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

Канали зв’язку з авторами залежать від усталених традицій відповідної програми щодо помилок, пов’язаних з локалізацією. У невеличких проектах, ви можете просто зв’язатися за автором електронною поштою. Відповідну адресу може бути вказано у полі заголовка Report-Msgid-Bugs-To шаблону файла PO. У більших проектах для цього призначено список листування або систему стеження за вадами. У KDE, наприклад, ви можете написати повідомлення до списку листування перекладачів або створити звіт про ваду у програмі, яку ви перекладаєте. У GNOME слід надавати перевагу створенню повідомлення про ваду. Загалом кажучи, якщо ви не впевнені щодо способу покращення повідомлення та впливу цього покращення на переклади іншими мовами, краще спочатку обговорити все з іншими перекладачами у відповідному списку листування.

Після внесення відповідних виправлень, очевидно, файли PO буде виправлено не одразу (все залежить від кількості розробників та їх активності). Може пройти тиждень або навіть місяць. Іншою причиною подібних затримок може бути так звана заморозка повідомлень (message freezes), період у житті програми безпосередньо перед випуском нової версії, коли автор вносить лише ті зміни, які є критичними для роботи програми. Пам’ятайте, що після зміни переклад повідомлення стане неточним, тобто кінцевий користувач не побачить перекладеного повідомлення у інтерфейсі чи довідці з програми. Якщо повідомлення буде змінено, наприклад, за два дні до випуску, десяткам команд перекладачів залишиться лише день або навіть менше для оновлення перекладу. Отже, у такому випадку випуск програми не міститиме виправлення. Виправлення буде додано до наступного або одного з наступних випусків програми.

Списки листування програм та дистрибутивів, написання звітів про вади перекладу

KDE

Підписатися на список листування перекладачів
Архів списку листування перекладачів
Підписатися на список листування команди перекладу українською (зараз мертвий, але дуже просто може бути оживлений)
Сайт системи стеження за вадами: "component" з назвою "i18n", "product" — "general" або "uk".

Але простіше просто написати повідомлення перекладачеві електронною поштою або у jabber (yurchor@jabber.kiev.ua).