Prevođenje - kako to tehnički izvesti

[Pedja]

Ovih dana radim sajt za klijenta na pet jezika. Prvo smo uradili verziju na srpskom, a sada smo u procesu prevođenja na ostala četiri jezika. Cela stvar je prilično komplikovana i svodi se na mnogo pešačkog posla.

Pošto je sajt urađen na PHP podlozi, dobar deo sadržaja sam smestio u "rečnik", tako da sam prevodiocima dao taj rečnik da ga prevedu. Taj deo je prošao vrlo lepo, ali tako se mogu rešiti smaoneki opšti detalji kao što su nazivi dokumenata, opcija menija, često korišćeni izrazi i slično.

Ipak, najveći deo sajta je sadržaj dokumenata, koji je jedinstven za svaki dokument i veoma raznolik. S obzirom da prevodioci nisu web pismeni, ne može se računati na njihovo uključivanje u ceo proces dalje od toga da kucaju prevod u Word-u.

Najbolje što smo mogli da uradimo to je da prevodiocima spremimo sadržaj strana u Word-u tako što smo konvertovali HTML, kako bi imali tekst koji treba d aprevedu ali formatiran kako stoji na sajtu. Ljudi su to tako i preveli.

E sad, šta je problem: sav taj prevod treba vratiti nazan u HTML. TO mora da se radi peške, često rečenicu po rečenicu i veoma pažljivo jer sam sadržaj dokumenta nije čist HTML tekst, već tu ima i linkova, umetnutih znakova, pa i PHP koda. Čak i sa prevodom na engleski koji znamo, išao je prilično sporo. Sad treba da raidmo druge jezike koje ne poznajemo, tako da ne može da nam pomogne to što prepoznajemo u tekstu šta je šta i gde treba da ga smestimo.

Da li se neko bavio ovim problemom i, možda, smislio neki efikasniji sistem za prevođenje?

[Филип Милетић]

