Localization/Concepts/PO Odyssey (sr)

Localization/Concepts/PO_Odyssey

Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | Eesti | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenčina | Slovenščina | српски | Türkçe | Tiếng Việt | Українська | 简体中文 | 繁體中文

Формат ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наступа ПО

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

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

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

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

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

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

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

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

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

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

1. finddialog.cpp:38

msgid "Globular Clusters" msgstr "" ⁠

1. finddialog.cpp:39

msgid "Gaseous Nebulae" msgstr "" ⁠

1. finddialog.cpp:40

msgid "Planetary Nebulae" msgstr ""

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

1. finddialog.cpp:38

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

1. finddialog.cpp:39

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

1. finddialog.cpp:40

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

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

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

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

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

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

1. addcatdialog.cpp:45

msgid "Import Catalog" msgstr ""

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

setCaption( i18n( "Import Catalog" ) );

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

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

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

1. 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. На пример, овај превод претходне поруке:

1. indimenu.cpp:96

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

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

1. indimenu.cpp:96

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

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

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

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

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

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

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

msgid "Equator" msgstr ""

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

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

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

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

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

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

1. locationdialog.cpp:228

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

1. locationdialog.cpp:229

msgid "Override Existing Data?" msgstr "" ⁠

1. locationdialog.cpp:229

msgid "Override Data" msgstr "" ⁠

1. locationdialog.cpp:229

msgid "Do Not Override" msgstr ""

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

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

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

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

1. . i18n: A classical test phrase, with all letters of the English alphabet.
2. . Replace it with a sample text in your language, such that it is
3. . 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:, која је и подразумевана за преводилачки систем Геттекст (под чијим окриљем се одржава формат ПО).

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

1. . Tag: title

   skycoords.docbook:73

msgid "The Horizontal Coordinate System" msgstr ""

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

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

1. . i18n: file: tools/observinglist.ui:263
2. . 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: ..., може деловати помало ко̑дно-криптично, али и поред тога лако из њега можете погодити да је ова порука облачић на неком дугмету.)

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

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

1. . i18n: First letter in 'Scope'

   tools/observinglist.cpp:700

msgid "S" msgstr "" ⁠

1. i18n: South

   skycomponents/horizoncomponent.cpp:429

msgid "S" msgstr ""

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

1. . i18n: First letter in 'Scope'
2. . i18n: South

   tools/observinglist.cpp:700 skycomponents/horizoncomponent.cpp:429

msgid "S" msgstr ""

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

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

1. . i18n: First letter in 'Scope'

   tools/observinglist.cpp:700

msgid "S" msgstr "" ⁠

1. i18n: South

   skycomponents/horizoncomponent.cpp:429

msgid "S" msgstr ""

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

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

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

msgid "Normal" msgstr ""

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

1. utils/katestyletreewidget.cpp:132

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

1. utils/kateautoindent.cpp:78

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

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

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

1. utils/katestyletreewidget.cpp:132

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

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

1. utils/gatestyletreewidget.c:132

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

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

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

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

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

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

1. Википедија каже да је ‘етрурски’ наше име за ово писмо.

   viewpart/UnicodeBlocks.h:151

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

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

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

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

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

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

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

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

1. skycomponents/constellationlines.cpp:106

2. , kde-format

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

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

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

1. skycomponents/constellationlines.cpp:106

2. , c-format

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

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

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

1. skycomponents/constellationlines.cpp:106

2. , python-format

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

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

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

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

1. kxsldbgpart/libxsldbg/xsldbg.cpp:256

2. , kde-format

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

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

1. gxsldbgpart/libxsldbg/xsldbg.c:256

2. , c-format

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

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

1. hypothetical.cpp:100

2. , kde-format

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

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

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

1. hypothetical.cpp:100

msgid "No star named " msgstr "" ⁠

1. hypothetical.cpp:100

msgid " found." msgstr ""

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

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

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

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

1. rc.cpp:1632 rc.cpp:3283

msgid "Name:" msgstr "" ⁠

1. kgeography.cpp:375

2. , kde-format

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

1. 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/> уводи прелом реда (читаоци који знају нешто ХТМЛ-а одмах ће препознати ове ознаке).

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

1. . Tag: title

   blackbody.docbook:13

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

1. . 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> наводницима. Уопштено говорећи, што сте упознатији са одређеним обележавањем, то можете ићи даље од његовог простог копирања из изворног текста.

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

1. utils/katecmds.cpp:180

2. , kde-format

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

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

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

1. poformat.txt:191

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

1. 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>. Још један тип обележавања је изворни језик упутних страна, роф:

1. 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. Пре свега, помислите на обичан двоструки наводник ("): пошто се користи за издвајање ниски поља, сирови двоструки наводник унутар текста прерано би окончао ниску, искваривши синтаксу поруке. Такви знакови се зато записују избегавачким низовима, комбинацијама контракроз (обрнуте косе црте) и другог знака, које се интерпретирају у жељене једноструке знакове када се текст приказује кориснику. Обичан двоструки наводник пише се као \":

1. kstars_i18n.cpp:3591

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

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

1. 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 и са̑мо контракроз \\ (јер једноструко контракроз увек започиње избегавачки низ). Постоје још неки избегавачки низови, али су њихове појаве изузетно ретке.

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

1. kstars_i18n.cpp:3591

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

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

Убрзивачи

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

1. kstarsinit.cpp:163

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

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

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

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

1. kstarsinit.cpp:163

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

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

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

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

1. kspopupmenu.cpp:203

msgid "Center && Track" msgstr "" ⁠

1. . Tag: phrase

   config.docbook:137

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

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

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

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

1. hypothetical.cpp:100

2. , kde-format

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

1. hypothetical.cpp:101

2. , kde-format

msgid "Time: %1 seconds" msgstr ""

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

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

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

1. mainwindow.cpp:127

2. , kde-format

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

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

1. mainwindow.cpp:127

2. , kde-format

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

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

1. mainwindow.cpp:127

2. , 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, ево како би претходна порука изгледала у њему:

1. mainwindow.cpp:127

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

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

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

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

1. modes/typesdialog.cpp:425

2. , 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 ово није било могуће, јер су постојала само три облика за српски).

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

1. 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) и даље су каквим сте их оставили, па с оваквим порукама немате новог посла. Друга категорија су потпуно нове поруке, у међувремену додате у извору, које чекају да их преведете. Притом, нове поруке неће бити додате произвољним редоследом, на пример тек надовезане на крај ПО фајла. Уместо тога биће помешане са преведеним порукама, тако да се испоштује редослед јављања порука у текућем извору. Ово вам омогућава да закључујете о контексту нових порука на основу претходних и наредних, баш као што сте могли и при превођењу ПО фајла од нуле. На пример:

1. fitshistogram.cpp:347

msgid "Auto Scale" msgstr "" ⁠

1. fitshistogram.cpp:350

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

1. fitshistogram.cpp:353

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

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

Мутне поруке

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

1. src/somwidget_impl.cpp:120

2. , fuzzy
3. | 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 и коментаре претходних поља (#|), чиме ажурирана порука постаје:

1. src/somwidget_impl.cpp:120

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

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

1. src/somwidget_impl.cpp:120

2. , fuzzy

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

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

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

1. kstarsinit.cpp:451

2. , fuzzy
3. | msgctxt "Constellation Line"
4. | msgid "Constell. Line"

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

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

1. kstarsinit.cpp:444

2. , fuzzy
3. | msgid "Solar System"

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

1. finddialog.cpp:102

2. , fuzzy
3. | msgctxt "object name (optional)"
4. | msgid "Andromeda Galaxy"

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

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

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

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

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

Застареле поруке

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

1. ~ msgid "Set the telescope longitude and latitude."
2. ~ msgstr "Постави гео. дужину и ширину телескопа."

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

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

Која је онда сврха застарелих порука? Често долази до тога да се одељак изворног садржаја, нпр. ко̑д задужен за одређену могућност програма, привремено уклони. Аутори понекад воле да побољшавају одељке засебно, изван главног садржаја који се преводи, а понекад одељак може бити и накратко погрешком уклоњен, приликом премештања и преименовања у извору. Када се ово догоди, дотичне поруке ће постати застареле у стопљеном ПО-у; али, када се недостајући одељак врати у извор, стапајући алгоритам ће узети у обзир застареле поруке, и унапредити их у стварне (преведене или мутне) када је могуће. Тиме се може уштедети нешто непотребног преводилачког напора.

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

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

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

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

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

ПО заглавље

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

1. SOME DESCRIPTIVE TITLE.
2. Copyright (C) YEAR This_file_is_part_of_KDE
3. This file is distributed under the same license as the PACKAGE package.
4. FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
6. , 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 говори да ПО фајл није раније превођен. Делови исписани великим словима су местодржачи које треба да замените стварним вредностима. Заглавље ажурирано да одражава стање превода могло би изгледати овако:

1. Translation of kstars.po into Serbian.
2. This file is distributed under the same license as the kdeedu package.
3. Pera Peric <[email protected]>, 2005, 2006, 2007, 2008.
4. 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) положајни контекст (претходне и наредне поруке)

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

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

1. Имамо ли бољи превод за /froobaz/?
2. . i18n: 'Froobaz' is short for 'froolimatic bazzier'.

   contrivance.cpp:42

3. , fuzzy, kde-format
4. | msgctxt "control station: alpha"
5. | msgid ""
6. | "

   Froobaz \"%1\" asks for attention.

   \n"
7. | "

   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

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

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

Локализуј

ПО порука у Локализују 0.2

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

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

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

ПО порука у Г-преводиоцу 1.1.8

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

Поедит

ПО порука у Поедиту 3.1.0

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

Основна одлика Поедита је веома компактан распоред. Подржава и рад преко целог екрана.

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

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

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

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

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