Added basic.txt intro.txt preface.txt translate.txt to it version
authorMattia Rigotti <matrig@hotmail.com>
Tue, 4 Jun 2013 03:08:49 +0000 (3 23:08 -0400)
committerMattia Rigotti <matrig@hotmail.com>
Tue, 4 Jun 2013 03:08:49 +0000 (3 23:08 -0400)
it/basic.txt [new file with mode: 0644]
it/intro.txt [new file with mode: 0644]
it/preface.txt [new file with mode: 0644]
it/translate.txt [new file with mode: 0644]

diff --git a/it/basic.txt b/it/basic.txt
new file mode 100644 (file)
index 0000000..b312ec3
--- /dev/null
@@ -0,0 +1,269 @@
+== Trucchi di base  ==
+
+Piuttosto che immergerci nel mare di comandi di Git, bagnamoci un po' i
+piedi con i seguenti esempi elementari. Nonostance la loro semplicità,
+ognuno di loro è utile. In effetti, durante i miei mesi iniziali
+d'utilizzazione di Git, non mi sono mai avventurato al di là di del
+materiale in questo capitolo.
+
+=== Salvare lo stato corrente ===
+
+Siete sul punto di fare qualcosa di drastico? Prima di proseguire,
+catturate lo stato di tutti i files nella directory corrente:
+
+ $ git init
+ $ git add .
+ $ git commit -m "Il mio primo backup"
+
+Qualora le cose dovessero andare per il peggio, potrete sempre
+ripristinare la versione salvatae:
+
+ $ git reset --hard
+
+Per salvare un nuovo state:
+
+ $ git commit -a -m "Un altro backup"
+
+=== Aggiungere, rimuovere e rinominare files ===
+
+Le istruzioni che abbiamo appena visto tengono traccia solo dei files
+ che erano presenti nel momento dell'esecuzione di *git add*. Ma se
+ aggiungete nuovi files o sottocartelle, dovrete dirlo a Git:
+
+ $ git add readme.txt Documentation
+
+Analogamente se volete che Git ignori alcuni files:
+
+ $ git rm kludge.h obsolete.c
+ $ git rm -r incriminating/evidence/
+
+Git rimuoverà questi files per voi, se non l'avete ancora fatto.
+
+Un file può essere rinominato rimuovendo il vecchio nome e aggiungendo
+il nuovo nome. È anche possibile usare la scorciatoia *git mv* che segue
+la stessa sintassi del comando *mv*. Ad esempio:
+
+ $ git mv bug.c feature.c
+
+=== Annullare/Ripristino avanzati ===
+
+A volte può capitare che vogliate solamente ritornare indietro e
+dimenticare le modifiche effettuate dopo un certo punto, perché sono
+tutte sbagliate. In quel caso:
+
+ $ git log
+
+vi nostra una lista dei commits più recenti, accompagnati dal loro
+codice SHA1:
+
+----------------------------------
+commit 766f9881690d240ba334153047649b8b8f11c664
+Author: Bob <bob@example.com>
+Date: Tue Mar 14 01:59:26 2000 -0800
+
+    Sostituzione di prinf() con write()
+
+commit 82f5ea346a2e651544956a8653c0f58dc151275c
+Author: Alice <alice@example.com>
+Date:   Thu Jan 1 00:00:00 1970 +0000
+
+    Commit iniziale
+----------------------------------
+
+I primi caratteri del codice SHA1 sono sufficienti per specificare un
+commit; alternativamente copiate e incollate l'intero codice SHA1.
+Digitate:
+
+ $ git reset --hard 766f
+
+per reinstaurare lo stato corrspondente al commit corrente e
+permanetemente cancellare i commits più recenti.
+
+Altre volte potrebbe capitarvi di voler fare solo un breve salto in uno
+stato precedente. In questo caso eseguite:
+
+ $ git checkout 82f5
+
+Questo vi riporta indietro nel tempo, preservando i commits più recenti.
+Bisogna però sapere che, come in ogni viaggio nel tempo in un film di
+fantascienza, se ora modificate e sottomettete un commit vi ritroverete
+in una realtà alternativa, perché avrete fatto delle azioni differenti
+rispetto alla realtà originaria.
+
+Questa realtà parallela viene chiamata 'ramificazione' o 'branch', et
+<<branch,vi dirò di più in proposito in seguito>>. Per ora è abbastanza
+ricordare che
+
+ $ git checkout master
+
+vi riporta al presente. In oltre, per evitare che Git si lamenti,
+ricordatevi di fare un commit o un reset delle vostre modifiche prima di
+fare un checkout.
+
+Per riprendere l'analogia con i videogiochi digitate:
+
+- *`git reset --hard`* : carica un vecchio salvataggio e cancella
+  tutte le partite salvate più recenti di quella appena caricata.
+
+- *`git checkout`* : carica una vecchia partita, ma se ci giocate, lo
+  stato della partita sarà diverso da quello dei salvataggi successivi
+  che avete fato inizialmente. Da ora in poi ogni volta che salvate una
+  partita finirete in un branch separata che rappresenta la realtà
+  parallela in cui siete entrati. <<branch,Ci occuperemo di questo più
+  tardi>>.
+
+
+Potete scegliere di ripristinare files e sottocartelle particolari
+aggiungendoli alla fine del seguente comando:
+
+ $ git checkout 82f5 un.file un-altro.file
+
+Fate però attenzione: questa forma di *checkout* può sovrascrivere dei
+files senza avvertimenti. Per evitare incidenti, fate un commit prima di
+eseguire un comando di checkout, specialmente se siete alle prime armi
+con Git. In generale, ogni volta che non siete sicuri delle conseguenze
+di comando, che sia di Git o no, eseguite prima *git commit -a*.
+
+Non vi piace copiare e incollare codice hash? Allora utilizzate:
+
+ $ git checkout :/"Il mio primo b"
+
+per saltare direttamente al commit che inizia con quel messaggio. Potete
+anche chiedere, ad esempio, il quintultimo stato salvato:
+
+ $ git checkout master~5
+
+=== Annullare (revert) ===
+
+In una corte di giustizia, certi avvenimenti possono essere stralciati
+dal processo verbale. Analogamente, potete selezionare degli specifici
+commit da annullare.
+
+ $ git commit -a
+ $ git revert 1b6d
+
+annulla solo l'ultimo commit con il dato codice hash. Il revert viene
+registrato come un nuovo commit, fatto che potrete verificare eseguendo
+un *git log*.
+
+=== Generare un diario delle modifiche (changelog) ===
+
+Certi progetti richiedono un
+http://it.wikipedia.org/wiki/Changelog[changelog].  Createlo digitando:
+
+ $ git log > ChangeLog
+
+=== Scaricare dei files ===
+
+Fate una copia di un progetto gestito da Git digitando:
+
+ $ git clone git://server/percorso/verso/files
+
+Ad esempio, per ottenere tutti i files che ho usato per creare questo
+sito:
+
+ $ git clone git://git.or.cz/gitmagic.git
+
+Avremo molto da dire a proposito del comando *clone* tra poco.
+
+=== L'ultima versione ===
+
+Se avete già scaricato una copia di un progetto usando *git clone*,
+potete aggiornarla all'ultima versione con:
+
+ $ git pull
+
+=== Pubblicazione istantanea ===
+
+Immaginate di aver scritto uno script che volete condividere con altri.
+Potreste semplicemente dire loro di scaricarlo dal vostro computer, ma
+le fanno mentre state migliorando lo script o sperimentando con delle
+modifiche, potrebbero finire nei guai. Naturalmente, questo tipo di
+situazioni sono la ragione per cui esistono i cicli di rilascio. Gli
+sviluppatori possono lavorare frequentemente ad un progetto, ma
+rilasciano il codice solo quando hanno l'impressione che sia
+presentabile. 
+
+Per fare questo con Git, nella cartella che contiene lo script eseguite:
+
+ $ git init
+ $ git add .
+ $ git commit -m "Prima versione"
+
+In seguito dite agli utenti di eseguire:
+
+ $ git clone il.vostro.computer:/percorso/verso/lo/script
+
+per scaricare il vostro script. Questo assume che tutti abbiamo accesso
+ssh al vostro computer. Se non fosse il caso, esguite *git daemon* e
+dite ai vostri utenti di eseguire invece:
+
+ $ git clone git://il.vostro.computer/percorso/verso/lo/script
+
+A partire da questo momento, ogni volta che il vostro script è pronto
+per essere rilasciato, eseguite:
+
+ $ git commit -a -m "Nuova versione"
+
+e i vostri utenti potranno aggiornare la loro versione andando
+nella cartella che contiene lo script e digitando:
+
+ $ git pull
+
+I vostri utenti non si ritroveranno mai più con una versione del vostro
+script che non volete che vedano.
+
+=== Che cosa ho fatto? ===
+
+Ritroverete le modifiche fatte dall'ultimo commit con:
+ $ git diff
+
+Oppure quelle a partire da ieri con:
+
+ $ git diff "@{yesterday}"
+
+O tra una versione specifica e due versioni fa:
+
+ $ git diff 1b6d "master~2"
+
+In ogni caso il risultato è una patch che può essere applicata con *git
+apply*.
+Potete anche provare:
+
+ $ git whatchanged --since="2 weeks ago"
+
+Spesso esamino invece la storia dei commits con
+http://sourceforge.net/projects/qgit[qgit], per via della sua
+sfolgorante interfaccia, oppure http://jonas.nitro.dk/tig/[tig],
+un'interfaccia in modalità testo che funziona bene anche con le
+connessioni più lente. Alternativamente, installate un server web,
+lanciate *git instaweb* e lanciate il vostro browser.
+
+
+=== Esercizio ===
+
+
+Siano A, B, C, D quattro commits successivi, dove B è identico a A, con
+l'eccezione che alcuni files sono stati rimossi. Vogliamo rimettere i
+files in D. Come possiamo fare?
+
+Ci sono almeno tre soluzioni. Assumiamo che siao in D:
+
+  1. La differenza tra A e B sono i files rimossi. Possiamo creare una
+  patch che rappresenti la differenza e applicarla:
+
+   $ git diff B A | git apply
+
+  2. Visto che i files in questioni sono presenti in A, possiamo
+  recuperarli:
+
+   $ git checkout A foo.c bar.h
+
+  3. Possiamo anche pensare al passo da A a B come ad una modifica che
+  vogliamo annullare:
+
+   $ git revert B
+
+Quel è la scelta migliore? Quella che preferite! È facile ottenere
+quello che volete con Git, e spesso ci sono diversi modi di ottenerlo.
diff --git a/it/intro.txt b/it/intro.txt
new file mode 100644 (file)
index 0000000..f60743e
--- /dev/null
@@ -0,0 +1,157 @@
+== Introduzione ==
+
+Farò uso di un'analogia per introdurre il controllo di versione. Fate
+riferimento alla http://it.wikipedia.org/wiki/Controllo_versione[pagina
+wikipedia sul controllo di versione] per una spiegazione più sobria.
+
+=== Il lavoro è gioco ===
+
+Ho giocato ai videogiochi quasi tutta la mia vita. Per contro ho
+iniziato ad utilizzare sistemi di controllo di versione solo da adulto.
+Sospetto di non essere il solo, e il paragone tra i due può rendere
+alcuni concetti più facile da spiegare e comprendere.
+
+Pensate alla scrittura di codice o documenti come ad un videogioco.
+Non appena avete fatto progressi sostanziali, è desiderabile salvare il
+vostro lavoro. Per fare ciò cliccate sul pulsante 'Salva' del vostro
+fidato editor.
+
+Ma questo sovrascriverà la versione precedente del documento. È come
+quei vecchi videogiochi in cui si poteva salvare la partita, ma senza
+poter ritornare a uno stato precedente del gioco. Il che era un peccato,
+perché il vostro salvataggio precedente avrebbe potuto trovarsi ad un punto
+particolarmente divertente del gioco che avreste magari voluto
+rivisitare in futuro. O ancora peggio se il vostro salvataggio più
+recente si fosse rivelato essere uno stato da cui è impossibile vincere
+il gioco, obbligandovi a ricominciare la partita da zero. 
+
+=== Controllo di versione ===
+
+Quando modificate un documento di cui volete conservare le vecchie
+versioni, potete 'Salvare come...' sotto un nome di file diverso, oppure
+copiare il file in un'altra cartella prima di salvarlo. Potreste anche
+comprimere  queste copie del file, se volete risparmiare spazio su
+disco. Questa è una forma primitiva e inefficiente forma di controllo di
+versione. I videogiochi hanno migliorato questo punto molto tempo fa,
+provvedendo in molti casi multiple possibilità di salvataggio
+automaticamente ordinate temporalmente.
+
+Rendiamo il problema un po' più complicato. Immaginate di avere un
+un gruppo di files che vanno insieme, come il codice sorgente di un
+progetto o i files per un sito web. In questo caso se volete conservare
+una vecchia versione dovete archiviare una directory intera. Conservare
+diverse versioni a mano non è scomodo e diventa rapidamente
+impraticabile.
+
+Nel caso di alcuni videogiochi, il salvataggio di una partita consiste
+effettivamente in una directory contenente diversi files. Questi giochi
+nascondono questo dettaglio al giocatore e presentano una comoda
+interfaccia per gestire le diverse versioni di tale cartella.
+
+I sistemi di controllo di versione non sono niente più di questo. Hanno
+tutti una comoda interfaccia per gestire una directory piena di files.
+Potete salvare lo stato della directory di tanto in tanto, e più tardi
+potete caricare ognuno degli stati precedentemente salvati. A differenza
+della maggioranza di videogiochi, conservano in maniere intelligente lo
+spazio. Tipicamente, pochi files alla volta cambiano da una versione
+alla successiva. Si può quindi risparmiare spazio salvando le differenze
+invece di fare nuove copie complete.
+
+=== Controllo distribuito ===
+
+Immaginate ora un videogioco difficilissimo. Così difficile da terminare
+che molti esperti giocatori da tutto il mondo decidono di collaborare e
+condividere le loro partite salvate per cercare di venirne a capo. 
+Gli http://it.wikipedia.org/wiki/Speedrun[Speedrun] sono un
+esempio concreto di questa pratica: dei giocatori si specializzano
+ognuno a giocare un livello dello stesso gioco nel miglior modo
+possibile, e collaborano così per ottenere dei risultati incredibili.
+
+Come costruireste un sistema che permetta loro di accedere facilmente ai
+salvataggi degli altri? E che permetta di caricarne di nuovi?
+
+Nel passato ogni progetto usava un sistema di controllo di versione
+centralizzato. Un server centrale unico da qualche parte manteneva tutte le partite
+salvate. Ogni giocatore conservava al massimo qualche salvataggio sul
+proprio computer. Quando un giocatore aveva intenzione di avanzare nel
+gioco, scaricava il salvataggio più recente dal server centrale, giocava
+per un po', salvava e ricaricava sul server i progressi ottenuti così
+che ognuno potesse usufruirne.
+
+Ma che cosa succedeva se un giocatore per qualche ragione voleva
+accedere ad una vecchia partita salvata? Forse perché la versione più
+attuale si trovava in uno stato da cui non era più possibile vincere il
+gioco perché qualcuno aveva dimenticato di raccogliere un oggetto al
+terzo livello, e ora era necessario ritrovare l'ultima partita salvata
+in un momento in cui la partita è ancora completabile. O magari si
+desiderava paragonare due partite salvate precedentemente per vedere
+quanto progresso avesse fatto un giocatore particolare.
+
+Potrebbero esserci molte ragioni per voler recuperare una vecchia
+versione, ma il risultato è sempre lo stesso: era necessario chiederla
+al server centrale. E più partite salvate erano necessarie, più dati era
+necessario trasmettere.
+
+La nuova generazione di sistemi di controllo di versione di cui Git fa
+parte sono detti sistemi distribuiti e possono essere pensati come una
+generalizzazione dei sistemi centralizzati. Quando i giocatori scaricano
+dal server centrale ricevono tutti i giochi salvati, non solo l'ultima.
+È come se fossero un
+http://it.wikipedia.org/wiki/Mirror_(informatica)[mirror] del server
+centrale.
+
+Questa operazione iniziale di clonaggio può essere costosa, soprattutto
+se c'è una lunga storia di salvataggi precedenti. Ma a lungo termine è
+una strategia che ripaga. Un beneficio immediato è che, quando per
+qualche ragione si desidera un salvataggio precedente, non è necessario
+comunicare con il server centrale.
+
+=== Una sciocca superstizione  ===
+
+Una credenza popolare vuole che i sistemi distribuiti non siano adatti a
+progetti che richiedono un deposito centrale ufficiale. Niente potrebbe
+essere più lontano dalla verità. Fotografare qualcuno non ne ruba
+l'anima. Similarmente, clonare un deposito principale non ne diminuisce
+l'importanza.
+
+Una buona prima approssimazione è che tutto ciò che può fare un sistema
+di controllo di versione centralizzato può essere fatto meglio da un
+sistema distribuito ben concepito. Le risorse di rete sono semplicemente
+più costose che le risorse locali. Nonostante vedremo più in là che ci
+sono alcuni svantaggi associati agli approcci distribuiti, ci sono meno
+probabilità di fare paragoni sbagliate con questa approssimazione.
+
+Un piccolo progetto potrebbe non necessitare di tutte le funzionalità
+offerte da un tale sistema, ma il fatto di usare un sistema
+difficilmente estensibile per progetti piccoli è come usare il sistema
+di numerazione romano per calcoli con numeri piccoli.
+
+In aggiunta il vostro progetto potrebbe crescere al di là delle vostre
+previsioni iniziali. Usare Git dall'inizio è come avere sempre con se un
+coltellino svizzero, anche se lo utilizzate primariamente per aprire
+delle bottiglie. Quel giorno in cui avrete disperatamente bisogno un
+cacciavite sarete felici di avere più di un semplice apribottiglie.
+
+=== Merge di conflitti ===
+
+Per questo argomento la nostra analogia basata sui videogiochi inizia ad
+essere tirata per i capelli. Ritorniamo quindi invece al caso della
+formattazione di un documento.
+
+Immaginiamo che Alice inserisce una linea di codice all'inizio di un
+file, e Bob ne aggiunge una alla fine della propria copia. Entrambi
+caricano le loro modifiche nel deposito. La maggior parte dei sistemi
+decideranno una linea d'azione ragionevole: accettare e fondere (merge)
+entrambe le modifiche, così che sia le modifiche di Alice e Bob sono
+applicate.
+
+Ma supponiamo ora che Alice e Bob hanno fatto distinte modifiche alla
+stessa linea del documento. È impossibile procedere senza intervento
+umano. La seconda persona a caricare il file viene informata di un
+_conflitto di merge_, e bisogna scegliere una modifica piuttosto che un
+altra, oppure riscrivere interamente la riga.
+
+Situazioni più complesse possono presentarsi. Sistemi di controllo di
+versioni si possono occupare autonomamente dei casi più semplici, et
+lasciano i casi difficili all'intervento umano. Generalmente, questo
+comportamento è configurabile.
diff --git a/it/preface.txt b/it/preface.txt
new file mode 100644 (file)
index 0000000..1827b62
--- /dev/null
@@ -0,0 +1,99 @@
+= Git Magic =
+Ben Lynn
+Agosto 2007
+
+== Prefazione ==
+
+http://git.or.cz/[Git] è il coltellino svizzero per il controllo di
+versioni. Uno strumento per la gestione di revisioni affidabile,
+versatile e multifunzionale, ma la cui flessibilità ne rende difficile
+l'apprendimento, e ancora di più la padronanza.
+
+Come osserva Arthur C. Clarke, qualunque tecnologia sufficientemente
+avanzata è indistinguibile dalla magia. Questo è un buon atteggiamento
+con cui approcciare Git: i novizi possono ignorare i suoi meccanismi
+interni e utilizzare Git come fosse una bacchetta magica con cui
+meravigliare gli amici e far infuriare gli avversari.
+
+Invece di dilungarci nei dettagli, vedremo quali istruzioni vanno usate
+per ottenere risultati specifici. In seguito, grazie all'uso ripetuto,
+capiremo il funzionamento di ognuno dei trucchi, e come possono essere
+combinati per sopperire alle nostre necessità.
+
+.Traduzioni
+
+ - link:/\~blynn/gitmagic/intl/zh_cn/[Cinese semplificato]: JunJie, Meng
+   e JiangWei. Conversione in link:/~blynn/gitmagic/intl/zh_tw/[Cinese
+   traditional] tramite +cconv -f UTF8-CN -t UTF8-TW+.
+ - link:/~blynn/gitmagic/intl/fr/[Francese]: Alexandre Garel, Paul
+   Gaborit, e Nicolas Deram. Anche scaricabile da http://tutoriels.itaapy.com/[itaapy].
+ - link:/~blynn/gitmagic/intl/de/[Tedesco]: Benjamin Bellee e Armin
+   Stebich; anche scaricabile dal http://gitmagic.lordofbikes.de/[sito
+   web di Armin].
+ - http://www.slideshare.net/slide_user/magia-git[Portoghese]: Leonardo
+   Siqueira Rodrigues
+   [http://www.slideshare.net/slide_user/magia-git-verso-odt[formato ODT]].
+ - link:/~blynn/gitmagic/intl/ru/[Russo]: Tikhon Tarnavsky, Mikhail
+   Dymskov, e altri.
+ - link:/~blynn/gitmagic/intl/es/[Spagnolo]: Rodrigo Toledo e Ariset Llerena Tapia.
+ - link:/~blynn/gitmagic/intl/uk/[Ucraino]: Volodymyr Bodenchuk.
+ - link:/~blynn/gitmagic/intl/vi/[Vietnamita]: Trần Ngọc Quân; anche
+   scaribabile dal http://vnwildman.users.sourceforge.net/gitmagic/[suo
+   sito web].
+
+.Altre edizioni
+
+ - link:book.html[Pagina web individuale]&#160;: simplice documento
+   HTML, senza CSS ;
+ - link:book.pdf[File PDF]: versione stampabile.
+ - http://packages.debian.org/gitmagic[Pacchetto Debian],
+   http:://packages.ubuntu.com/gitmagic[pacchetto Ubuntu]: ottenete
+   rapidamente una copia locale. Pratico quando
+   http://csdcf.stanford.edu/status/[questo server] non è raggiungibile.
+ - http://www.amazon.com/Git-Magic-Ben-Lynn/dp/1451523343/[Libro vero e
+   proprio [Amazon.com]]: 64 pagine, 15.24cm x 22.86cm, bianco e nero,
+   in inglese. Pratico in caso di mancanza di elettricità.
+
+=== Grazie! ===
+
+Voglio ringraziare le persone che hanno prestato il loro lavoro per
+tradurre queste pagine. Sono grato di poter raggiungere un numero più
+ampio di lettori grazie agli sforzi delle persone appena citate.
+
+Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael
+Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick,
+Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer,
+Thomas Miedema, Joe Malin e Tyler Breisacher hanno contribuito con le
+loro correzioni e miglioramenti.
+
+François Marier mantiene il pacchetto Debian, creato originariamente da
+Daniel Baumarr.
+
+John Hinnegan ha acquistato il dominio http://www.gitmagic.com/[gitmagic.com].
+
+Sono anche grato a molti altri per i loro sostegno e incoraggiamenti.
+Sono tentato di menzionarvi qui, ma rischierei di alzare eccessivamente
+le vostre aspettative.
+
+Se per errore ho dimenticato di menzionare qualcuno, fatemelo per favore
+sapere, o mandatemi semplicemente una patch!
+
+=== Licenza ===
+
+Questo manuale è pubblicato sotto la licenza http://www.gnu.org/licenses/gpl-3.0.html[GNU
+General Public License version 3]. Naturalmente il codice sorgente è
+disponibile come deposito Git, e si può ottenere digitando: 
+
+ $ git clone git://repo.or.cz/gitmagic.git  # Crea la cartella
+ "gitmagic"
+
+oppure da altri server:
+
+ $ git clone git://github.com/blynn/gitmagic.git
+ $ git clone git://gitorious.org/gitmagic/mainline.git
+ $ git clone https://code.google.com/p/gitmagic/
+ $ git clone git://git.assembla.com/gitmagic.git
+ $ git clone git@bitbucket.org:blynn/gitmagic.git
+    
+GitHub, Assembla, e Bitbucket supportano deposito privati, gli ultimi
+due sono gratuiti.
diff --git a/it/translate.txt b/it/translate.txt
new file mode 100644 (file)
index 0000000..c8727b5
--- /dev/null
@@ -0,0 +1,38 @@
+== Appendice B: Tradurre Questo Manuale  ==
+
+La mia raccomandazione è di rispettare la seguente procedura per la
+traduzione di questo manuale, in maniera da poter rapidamente generare
+le versioni HTML e PDF del documento con gli script forniti, e così che
+tutte le traduzioni siano incorporate nello stesso repository.
+
+Fate un clone della sorgente, poi create una directory il cui nome
+corrisponda http://www.iana.org/assignments/language-subtag-registry[al
+codice IETF della lingua desiderata] : vedere
+http://www.w3.org/International/articles/language-tags/Overview.en.php[l'articolo
+del W3C concernente internationalizzazione]. Per esempio la versione in
+inglese è nella directory "en", quella in giapponese è in "ja". Nella
+nuova directory traducete i file +txt+ della directory originari "en".
+
+Per esempio, per creare questa guida in
+http://it.wikipedia.org/wiki/Lingua_klingon[Klingon], eseguite:
+
+ $ git clone git://repo.or.cz/gitmagic.git
+ $ cd gitmagic
+ $ mkdir tlh  # "tlh" è il codice IETF della lingua Klingon.
+ $ cd tlh
+ $ cp ../en/intro.txt .
+ $ edit intro.txt  # Tradurre il file.
+
+e così di seguito per tutti i file.
+
+Modificate il Makefile aggiungendo il codice della lingua alla
+variabile `TRANSLATIONS`. In questo modo potete rivedere il vostro
+lavoro  in modo incrementale:
+
+ $ make tlh
+ $ firefox book-tlh/index.html
+
+Fate spesso dei commit per le vostre modifiche e avvertitemi non appena
+sono state implementate. Github possiede un'interfaccia che facilita il
+lavoro collaborativo: fate un fork del progetto "gitmagic", fate un
+push delle vostre modifiche, e chiedetemi di incorporarle.