Конвертовање ручног превода у po4a пројекат

po4a-gettextize ће покушати да издвоји садржај било ког датог фајла превода, и искористиће тај садржај као msgstr у креираном PO фајлу. Имајте на уму да је овај процес врло осетљив: Нти стринг преведеног фајла би требало да буде превод Нтог стринга у оригиналу. Наравно да ово неће функционисати ако оба фајла немају потпуно исту структуру.

Интерно, сваки po4a парсер пријављује синтактични тип сваког издвојеног стринга. На тај начин се откривају десинхронизације током gettextизације. На пример, ако фајлови имају следећу структуру, мало је вероватно да је 4ти стринг у преводу (типа 'chapter') превод 4тог стринга у оригиналу (типа 'paragraph'). Више је вероватно да је оригиналу додат нови пасус, или да су у преводу два пасуса из оригинала спојена.

    Оригинал         Превод
  chapter            chapter
    paragraph          paragraph
    paragraph          paragraph
    paragraph        chapter
  chapter              paragraph
    paragraph          paragraph

po4a-gettextize ће детаљно да дијагностицира било какву откривену десинхронизацију структуре. Када се то догоди, требало би ручно да уредите фајлове (то вероватно захтева да познајете неке основе циљног језика). Морате да додате лажне пасусе или да уклоните неки садржај у једном од докумената (или у оба) како би исправили пријављене диспаритете, све док се структуре оба документа саршено не поклопе. Неки од трикова за то су дати у наредном одељку.

Ча ки када је документ успешно обрађен, и даље су могуће тихе грешке и неоткривени диспаритети. Због тога је сваки превод који је аутоматски доделио po4a-gettextize обележен као fuzzy чиме се захтева ручна људска инспекција. Мора да се провери да ли је сваки прибављен msgstr заиста и превод придруженог msgid, а не стринга пре или после.

Као што можете да видите, кључна ствар овде је да преведени и оригинални документ имају потпуно исту структуру. Најбоље је када се ради gettextизација тачно оне верзије документа master.doc који је употребљен за превод, и да се PO фајл ажурира у односу на најновији мастер фајл једном када gettextизација успе.

Ако имате довољно среће да вам се структуре фајлова савршено поклапају, изградња исправног PO фајла траје неколико секунди. У супротном, врло брзо ћете разумети зашто овај процес има тако ружно име :) Али запамтите да је овај гломазан посао цена која мора да се плати како би се након тога добио комфор који омогућава програм po4a. Онда када се конверзија обави, синхронизација између мастер докумената и превода ће увек бити потпуно аутоматска.

Чак и када ствари крену по злу, gettextизација остаје бржа од поновног превођења свега. Успео сам да одрадим gettextiзацију постојећег француског превода комплетне Perl документације за један дан упркос томе што је структура многих докумената била десинхронизована. То је било више од 2 мегабајта оригиналног текста (2 милиона карактера): поновно започињање превода из почетка би захтевало неколико месеци рада.

Савети и трикови за процес gettextизације

Чим се открије десинхронизација, gettextизација се прекида. Теоретски, вероватно би било могуће да се gettextизација ресинхронизује касније у документу употребом нпр. истог алгоритма који користи и diff(1) алат. Али ручна интервенција би и даље била обавезна да би се ручно подударили елементи који нису могли аутоматски да се подударе, чиме се објашњава зашто аутоматска ресинхронизација (још?) није имплементирана.

Када се то догоди, све се своди на поновно поравнавање ових проклетих структура фајлова кроз ручно уређивање. po4a-gettextize је прилично детаљан у вези тога шта је кренуло погрешно. Он пријављује стрингове који се не подударају, њихове позиције у тексту, и тип сваког од њих. Уз то, PO фајл који је до тада генерисан се избацује као gettextization.failed.po како бисте могли даље да истражујете.

Ево неких осталих трикова који могу да вам помогну у овом заморном процесу:

• Уклоните сав додатни садржај превода, као што је одељак у коме се одаје признање преводиоцима. Можете касније да их додате са po4a, употребом додатака (погледајте po4a(7)).
• Ако је потребно да уређујете фајлове како бисте им поравнали структуре, радије уређујте превод ако је могуће. Заиста, ако измене оригинала нису суптилне, стара и нова верзија неће да се подударају приликом освежавања PO фајла, па ће одговарајући превод у сваком случају да се одбаци. Али ако је неопходно да такође уредите и оригинални документ, не оклевајте да то учините: важна ствар је да за почетак добијете први PO фајл.
• Не оклевајте да уконите било какав оригинални садржај који не постоји у преведеној верзији. Тај садржај ће касније аутоматски да се врати, када се PO фајл буде синхронизовао са документом.
• Вероватно ћете морати да обавестите оригиналног аутора о било каквим променама структуре у превпду које се чине оправданим. Проблеми у оригиналном документу би требало да се пријаве аутору. Ако се поправе у само у вашем преводу, само део заједнице ће знати за то. А и иначе је немогуће да се тако нешто уради када се користи po4a ;)
• Понекад се садржаји пасуса подударају, али не и њихови типови. Исправљање овог проблема је углавном зависно од формата. Често се догађа у POD и man због чињенице да један од пасуса садржи линију која почиње празним простором док други не. У тим форматима, такви пасуси не могу да се обавију и стога постају други тип. Једноставно уклоните размак и биће како треба. Узрок такође може да буде и грешка у куцању имена ознаке у XML.

  Слично, два пасуса могу у POD фајлу да се споје у један када раздвајајућа линија садржи неке размаке, или када нема празне линије између =item линије и садржаја ставке.

• Понекад се чини да је порука о десинхронизацији необична јер је превод придружен погрешном оригиналном пасусу. То је знак неоткривеног проблема раније у процесу. Потражите стварну тачку десинхронизације испитивањем фајла gettextization.failed.po, и исправите проблем тамо где се он заиста и налази.
• Код неких незахвалних поставки имаћете утисак да је po4a појео неке делове текста, било оригиналног, било превода. gettextization.failed.po указује да су се оба фајла подударила, као што се и очекује, све до пасуса N. Али тада, направљен је (неуспели) покушај да се подудари пасус N+1 оригиналног фајла не са N+1 пасусом превода, као што би требало, већ са N+2 пасусом. Као да је N+1 пасус који видите у оригиналном документу једноставно нестао из фајла током процеса.

  Ова несрећна ситуација се дешава када се исти пасус понавља по документу. У том случају се у PO фајлу не прави нова ставка, већ се постојећој ставки додаје нова референца.

  Дакле, претходна листуација се дешава када се сва слична али ипак различита пасуса преведу на потпуно исти начин. Очигледно, то ће да уклони пасус из превода. Да бисте решили проблем, довољно је да на једном од превода у документу начините ситну измену. А можда вам више одговара да избаците други пасус из оригиналног документа.

  С друге стране, ако се исти пасус који се појављује у оригиналном документу двапут не преведе идентично на обе локације, имаћете утисак да је један пасус оригиналног документа једноставно испарио. Само ископирајте најбољи превод преко оног другог у преведеном документу и решићете проблем.

• Као последња напомена, немојте сувише да се изненадите ако прва синхронизација вашег PO фајла траје прилично дуго. То је стога што се већина msgid стрингова PO фајла који је генерисала gettextизација не подудара потпуно са било којим елементом POT фајла који је креиран из скорашњих мастер фајлова. Услед тога gettext тражи најближе подударање употребом захтевног алгоритма близине стрингова.

  На пример, првом позиву po4a-updatepo француског превода Perl документације (PO фајл величине 5.5 MБ) је требало око 48 сати (да, два дана) док су наредни трајали само десетак секунди.