Главна гитовска ризница Појмовника налази се на Гитхабу, и може се клонирати овако:

$ git clone https://github.com/caslav-ilic/sverapoj.git

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

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

Уобичајени приказ разлика при управљању верзијама је онај са +/- прегледом измењених, додатих или уклоњених редова. Ово је сасвим довољно за рад на програмском коду, али није прегледно за дуже непреломљене текстове какви постоје у Појмовнику — за њих је погоднији преглед разлика на нивоу речи. У том циљу, сама наредба git-diff даје опцију којом се истичу измене у речима уместо целих редова:

$ git diff --color-words <остале-опције> | less -r

Ово треба добро утврдити: како најбоље прегледати разлике у тексту? Нпр. у горњој наредби less прелама ред усред речи. Можда приправити и скриптицу ил' две у util/.

Посебно скројене скрипте за обраду диверглоса, ИксМЛ-а којим је писан Појмовник, такође се држе у гитовској ризници, али засебној од Појмовникове:

$ git clone https://github.com/caslav-ilic/sverapoj.git

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

$ git clone <адреса>
$ cd divergloss
$ dgproc/po/update-po.sh compile # градња превода
[...нешто исписа...]
$ export PATH=$PWD/dgproc:$PATH

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

Да се скрипте не би увек ручно позивале, за најчешће потребе написани су справљачки циљеви који се извршавају са:

$ cd <ризница-Појмовника>
$ make <циљ>

Списак свих дефинисаних циљева добија се извршавањем make без аргумената (или с циљем help). Најосновнији циљ је check, за проверу техничке ваљаности целокупног Појмовника, који уредници извршавају пре сваке предаје у ризницу. Други користан циљ је dvg-html, којим се гради општи ХТМЛ поглед у директоријуму dvg-html/ (задато је да се овај директоријум игнорише у СУВ поступцима, тако да не смета да стоји у локалној копији ризнице).

Радње које нису дефинисане справљачким правилима могу се ручно извршити главном скриптом за обраду Појмовника, dgproc.py. У најосновнијем облику, она се извршава овако:

$ cd <ризница-Појмовника>
$ dgproc.py top.xml

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

У проширеном облику, dgproc.py провлачи појмовник кроз сита различитих намена, од којих свако прихвата одређене параметре. На пример, провлачењем кроз сито html гради се општи ХТМЛ поглед:

$ dgproc.py html top.xml -sbase:test-html/

Први параметар је назив сита, други збирна датотека Појмовника, а затим следе параметри сита, који се задају опцијом -s<парам>:<вредност>. Овде base:test-html/ каже у ком директоријуму треба саградити ХТМЛ поглед. Да би се начинио ХТМЛ поглед специјализован за неко окружење, нпр. КДЕ, треба издати:

$ dgproc.py html top.xml -senv:kde -sbase:test-html-kde/

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

$ dgproc.py po top.xml -senv:kde -solang:en -stlang:sr -sfile:test-kde.po

Детаљна документација за dgproc.py и расположива сита може се наћи у њеној ризници — како корисничка, тако и развојна за писање нових сита.

Сав текстуални садржај Појмовника на српском језику пише се искључиво ћирилицом. Ово укључује како садржај у ужем смислу (ИксМЛ датотеке: описи појмова, изрази, итд.), тако и текст у свим помоћним датотекама, па и поруке уз предаје у ризницу. Више је разлога овоме.

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

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

Можда се треба посебно осврнути на предајне поруке, тј. текстове које уредници морају уносити при предаји садржаја, наредбом git-commit. Једно сасвим лоше решење је да их свако пише како се накани у тренутку предаје (ћирилицом, латиницом, ошишаном латиницом...) јер се тиме отежава претрага ризничког дневника. Како ћирилици и латиници свакако треба дати предност над ошишаном латиницом где год је то технички могуће, а Гит се сасвим добро сналази са кодирањем УТФ-8 (чак је оно подразумевано), онда је складно да се и за предајне поруке користи ћирилица, кад већ за сав остали садржај.

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

Стабло директоријума и датотека у ризници изгледа овако:

top.xml
...
about/
    editors.xml
    environments.xml
    ...
concepts/
    0.xml
    a.xml
    b.xml
    ...
doc/
    ...
html/
    ...
util/
    ...

Датотека top.xml сабира све остале ИксМЛ датотеке, које чине садржај Појмовника; од ње увек почињу аутоматске обраде, нпр. изградња погледа̂. Директоријуми највишег нивоа, редом, имају следеће намене:

Имена директоријумима и датотекама увек се дају по квазиенглеском обрасцу, јер се сматрају техничком скелом Појмовника, нпр. као и ИксМЛ ознаке унутар датотека, или ко̑д помоћних програма.