Пеђа, погледај „буразера преводиоца“ (i18ndude, http://plone.org/products/i18ndude).  То је најбољи систем за превођење хипертекста који знам.  Не знам колико је применљив за ПХП преплетен са ХТМЛом, али ако ништа друго бар идеје могу да се покупе.

и18ндуде ради тако што у тексту тражи посебне одељке, који су означени као преводиви делови текста.  Када их нађе, онда извуче садржај тог дела текста и смести у ПО датотеку која се онда лако преводи.  Наравно, постоји и инвертор који овако добијен текст враћа на своје место.

Ствар одлично ради оно чему је намењена.  На жалост, не подржава родове, бројеве и падеже (што је верујем очекивано), али управо у том недостатку можда лежи наших пет минута.

ф

[Pedja]

Razvio sam neki svoj sistem, koji funkcionise, ali upravo nisam zeleo da bas sav tekst prebacim u recnik, vec da ono sto je celina ostavim u HTML-u, da bi dizajner imao da radi sa necim konkretnim. Uz to, ne svidja mi se ideja da ama bas sav tekstualni sadrzaj treba da se umece kroz nekakav mehanizam, narocito ako je taj sadrzaj po prirodi statican.

Ovaj i8ndude je otpao onog momenta kada je insistirao da se na racunar prvo instalira Python, posto mi treba sitem koji ce da funkcionise sa prevodiocima koji nisu i ne treba da bduu poznavaoci racunara. Njima treba jednostavno da posaljem tekst koji se prevodi i da ga oni prevedu, na nacin koji njima odgovara (a to najcesce znaci da koriste MSWord).

No, ovo mi je dalo neku ideju koju bih mogao da probam da ralizujem: da u tekst ubacujem oznake kojima se utvrdjuju celine koje se prevode i onda napravim neki alat koji ce to da izvuce iz HTML-a i prebaci u obican lako citljiv tekst koji se moze azurirati u bilo kom editoru, a kada je prevodjenje zavrseno, da ume da sav taj tekst umetne nazad gde mu je mesto. To se ne bi radilo online, vec jednokratno, rucno, kada se zaista i radi prevodjenje sajta, jer sam se vec odlucio da za statican sadrzaj postoje posebni dokumenti za svaki jezik.

Hmm, cak mi se icni da imam ideju koja bi mogla da se primeni ne samo za HTML, moramo to malo razraditi, pa se mozda nadje neko ko je zainteresovan da napravi.

[Филип Милетић]

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

и18ндуде само извуче текст из хтмла и направи ПОТ, а кад ти врате преведени ПО, онда и18ндуде то врати назад у текст.

ф

[Pedja]

Vrlo verovatno da nisam shvatio kako treba. Svojevremeno sam istrazivao takav nacin prevodjenja i nisam stigao dotle da uopste dobijem nesto sto se da prevoditi, a svi alati su mi ostavljali utisak jednog velikog krpeza.

Mislim da sma cak jednom prilikom razmsilajo da korsitim skript koji je korsitio .po datoteke za prevodjenje i da je samo trebalo da ih prevedem i da sam vrlo brzo odustao od cele zamisli jer je sve delovalo previse komplikovano.

[Милан Динић]

Радио сам сада преводе два CMS-а рађена у PHP-u (први је Вордпрес, за други је Плогер, чекам да га аутор постави на мрежу па ћу ставити везу и ка њему) који за локалиацију користе PHP gettext (који је ваљда развио Данило Шеган), односно ПОТ, ПО и МО датотеке.

Погледај званично упутство, а онда и ова два одлична текста и мислим да ћеш схватити отприлике начин на који функционише. Добра ствар је да постоји могућност да се одређени изрази преводе различито за једнину и множину, и различите облике у множини. Лоша ствар се може десити када се један израз понавља на више места он се мора превести као један, а некад то није исто. Сад ми на памет пада само један (можда лош) пример. Ако се појави реч Post њено значење је у неким датотекама „објавити“ а негде се мисли на чланак (оно што се код нас одомаћило и као „пост“). Али нису баш толико чести овакви случајеви.

У изразима се често појављује оно што они зову php format па рецимо постоји један овакав:

Код:

Permanent Link to %s

.
Ово %s се значи посебно генерише. Па ја тако преведем као

Код:

Стална веза ка: %s

Исто можеш да убациш ХТМЛ за посебне карактере као и код обичног ХТМЛа, на пример:

Код:

Read the rest of this entry »

а можеш и прави ХТМЛ у комбинацији са PHP-ом:

Код:

Category <a href=\"#%s\">%s</a> added

или без PHP-а:

Код:

Thank you for creating with <a href=\"http://wordpress.org/\">WordPress</a>

Превођење преко poEdit-а није тешко, а може и у обичном текстуалном уређивачу.

Пошто си ти већ завршио тај пројекат, вероватно ће бити компликовано да сада убацаш Геттекст (не знам колико је обимно; мада ти чим желим неки другачији систем ти свеједно мораш да мењаш), али за будуће пројекте можеш ово да искористиш.

Е да, имаш још нека упутства око Геттекста на преводу Гнома, то је уопштено за Геттекст не само за PHP.

[Pedja]

Hvala na detaljima. Proucicu ovo, ali mi se cini da nisam dovoljno objasnio probl;em. Dakle, prevodjenej pojedinih reci i zraza imam reseno i sasvim sam zadovoljan kako to radi. Problem mi je prevodjenje ostatka, to jesto onoga sto predstavlja stvarni sadrzaj dokumenta. To je mnogo teksta da bi ga trpao sa strane u recnik kao sto se to radi sa izrazima.

Uz to, to je sadrzaj koji po pravilu nije prost tekst nego kompleksan HTML dokument.


Ovih dana sam naleteo na jos jedan problem. Milsim, imao sam ga i ranije ali sam ga ignorisao. Rec j eo tome da se neki podaci koji se prikazuju na sajtu ibucno nalaze u nekoj vrsti baze podataka. Iz baze se izvlace i prikazuju u formi koja je potrebna. Visejezicna podrska stane je obezbedjena na uobicajen nacin. Medjutim, postavlja seproblem sto sama baza takodje treba da bude visejezicno. Prakticno svaki tekstualni podatak u tabelama potencvijalno treba da omoguci visejezivan unos. to se odnosi cak i na najtrivijalne podatke.

Uzmimo na primer da se u neku tabelu upisuje ime i prezime. Taj podatak se u originalu unosi cirilicom a prikazuje se na sajtu koji je visejezican. Nekako bih mogao da izvedem da se, ako se dokument prikazuje na jeziku koji koristi latinicu, cirilice prevede u latinicu i tako prikaze i to bi bilo kompromisno resenje, medjutim, daleko je od dobrog. Pravila preslovljavanja iz srpke cirilice u srpsku latinicu su jasna, ali ta pravila ne moraju da vaze ako se radi o drugim jezicima. Isto iem se u razlicitim jezicima moze pisati isto.

Ili da uzmemo ekstreman primer, sta ako se u bazu podaci unose cirilicom i tako se recimo ime John upise kao Џон, što je u srpskom jeziku, kada se piše ćirilicom jedino ispravno. E sad, ako se sajt prikazuje na engleskom, neprihvatljivo je da se napiše to Џон, a ni transkribovano u latinicu kao Džon nije ništa bolje. Na engleskom, tu treba da piše John.

Problem naravno nije nerešiv. Osnovna pravila modeliranja baza podataka nalažu da se u takvim slučajevima obezbeđuje mehanizam koji omogućava da se podatak može u bazu upisati za svaki jezik posebno. To ne bi bilo problem da se radi o nekom specifičnom podatku, već se ovde praktično radi o tome da svako polje u koje se slobodno unosi tekst, mora da omogući unos na više jezika. To drastično komplikuje bazu i čak najjednostavniju tako zakukulji da je njen razvoj i održavanje noćna mora, a da ne pričamo kako se time drastično smanjuje njena praktična upotrebljivost i efikasnost.

[Филип Милетић]

везу и ка њему) који за локалиацију користе PHP gettext (који је ваљда развио Данило Шеган), односно ПОТ, ПО и МО датотеке.

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

