Fix translations

- Use "skript" instead of "skripta" according to computer dictionary.
- Add some grammar fixes here and there.

Author: petk

C-git-commands.asc

@@ -13,7 +13,7 @@ Govorili bomo o tem, kaj vsak ukaz na splošno naredi, in nato poudarili, kje v
 Dolge možnosti lahko skrajšate.
 Na primer, vtipkate lahko `git commit --a`, kar deluje tako, kot da bi vtipkali `git commit --amend`.
 To deluje samo, če so črke za `--` edinstvene za eno možnost.
-Pri pisanju skript uporabljajte polno opcijo.
+Pri pisanju skriptov uporabljajte polno opcijo.
 ====
 
 === Nastavitev in konfiguracija
@@ -205,7 +205,7 @@ Podobno kot ukaz `git add`, tudi ta ukaz pripravi odstranitev datoteke za nasled
 V poglavju <<ch02-git-basics-chapter#_removing_files>> smo podrobneje obravnavali ukaz `git rm`, vključno z rekurzivnim odstranjevanjem datotek in odstranjevanjem datotek samo iz področja priprave, vendar jih pustimo v delovnem direktoriju z uporabo možnosti `--cached`.
 
 Edina druga različna uporaba ukaza `git rm` v knjigi je v poglavju <<ch10-git-internals#_removing_objects>>, kjer smo na kratko uporabili in pojasnili uporabo možnosti `--ignore-unmatch` pri izvajanju ukaza `git filter-branch`, kar preprosto preprečuje, da bi se prijavila napaka, ko datoteke, ki jih želimo odstraniti, ni.
-To se lahko uporabi za skriptiranje.
+To je lahko uporabno za namene skriptiranja.
 
 ==== git mv
 
@@ -357,7 +357,7 @@ V poglavju <<ch02-git-basics-chapter#_sharing_tags>> smo videli, kako ga uporabi
 
 V poglavju <<ch07-git-tools#_publishing_submodules>> smo uporabili možnost `--recurse-submodules`, da smo preverili, ali je bilo vse delo z našimi podmoduli objavljeno, preden potisnemo nadrejeni projekt, kar je lahko resnično koristno pri uporabi podmodulov.
 
-V poglavju <<ch08-customizing-git#_other_client_hooks>> smo na kratko govorili o kljuki `pre-push`, ki je skripta, ki jo lahko nastavimo, da se izvede pred končanjem potiskanja, da preveri, ali je potiskanje dovoljeno.
+V poglavju <<ch08-customizing-git#_other_client_hooks>> smo na kratko govorili o kljuki `pre-push`, ki je skript, ki ga lahko nastavimo, da se izvede pred končanjem potiskanja, da preveri, ali je potiskanje dovoljeno.
 
 Na koncu, smo si v poglavju <<ch10-git-internals#_pushing_refspecs>> ogledali potiskanje z uporabo celotnega refspec-a namesto splošnih bližnjic, ki se običajno uporabljajo.
 To vam lahko pomaga, da boste zelo specifični glede dela, ki ga želite deliti.

book/01-introduction/sections/about-version-control.asc

@@ -46,16 +46,16 @@ Najbolj očitna je odpoved ene same točke, ki jo centralizirani strežnik preds
 Če se trdi disk, na katerem je osrednja podatkovna baza, poškoduje in ustrezne varnostne kopije niso bile ohranjene, boste izgubili absolutno vse - celotno zgodovino projekta razen samega posnetka, ki ga imajo uporabniki na svojih lokalnih napravah.
 Lokalni sistemi VCS trpijo za enakim problemom - kadarkoli imate celotno zgodovino projekta na enem mestu, tvegate, da boste izgubili vse.
 
-==== Razdeljeni sistemi nadzora različic
+==== Porazdeljeni sistemi nadzora različic
 
-(((Nadzor različic, razdeljeni)))
-To je mesto, kjer pristopijo razdeljeni sistemi nadzora različic (DVCS-ji).
-V DVCS (kot je Git, Mercurial, Bazaar ali Darcs) odjemalci ne izvlečejo samo zadnjega posnetka datotek: v celoti kopirajo repozitorij skupaj s celotno zgodovino.
+(((Nadzor različic, porazdeljeni)))
+To je mesto, kjer pristopijo porazdeljeni sistemi nadzora različic (DVCS-ji).
+V DVCS (kot je Git, Mercurial, Bazaar, ali Darcs) odjemalci ne izvlečejo samo zadnjega posnetka datotek: v celoti kopirajo repozitorij skupaj s celotno zgodovino.
 V primeru, da katerikoli strežnik odpove in ti sistemi sodelujejo preko tega strežnika, se lahko kopira repozitorij katerega koli odjemalca na strežnik ter se povrne.
 Vsak klon je resnično celotna varnostna kopija vseh podatkov.
 