У програмерским круговима, вечиту тему размирица представља стил кодирања — како тачно раздвајати и распоређивати синтаксне елементе кода, тамо год је то могуће на више начина. Ова тема се заправо преноси на сваки синтаксички уређени текстуални садржај, какав је и ИксМЛ формат Појмовника. Једино у чему се већина учесника поменутих размирица наизглед слаже, то је да никако није добро мешати стилове кодирања тамо где више људи сарађује на истом садржају (одређеном скупу датотека). Како Појмовник не дели задужења уредника̂, већ сваки може уређивати сваку датотеку, то је потребно установити један стил кодирања ради избегавања стилског хаоса.

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

Датотека с појмовима (оне у директоријуму concepts/) уређена је на следећи начин:

<?xml version="1.0" encoding="UTF-8"?>
<concepts>

<concept id="applet">
    ...тело појма 1...
</concept>

<concept id="application">
    ...тело појма 2...
</concept>

...

</concepts>

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

Атрибути елемента concept наводе се редом: прво кључ (id), области (topic), па сродни појмови (related). Ако га има, атрибут related преноси се у наредни ред и равна са почетком атрибута̂, пошто може садржати произвољан број појмова и временом је непостојанији од претходних. На пример:

<concept id="gnu" topic="acrons">
    ...
</concept>

<concept id="konqueror" topic="apps"
         related="firefox epiphany opera safari">
    ...
</concept>

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

<concept id="syntaxhighlighting">
    <desc>Визуелно разликовање синтаксичких [...] посматра.</desc>
    <!-- @упути: ... -->

    <term lang="en" gr="is">syntax highlighting</term>
    <term gr="is">истицање синтаксе</term>
    <term env="moz" gr="is">бојење синтаксе</term>

    <details root="wpen" rel="Syntax_highlighting"/>
</concept>

(о @-коментарима, какав се види у примеру испод описа, у даљем тексту). Празни редови притом треба да буду потпуно празни, без размака до нивоа увлачења; и иначе не треба остављати пратеће размаке у редовима.

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

<concept id="ckey">
    ...
    <term env="kde" gr="i">аплет</term>
    <eterm env="gnm ooo" gr="i">
        <nom>програмче</nom>
        <decl gr="mn">програмчићи</decl>
    </eterm>
    ...
</concept>

Дужи текстови, какав је опис, не преламају се статички на одређеној колони, већ се пуштају да теку колико је потребно. Визуелно преламање ради прегледности очекује се од уређивача текста којим се ради на датотеци. Ово је неопходно зато што се могу очекивати честе измене описа, како се додају нови појмови и упућује на њих или мењају изрази, што би стално захтевало поновно преламање, потирући добре стране статичког прелома. Незгода непреломљених пасуса је у томе што су делте при предаји у неким случајевима веће него што би морале бити, али се то узима као мање зло. С позитивне стране, Гит при прегледању разлика омогућава да се уместо простог +/- прегледа измењених редова добија обојени преглед измењених речи, а постоје и друге сличне могућности (в. раније о томе).

У случају да опис (или неки коментар) тражи неколико пасуса, што би требало да је реткост, може се употребити елемент дугог описа ldesc, који садржи поделементе пасуса. Пасуси се тада увлаче један ниво, стоје један по реду, такође без статичког прелома у оквиру пасуса:

<concept id="ckey">
    <ldesc>
        <para>Први пасус [...] готов.</para>
        <para>Други пасус [...] готов.</para>
    </ldesc>
    ...
</concept>

Једнако за елементе дугог коментара и порекла, lcomment и lorigin.

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

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

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

Када се кључ одреди, скела појма (ИксМЛ елемент concept) упише се у датотеку у поддиректоријуму concepts/ према почетном слову кључа; у оквиру датотеке, уметне се у лексикографском поретку по кључевима.

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

Често ће се десити да уредник жели да упути на појам који Појмовник још увек не бележи. Тада, уредник саставља кључ тог појма како је раније описано, али га не може формално додати (атр. related), јер би то изазвало грешку упућивања на непостојећи појам. Уместо тога, кључ се ставља у посебан @-коментар, у ред испод отварајуће ознаке елемента појма. Нпр. при додавању појма addon, ако је extension2 знани појам, а plugin још не постоји, тада:

<concept id="addon"
         related="extension2">
    <!-- @види: plugin -->
    ...
</concept>

Последично, како се појам дода, треба потражити његов кључ свуда кроз Појмовник, и где год се нађе у @-коментару, пребацити га у атрибут related, или у елемент ref ако се @-коментар односи на опис. Ако притом неки @-коментар остане празан, без кључева, уклонити цео његов ред.

Иако можда делује као изврнут редослед, новододатом појму лакше је прво записати израз (односно изразе), па тек потом опис — који се не може изоставити. Зато о додавању израза пре него о описима.

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

Прво се наводе енглески изрази. Ако се зна само за један, наводи се уз језик и граматичку категорију:

<term lang="en" gr="i">software</term>

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

<term lang="en" gr="i">folder</term>  <!-- у већини окружења -->
<term lang="en" env="unx" gr="i">directory</term>

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

<term gr="i">датотека</term>
<term env="kde" gr="i">фајл</term>

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