Код ПХП геттекста важно је да се разуме шта је по среди.  У питању је замена за нормални ГНУов геттекст.  Данилов ПХПгеттекст служи да би локализација програма помоћу ПО датотека била могућа и на рачунарима на којима немате директну контролу над библиотекама.  То нуди ПХПгеттекст, а с обзиром како је Пеђа описао свој проблем, он ми не делује као решење.

Конкретније, замислите два сценарија:  1) веб сервер имате код своје куће и 2) веб сервер је у власништву неке фирме која хостује.   

У првом случају, ако вам затреба гнуова геттекст библиотека, просто је инсталирате и користите ПХП „бајндинг“ за геттекст. 

У случају 2) веб сервер је у некој западној земљи, где геттекст ем није инсталиран, ем нема начина (или није рентабилно) да се убеђујете са фирмом да вам омогући да користите геттекст.  У горим случајевима је цео галиматијас да их само убедите да подесе Апача да странице испоручује као УТФ8.  У овом другом случају, скинете Данилову библиотеку, убаците поред својих ПХП модула и ствар ради.

Пеђин изворни проблем је другачији, бар ми тако изгледа. Он има између осталог да преведегомилу текста који је спакован у ХТМЛ одн. ПХП датотеке.  То су обично сплетови текста и кода, где бих грдно забрљао ако бих случајно превео што не треба и тако оштетио део кода. 

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

Зато би идеално било да се има начин да се текст и код раздвоје, и преводиоцима само понуди да преводе текст, док би се код налазио безбедан негде другде.  Разна решења за овај проблем постоје, али она не нуде све што би могло да се пожели.  Чини ми се да је то зато што у једном тренутку концесије које локализација тражи науштрб главне сврхе програма постану превелике, и развојни тим одлучи да ту повуче црту.

То наравно не значи да не можемо да смишљамо како треба да изгледа идеални систем за локализацију.  (Једино ми није јасно да ли овде причамо о конкретним постојећим решењима која су спремна за употребу, или причамо о томе шта би могло да се уради?)

Наставак следи.

ф

[Филип Милетић]

Изгледа ми да је Часлав најдаље отишао у исправном превођењу програма на српски.  Његов систем (нигде није експлицитно наведено, али изглед да да је Часлав аутор новог КДЕовог система за српски превод) подржава родове, бројеве и падеже. 

Многи „стандардни“ системи за и18н стају код просте статичке замене текста на изворном језику текстом на одредишном језику.  ГНУов геттекст је један од ретких који је отишао даље и који омогућава динамичку замену за бројеве.  (1 човек, 2 човека, 5 људи)  Али ни они не иду даље.  Чаславов систем подржава колико сам видео падеже, родове, бројеве и још доста специјалних случајева.  (Узгред, Чаславе они зихерашки захвати имају пар покварених веза, јел то може да се исправи?)   То је све добро за преводе програма.  Добро је, јер је код програмског кода често веома јасно шта је текст који се преводи а шта није, па се лако издваја и њиме манипулише.

Али...

