Localization/Concepts/PO Odyssey (sr)

Localization/Concepts/PO_Odyssey

Формат ПО

On Localization	Концепти
Prerequisites	Кодирање текста
Related Articles	ИксМЛ обележавање, Геттекстове алатке
External Reading	Упутство за Геттекст

Упошљавање превода

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

аутор спреми текстуални документ, рецимо, у Опенофисовом Писцу;

преводилац прибави тај документ и преведе га такође Писцем, пасус по пасус смењујући изворни текст преведеним;

корисник преведени документ добије на читање као ПДФ, који произведе Писац.

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

Претходни пример тицао се статичког превода, попут текстуалног документа или ХТМЛ стране. Док дати пример цевовода није био ваљан, чак и са одговарајућим излаз за крајњег корисника мора бити статички преведени документ, попут ПДФ фајла или друге ХТМЛ стране. Како се ово одсликава на преведено корисничко сучеље програма, где се у позадини извршава живи ко̑д? За почетак, може бити немаштовити и поћи статичким путем: програмер може држати све ниске текста у сучељу у текстуалном фајлу, који бива уграђен у извршни фајл програма при градњи инсталационог пакета. Пратећи исти неодговарајући цевовод, преводилац може превести тај текстуални фајл, смењујући ниску за ниску, после чега се изгради још један инсталациони пакет, овог пута локализован. Тако, као и у случају ПДФ‑ова где на крају мора постојати један по језику, овде би постојао један програмски пакет за сваки језик.

Међутим, главнина ПДФ фајла је чист текст, тако да готово да нема беспотребног умножавања језички независног садржаја. Насупрот томе, у просечном програму, попут менаџера фајлова или веб прегледача, преводиви текст је сићушан део укупне величине инсталационог пакета. То значи да би складиштење једног пакета по језику довело до огромног бацања дигиталног простора. Ако помислимо на ових дана уобичајену дистрибуцију оперативног система, ово би практично спречило да подразумевани инсталациони дискови долазе са икаквим другим до изворних енглеских пакета. Не треба рећи, статичко превођење програма тешко да је опција за слободан софтвер, којем је међународни досег један од главних циљева.

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

Сада се можемо вратити преводном цевоводу. Као што је изнето, без обзира на то да ли је превод статички (ПДФ фајлови, ХТМЛ стране) или динамички (сучеља програма), на концу постоји фајл пун текста на енглеском који треба превести. Зашто га је онда погрешно само отворити у Писцу (или К‑ворду, Абиворду, итд.) и превести пасус по пасус? Овакав приступ обезвређују два чиниоца:

Разнолики формати. Док чист текстуални документ, нпр. као ПДФ у крајњем облику, може бити „само текст“, ниске корисничког сучеља захтевају нешто додатних података како би их програми могли дохватати при извршавању. Ниске сучеља ће такође садржати разне посебне подниске, уз ограничења шта се с њима може учинити у преводу. Ови се аспекти још разликују између различитих програмских радних оквира (КДЕ, Гном, итд.), чиме се поставља питање овере преведеног текста — погрешан превод може покварити понашање програма.

Одржавање. Софтвер, било сами програми или њихова документација, временом еволуира прилагођавајући се потребама корисника. Ово значи да се и текст мења: додају се нове ниске сучеља и пасуси документације, неки стари се уклањају или преправљају. Ако би се преводило Писцем, када дође време да се превод ажурира, како би преводилац знао, рецимо, да је уметнут нови пасус између пасуса 128 и 129, а да је у пасусима 42 и 86 измењена по једна реченица?

Ради разрешавања ових проблема, слободан софтвер се умногоме кретао следећим путем: док се један формат преводних фајлова органски развијао, израђене су многобројне независне, али комплементарне алатке за превођење, оверу, одржавање и претварање овог формата из и у разне циљне формате. Тако, било да преводи корисничко сучеље (у различитим програмским радним оквирима), документацију, упутне стране, белешке о издању, садржај на Вебу, преводилац то може ефикасно чинити упознавши преводни цевовод око овог једног фајл формата.

Наступа формат ПО

Формат ПО се развија као формат преводних фајлова преводилачког система Геттекст, на који се данас ослања мноштво слободног софтвера. С обзиром на уводна разматрања о преводним цевоводима, корисно је објаснити шта се тачно подразумева под ослања. Три су истакнута начина употребе формата ПО:

Посредни статички преводи. Статички текст, попут документације софтвера, претвара се из свог изворног формата у ПО, преводи, па претвара назад у првобитни формат. Из тога се граде коначни документи за корисничку потрошњу, као што су ПДФ фајлови или ХТМЛ стране.

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

Самосвојни динамички преводи. Коначно, многи програми користе ПО као самосвојни формат за ниске корисничког сучеља, тако да никакво претварање није потребно. У ове спадају окружења радне површи КДЕ и Гном, Гнуове алатке, итд. Да би се могли користити у раду, преведени ПО фајлови само се компилују у бинарне МО фајлове.

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

Развој формата ПО био је, и још увек је подстицан искључиво потребама његових корисника, како оне временом бивају јасно формулисане и уопштене; отуда ранија оцена о „органском развитку“. Захваљујући овоме, могућности формата изнад најосновнијих могу се постепено уводити где су потребне, а не бити на сметњи када нису. Формат је врло сажет, читак, и може се уређивати без наменских алатки (мада су, наравно, оне од користи). Ови аспекти погодују кривуљи учења, свакодневној употреби и показним текстовима попут овог.

Иако ће преводиоци често радије радити на ПО фајловима помоћу наменских преводних уређивача, који теже да сакрију „техничке детаље“ попут подложног фајл формата, свеједно би требало да врло добро разумеју формат ПО. Ово стога што је ПО више од простог садржаоца текста за превод, већ, у светлу начина на који се развија, одсликава важне концепте у преводном цевоводу. Или, конкретније речено, преводилац треба да зна како дати наменски ПО уређивач представља разноврсне податке које пружа формат ПО.

Основе формата

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

Без даљег одлагања, ево исечка из средине једног ПО фајла, који показује три најосновније поруке, непреведене:

finddialog.cpp:38

msgid "Globular Clusters"
msgstr ""
⁠

finddialog.cpp:39

msgid "Gaseous Nebulae"
msgstr ""
⁠

finddialog.cpp:40

msgid "Planetary Nebulae" msgstr ""

Свака порука садржи кључну реч msgid, праћену текстом на енглеском, омотаном двоструким наводницима. Кључна реч msgstr означава ниску која треба да је превод енглеске, такође под наводницима. Тако, пошто сте прошли кроз ПО фајл додајући преводе, дате поруке би гласиле:

finddialog.cpp:38

msgid "Globular Clusters"
msgstr "Глобуларна јата"
⁠

finddialog.cpp:39

msgid "Gaseous Nebulae"
msgstr "Гасне маглине"
⁠

finddialog.cpp:40

msgid "Planetary Nebulae" msgstr "Планетарне маглине"

Није исувише компликовано, зар не?

