Перетворення виконаного вручну перекладу до формату po4a¶

po4a-gettextize намагається виконати видобування перекладів з перекладених документів і зберегти як записи msgstr їх до записаного файла PO. Майте на увазі, що можливості із розбору тексту у цьому процесі доволі обмежено: програма просто вважатиме N-ий рядок із перекладеного файла перекладом N-го рядка із початкового файла. Звичайно ж, нічого не вийде, якщо структура двох файлів є різною.

На внутрішньому рівні обробник po4a повідомляє про синтаксичний тип кожної з видобутих рядків. У цей спосіб можна виявити розсинхронізацію під час перетворення до формату gettext. Наприклад, якщо файли мають наведену нижче будову, дуже малоймовірним є те, що 4-й рядок у перекладі (типу «глава») є перекладом 4-го рядка оригіналу (типу «абзац»). Найімовірніше, до оригіналу було додано новий абзац або два абзаци в оригіналі було об'єднано у перекладі.

    Оригінал         Переклад
  глава                глава
    абзац                абзац
    абзац                абзац
    абзац              глава
  глава                абзац
    абзац                абзац

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

Навіть після успішної обробки документа можуть лишитися невиявлені невідповідності і помилки, про які не було повідомлено. Ось чому усі переклади, які було автоматично пов'язано із початковими рядками програмою po4a-gettextize, буде позначено як неточні, щоб перекладач переглянув їх вручну. Слід перевірити, чи кожен отриманий рядок msgstr є насправді перекладом відповідного рядка msgid, а не рядка перед ним або після нього.

Як бачите, ключовим тут є точний збіг структур перекладеного документа та початкового документа. Найкращі результати можна отримати, якщо виконати перетворення до формату gettext тієї самої версії master.doc, яку було використано для перекладу, а потім виконати оновлення PO за найсвіжішою версією основного файла.

За сприятливих умов (тобто якщо обидва документи повністю збігаються за структурою), перетворення буде виконано без проблем, і воно триватиме декілька секунд. Якщо ж це не так, будьте готові до певної марудної роботи. Щоб там не було, пам'ятайте, що уся ця робота є платою за наступне комфортне використання po4a. Після перетворення синхронізація вмісту між основними документами і перекладами завжди буде повністю автоматичною.

Навіть якщо щось іде не так, перетворення до формату gettext є швидшим за повторний повний переклад. Мені вдалося перетворити на формат gettext наявний переклад французькою документації до Perl за один день, хоча там і були проблеми. Об'єм перекладу перевищував два мегабайти (2 мільйони символів), на новий переклад довелося б витратити місяці або навіть роки.

Підказки і настанови щодо процедури перетворення до формату gettext¶

Перетворення до формату gettext буде зупинено, щойно буде виявлено розсинхронізацію. Теоретично, можна повторно синхронізувати процес перетворення до формату gettext пізніше у документах, наприклад, за допомогою того самого алгоритму, що і у програмі diff(1). Але ручне втручання все одно буде обов'язковим для встановлення відповідності елементів, які не може бути співвіднесено автоматично, ось чому автоматичну повторну синхронізацію (ще?) не реалізовано.

Коли таке трапляється, усе зводиться до повторного вирівнювання структури файлів вручну. po4a-gettextize доволі докладно повідомляє про те, що не так. Програма повідомить вам про рядки, які не збігаються, їхнє розташування у тексті та тип кожного з них. Більше того, дані PO, які буде отримано на момент помилки, буде записано до файла gettextization.failed.po для подальшого вивчення.

Ось декілька підказок, які допоможуть вам у цій марудній справі:

• Вилучіть усі зайві елементи перекладу, зокрема розділ із подяками перекладачам. Ви зможете додати подібні розділи пізніше за допомогою додатків (див. po4a(7)).
• Якщо потрібно редагувати файли для вирівнювання структури, варто надавати перевагу редагуванню файла перекладу. Справді, якщо зміни у початковому файлі є надто разючими, відповідність старої і нової версії все одно не буде встановлено під час оновлення PO, отже відповідний переклад все одно буде відкинуто. Але не варто відкидати і редагування початкового документа: важливо отримати початкову версію файла PO, яку можна буде виправити пізніше.
• Не вагайтеся і прибирайте з початкового файла усе, чого немає у перекладеній версії. Ці дані буде автоматично відтворено пізніше, під час синхронізації файла PO з документом.
• Вам, ймовірно, слід повідомити автора початкового документа про будь-які зміни у структурі перекладу, які варто зробити. Якщо у оригіналі документа були вади, вам слід повідомити про них авторові. Виправлення цих вад у вашому перекладі буде корисним лише частині спільноти. Більше того, таке виправлення неможливе, якщо використовується система po4a ;)
• Іноді вміст абзаців збігається, але їхні типи є різними. Шлях виправлення цієї помилки залежить від формату документа. У POD і man поширеною причиною подібних проблем є те, що один з рядків починається із пробілу, а інший — ні. У таких форматах абзац із пробілом не можна переносити за рядками, отже він стає абзацом іншого типу. Достатньо вилучити пробіл, і усе запрацює. Також причиною може бути друкарська помилку у назві теґу у XML.

  Далі, у POD два абзаци може бути об'єднано, якщо рядок, який їх відокремлює містить пробіли, або якщо між рядком =item і вмістом запису немає порожнього рядка.

• Іноді між файлами виникає розсинхронізація, і переклад поєднується із помилковим початковим рядком. Це означає, що під час перетворення виникли якісь проблеми ще до розсинхронізованого рядка. Знайдіть у gettextization.failed.po місце, де починається розсинхронізація, і виправте її.
• У деяких випадках po4a додає пробіл наприкінці або початкового, або перекладеного рядківtrings. Причиною є те, що кожен рядок має бути позбавлено дублікатів під час перетворення до формату gettext. Уявіть собі, що рядок з'являється декілька разів у початковому тексті без змін, але його переклади є різними, або різні параграфи мають зовсім однакові переклади.

  Без усування дублювання такі випадки порушували б роботу алгоритму перетворення тексту до формату gettext, оскільки має бути однозначна відповідність між msgid основного і перекладеного файлів. Оскільки у одному з файлів PO не було б якогось запису (про який би було повідомлено як дублікат), однозначну відповідність було б порушено.

  Оскільки po4a використовує для визначення того, чи розсинхронізовано потоки обробки, тип запису («заголовок» або «звичайний абзац» тощо), подібні проблеми можуть трапитися, якщо два ідентичних записи (той самий вміст, але різний тип) основного файла перекладено зовсім однаково у файлі перекладу. po4a виявляє фіктивну розсинхронізацію у таких випадках.

  У більшості випадків, коли po4a дописує додатковий пробіл для усування дублювання рядків, цей пробіл не впливає на форматування. Переклади рядків попри це буде позначено як неточні, а msgmerge згодом, ймовірно, зіставить рядки відповідним чином.

• І нарешті, не слід надто дивуватися, якщо перша синхронізація вашого файла PO буде досить тривалою. Причиною є те, що більшість msgid у файлі PO, який є результатом перетворення до формату gettext, не зовсім точно збігаються із елементами файла POT, якщо побудовано на основі свіжих основних файлів. Наслідком цього є те, що gettext доводиться шукати найближчі відповідники, використовуючи складний алгоритм порівняння і оцінки рядків.

  Наприклад, перша синхронізація po4a-updatepo перекладу документації до Perl французькою мовою (файл PO розміром 5,5 МБ) тривала 48 годин (так, два дні), хоча для наступних синхронізацій було достатньо десятка секунд.