Кад се дође до ХТМЛ датотека, и то поготово оних које у себи садрже смешу кода и текста, ствари се компликују.  Више није тако лако да се одреди шта се преводи а шта се не преводи, јер је цела датотека једна супа кода, са резанцима од текста.  Идеално би било да постоји програм који из такве супе издваја текст (и то минимално измењен, ако је икако могуће) који онда може да се да преводиоцима да га они преведу на начин који им највише одговара.  Идеално би било и да постоји програм који може да узме тако преведен текст, узме изворну датотеку, и те две ствари споји у једну, нову, преведену датотеку.

и18ндуде је програм који ради ово последње описано.  Уме да издвоји текст и преспе га у ПО датотеку,  и уме да преведен текст из ПО датотеке пребаци назад на одговарајуће место у ИксМЛ (хтмл или др.) код.  Постоје два проблема са и18ндудетом.  Први је што је замена проста. Текст се статички мења, не постоји подршка за вишеструку множину, нити за езгибиције које нам је показао Часлав.  Други је што, да би то било могуће, у ИксМЛ морају да се убаце посебне ознаке (тагови) које означавају делове који треба да се преведу. 

Да не буде да само кудим, казаћу и пар позитивних ствари о томе.  Ствар ради прилично добро.  Цео Плоне (http://www.plone.org) преводи се на овај начин.  Тојест, ако нисте цепидлака као  Часлав па вам не сметају повремено места на којима је наш језик сувише окретан да би га и18ндуде савладао.

На сличан начин ради и Транслејт тулкит (Translate Toolkit, http://translate.sf.net, Пеђа погледај и овај алат). То је збирка алата који служе да све могуће и немогуће текстуалне формате преметну у ПО, и из ПО а врате назад.  Ствар је доста добра (скоро целу Мозилу превео сам помоћу ове конверзије — осим датотека помоћи које су у ХТМЛу, видеће се одмах и зашто).  Једини проблем је што је превођење СГМЛ датотека (па према томе, ХТМЛ, ИксМЛ и осталих) прилично трапаво решено, управо зато што текст није тако једноставно парсирати.  Мада, можда може да послужи.

ф

[Филип Милетић]

И ево, трећа срећа, да се вратим на Пеђин текст и на последњи проблем ког је уочио:

Ili da uzmemo ekstreman primer, sta ako se u bazu podaci unose cirilicom i tako se recimo ime John upise kao Џон, što je u srpskom jeziku, kada se piše ćirilicom jedino ispravno. [...]
praktično [se] radi o tome da svako polje u koje se slobodno unosi tekst, mora da omogući unos na više jezika. To drastično komplikuje bazu i čak najjednostavniju tako zakukulji da je njen razvoj i održavanje noćna mora

У конкретном случају поља за име који си навео, ово решење ми делује неодговарајуће.  Да размотримо два примера.

Замислимо да смо базу уредили тако да сваки текстуални унос може да има вишејезичан опис.  Питање је сад, да ли је за баш сваки текстуалан унос то неопходно.  Замисли да имамо два Џона (John) у нашој бази. 

У том случају оба поља имала би вишејезичне „дупликате“.  Међутим, очигледно је да оба Џона имају једну те исту транскрипцију на српски језик.  Другим речима, пресловљавање не треба да буде део базе пошто је ортогонална на садржај, већ текст треба да се преслови након што се образује табела.  Што је добро у овом конкретном случају, јер је пресловљавање одвојено као што и треба да буде, па се одржавање базе не компликује.

Други проблем је што унос свега на ћирилици не даје савршене резултате.  Узмимо да је тачно да се име John  на српски пресловљава као Џон.  Али, и име Jon (од: Џонатан, в. нпр. Џон Стуарт (Jon Stuart)) се исто изговара као Џон.  Пресловљавањем Џона на српски изгубили бисмо информацију о његовом правом имену.  С друге стране, ако оставимо у оригиналу, бар имамо шансу да у догледно време унесемо тог Џона у табелу за пресловљавања.  Табела може да се допуњава временом како настане потреба.  Тиме смо бар решили проблем уноса имена, без претераног компликовања базе.  У овом случају довољно је само да се означи на ком језику је унос, уместо да се свако поље дуплицира онолико пута колико се језика подржава.

Имао бих још на ову тему, ал рекох да паузирам мало.

ф

[Pedja]

Isprobacu ove alate sto si predlozio pa cu videti da li mi seuklapaju u problem.

Sto se tice Dzona, ti si ukazao na dodatne komplikacije koje su sasvim izvesne. Ideja sa preslovljavanjem se sama namece i u nekim slucajevima zaista moze da bude resenje, ako polje koje se popunjava ima konacan broj unapred poznatih vrednosti.

Ako je unos slobodan to je problem, prvo zato sto ne znamo sta ce korsinik da unese, tako da ne mozemo da obezbedimo ispravno preslovljavanje unapred, a onda i zato sto, ako se koristi spoljni recnik, uredjivanje redosleda i pretraga po tom polju postaje neizvodljiva (polje vise ne sadrzi vrednost koja se trazi).

Ja sam na ovaj problem naleteo u vrlo jednostavnom primeru: hteo sam da napravim obican, najobicniji adresar za sajtu, koji se sastoji od samo jedne tabele, a sajt moze da se pregleda i na srpskoj cirilici i na srpskoj latinici i na jos cetiri strana jezika. Presabirajuci sta bih sve morao da urdim da bih obezbedio neku mnimalnu funkcionalnost, odustao sam i izbacio cirilicu sa sajta (cime nisam do kraja resio problem jer je jedan od stranih jezika ruski, koje je cirilican).

Sto je najcrnje, ovo je ozbiljan problem, koji ce vrlo verovatno uticati na to da neki sajtovi koje budem radio nece imati cirilicu (iako sam ja zagovornih stava da domaci sajtovi treba da imaju i cirilicnu verziju).

[Часлав Илић]

(Упозорење: моје „знање“ ПХПа се своди на прочитан туторијал на В3школи...)

Пре свега, чињеница да је вебсајт у сваком тренутку под контролом аутора, тј. без захтева за разним сагласностима што би их изискивао нпр. неки кориснички програм, даје доста слободе у пројектовању и18н подсистема.

Хипотетички посматрано од нуле, нека се сав текст који се представља корисницима провлачи кроз ПХП позив. Нпр. уместо овог:

Код:

<p>Welcome to the home page of...</p>
<p>We are leaders in design of flying toasters...</p>
...

да буде:

Код:

<?php
_("<p>Welcome to the home page of...</p>");
_("<p>We are leaders in design of flying toasters...</p>");
...
?>

У том случају био проблем био сведен на исти као и код превођења програма, за шта већ постоји читава добро утврђена техничко-организациона машинерија Геттекста и ПО формата.

С техничке стране, прва и најбитнија ствар била би та да превод одједном постаје динамички, што значи да није потребна никаква разградња/изградња изворних докумената, већ се сваки поједини део текста вуче директно из ПО датотека. Ако неки део недостаје, корисник неће видети тај пасус преведен већ на изворном језику, али неће доћи ни до каквих других тех-орг проблема.

Аутоматски се добија могућност правилног уметања делова текста:

Код:

<?php
_("<p>Number of messages: %d</p>", $nMsg);
?>

за разлику од лошег:

Код:

<p>Number of messages: <?php echo $nMsg ?></p>

као што је имплицирано у примерима на В3школи — тако се једноставно не ради са текстом намењеном превођењу. Даље, такође се добија могућност задавања контекста за преводиоце и множинских облика:

Код:

<?php
_c("New message", "<b>New</b>", $nMsg);
// prevodilac vidi obe niske, korisnik samo drugu
...
_n("<p>You have one new message.</p>",
   "<p>You have %d new messages.</p>", $nMsg);
?>

Наравно, било би потребно написати све ове функције, _(), _c(), _n(), али би то било релативно мало ко̑да који изнутра користи стандардне геттекст-позиве.

С организационе стране, главно је што се добија велика лакоћа одржавања превода. Геттекст аутоматски извлачи шаблон за превођење из ПХП датотека (колико видим, већ познаје ПХП као један извор), који преводилац попуни овако:

Код:

#: az.php:132
msgid "<p>Welcome to the home page of...</p>"
msgstr "<p>Добродошли на домаћу страну...</p>"
...
#: buki.php:456
#, php-format
msgid "<p>Number of messages: %d</p>"
msgstr "<p>Број порука: %d</p>"
...
#: vjedi.php:101
msgctxt "New message"
msgid "<b>New</b>"
msgstr "<b>Нова</b>"
...
#: vjedi.php:231
#, php-format
msgid "<p>You have one new message.</p>"
msgid_plural "<p>You have %d new messages.</p>"
msgstr[0] "<p>Имате %d нову поруку.</p>"
msgstr[1] "<p>Имате %d нове поруке.</p>"
msgstr[2] "<p>Имате %d нових порука.</p>"
msgstr[3] "<p>Имате нову поруку.</p>"

при чему су доступне разне аутоматске провере, нпр. да преводилац није изоставио форматску директиву (%d у примерима), итд.

Друго, када се сајт измени, Геттекст стапа нове шаблоне са постојећим преводима, и преводилац тачно види нове и измењене поруке. Нпр. преправи се мало порука <p>Welcome to the home page of...</p>, и преводилац добије „мутан“ унос:

Код:

#: vjedi.php:101
#| msgid "<p>Welcome to the home page of...</p>"
#, fuzzy
msgid "<p>Welcome to the web site of...</p>"
msgstr "<p>Добродошли на домаћу страну...</p>"

који онда може да доради како треба и уклони заставицу fuzzy. Ово је посебно битно за дуге пасусе, где се може упоредити тренутна и претходна верзија поруке и тачно видети разлике (аутоматски у неким ПО уређивачима, а могу се и угњездити директно у ПО датотеку малом предобрадом).

Како ово ради са тим именима/адресама што корисници сајта треба да уносе? Па, никако :) Али то никако нигде и не ради... Просто, узима се што корисник унесе, и тачка; на њему је да унесе како мисли да је најбоље.

Међутим, ако је очекивани обим тих корисничких уноса мали, и одржавалац сајта нема ништа против да сваки „контролише“, онда би могло овако да се уради. Корисник унесе своје податке. Одржавалац их измени, тако да у бази буду само и једино на подразумеваном језику. Табелу на страни ствара повлачењем ових уноса из базе, али тако да их претходно провуче кроз геттекст позив:

Код:

<?php
...
echo "<td>" . _c($unos->getContext(), $unos->getName()) . "</td>";
...
?>

а некако уреди да се од уноса̑ из базе аутоматски ствара засебан ПО шаблон, где је јединствени кључ уноса и назив поља дат као контекст уз сваку поруку:

Код:

msgctxt "ad82c92a:Name"
msgid "Pera Peric"
msgstr "Пера Перић"

коју онда преводиоци обрађују као и све остало.

* * *

Е сад, то би био идеални свет. Реално је вероватно да већ има гомила тих ХТМЛ докумената који се не дају преправљати тако да сав текст иде кроз ПХП позиве. У том случају — Пеђа, нек ти је виша сила у помоћи :) Посебно када дође до питања организације и ажурирања превода...