Као и обично с текстуалним форматима, одмах се мора рећи нешто о кодирању ПО фајла: иако бисте могли користити неко кодирање уместо УТФ‑8 када изворни текст не садржи не-аски знакове, заиста би требало да користите УТФ‑8 (КДЕ то чак захтева). Кодирање се задаје и унутар ПО фајла, и подразумевано је УТФ‑8; ако желите неко друго, поред тога што ћете фајл сачувати у њему, морате га навести у ПО заглављу.

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

Упућивачи на извор

Свака порука изнад такође носи коментар упућивача на извор, што је ред који почиње са #:. Он говори из којег је изворног фајла програма (или извора друге врсте), и којег тачно реда у њему, порука издвојена у ПО фајл. Овај податак може испрва деловати чудно — од какве је користи преводиоцима, да заслужује укључивање у ПО фајл? Пошто је формат ПО развијен за локализацију слободног софтвера, упућивач на извор омогућава вам да заиста погледате поруку у изворном фајлу, када вам треба више контекста да је правилно преведете. Ово не захтева да будете и сами програмер, пошто је изворни ко̑д неретко довољно читљив да можете закључити о контексту поруке без стварног разумевања ко̑да. На пример, у неким језицима обично је писати текст у служби наслова у именичком облику, а из самог ПО фајла не мора бити очигледно да је порука:

addcatdialog.cpp:45

msgid "Import Catalog" msgstr ""

од такве врсте. Међутим, ако испратите упућивач на извор, видећете овакав исказ у фајлу addcatdialog.cpp, ред 45:

setCaption( i18n( "Import Catalog" ) );

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

Преламање ниски

Када је порука дугачка или садржи неке логичке преломе реда, њене изворне и преведене ниске могу бити преломљене у ПО фајлу (обично с границом на колони 80), на пример:

indimenu.cpp:96

msgid "" "No INDI devices currently running. To run devices, please select devices " "from the Device Manager in the devices menu." msgstr ""

Овакво преламање потпуно је небитно у окружењу где се порука користи, било да је то корисничко сучеље програма, документација, или шта друго. Алатке за обраду ПО‑а производе преломе понајвише као погодност за преводиоце који воле да раде на ПО фајловима у обичним уређивачима текста. Ово значи да сте слободни да преламате превод (ниску msgstr) на исти начин, другачије, или да је не преламате уопште — резултат ће бити исти. Само не треба заборавити сваки наредни преломљени ред омотати двоструким наводницима, као што је то и са msgid. На пример, овај превод претходне поруке:

indimenu.cpp:96

msgid "" "No INDI devices (...)" "(...) in the devices menu." msgstr "" "Нема ИНДИ уређаја (...)" "(...) у менију уређаја."

потпуно је еквивалентан овоме:

indimenu.cpp:96

msgid "" "No INDI devices (...)" "(...) in the devices menu." msgstr "Нема ИНДИ уређаја (...) у менију уређаја."

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

Јединственост порука

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

Прва последица овакве одређености је да се порука може поуздано „пријавити“ искључиво навођењем њене ниске msgid у целости, чак и када особа којој пријављујете има приступ ПО фајлу из којег је порука. (На поруку можете желети да укажете када се саветујете са преводиоцима сарадницима, или када пријављујете ауторима погрешку у куцању или неки други проблем у изворном тексту.) Преводиоцима новајлијама понекад не буде указано на ово, па испрва пријављују број реда поруке, или њен редни број у опсегу свих порука, а да не наведу msgid. Бројеви редова не раде, на пример, због претходно поменутог прелома ниски, које је произвољно од једног до другог преводиоца. Редни бројеви нису од користи јер ваш ПО фајл може бити нешто старији или новији од оног вашег саговорника, а у међувремену је дошло до њихове прерасподеле.

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

colorscheme.cpp:79 skycomponents/equator.cpp:31

msgid "Equator" msgstr ""

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

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

Контекст порука

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

Један смо већ видели: завиривањем у изворни фајл поруке, на који указује упућивач на извор. Али ово може бити заморно. Не само да преводиоцу неупућеном у програмирање изворни ко̑д може деловати претеће, већ и зато што, иако слободно доступан, може бити неудобно скупљати сав тај ко̑д около само ради потрага за контекстом. Ово је добро позната потешкоћа, због чега су осмишљени предусретљивији показивачи контекста.

Један једноставан начин да пратите контекст јесте да, док преводите текућу поруку, имате пред очима неколико порука пре и после ње. Као тривијалан пример, следеће четири поруке:

locationdialog.cpp:228

msgid "Really override original data for this city?"
msgstr ""
⁠

locationdialog.cpp:229

msgid "Override Existing Data?"
msgstr ""
⁠

locationdialog.cpp:229

msgid "Override Data"
msgstr ""
⁠

locationdialog.cpp:229

msgid "Do Not Override" msgstr ""

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

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

Издвојени коментари

Једно место где поруке носе изричити контекст, који дају аутори, јесте унутар издвојених коментара, оних који почињу са #.. На пример, порука:

. i18n: A classical test phrase, with all letters of the English alphabet.
. Replace it with a sample text in your language, such that it is
. representative of language's writing system.
kdeui/fonts/kfontchooser.cpp:382

msgid "The Quick Brown Fox Jumps Over The Lazy Dog" msgstr ""

има издвојени коментар који говори да енглеску фразу не треба превести такву каква је, већ уместо ње унети фразу са наведеним својствима у вашем језику.

Ова врста контекста обично почиње договореном кључном речи. У горњем случају то је i18n: (скраћено од енгл. internationalization), типична за КДЕ, али у принципу зависи од окружења. У многим другим окружењима (нпр. Гному) кључна реч је непосредније TRANSLATORS:, која је и подразумевана за преводилачки систем Геттекст (под чијим окриљем се одржава формат ПО).

Издвојене коментаре понекад могу додавати не аутори-људи, већ алатке којима се ПО фајлови праве или обрађују. На пример, када се преводе документи са обележеним текстом, попут ХТМЛ‑а, или докбука за документацију, издвојени коментар често даје ознаку којом је омотан текст у изворном документу:

. Tag: title
skycoords.docbook:73

msgid "The Horizontal Coordinate System" msgstr ""

У горњем примеру, коментаром #. Tag: title обавештени сте да је порука наслов, и можете томе прилагодити превод.

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

. i18n: file: tools/observinglist.ui:263
. i18n: ectx: property (toolTip), widget (KPushButton, ScopeButton)
rc.cpp:5865

msgid "Point telescope at highlighted object" msgstr ""

Овде је rc.cpp:5865 лажни привремени извор, док је прави изворни фајл дата као file: tools/observinglist.ui:263. (Аутоматски издвојен коментар ectx: ... може деловати помало ко̑дно-криптично, али и поред тога лако можете погодити да је ова порука облачић на неком дугмету.)

Разликујући контексти

Размотрите наредне две поруке из корисничког сучеља програма:

. i18n: First letter in 'Scope'
tools/observinglist.cpp:700

msgid "S"
msgstr ""
⁠

i18n: South
skycomponents/horizoncomponent.cpp:429

msgid "S" msgstr ""