<term env="fed" gr="i">програмчић</term>
<term env="gnm ooo" gr="i">програмче</term>
<term env="kde moz uk" gr="i">аплет</term>  <!-- компромисни -->

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

Уместо елемента term, може се користи и елемент eterm, тзв. проширени израз. Он се користи, рецимо, када треба назначити одређену деклинацију израза (често проблематичан генитив, избор једног од два облика множине, итд.), или када се израз жели прокоментарисати. Тада се основни израз додаје као поделемент nom:

<eterm gr="i">
    <nom>софтвер</nom>
    <comment>Градивна именица, у множини само за [...]</comment>
</eterm>
...
<eterm env="kde" gr="i">
    <nom>знак</nom>
    <decl gr="mn">знакови</decl>
</eterm>

При писању новог појма, уредник може различито поступити са изразима. Може, на пример, не додати нити један једини израз, ако је појам нешто ново и ретке појаве. Може додати само израз за окружење које му је најближе — тада му поред кључа тог окружења аутоматски додаје и уреднички компромис (кључ uk, в. горе), али га не проглашава за претежно (тако што му уопште не би навео окружење). Коначно, може бити вредан па пребрати по разним окружењима, додајући изразе за свако од њих; тада може, ако процени, један израз оставити без кључа окружења, тј. прогласити га претежним, а кључеве окружења додати само другим изразима. Уредник је такође слободан да наброји изразе који се не налазе у окружењима које Појмовник прати, заводећи их под „идејно“ метаокружење (кључ id); израз не може бити истовремено и под овим и под неким стварним окружењем.

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

Каде се додаје израз који је придев, треба га увек давати у мушком роду, и то неодређеном виду ако постоји. На пример: „овај штампач је подразумеван“ — „подразумевани штампач“, значи да се придев наводи као „подразумеван“, док „овај штампач је мрежни“ — „мрежни штампач“, даје само придев „мрежни“.

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

Прво, дакле, треба осмислити сирови текст описа. Ту се нема шта много рећи, сваки уредник личном проценом одређује шта је најпрече изнети о појму. Што се обима тиче, опис треба природно да буде један пасус, односно једна или више реченица; уколико уредник ухвати себе како често користи „или“, алтернативе у заградама, или да би радо поделио опис у два пасуса, то је готов знак да су у ствари у питању два раздвојена појма (без обзира на то што их именује исти израз), те их као различите треба и додати у Појмовник (за пример в. online, online2, online3).

Потом, уредник треба да размисли који делови текста помињу друге појмове које би Појмовник требало такође да садржи — кандидате за упућивање угњежденим елементом ref у тексту. Уредник затим одреди њихове вероватне кључеве, према наведеном обрасцу, па потражи које Појмовник већ бележи. На пронађене заиста упути елементом ref, а кључеве још увек ненаписаних забележи @-коментаром подно појма. На пример, ако појам application постоји, а појам menu још увек не, онда би један опис могао тећи овако:

<desc>У <ref c="application">програмима</ref>,
наслов <ref c="zzz">менија</ref> чијим ставкама корисник утиче на
податке које програм пружа у датом тренутку, или на визуелну
представу документа на којем тренутно ради.</desc>
<!-- @упути: menu -->

Овај пример показује и то да иако појам menu не постоји, за њега је у текст описа ипак убачен упућивач, али му је као одредишни кључ (атрибут c) задато zzz. Појам zzz је метапојам дефинисан у датотеци concepts/0.xml, управо да би уредник унапред могао да обележи где треба убацити стварне кључеве када се појмови једном заиста напишу. (Ако би атрибут c одмах добио вредност кључа непостојећег појма, дошло би до грешке при аутоматској овери.)

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

За друге појмове које опис помиње такође је могуће да су различито именовани кроз окружења — што ће уредник приметити при провери да ли је појам на који жели да упути већ забележен. Тада унутар упућивача убацује угњеждени бирач облика ~<кључеви-окр1>:<текст1>|...~, који одређује који ће део текста бити изабран према окружењу за које се гради поглед на појмовник. Имајући у виду претходне примере разноврсно именованих појмова, описи би на њих овако могли упућивати:

<desc>Ниво организације података
изнад <ref c="file">~датотека|kde:фајлова~</ref>, на којем [...]</desc>
...
<desc>[...] обично са <ref c="applet">~аплетом|fed:програмичићем|
gnm ooo:програмчетом~</ref> у оквиру [...]</desc>

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

Коначно, све изнесено за описе важи и за коментаре и порекла, што појмова што израза (елементи comment и origin).

Какви појмови приличе Појмовнику (боље — какви не приличе)? Нешто о областима.

Нешто о граматичким категоријама. Категорије за синтагме (наставак -s); где не наводити (нпр. за стандардне текстове, област stdui).

Елемент by, који наводи уредника — да ли га, и где, додавати; нпр. коментар типа личног мишљења? Исто атрибут src, који наводи извор; нпр. за изразе идејног типа (окружење id)?

Неки устаљени типови коментара који могу бити од користи за појмове и изразе?