Поред тога, поштено речено, нисам сигуран ни колико би се тој преводилачкој раји свидео ПО формат. Треба им објаснити контексте, множине, мутне заставице, упоређивање тренутног с претходним извором, шта ту треба а шта не треба преводити, итд. — професионалци се ту очас посла стумбају, то је више за аматере попут нас ;)

[Часлав Илић]

Његов систем (нигде није експлицитно наведено, али изглед да да је Часлав аутор новог КДЕовог система за српски превод) [...]

У ствари је још горе: преорао сам и подјармио цео и18н подсистем КДЕ четворке, како бих несметано могао да изведем што нам треба. Па кријем ко̑ змија ноге, пошто је удобније рећи „КДЕ у верзији 4 доноси нове могућности превођења...“, него „види шта је онај болид склепао“. Додуше, бар ми се већ један јапански преводилац уплео у мрежу, тако да могу мирне савести да кажем да није само за српски :)

Ех, Јапанци... Морам да испричам. Док смо тако решавали граматичку обраду за јапански у вези с неким образовним програмом за географију, у једној закрпи коју је послала за неке техничке ситнице, приметим и измењено име на енглеском неке леве области у Белорусији; исправљена грешка, и то таква да бих је, без обзира на макар приближан матерњи, лично прогутао без размишљања. Питам, „Извини, али, како бре нађе да је погрешно?!“, а она ће да за сваки унос проверава изговор на Википедији, како би пресловила на јапански. Одлепим на лицу места — програм имао једно хиљаду таквих географских одредница...