На први поглед, могли бисте рећи да је лепо од програмера што је додао изричите контексте (редови #. i18n: ...), указујући да је S прве поруке скраћено од Scope, а друге скраћено од South, тако да су преводиоци обавештени да треба да употребе слова која у њиховим језицима одговарају овим речима. Али, запажате ли проблем? Проблем је у томе што ове поруке не могу бити део ваљаног ПО фајла, јер, као што смо рекли, све поруке имају јединствене ниске msgid. Уместо тога, у стварном ПО фајлу ове две поруке би биле сажете у једну:

. i18n: First letter in 'Scope'
. i18n: South
tools/observinglist.cpp:700 skycomponents/horizoncomponent.cpp:429

msgid "S" msgstr ""

Оба контекста су и даље ту, преводиоци су још увек добро обавештени, али је сада неопходно да речи Scope и South почињу истим словом и у циљном језику — што је нимало извесно.

У оваквим случајевима, програмер може порукама одредити другачији тип контекста, познат као разликујући контекст. Ови контексти се не дају у издвојеном коментару, већ помоћу пуноправне кључне речи, msgctxt:

. i18n: First letter in 'Scope'
tools/observinglist.cpp:700

msgid "S"
msgstr ""
⁠

i18n: South
skycomponents/horizoncomponent.cpp:429

msgid "S" msgstr ""

Ово је сада ваљан ПО фајл, и можете свако S правилно превести. Овим допуњујемо апроксимацију од раније да поруке морају бити јединствене по нискама msgid: заправо морају бити јединствене по збиру ниски msgctxt и msgid. Ако ниска msgctxt недостаје, како најчешће и јесте, можете замислити да је присутна али празна.

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

utils/kateautoindent.cpp:78 utils/katestyletreewidget.cpp:132

msgid "Normal" msgstr ""

У многим језицима облик придева прати по роду именицу уз коју стоји, тако да ако се Normal изнад односи нпр. на режим увлачења и стил текста, готов сигурно је неопходно опремити поруке разликујућим контекстима:

utils/katestyletreewidget.cpp:132

msgctxt "Text style"
msgid "Normal"
msgstr "обичан"
⁠

utils/kateautoindent.cpp:78

msgctxt "Autoindent mode" msgid "Normal" msgstr "обично"

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

У тренутку када је ово писано, кључна реч msgctxt релативно је свеж додатак формату ПО. Али је потреба за разликујућим контекстима запажена много раније, због чега су различита преводилачка окружења историјски користила различита посебна решења да их омогуће. Такви старији ПО фајлови још увек се могу наћи у великом мноштву, те има смисла дати неколико примера посебних контекста. Пошто су пре увођења кључне речи msgctxt поруке заиста морале да буду јединствене по msgid, контексти су морали постати део саме msgid, угњеждени уз нешто специјалне синтаксе. Ако узмемо прву поруку из претходног примера, ево како би она изгледала у ПО фајлу КДЕ‑а 3:

utils/katestyletreewidget.cpp:132

msgid "" "_⁠: Text style\n" "Normal" msgstr "обичан"

Разликујући контекст је угњежден на почетку msgid, омотан у _⁠: ...\n (сама ниска msgid преломљена је у два реда зато што ПО алатке преламају ниске код \n без обзира на укупну дужину; више о овом специјалном низу знакова касније). У Гному, иста порука би изгледала овако:

utils/gatestyletreewidget.c:132

msgid "Text style|Normal" msgstr "обичан"

Овде је контекст поново на почетку msgid, али раздвојен од стварног текста само знаком цевке, |.

Преводилачки коментари

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

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

У оваквим ситуацијама можете записати подсетнике, недоумице, закључке о контексту, итд. у још једном типу коментара, преводилачком коментару. Ови коментари почињу једноставно са # (тараба и размак), праћеним каквим год текстом желите; као и других коментара, и ових може бити више од једног. Хипотетички пример:

Википедија каже да је ‘етрурски’ наше име за ово писмо.
viewpart/UnicodeBlocks.h:151

msgid "Old Italic" msgstr "етрурски"

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

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

Конструктивне подниске

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

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

Форматске директиве

Када менаџер фајлова покаже поруку попут Заиста обрисати фајл tmp10.txt? или Отвори К‑писањем, делови ‘tmp10.txt’ и ‘К‑писањем’ свакако су морали бити уметнути у целину поруке при извршавању. У таквим случајевима, изворни текст који види преводилац садржаће форматске директиве, подниске које програм смењује одговарајућим аргументима како би конструисао поруку коју показује кориснику. На пример:

skycomponents/constellationlines.cpp:106
, kde-format

msgid "No star named %1 found." msgstr "Нема звезде по имену %1."

Форматска директива у овој поруци је %1 — програм ће је при извршавању заменити аргументом који (вероватно) зада корисник као име које треба потражити. Форматске директиве облика %<број> типичне су за КДЕ програме. Појавио се и нови тип коментара, коментар заставица. Почиње са #,, за чим следи зарезима раздвојен списак кључних речи, или заставица, које појашњавају стање или тип поруке. У овом примеру заставица је kde-format, потврђујући да су све форматске директиве у поруци КДЕ‑овог типа.

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

skycomponents/constellationlines.cpp:106
, c-format

msgid "No star named %s found." msgstr "Нема звезде по имену %s."

Форматска директива је постала %s, а заставица формата c-format. Ово је формат који користи највећи део програма писаних на Ц‑у, и многи на Ц++у. (У Ц формату, директива %s означава смену ниски као аргумената, а друга честа директива је %d за целе бројеве; али их има још мноштво. Између знака процента и слова могу се наћи и бројеви и нешто интерпункције, нпр. %03d.)

Покажимо још један пример ради илустровања разноликости форматских директива. Да је програм написан на питону, порука би била:

skycomponents/constellationlines.cpp:106
, python-format

msgid "No star named %(starname)s found." msgstr "Нема звезде по имену %(starname)s."

Овде је форматска директива %(starname)s, наводећи тип аргумента као у Ц формату (%s), али и његово име у заградама. Стога заставица python-format. Име аргумента не смете изменити у преводу, јер тада програм неће моћи да га пронађе и смени — што ће вероватно довести до пада програма када покуша да употреби поруку.

Обично морате обезбедити да се свака директива из изворне ниске појави у преводу, а врло ретко да мењате саме директиве. Форматске заставице, попут kde-format, c-format, итд., нису дате само као податак за преводиоце, већ их користе и алатке за проверу ПО фајлова. На пример, ако заборавите или погрешно откуцате директиву у преводу, такве алатке ће то пријавити. Наменски ПО уређивачи могу издавати упозорења на лицу места, или при записивању фајла. Ово вам пружа „сигурносну мрежу“, докле год не заборавите да извршите провере пошто довршите превођење (ако уређивач то већ не ради аутоматски).

Један случај који може захтевати измену директива је када их има неколико, и треба их различито поређати у преводу:

kxsldbgpart/libxsldbg/xsldbg.cpp:256
, kde-format

msgid "%1 took %2 ms to complete." msgstr "Требало је %2 ms да се %1 заврши."

Уз КДЕ‑ове форматске директиве, које су нумерисане, промена редоследа је једноставна као изнад. Слично је и са поменутим питонским форматом, где су директиве именоване. Али у форматима где директиве подразумевано нису ни нумерисане ни именоване, као у Ц формату (где наводе само тип аргумента), понекад их можете изменити ради жељеног ефекта:

gxsldbgpart/libxsldbg/xsldbg.c:256
, c-format

msgid "%s took %d ms to complete." msgstr "Требало је %2$d ms да се %1$s заврши."

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

hypothetical.cpp:100
, kde-format

msgid "%1 is the blah, blah, blah. With %1 you can blah, blah." msgstr "%1 је бла, бла, бла. Помоћу њега можете бла, бла."

где је њега употребљено уместо поновљене %1. Обрнуто, могуће је поновити директиву ако боље пристаје тамо где у енглеском извору стоји заменица.

Понекад се догоди да програмер не употреби директиву да смени аргумент, већ уместо тога надовезује цео текст из исецканих порука:

hypothetical.cpp:100

msgid "No star named "
msgstr ""
⁠

hypothetical.cpp:100

msgid " found." msgstr ""

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

Обележавање текста

Програми понекад приказују делове текста другачије него обично: неке речи могу бити у курзиву или подебљане, наслови с већим фонтом, спискови с уводним тачкама, итд. Ово се често јавља, на пример, у текстовима „Шта је ово?“ и дијалозима за поруке. Још богатији типографски елементи овог типа обично се сусрећу у документацији и другом статичком садржају, где крајњи излаз треба да буде пригодан за штампање и дуже читање. На страни преводиоца, такав изворни текст садржаће обележавање, где су речи, изрази и цели пасуси омотани посебним ознакама.

Следеће поруке су типични примерци обележавања у корисничком сучељу програма:

rc.cpp:1632 rc.cpp:3283

msgid "Name:"
msgstr ""
⁠

kgeography.cpp:375
, kde-format

msgid "<qt>Current map:
%1</qt>"
msgstr ""
⁠

rc.cpp:2537 rc.cpp:4188

msgid "" "Tip Some non-Meade telescopes support a subset of the LX200 " "command set. Select LX200 Basic to control such devices." msgstr ""

Обележавање у овим порукама је ИксМЛ-олико, где ознаке за визуелно форматирање омотавају видљиве делове текста као <ознака>...</ознака>. На пример, <b>...</b> говори да унутрашњи текст треба приказати подебљано, <tt>...</tt> задаје употребу једноширинског фонта, а самостално <br/> уводи прелом реда (читаоци који знају нешто ХТМЛ‑а одмах ће препознати ове ознаке).

Још једно често ИксМЛ обележавање сусреће се у ПО‑овима документације, која се у КДЕ‑у (као и Гному и многим другим окружењима) углавном пише у формату докбук:

. Tag: title
blackbody.docbook:13

msgid "<title>Blackbody Radiation</title>"
msgstr ""
⁠

. Tag: para
geocoords.docbook:28

msgid "" "The Equator is obviously an important part of this coordinate system; " "it represents the <emphasis>zeropoint</emphasis> of the latitude angle, " "and the halfway point between the poles. The Equator is the " "<firstterm>Fundamental Plane</firstterm> of the geographic coordinate " "system. <link linkend='ai-skycoords'>All Spherical</link> Coordinate " "Systems define such a Fundamental Plane." msgstr ""

Докбук ознаке именоване су нешто другачије од ХТМЛ-оликих претходно виђених у сучељима програма, тако што наводе значење дела текста који омотавају пре него визуелну појаву (тзв. семантичко обележавање). Ова разлика вама као преводиоцу није толико битна, осим што вам дата значења понекад могу помоћи у разрешавању контекста. Докбук ознаке некад ће садржати и један или више атрибута у отварајућој ознаци, попут горњег <link linkend=...> (овога може бити с неким ХТМЛ ознакама).

Када преводите обележени текст, требало би, у општем случају, да пренесете исти скуп ознака у превод, додељујући их одговарајућим деловима преведеног текста. Ознаке саме нипошто се не смеју преводити (нпр. <title> или <emphasis>), јер их обрађује аутомат за израђивање коначног форматираног текста. Што се тиче атрибута ознака (linkend='ai-skycoords' у примеру изнад), њихова имена се такође никад не преводе, али у ретким случајевима могу им бити преведене вредности под наводницима (обично када је вредност очигледно текст намењен кориснику).

Међутим, овим не желимо да кажемо да никада не треба да мењате обележавање. Посебно код ХТМЛ-оликих ознака, не тако ретко обележавање у изворном тексту биће понешто немарно (нпр. недостатак затварајућих ознака), што сте слободни да исправите у преводу. Још један пример би били ЦЈК језици (кинески-јапански-корејски), у којима је подебљан текст тежак за читање, па њихови преводиоци теже да смењују ознаку <b> наводницима. Уопштено говорећи, што сте упознатији са одређеним обележавањем, то можете ићи даље од његовог простог копирања из изворног текста.

У ПО‑овима програмских сучеља, врло често се могу срести делови изворног текста који понешто сличе ИксМЛ обележавању, на пример:

utils/katecmds.cpp:180
, kde-format

msgid "Missing argument. Usage: %1 <value>" msgstr ""

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

Понекад се при превођењу наилази и на обележавања која нису налик на ИксМЛ. Једно би било вики обележавање, којим је написан сам овај чланак:

poformat.txt:191

msgid "=== Издвојени коментари ==="
msgstr ""
⁠

poformat.txt:193

msgid "" "One place where messages store explicit context provided by the " "authors is within extracted comments, those which (...)" msgstr ""

где је ===...=== приближно ХТМЛ‑овом <h2>...<h2>, док је ''...'' парњак са <i>...<i>. Још један тип обележавања је изворни језик упутних страна, роф:

type: Plain text
../../doc/man/wesnoth.6:55

msgid "" "compresses a savefile (B<infile>) that is in text WML format into " "binary WML format (B<outfile>)." msgstr ""

где је B<...> еквивалент ХТМЛ‑овом <b>...<b>.

Када сте суочени са новом врстом обележавања, с којим до тада још нисте радили, неизоставно би требало да прелетите кроз један или два туторијала о њему. ИксМЛ-олика обележавања која се користе у КДЕ‑у обрађена су засебним чланком, који их излаже са становишта преводилаца.

Избегавачки низови

Постоји неколико посебних знакова који се не могу дословно јавити у пољима msgid и msgstr. Пре свега, помислите на обичан двоструки наводник ("): пошто се користи за издвајање ниски поља, сирови двоструки наводник унутар текста прерано би окончао ниску, искваривши синтаксу поруке. Такви знакови се зато записују избегавачким низовима, комбинацијама контракроз (обрнуте косе црте) и другог знака, које се интерпретирају као одговарајући једноструки знакови када се текст приказује кориснику. Обични двоструки наводник пише се као \":

kstars_i18n.cpp:3591

msgid "The \"face\" on Mars" msgstr "\"Лице\" на Марсу"

Још један чест избегнути знак је нови ред, представљен као \n:

kstarsinit.cpp:699

msgid "" "The initial position is below the horizon.\n" "Would you like to reset to the default position?" msgstr "" "Почетни положај је испод хоризонта.\n" "Желите ли да вратите на подразумевани?"

Већина ПО алатки безусловно прелама текст на новим редовима, игноришући задату колону прелом, па чак и када је преламање искључено. Тако се поступа ради боље читљивости при уређивању ПО фајла. Ако текст није састављен од обележавања (нпр. није ХТМЛ или докбук), нови редови су значајни и на страни корисника, па их треба верно пренети у преводу; за значај нових редова у обележеном тексту, погледајте чланак о обележавању. Уопштено, осим ако сте сигурни да нове редове можете преуредити на одређени начин, требало би да испратите оно што даје msgid.

Још два избегавачка низа, обично много ређа него двоструки наводник и нови ред, јесу табулатор \t и само контракроз \\ (јер једноструко контракроз увек започиње избегавачки низ). Постоје још неки низови, али су њихове појаве изузетно ретке.

Што се тиче двоструких наводника, имајте још на уму да док енглески извор обично користи обичне аски наводнике, преводи често користе „помодне“ наводнике, сагласне ортографији језика:

kstars_i18n.cpp:3591

msgid "The \"face\" on Mars" msgstr "„Лице“ на Марсу"

Ово важи и за двоструке и за једноструке наводнике. У српском су то најчешће парови „“ и ‘’, и увек их треба користити уместо аски наводника.

Убрзивачи

У сучељима програма, кратки текстови на виџетима којима се извршавају радње или отварају дијалози често садрже једно подвучено слово. Ово указује да када корисник притисне тастер алт и подвучено слово, активираће се одговарајућа радња. Таква слова се називају убрзивачима, а у преводу се обично задају тако што им претходи посебан знак за ту сврху, обележивач убрзивача:

kstarsinit.cpp:163

msgid "Set Focus &Manually..." msgstr "Задај фокус &ручно..."

У КДЕ‑у обележивач убрзивача је амперсенд (&). Тако је у поруци изнад убрзивач задат на енглеском као слово ‘M’, а у преводу као слово ‘р’. Обележивачи убрзивача обично се разликују кроз окружења, нпр. у Гному се користи подвлака (_), у Опенофису тилда (~), итд.

Бирање убрзивача у преводу (тј. где се ставља обележивач) може бити незгодан посао, јер лако можете доћи у ситуацију да у истом контексту сучеља (нпр. у оквиру истог менија) две ставке носе исти убрзивач. Ово неће довести ни до чега исувише лошег, нпр. програм може аутоматски прерасподелити сукобљене убрзиваче, или ће корисник морати да притисне алт+слово неколико пута док дође до жељене ставке. Ипак, сукобљени убрзивачи нису леп призор, али нема начина да их без проблема избегнете; једино можете покушати да пратите контекст у ПО фајлу, и да проверавате уживо у програмима. Ово заправо није проблем само у преводу, већ ће неретко и енглески извор садржати сукобљене убрзиваче!

ЦЈК језици користе методе уноса различите од оних за алфабете (распореда тастатуре), тако да уместо да додељују идеограм за убрзивач, додају једно енглеско слово у ту сврху:

kstarsinit.cpp:163

msgid "Set Focus &Manually..." msgstr "フォーカスを手動でセット(&M)..."

Ово слово се обично бира да буде исто као у извору, сводећи тиме могућност сукоба убрзивача на онолико колико су сами програмери успели да их избегну.

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

Пошто обележивач убрзивача углавном није баш тако ретко коришћени знак, може се јавити у контекстима у којима не обележава убрзивач. На пример:

kspopupmenu.cpp:203

msgid "Center && Track"
msgstr ""
⁠

. Tag: phrase
config.docbook:137

msgid "<phrase>Configure &kstars; Window</phrase>" msgstr ""

У првој горњој поруци, обележивач је употребљен да избегне самог себе, тј. да произведе дословни амперсенд на излазу (слично као са избегавачким низовима где се двоструким контракроз представља једно дословно контракроз). У другој поруци, амперсенд је употребљен за уметање ИксМЛ ентитета &kstars;, о којима више можете сазнати у чланку о обележавању. Да знак није употребљен као обележивач убрзивача може се закључити само по контексту, али пошто стекнете мало искуства, та разлика ће вам готово увек бити очигледна.

Облици множине

Програми често треба да известе корисника о броју објеката у неком контексту: „Нађено 10 фајлова“, „Желите ли заиста да обришете 5 порука?“, итд. Наравно, на енглеском би овакве поруке имале парњаке у једнини, као „Нађен 1 фајл“, „...обришете 1 поруку?“. Ово значи да су неопходна два засебна енглеска текста у ПО фајлу, један који покрива случај једнине, а други множине. Могли бисте претпоставити да ће то онда бити две поруке, као у овом хипотетичком примеру:

hypothetical.cpp:100
, kde-format

msgid "Time: %1 second"
msgstr ""
⁠

hypothetical.cpp:101
, kde-format

msgid "Time: %1 seconds" msgstr ""

где програм дохвати прву поруку када је број објеката 1, а другу поруку за било који други број.

Међутим, док ово ради за још неке језике поред енглеског (нпр. шпански, немачки, француски...), не ради за све језике. Разлог је тај што док енглеском треба један текст за јединицу, а други за било који други број, у многим другим језицима је то сложеније — укључујући и српски. У српском, на пример, облик једнине користи се за све бројеве који се завршавају на 1 а не завршавају се на 11, тако да би програм грешио ако би узимао облик једнине само за тачно 1. Даље, уместо два, у српском су потребна чак четири облика множине: један претходно поменути, други за све који се завршавају на 2, 3, 4 а не на 12, 13, 14, трећи за све остале, и четврти за тачно 1 (видећемо ниже зашто је поред првог потребан и овај четврти).

Како би савладао ову разноликост, формат ПО изводи множинске поруке. Претходни пример би у стварности изгледао овако:

mainwindow.cpp:127
, kde-format

msgid "Time: %1 second" msgid_plural "Time: %1 seconds" msgstr[0] "" msgstr[1] ""

Енглески облик једнине дат је пољем msgid, док је облик множине дат пољем msgid_plural. Сада постоји неколико поља msgstr, индексирана у угластим заградама почев од нуле, тако да се може додати онолико превода колико постоји облика множине у циљном језику. Подразумевано су дата два поља msgstr, али се ред са трећим (индекса 2) може просто уметнути, и тако даље. На пример, превод на шпански, који има исте облике множине као енглески, гласио би:

mainwindow.cpp:127
, kde-format

msgid "Time: %1 second" msgid_plural "Time: %1 seconds" msgstr[0] "Tiempo: %1 segundo" msgstr[1] "Tiempo: %1 segundos"

док српски превод, са своја четири облика (у овом случају четврти исти као први) изгледа овако:

mainwindow.cpp:127
, kde-format

msgid "Time: %1 second" msgid_plural "Time: %1 seconds" msgstr[0] "Време: %1 секунда" msgstr[1] "Време: %1 секунде" msgstr[2] "Време: %1 секунди" msgstr[3] "Време: %1 секунда"

Али, како ће програм знати који облик одговара ком броју? Одредница овога записује се у сам ПО фајл, у заглавље (више о ПО заглављу касније); састоји се од броја облика који ће имати свака множинска порука у ПО фајлу, и израчунљивог логичког израза, који за сваки унети број рачуна индекс потребног облика множине. Овај израз изгледа прилично криптично, али га не морате заиста разумети како ради. Пошто је константан за један дати језик, израз за српски који увек можете користити дат је испод, а већ смо видели који облик (по индексу msgstr) одговара ком случају српске множине. Ради потпуности, ево прво одреднице множине за шпански:

nplurals=2; plural=(n != 1);

и коначно доста сложеније одреднице за српски:

nplurals=4; plural=(n==1 ? 3 : n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);

Вредност nplurals говори колико има облика множине, а plural је израз који рачун индекс поља msgstr за дати број n (ако вам је синтакса блиска, то је зато што знате нешто Ц‑а).

Понекад ћете наићи на поруку, или пар порука, која је баш као у првом, хипотетичком примеру изнад — с бројем у себи, а да притом није множинска, иако јасно видите да би требало да буде. У већини окружења данас (нпр. у КДЕ‑у или Гному), ово једноставно значи да је програмер заборавио да употреби множинску поруку. Пошто се ово сматра грешком, требало би да обавестите ауторе да смене обичну поруку множинском. У неким окружењима, међутим, програми не умеју да рукују множинама, и то углавном где се ПО користи као посредни формат (нпр. у Опенофису). Ако је то случај, једино вам остаје да поруку преведете „најмање лоше“.

У доба када је КДЕ уводио множинске поруке, изложена самосвојна подршка формата ПО за њих била је прилично свежа. Зато су, слично као са разликујућим контекстима, у КДЕ‑у 3 множинске поруке биле угњеждене у обичне. Пошто вам још увек може запасти неки залутали ПО фајл из КДЕ‑а 3, ево како би претходна порука изгледала у њему:

mainwindow.cpp:127

msgid "" "_n: Time: %n second\n" "Time: %n seconds" msgstr "" "Време: %n секунда\n" "Време: %n секунде\n" "Време: %n секунди"

Почетно _n: у msgid одређује поруку као множинску, а облици множине дати су раздвојени новим редовима, и у извору и у преводу. Уместо обичног нумерисаног местодржача, за број се користи посебан местодржач %n. Одредница множине, уместо у заглављу сваког ПО фајла, била је укодирана директно у библиотеке КДЕ‑а и непроменљива. Због тога се није могао задати четврти српски облик множине, онај за број тачно 1, чија намена следи.

Изостављање броја

Врло често ће енглески облик једнине изостављати број, односно, само ће облик множине садржати форматску директиву за број:

modes/typesdialog.cpp:425
, kde-format

msgid "Are you sure you want to delete this type?" msgid_plural "Are you sure you want to delete these %1 types?" msgstr[0] "Желите ли заиста да обришете овај %1 тип?" msgstr[1] "Желите ли заиста да обришете ова %1 типа?" msgstr[2] "Желите ли заиста да обришете ових %1 типова?" msgstr[3] "Желите ли заиста да обришете овај тип?"

Зависи од окружења да ли је дозвољено изоставити број на овај начин. На пример, у КДЕ програмима (заставица kde-format) ово је увек могуће, тако је и у Гному (c-format), али не и у чистом КуТ‑у (qt-format). У преводу, ако окружење подржава изостављање, број можете изоставити или задржати у једнини без према томе шта је стилски боље, а без обзира на то да ли је изостављен или не у извору. Прецизније, број можете изоставити у сваком облику који се користи за тачно један број. Обрнуто, ако се сви облици користе за више од једног броја (нпр. облик „једнине“ који се користи за све бројеве који се завршавају на 1), онда број не можете уопште изоставити. Сада је јасно чему служи четврти облик у српском — када је, као у овом примеру, стилски природно изоставити број 1 (у КДЕ‑у 3 ово није било могуће, јер су постојала само три облика за српски).

У ретким приликама множинска порука неће имати број ни у енглеској једнини ни у множини, онда када је програмер хтео да изабере тек између облика за „један“ и „неколико“. Ово је сасвим ваљана порука:

kgpg.cpp:498

msgid "Decryption of this file failed:" msgid_plural "Decryption of these files failed:" msgstr[0] "Дешифровање фајлова није успело:" msgstr[1] "Дешифровање фајлова није успело:" msgstr[2] "Дешифровање фајлова није успело:" msgstr[3] "Дешифровање фајла није успело:"

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

У старим угњежденим множинама у ПО фајловима КДЕ‑а 3, местодржач %n може бити изостављен по истим правилима.

Стапање са шаблонима

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

Овоме се приступа на следећи начин. С једне стране, ту је ваша последња преведена верзија ПО фајла. С друге стране, ту је последњи нетакнути ПО, са непреведеним порукама које одсликавају тренутно стање извора. Нетакнути ПО фајлови заправо се зову шаблонима, и имају наставак .pot, за разлику од наставка .po преведених ПО‑ова. Преведени ПО фајл и шаблон затим се стопе на посебан начин, дајући нови, делимично преведени ПО у којем можете допунити превод. Техникалије стапања нису тако битне испрва, пошто ћете у сваком утврђеном преводилачком пројекту моћи просто да дохватите најновије стопљене ПО фајлове; важније је шта можете очекивати да видите у једном таквом.

У општем случају, стопљени ПО фајлови садрже три категорије порука. Прва су оне поруке које су биле присутне у ПО фајлу када сте последњи пут на њему радили, у смислу да није дошло до промена поља msgctxt и msgid. Као што бисте очекивали, њихови преводи (поља msgstr) и даље су каквим сте их оставили, па с оваквим порукама нема шта ново да се ради. Друга категорија су потпуно нове поруке, у међувремену додате у извору, које вам следе да их преведете. Притом, нове поруке неће бити додате произвољно, на пример тек надовезане на крај ПО фајла. Уместо тога ће бити смешане са преведеним порукама, тако да се испоштује редослед јављања порука у текућем извору. Ово вам омогућава да закључујете о контексту нових порука на основу претходних и наредних, баш као што сте могли и при превођењу ПО фајла од нуле. На пример:

fitshistogram.cpp:347

msgid "Auto Scale"
msgstr ""
⁠

fitshistogram.cpp:350

msgid "Linear Scale"
msgstr "линеарна скала"
⁠

fitshistogram.cpp:353

msgid "Logarithmic Scale" msgstr "логаритамска скала"

Прва порука је нова, непреведена, а друге две старе, раније преведене. Из те две можете закључити да нова порука пружа још један избор различитих скала (може бити за осе графика), а да није, рецимо, наредба или опција за измену величине нечега, као у „скалирај аутоматски“.

Мутне поруке

Најзанимљивија, међутим, јесте трећа категорија порука у стопљеном ПО фајлу. То су старе поруке које су у међувремену понешто измењене, тј. дошло је до промена у једном или оба поља msgctxt и msgid. Или, може ово бити и нова порука која довољно сличи некој од старијих. Заправо се ова два случаја не могу раздвајати, пошто се нова или измењена порука сврстава у ову категорију једино по сличности са неком од раније преведених порука. Како год било, таква порука назива се мутном, и изгледа овако:

src/somwidget_impl.cpp:120
, fuzzy
| msgid "Elements with boiling point around this temperature:"

msgid "Elements with melting point around this temperature:" msgstr "Елементи с тачком кључања у близини ове температуре:"

Заставица fuzzy показује да је порука мутна. Коментар који почиње са #| назива се коментаром претходног поља, пошто садржи претходну вредност поља msgid, ону која одговара преводу датом у msgstr. Овај превод, међутим, не одговара текућој (некоментарисаној) вредности поља msgid. Упоређујући претходно и текуће msgid, можете видети да је реч boiling замењена речју melting, па према томе прилагодити превод. Пошто сте тако урадили, уклањате заставицу fuzzy и коментаре претходних поља (#|), чиме ажурирана порука постаје:

src/somwidget_impl.cpp:120

msgid "Elements with melting point around this temperature:" msgstr "Елементи с тачком топљења у близини ове температуре:"

Коментари претходних поља су још једна релативно новија допуна формата ПО, тако да их у неким преводилачким окружењима нећете имати у стопљеним ПО‑овима. Мутна порука ће тада бити дата само са заставицом fuzzy:

src/somwidget_impl.cpp:120
, fuzzy

msgid "Elements with melting point around this temperature:" msgstr "Елементи с тачком кључања у близини ове температуре:"

Ово не мора деловати као велики губитак: све док визуелно упоређујете текстове, уместо поређења претходног (којег овде нема) и текућег msgid, баш бисте могли упоредити и текуће msgid и стари превод дат у msgstr, и поправити превод на основу тога. Међутим, ово доноси две непогодности. Мање важно, може не бити тако лако уочити разлику упоређивањем новог извора и старог превода. На пример, можда је у извору само исправљена грешка у куцању или додата тачка, што вас може ставити у недоумицу да не пропуштате нешто. Важније, наменски ПО уређивач може употребити претходно и текуће msgid да истакне разлике између њих, тако да их много лакше уочите. Чак и ако радите обичним уређивачем текста, постоје скрипте командне линије које угњежђују разлике у претходно msgid, чиме их опет можете лакше видети. Што је порука дужа то је аутоматско истицање битније — замислите на дугачки пасус у којем је промењена само једна реч. Из ових разлога, ако вам стопљени ПО фајлови не долазе са коментарима претходних поља, свакако се распитајте код аутора да ли их могу укључити (може бити да једноставно не знају за њих, пошто не спадају у подразумевано понашање стапања).

Поред msgid (и msgid_plural код множинских порука), у коментарима претходних поља такође се може наћи и msgctxt. Без обзира да ли је измењено msgctxt или msgid, или и једно и друго, оба ће бити дата у коментарима претходних поља:

kstarsinit.cpp:451
, fuzzy
| msgctxt "Constellation Line"
| msgid "Constell. Line"

msgctxt "Toggle Constellation Lines in the display" msgid "Const. Lines" msgstr "Линије сазвежђа"

Посебно, порука ће бити помућена ако претходно није имала msgctxt па га добила по стапању, или га је имала па изгубила. У првом случају, коментари претходних поља даваће само msgid, чак и ако је исто као текуће; тако ћете знати да је једина промена била додавање контекста. У другом случају, коментари претходних поља даваће и msgctxt и msgid, док неће бити текућег msgctxt. Следе примери ове две могућности:

kstarsinit.cpp:444
, fuzzy
| msgid "Solar System"

msgctxt "Toggle Solar System objects in the display"
msgid "Solar System"
msgstr "Сунчев систем"
⁠

finddialog.cpp:102
, fuzzy
| msgctxt "object name (optional)"
| msgid "Andromeda Galaxy"

msgid "Andromeda Galaxy" msgstr "Андромеда, галаксија"

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

Схватање мутних порука

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

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

Отпочињање новог ПО фајла

У светлу одржавања превода кроз поступак стапања, започињање рада на раније непревођеном ПО фајлу можете схватити као „почетно стапање“: мораћете да прибавите шаблон и преименујете га у нешто са наставком .po, па почнете са превођењем. У шта га треба преименовати зависи од окружења, али је обично једно од два: или исто име као шаблона само са наставком .po (овако је у КДЕ‑у), или ко̑д језика са наставком .po (као у Гному; ко̑д језика за српски ћирилицом је sr, а латиницом sr@latin). Начин именовања ПО фајлова у суштини зависи од организације конкретног преводилачког пројекта.

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

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

ПО заглавље

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

SOME DESCRIPTIVE TITLE.
Copyright (C) YEAR This_file_is_part_of_KDE
This file is distributed under the same license as the PACKAGE package.
FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.

, fuzzy

msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: http://bugs.kde.org\n" "POT-Creation-Date: 2008-09-03 10:09+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <[email protected]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"

Заглавље се састоји од уводних коментара, праћених празним msgid, и msgstr које садржи поља заглавља. Коментари заглавља, слични онима у нормалним порукама, нису сасвим произвољног облика, већ одражавају извесну структуру. Поље msgstr подељено је новим редовима (\n) у потпоља облика име: вредност (име податка и сам податак). Иако је заглавље нетакнуто, неке вредности које зависе од окружења обично су већ испуњене, нпр. гдегод се изнад помиње КДЕ. Заставица fuzzy говори да ПО фајл није раније превођен. Делови исписани великим словима су местодржачи које треба да замените стварним вредностима. Заглавље ажурирано да одражава стање превода могло би изгледати овако:

Translation of kstars.po into Serbian.
This file is distributed under the same license as the kdeedu package.
Pera Peric <[email protected]>, 2005, 2006, 2007, 2008.
Rada Radic <[email protected]>, 2007, 2008.

msgid "" msgstr "" "Project-Id-Version: kstars\n" "Report-Msgid-Bugs-To: http://bugs.kde.org\n" "POT-Creation-Date: 2008-09-01 09:37+0200\n" "PO-Revision-Date: 2008-07-22 18:13+0200\n" "Last-Translator: Pera Peric <[email protected]>\n" "Language-Team: Serbian <[email protected]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=4; plural=(n==1 ? 3 : n%10==1 && n%100!=11 ? " "0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"

И поред тога што је овај примерак заглавља понешто скраћен ради прегледности, вероватно и даље делује претеће, с мноштвом података — треба ли све ово сами ручно да испуните? Не заиста. Ако користите наменски ПО уређивач, даће вам фини дијалог за подешавање у којем можете унети податке о себи, о језику, итд., и кад год сачувате ПО фајл, уређивач ће аутоматски испунити заглавље. Ако радите обичним уређивачем текста, постоје алатке командне линије које слично аутоматски испуњавају заглавље. Али чак и поред оваквих помагала, вреди пружити неколико општих смерница у вези са коментарима и пољима заглавља.

Први коментар обично игра улогу наслова, који говори нешто о томе шта је и на који језик преведено. Други коментар каже нешто о лиценцирању. Неколико наредних коментара сваки наводи по једног преводиоца који је у неком тренутку радио на датом ПО фајлу, његово име, адресу е-поште, и године доприноса. После тога, могу се додати слободни коментари по жељи. Заставица fuzzy је уклоњена, пошто је рад на фајлу отпочет.

Поље заглавља Project-Id-Version наводи име и можда верзију онога што се преводи, Report-Msgid-Bugs-To даје адресу на коју се можете обратити када уочите проблеме у изворном тексту, POT-Creation-Date време стварања шаблона, PO-Revision-Date време када је преводилац последњи пут радио на фајлу, Last-Translator име и адресу последњег преводиоца који је радио на фајлу, и Language-Team име и адресу преводилачког тима (ако га има) чији је последњи преводилац члан. Поља MIME-Version, Content-Type и Content-Transfer-Encoding обично су увек и за сваки језик каква су дата горе, и стога не посебно занимљива (иако бисте могли променити кодирање у неко друго уместо УТФ‑8, у данашње време стварно треба трипут да размислите пре него што то учините). У последње поље из примера, Plural-Forms, уписујете одредницу множина за језик превода (о којој је писано у одељку о облицима множине).

Од представљених коментара и поља, готово сва се задају само једном, када се отпочне превођење ПО фајла. Када се навратите на неки ПО ради ажурирања превода, ако нико други на њему није радио у међувремену треба само да ажурирате поље PO-Revision-Date. Ако неко јесте радио на њему, такође треба да унесете своје податке у поље Last-Translator. Ако ви по први пут радите на ПО фајлу на којем је неко пре вас већ радио, треба још да се допишете и списак преводилаца у коментарима. (Ако користите наменски ПО уређивач, он ће све ове измене обавити за вас кад год сачувате фајл.)

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

Поред стандардних поља заглавља, можете сусрести и нека посебна, чија имена почињу са X-. Оваква поља у заглавље додају разне ПО алатке. Једно уобичајено посебно поље је X-Generator, у које наменски ПО уређивач уписује своје име и верзију. Друго посебно поље које се понекад виђа је X-Accelerator-Marker, за навођење знака који се користи као обележивач убрзивача (препознају га неке алатке нпр. за тражење кроз ПО фајлове, када би у супротном обележивач убрзивача могао да „замаскира“ реч тако што се нађе усред ње). Поред ових нешто чешћих посебних поља, различита преводилачка окружења могу додавати разна само њима специфична поља.

Представљање у уређивачима

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

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

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

(1) поље msgid (изворни текст)

(2) поље msgstr (преведени текст)

(3) поље msgctxt (разликујући контекст)

(4) издвојени коментари (контекст у виду коментара)

(5) упућивачи на извор (изворни фајл и ред поруке)

(6) заставице (fuzzy, *-format, итд.)

(7) стање мутности (иако међу заставицама, обично и посебно истакнуто)

(8) претходна поља (msgctxt и msgid)

(9) преводилачки коментари (они које додајете својеручно)

(10) положајни контекст (претходне и наредне поруке)

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

Следећа измишљена порука користи се као показни примерак на снимцима:

Имамо ли бољи превод за /froobaz/?
. i18n: 'Froobaz' is short for 'froolimatic bazzier'.
contrivance.cpp:42
, fuzzy, kde-format
| msgctxt "control station: alpha"
| msgid ""
| "Froobaz \"%1\" asks for attention.
\n"
| "Priority A message follows: %2
"

msgctxt "control station: alpha"
msgid ""

"

Froobaz \"%1\" demands immediate attention.

\n" "

Priority A message follows: %2

"

msgstr ""

"

Фрубаз „%1“ тражи пажњу.

\n" "

Порука приоритета А следи: %2

"

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

Кејт

К‑писање и Кејт чине КДЕ‑ов стандардни тим уређивача текста по принципу простији-сложенији, и деле исту компоненту за уређивање текста. Истицање синтаксе за формат ПО приказано снимком уведено је у верзији 3.1.0 Кејт (у саставу издања КДЕ‑а 4.1.0), док су раније верзије пружале једноставније истицање. Међутим, нова дефиниција истицања ПО‑а ради једнако добро с верзијама од 2.4.0 и каснијим, па их можете добавити ако користите старије издање Кејт.

Угњеждене разлике које се могу видети у претходним пољима, делови текста омотани у {+...+} и {-...-}, могу се произвести пропуштањем ПО фајла кроз Пологијино сито diff-previous.

Локализуј

Локализуј је нови наменски ПО уређивач (заправо општи преводилачки програма) за КДЕ 4, одмењујући К‑бабел у тој улози. Распоред на снимку је само подразумевани, пошто приказне и уређивачке виџете можете поређати како год желите.

Можете запазити како Локализуј користи претходна поља да аутоматски истакне разлике између претходног и текућег извора (окно доле лево, број 8). У окну за уређивање превода (десно у средини, бројеви 2 и 7), када је порука мутна текст ће бити у курзиву, што вам омогућава да врло лако разликујете мутне од преведених порука (иако можете укључити класичније лампице, као у К‑бабелу).

Г‑преводилац

Г‑преводилац је наменски ПО уређивач за Гном. У верзијама пре текуће 1.1.8 није могао да отвори ПО фајл са пољима msgctxt (пошто су ова најновији додатак формату), док ће у текућој стабилној верзији отворити такве фајлове, али неће приказати кориснику садржај msgctxt (стога црвени број 3 доле десно). Ово ће бити изведено у наступајућим издањима, како msgctxt почиње да се јавља у самим Гномовим ПО‑овима.

Контакт са ауторима

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

Очигледно, требало би да се обратите ауторима када вам је неопходна нека измена у извору (из којег се производи ПО шаблон и стапа са вашим преведеним ПО‑ом) како бисте могли добро да преведете одређену поруку. Међутим, понекад и када поруку можете превести сасвим фино, и даље има смисла да затражите неке измене. На пример, ако сте схватили значење тешке поруке тек пошто сте завирили у ко̑д, можете желети да јавите ауторима да јој придодају контекст чак и ако вама самима више није потребан. Или, ако сте наишли на тежак случај исецкане реченице коју сте успешно скрпили, да је ипак саставе у извору. Логика је једноставна: ако преводиоци на различите језике сви помогну побољшању порука у извору, ефикасно помажу једни другима. Док се ви бавите побољшањем једне поруке, други преводиоци ће се слично позабавити порукама које ће и вама у неком будућем тренутку доћи на црту.

Од преводилачког окружења зависи који се канали комуникације користе за питања локализације. У малим пројектима можете се једноставно обратити аутору непосредно е-поштом; адреса за контакт може бити дата у пољу заглавља Report-Msgid-Bugs-To ПО шаблона. Већи пројекти ће имати поштанску листу посвећену локализацији и пратилац грешака. У КДЕ‑у, на пример, можете или писати директно на поштанску листу, или послати извештај о грешки за програм који преводите; у Гному, чини се да је слање извештаја о грешкама пожељни начин. Уопштено, што сте мање сигурни како тачно поруку треба побољшати, и како то може утицати на друге језике, то је више разлог да пишете на поштанску листу где проблем могу претрести преводиоци на друге језике.

Пошто сте прогурали исправку, имајте на уму да се она не мора тренутно појавити у извору (нпр. у току недеље или месеца) и у вашем стопљеном ПО‑у. Ово услед такозваних смрзева порука, временских периода пред издање изворног садржаја (нпр. програма) када се прихватају само измене највише хитности. Сетите се да изменом порука постаје мутна, што значи непреведена за потрошача ПО фајла; ако би била измењена нпр. два дана пред издање, десетинама језичких тимова остао би дан или још мање да ажурирају превод. Зато, док прво наредно издање може не садржати исправку, једно од оних после њега хоће.