-.Diagram razdeljenega nadzora različic
-image::images/distributed.png[Diagram razdeljenega nadzora različic]
+.Diagram porazdeljenega nadzora različic
+image::images/distributed.png[Diagram porazdeljenega nadzora različic]
 
 Poleg tega se mnogo teh sistemov precej dobro spoprijema z mnogimi oddaljenimi repozitoriji, na katerih lahko delajo, tako da lahko sodelujete z različnimi skupinami ljudi na različne načine istočasno znotraj istega projekta.
 To vam omogoča postaviti več tipov poteka dela, ki na centraliziranih sistemih, kakršni so hierarhični modeli, niso možni.

book/01-introduction/sections/history.asc

@@ -13,7 +13,7 @@ Kot je sledilo, so nekateri cilji novega sistema:
 * Hitrost
 * Enostavna oblika
 * Močna podpora za nelinearen razvoj (tisoče vzporednih vej)
-* V celoti razdeljeno
+* V celoti porazdeljeno
 * Zmožnost učinkovitega upravljanja velikih projektov, kot je jedro Linux (hitrost in velikost podatkov)
 
 Od njegovega rojstva v 2005 se je Git razvil in postal zrel ter enostaven za uporabo ob tem, da je še vedno ohranil te začetne kakovosti.

book/02-git-basics/sections/remotes.asc

@@ -73,7 +73,7 @@ Bodite pozorni, saj te daljave uporabljajo številne protokole; več o tem bomo
 
 Omenili in podali smo nekaj demonstracij, kako vam ukaz `git clone` posredno doda daljavo `origin`.
 Tako se doda nova daljava izrecno.(((Ukazi Git, remote)))
-Da dodamo nov oddaljeni repozitorij Git kot kratko ime, na katerega se lahko enostavno sklicujete, poženite `git remote add <shortname> <url>`:
+Da dodate nov oddaljeni repozitorij Git kot kratko ime, na katerega se lahko enostavno sklicujete, poženite `git remote add <shortname> <url>`:
 
 [source,console]
 ----

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -274,7 +274,7 @@ Samo vpišite ime orodja, ki bi ga raje uporabljali.
 ====
 
 Ko zapustite orodje združevanja, vas Git vpraša, ali je bila združitev uspešna.
-Če poveste skripti, da je bila, da datoteko v področje priprave, da jo za vas označi kot rešeno.
+Če skriptu poveste, da je bila, da datoteko v področje priprave in jo tako za vas označi kot rešeno.
 Ponovno lahko poženete `git status`, da potrdite, ali so bili vsi konflikti rešeni:
 
 [source,console]

book/03-git-branching/sections/branch-management.asc

@@ -130,7 +130,7 @@ Tako je slabo ime veje v celoti nadomeščeno s popravljenim imenom veje.
 ====
 Spreminjanje imena veje, kot je master/main/mainline/default, bo pokvarilo integracije, storitve, pomožne programe in skripte za gradnjo in izdajo, katere uporablja vaš repozitorij.
 Preden to storite, se posvetujte s svojimi sodelavci.
-Prav tako poskrbite, da temeljito preiščete svoj repozitorij in posodobite vse sklice na staro ime veje v svoji kodi in skriptah.
+Prav tako poskrbite, da temeljito preiščete svoj repozitorij in posodobite vse sklice na staro ime veje v svoji kodi in skriptih.
 ====
 
 Preimenujte vašo lokalno vejo `master` v `main` s sledečim ukazom:

book/04-git-server/sections/git-daemon.asc

@@ -52,7 +52,7 @@ Preverite tudi, da je zagonska datoteka Git prav zares na `/usr/bin/git`, druga
 
 Na koncu boste pognali `systemctl enable git-daemon`, da se storitev avtomatsko zažene pri zagonu, in storitev lahko zaženete in končate s `systemctl start git-daemon` in `systemctl stop git-daemon`.
 
-Na drugih sistemih, boste morda želeli uporabiti `xinetd`, skripto v vašem sistemu `sysvinit` ali kaj drugega - dokler dobite ta ukaz kot prikriti proces in da je nekako spremljan.
+Na drugih sistemih, boste morda želeli uporabiti `xinetd`, skript v vašem sistemu `sysvinit` ali kaj drugega - dokler dobite ta ukaz kot prikriti proces in da je nekako spremljan.
 
 Naslednje morate Gitu povedati, katerim repozitorijem se dovoli neoverjen strežniško osnovani dostop Git.
 To lahko naredite v vsakem repozitoriju z izdelavo datoteke poimenovane `git-daemon-export-ok`.

book/04-git-server/sections/gitweb.asc

@@ -2,7 +2,7 @@
 
 (((Streženje repozitorijev, GitWeb)))(((GitWeb)))
 Sedaj, ko imate dostop osnovnega branja/pisanja in samo branja do svojega projekta, boste morda želeli nastaviti enostaven spletno osnovani vizualizator.
-Git prihaja s skripto CGI imenovano GitWeb, ki je včasih uporabljena za to.
+Git prihaja s skriptom CGI imenovanim GitWeb, ki je včasih uporabljen za to.
 
 [[gitweb]]
 .Spletno osnovani uporabniški vmesnik GitWeb