[...] подржава родове, бројеве и падеже.

У ствари, систем је општији у смислу да преведене поруке постају практично интерполације ниски у оквиру „ПО-шкољке“, док се „скрипте“ (тј. они $[...] позиви) пишу у неком позадинском скриптном језику — па, заправо, исти принцип као ово уметање ПХПом у ХТМЛ. За српски конкретно сам навео само оно што сам до сада дефинисао од позива, па ћу додавати како који затреба.

У случају КДЕа позадински језик је јаваскрипт, али само заслугом тога што већ постоји унутрашња имплементација, па је доступан „за џабе“. Јер ми је пао мрак на очи после цигло сата скриптовања, кад сам се питајући зашто ми се један затварач понаша неуротично, пронашао да јаваскрипт има динамички уместо лексичког досега...

(Узгред, Чаславе они зихерашки захвати имају пар покварених веза, јел то може да се исправи?)

Чим заиста и напишем те текстове :)

[Филип Милетић]

Е сад, то би био идеални свет. Реално је вероватно да већ има гомила тих ХТМЛ докумената који се не дају преправљати тако да сав текст иде кроз ПХП позиве. [...] нисам сигуран ни
колико би се тој преводилачкој раји свидео ПО формат.

Моје је виђење да нисмо преводиоцима изашли довољно у сусрет.  Циљ треба да буде да преводиоци смеју да виде само чисти текст.  ПО формат има проблем јер дозвољава да означавање (markup) уцури у текст који треба да се преводи. Из твог примера:

Код:

#: az.php:132
msgid "<p>Welcome to the home page of...</p>"
msgstr "<p>Добродошли на домаћу страну...</p>"

Овде преводилац преводи текст:

Код:

"<p>Welcome to the home page of...</p>"

уместо много природнијег:

Код:

"Welcome to the home page of..."

Не постоји апсолутно никакав разлог (осим ограничења ПО формата) да преводилац види ознаке за пасус (<p>) када преводи.  Делује наивно кад се посматра овај мали пример, али се врло лако претвара у ноћну мору: ако постоји простор да се у превод угура <p>, постоји простор и за много компликованије ствари.  Преводиоци се ту онда (с правом ) ресетују, и нисмо урадили ништа.

ИксМЛ (према идеји из и18ндуде) нуди доста занимљиво решење за овај проблем.  Превод ког преводилац обрађује је такође ИксМЛ (одн. може да буде!).  У обичан текст ументуте су ознаке које својим атрибутима указују шта треба да се уради са преводом.  Између ознака (тагова) налази се подразумевани текст ког преводилац види. 

Преводилац ради у неком едитору који уме да тумачи ИксМЛ (таквих има доста) и види чисти текст (пошто едитор сакрије означавања).  Преводиоцу остаје само да текст преведе на свој стари добри начин.

Узећу примере из твог текста:

Код:

<p><div class="translate" lang="en" context= "welcome-msg-1">
Welcome to the home page of...</div></p>

Ово се означавање уопште не види када се датотека приказује (јер је означавање и даље валидан ХТМЛ), али обезбеђује сав потребан контекст.  Од ове датотеке може да се трансформацијом направи нешто што преводилац може да свари:

Код:

<div class="translate" lang="en" context="welcome-msg-1">
Welcome to the home page of...</div>
превести као: [<div class="translate" lang="sr" context="welcome-msg-1>Овде упишите превод</div>]

Када преводилац гледа кроз неки ИксМЛ, или ХТМЛ едитор, тагови се не виде и остаје само:

Код:

Welcome to the home page of... превести као: [Овде упишите превод]

Едитор се стара да тагови остану на месту, како би касније цела ствар могла да се врати у преведени документ.

Згодан додатак у овом случају је и могућност да се убаце Чаславове интерполације:

Код:

<div class="translate" lang="en" context="messages:scheme:(= var-msg 1)">You have <div class="translate:var-msg">one</div> new message.</div>
<div class="translate" lang="en" context="messages:scheme:(>= var-msg 2)">You have <div class="translate:var-msg">two or more</div> new messages.</div>

У горњем примеру је за скрипт језик узета схема из чисте пакости према нељубитељима с-израза.  Преводиоци виде питомо:

Код:

You have one new message. You have two or more new messages.

За српски би било:

Код:

<div class="translate" lang="sr" context="messages:scheme:(= var-msg 1)">Имате <div class="translate:var-msg">једну</div> нову поруку.</div>
<div class="translate" lang="sr" context="messages:scheme:(and (>= var-msg 2) (<= var-msg 4))">Имате <div class="translate:var-msg">(две до четири)</div> нове поруке.</div>
<div class="translate" lang="sr" context="messages:scheme:(and (>= var-msg 5) (<= var-msg 10))">Имате <div class="translate:var-msg">(пет до десет)</div> нових порука.</div>

(правила за множине су мало сложенија него овде, занемаримо сад то.

То наравно захтева да нека добра душа направи датотеку у којој пише:

Код:

<div class="translate" lang="sr" context="(= var-msg 1)">једну</div>
<div class="translate" lang="sr" context="(and (>= var-msg 2) (<= var-msg 4))">(две до четири)</div>
<div class="translate" lang="sr" context="(and (>= var-msg 5) (<= var-msg 10))">(пет до десет)</div>

Све ово наравно подразумева да постоји систем за интерполације (тј. да се дозволи да преводи буду бар функције првог реда).

Имал ово неког смисла?

ф

[Pedja]

Mislim da to i ne resava problem narocito. To sto prevodilac ne vidi html kodove ne znaci da ne moze da ih poremeti. Prost primer je recimo novi red u tekstu, provedilac moze da ga ukloni. Drugi primer je link u tekstu.

Caslave, ovo sto si ti pokazao na primeru je sasvim ocigledan prsitup. I moj sistem za prevodjenje radi nesto slicno (to je u stvari Universal Language Tool for PHP i iako nema te mogucnosti prevodjenja po padezima i slicno, sasvim dobro radi posao. Ali to je zgodno za unapred poznat skup reci, i izraza koje treba prevesti.

Moj problem nije to, vec sto, na primer, mogu da imam celu knjigu, koja ima prilicno komplikovan sadrzaj iz ugla HTML koda a koji treba da se prevodi. Trpati svaki pasus ili celinu teksta koja se nalazi izmedju HTML kodova u automat za prevodjenje je neprakticno, prvo zato sto je to mnogo komplikovano napraviti, a drugo, zato sto bi drasticno trosilo resurse.

To je po prirodi statican sadrzaj, koji se na sajtu kao takav i skladisti. Dakle, ja imam za svaki dokument imamo posebnu datoteku za svaki jezik i tako i hocu da ostane. Jednostavno na osnovu izabranog jezika prikazem odgovarajucu datoteku sa staticnim sadrzajem.

Resenje, kako ga ja zamisljam, bi se sastojalo u tome da se iam alat koji iz zeljenog dokumenta (ili grupe dokumenata) izvuce sav tekstualni sadrzaj (bilo da je on oznacen, bilo da ga isparsira) i smesti u neki internfi format u kome bi se svaka jedinica teksta (a to bi bio svaki tekst koji se nalazi izmedju dva HTML tagova, ili u propretiju taga oznacila (nekim jedinstvenim brojem) i zabelezila.

Prevodilac bi dobio obicnu tekstualnu datoteku koja sdrzi sve tekstualne jedinice oznacene na odgovarajuci nacin tim jedinstvenim brojem. Tako prvodilac moze da radi u bilo kom tekst editoru, s tim sto mora da vodi racuna da ne narusi oznake (koje bi bile ocigledne) a pri tom uopste ne bi imao dodira sa HTML kodovima. Njegov se posao bi tako zaista sveo na to da prevede tekstove. Ako mu je potrebno da vidi kako tekst izglea u originalu (sto je sasvim cesto potrebno zbog konteksta prevodjenja) pogledao bi originalan HTML dokument u veb citacu.

Tako uradjene prevode bi bilo lako vratiti nazad u originalni HTML dokument prilikom kreiranja kopija prevedenih na druge jezike (moglo bi se cak upotrebitii za automatsko umetanje sadrzaja online, ako je to potrebno).

Posto bi baza tekstova sadrzavala celokupan izvorni tekst koji je preveden, lako bi se mogao napraviti mehanizam koji bi na zahtev proveravao da li je izvorni tekst u pocetnom HTML dokumentu menjan i izdvajao sve tekstove koje je potrebno usaglasiti i u prevodu.

Ako bi ovako nesto imali onda bi se azuriranje sadraja radilo na izvornom jeziku, alat bi lako prepoznao i izdvojio izmenjene tekstove koji treba da se dostave prevodiocima, a kada oni urade prevode tih tekstova, to bi se ugradjivalo u bazu i odatle bi se generisali prevedeni dokumenti.

Primeticete da je u ovom pristupu vrlo bitan element to sto je osnova prevodjenja izvorni HTML dokument (a ne recnik). Tako je omoguceno onome ko azurira dokument da ima punu slobodu da menja ne samo tekst, nego i sav ostali kod koji se nalazi u dokumentu.

[Тагови:]

Српски језик - Вокабулар форум
Srpski jezik - Vokabular forum > Наше писмо и рачунари > Преведени програми (Уредник: Филип Милетић) > Тема: Prevođenje - kako to tehnički izvesti