@@ -29,10 +29,10 @@ Ko končate in želite strežnik zapreti, lahko poženete enak ukaz z možnostjo
 $ git instaweb --httpd=webrick --stop
 ----
 
-Če želite poganjati spletni vmesnik na strežniku ves čas za vso svojo ekipo ali za odprtokodni projekt, ki ga gostujete, boste morali nastaviti skripto CGI, ki jo postreže vaš običajni spletni strežnik.
+Če želite poganjati spletni vmesnik na strežniku ves čas za vso svojo ekipo ali za odprtokodni projekt, ki ga gostujete, boste morali nastaviti skript CGI, ki ga postreže vaš običajni spletni strežnik.
 Nekatere distribucije Linux imajo paket `gitweb`, ki ga lahko morda namestite preko `apt` ali `dnf`, tako da morda poskusite najprej to.
 Zelo hitro bomo šli skozi ročno namestitev GitWeba.
-Najprej morate dobiti izvorno kodo Git, s katero prihaja GitWeb, in generirati skripto CGI po meri:
+Najprej morate dobiti izvorno kodo Git, s katero prihaja GitWeb, in generirati skript CGI po meri:
 
 [source,console]
 ----
@@ -48,7 +48,7 @@ $ sudo cp -Rf gitweb /var/www/
 ----
 
 Bodite pozorni, saj morate ukazu povedati s spremenljivko `GITWEB_PROJECTROOT`, kje najde vaše repozitorije Git.
-Sedaj morate pripraviti Apache, da uporabi CGI za to skripto, za kar lahko dodate VirtualHost:
+Sedaj morate pripraviti Apache, da uporabi CGI za ta skript, za kar lahko dodate VirtualHost:
 
 [source,apache]
 ----

book/04-git-server/sections/smart-http.asc

@@ -2,7 +2,7 @@
 
 (((Streženje repozitorijev, HTTP)))
 Sedaj imamo overjen dostop preko SSH in neoverjen dostop preko `git://`, vendar obstaja tudi protokol, ki lahko naredi oboje istočasno.
-Nastavitev pametnega HTTP (Smart HTTP) je v osnovi samo omogočenje skripte CGI, ki je ponujena z Gitom imenovana `git-http-backend` na strežniku.(((Ukazi Git, "http-backend")))
+Nastavitev pametnega HTTP (Smart HTTP) je v osnovi samo omogočenje skripta CGI, ki je ponujen z Gitom imenovanim `git-http-backend` na strežniku.(((Ukazi Git, "http-backend")))
 Ta CGI bo prebral pot in glave, ki jih pošlje `git fetch` ali `git push` k HTTP URL in določa, ali lahko odjemalec komunicira preko HTTP (kar velja za kateregakoli odjemalca od različice 1.6.6).
 Če CGI vidi, da je odjemalec pameten, bo z njim komuniciral pametno; drugače se bo vrnil k neumnemu (dumb) obnašanju (tako, da je združljiv za nazaj za branje s starejšimi odjemalci).
 

book/05-distributed-git/sections/maintaining.asc

@@ -63,7 +63,7 @@ error: ticgit.gemspec: patch does not apply
 ----
 
 Če ni nobenega izpisa, potem bi se moral programski popravek uporabiti gladko.
-Ta ukaz se tudi konča z neničelnim statusom, če preverjanje ni uspešno, tako da ga lahko uporabite v skriptah, če želite.
+Ta ukaz se tudi konča z neničelnim statusom, če preverjanje ni uspešno, tako da ga lahko uporabite v skriptih, če želite.
 
 [[_git_am]]
 ===== Uporaba popravka z `am`
@@ -201,7 +201,7 @@ $ git checkout -b rubyclient jessica/ruby-client
 To je najbolj uporabno, če redno sodelujete s to osebo.
 Če nekdo prispeva le občasno kakšen programski popravek, je sprejemanje prek e-pošte manj časovno potratno, kot zahtevati, da vsakdo zažene svoj lastni strežnik in nenehno dodaja in odstranjuje daljave, da bi dobili nekaj sprememb.
 Verjetno tudi ne želite imeti na stotine daljav, vsake za vsako osebo, ki prispeva le eno ali dve spremembi.
-Vendar pa lahko skripte in gostujoče storitve to olajšajo - odvisno je predvsem od tega, kako razvijate in kako razvijajo vaši sodelavci.
+Vendar pa lahko skripti in gostujoče storitve to olajšajo - odvisno je predvsem od tega, kako razvijate in kako razvijajo vaši sodelavci.
 
 Druga prednost tega pristopa je, da dobite tudi zgodovino opravljenih potrditev.
 Čeprav imate lahko legitimne težave z združevanjem, veste, kje v vaši zgodovini je njihovo delo, saj je pravilno tristopenjsko združevanje privzeto, namesto da bi morali zagotoviti `-3` in upati, da je oblika spremembe ustvarjena iz javne potrditve, do katere imate dostop.