[gentoo-docs-it] Breviario del traduttore?

[gentoo-docs-it] Breviario del traduttore?

[Daniele Segato]

ciao...

ho trovato un po' di tempo stamattina e volevo provare a capire tutto il 
giro, più che altro esserne sicuro

vi chiederei di correggere questa lista e completarla.. mi prenderò 
carico alla fine della discussione di rispondermi a questo messaggio con 
la lista "presa come buona"

poi però sarebbe meglio mettere tutto su una wiki, ne abbiamo una?

cmq.. se no divago... ecco la lista

da quel che ho capito:
1.
vado qui:
http://dev.gentoo.org/~ago/trads-it.xml
o qui
http://gentoo-docs-it.inservibile.org/

(quale dobbiamo usare?)

2.
cerco le traduzioni con pallini rossi / gialli

eventualmente guardo il diff per capire l'entità della traduzione

e ne scelgo una

ignorare i documenti barrati (sono nel bug tracker di gentoo)


3.
vedo il percorso di directory con il file effettivo della traduzione

4.
faccio
git pull origin master

per riallinearmi con il lavorato degli altri

5.
comincio a tradurre e fare commit

6.
faccio

git pull origin master

risolvo eventuali conflitti

7.
controllo che nel frattempo il mio documento non sia finito nel bug 
tracker di gentoo ( http://gentoo-docs-it.inservibile.org/ )

se è così chiedo il da farsi in ML

8.
metto a disposizione di tutti la mia traduzione:
git push origin master

9:
finito?
ho ancora tempo? restart from 1) :P



ora alcune cose che non mi sono chiare

prendo questo che credo di aver capito è quello ufficiale:
http://gentoo-docs-it.inservibile.org/

vedo queste colonne:
* Documento: ci sono delle sigle davanti, hanno qualche significato?
(ho visto che cliccando si va nell'utile dettaglio, bene)

* Palle: suppongo che queste mi diano un'idea dell'allineamento tra la 
versione italiana e quella inglese

ma COME è calcolato il disallineamento?

mi fa pensare che finito di tradurre devo impostare qualcosa del tipo: 
"allineato alla versione inglese XYZ"

non credo di aver capito come leggere le palle

credo che la priorità sia il colore:
verde (nessuna priorità) -> giallo -> arancione -> rosso (più prioritario)

e che il numero di pallini indichi l'entità del lavoro?



* Diff: ok vado al diff con l'inglese

* Versione En: dov'è scritta la versione?
* Versione it: dove la devo scrivere?

in realtà ho visto che queste due, così come le date, sono scritte in un 
commento XML "HEADER"

<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/contact.xml,v 1.6 
2010/09/10 14:49:41 nightmorph Exp $ -->

quindi è lasciato al traduttore il compito di scrivere correttamente 
quel dato a manina?

la data/ora è in UTC?
il nome utente (nightmorph) va lasciato quello originale?


vedo poi un tag versione nel documento:
<version>3</version>
<date>2010-09-10</date>

questo ha un'altro significato?


* Data En / it -- ok

* Valid: validazione dell'xml

* Pronto: la traduzione è più recente dell'originale inglese (rosso = 
però l'XML non è valido)



se potete spiegarmi meglio il significato dei pallini :)
io tendenzialmente prenderei prima quelli NON VALIDI

poi se sono tutti validi prenderei quelli con "Palle" rosse, quindi 
arancioni, infine gialle





per chiudere oggi mi sono piantato al punto 4) della mia lista:

a quanto pare gitorious è giù dall'altro ieri:
http://blog.gitorious.org/2012/02/02/downtime-today-at-14-cet/

mi ero messo or ora a guardare le cose per capire dove / come tradurre e 
al tentativo di pull mi sono accorto che è giù


voi che ci lavorate da un po': capita spesso o è un caso?

è la prima volta che uso gitorious e non è un buon inizio :P


grazie a tutti per le risposte ;)

Re: [gentoo-docs-it] Breviario del traduttore?

[HUjuice]

Prima di risponderti per punti, faccio un riepilogo.
La pagina ufficiale a cui devi far riferimento è
http://dev.gentoo.org/~ago/trads-it.xml
Dovresti riconoscere lo stile del sito di Gentoo, no?
Quella però fotografa lo stato dei documenti pubblicati.

Oltre a quelli pubblicati ci sono quelli già tradotti e in attesa di
pubblicazione.
Questo "limbo" è a sua volta fatto di due parti:
prima https://gitorious.org/documentazione-italiana-gentoo-linux/documentazione-italiana-gentoo-linux/trees/master/bump
poi https://bugs.gentoo.org/buglist.cgi?list_id=752677;resolution=---;query_format=advanced;bug_status=UNCONFIRMED;bug_status=CONFIRMED;bug_status=IN_PROGRESS;bug_status=VERIFIED;component=[IT];product=Doc%20Translations
infine vengono pubblicati.

Poiché con 200 e passa documenti era complicato orientarsi, io, a
titolo assolutamente personale, ho fatto l'altro strumento, scrivendo
un po' di codice.
L'altro strumento non ha nulla di ufficiale (e si allinea anche con la
relativa lentezza del cron).

Per quanto riguarda i documenti, le regole per la loro gestione sono
http://www.gentoo.org/proj/en/gdp/doc/translators-howto.xml
http://www.gentoo.org/proj/en/gdp/doc/doc-tipsntricks.xml
http://www.gentoo.org/proj/en/gdp/doc/metadoc-guide.xml

Lì trovi tutte le indicazioni sulla struttura e le regole dei documenti.
Personalmente, l'unico elemento che ho trovato poco chiaro è cosa fare
dell'header (che comunque è a carico di qualche hook CVS, credo).
Basta non toccarlo.

Per punti:

> 1.
> vado qui:
> http://dev.gentoo.org/~ago/trads-it.xml
> o qui
> http://gentoo-docs-it.inservibile.org/
>
> (quale dobbiamo usare?)

Devi usare la prima (http://dev.gentoo.org/~ago/trads-it.xml)
confrontandola con quello che è stato già tradotto ed è in attesa
(https://gitorious.org/documentazione-italiana-gentoo-linux/documentazione-italiana-gentoo-linux/trees/master/bump)
e quello che è stato tradotto e in fase di pubblicazione
(https://bugs.gentoo.org/buglist.cgi?list_id=752677;resolution=---;query_format=advanced;bug_status=UNCONFIRMED;bug_status=CONFIRMED;bug_status=IN_PROGRESS;bug_status=VERIFIED;component=[IT];product=Doc%20Translations)

Poiché con 200 e passa documenti era un po' caotico, io ho fatto
l'altro strumento, personale, che io trovo utilissimo ma che ha un
tenore soggettivo.
Dai miei script io vedo che mancano solo 4 documenti:
http://gentoo-docs-it.inservibile.org/index.php?status=todo
Ma ovviamente potrei sbagliare.

> 2.
> cerco le traduzioni con pallini rossi / gialli
>
> eventualmente guardo il diff per capire l'entità della traduzione
>
> e ne scelgo una
>
> ignorare i documenti barrati (sono nel bug tracker di gentoo)

Vale quanto detto sopra. Devi guardare anche il 'bump' di gitorious.

> 3.
> vedo il percorso di directory con il file effettivo della traduzione

> 4.
> faccio
> git pull origin master
>
> per riallinearmi con il lavorato degli altri

> 5.
> comincio a tradurre e fare commit

> 6.
> faccio
>
> git pull origin master
>
> risolvo eventuali conflitti

> 7.
> controllo che nel frattempo il mio documento non sia finito nel bug tracker
> di gentoo ( http://gentoo-docs-it.inservibile.org/ )
>
> se è così chiedo il da farsi in ML

Bugtracker: https://bugs.gentoo.org/buglist.cgi?list_id=752677;resolution=---;query_format=advanced;bug_status=UNCONFIRMED;bug_status=CONFIRMED;bug_status=IN_PROGRESS;bug_status=VERIFIED;component=[IT];product=Doc%20Translations
Vale ancora quanto detto prima.
Se il tuo documento è improvvisamente in bugtracker probabilmente è
perché non hai controllato il bump (o è passato molto tempo da quando
l'hai fatto).

> 8.
> metto a disposizione di tutti la mia traduzione:
> git push origin master

> 9:
> finito?
> ho ancora tempo? restart from 1) :P


> ora alcune cose che non mi sono chiare
>
> prendo questo che credo di aver capito è quello ufficiale:
> http://gentoo-docs-it.inservibile.org/
IL CONTRARIO!! Quello è il risultato di script che mettono insieme i
tre strumenti ufficiali.
Tra l'altro alcuni gli script girano in cron, leggi l'inizio pagina.

> credo che la priorità sia il colore:
> verde (nessuna priorità) -> giallo -> arancione -> rosso (più prioritario)
>
> e che il numero di pallini indichi l'entità del lavoro?
Nella pagina ufficiale c'è scritto tutto:
http://dev.gentoo.org/~ago/trads-it.xml

> * Diff: ok vado al diff con l'inglese
>
> * Versione En: dov'è scritta la versione?
> * Versione it: dove la devo scrivere?
Nel tag <version> che tu stesso citi più avanti.
C'è un secondo numero che non è la versione, ma il commit in CVS e non
è a nostro carico.

> in realtà ho visto che queste due, così come le date, sono scritte in un
> commento XML "HEADER"
>
> <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/contact.xml,v 1.6
> 2010/09/10 14:49:41 nightmorph Exp $ -->
>
> quindi è lasciato al traduttore il compito di scrivere correttamente quel
> dato a manina?

No. Quei dati vengono scritti da qualche hook del CVS, che non ci compete.

> vedo poi un tag versione nel documento:
> <version>3</version>
> <date>2010-09-10</date>
Qui devi scrivere le stesse cose del documento originale.


> per chiudere oggi mi sono piantato al punto 4) della mia lista:
>
> a quanto pare gitorious è giù dall'altro ieri:
> http://blog.gitorious.org/2012/02/02/downtime-today-at-14-cet/
>
> mi ero messo or ora a guardare le cose per capire dove / come tradurre e al
> tentativo di pull mi sono accorto che è giù
>
>
> voi che ci lavorate da un po': capita spesso o è un caso?
>
> è la prima volta che uso gitorious e non è un buon inizio :P
>
>
> grazie a tutti per le risposte ;)
Era la prima volta.

Ciao,
Sergio


HUjuice
mooodcast.net

Re: [gentoo-docs-it] Breviario del traduttore?

[Daniele Segato]

On 02/04/2012 03:55 PM, HUjuice wrote:
> Prima di risponderti per punti, faccio un riepilogo.
> La pagina ufficiale a cui devi far riferimento è
> http://dev.gentoo.org/~ago/trads-it.xml
> Dovresti riconoscere lo stile del sito di Gentoo, no?

mi è chiaro che la pagina ufficiale sia quella, mi era chiaro anche prima

ma visto che hanno più o meno le stesse informazioni non era così 
assurdo pensare che il tuo script potesse essere usato da tutti qui 
"ufficiosamente"

ho espresso male la domanda, si, ma non sono ancora arteriosclerotico, 
spero :P

sia chiaro.. ho aperto questo thread per esser certo della procedura e 
per renderla più chiara anche a tutti i nuovi che, come me, sono stati 
accalappiati :P da Ago


> Quella però fotografa lo stato dei documenti pubblicati.
>
> Oltre a quelli pubblicati ci sono quelli già tradotti e in attesa di
> pubblicazione.
> Questo "limbo" è a sua volta fatto di due parti:
> prima https://gitorious.org/documentazione-italiana-gentoo-linux/documentazione-italiana-gentoo-linux/trees/master/bump
> poi https://bugs.gentoo.org/buglist.cgi?list_id=752677;resolution=---;query_format=advanced;bug_status=UNCONFIRMED;bug_status=CONFIRMED;bug_status=IN_PROGRESS;bug_status=VERIFIED;component=[IT];product=Doc%20Translations
> infine vengono pubblicati.

ok:
0: documento datato
1: tradotto e messo in bump
2: aperto ticket su bug.gentoo.org per richiederne la pubblicazione
3. pubblicato --> back to 0 quando qualcuno aggiorna l'originale inglese

manca qualche passaggio?

> Poiché con 200 e passa documenti era complicato orientarsi, io, a
> titolo assolutamente personale, ho fatto l'altro strumento, scrivendo
> un po' di codice.

si questo mi era chiaro

> L'altro strumento non ha nulla di ufficiale (e si allinea anche con la
> relativa lentezza del cron).

che non abbia nulla di ufficiale OK, ma le domande su come leggerlo mi 
servivano per poterlo comunque sfruttare per estrarne informazioni utili.



> Per quanto riguarda i documenti, le regole per la loro gestione sono
> http://www.gentoo.org/proj/en/gdp/doc/translators-howto.xml

chi è il nostro Lead translator?

alla pagina indicata c'è Davide Cendron che però so essersi dimesso 
(dalla lettura degli archivi della ML)

Davide aveva indicato un'altra persona come responsabile (non ricordo il 
nome), mi par però di capire che non è qui dentro / non si occupa della 
traduzione italiana?


forse la domanda dovrebbe essere "chi è il Follow-up" del Lead Translator?

se ho ben capito non abbiamo ne l'uno ne l'altro ed infatti non abbiamo 
qualcuno con l'accesso a CSV, per questa ragione passiamo dal bug tracker


altra cosa: non mi era stato detto di iscrivermi alla ML del CSV per 
essere informato delle traduzioni inglesi che vengono committate...
anche se la pagina lo consiglia suppongo che noi possiamo farne a meno 
grazie all'esistenza di:
http://dev.gentoo.org/~ago/trads-it.xml

o del tuo script in alternativa

> http://www.gentoo.org/proj/en/gdp/doc/doc-tipsntricks.xml

ok
qui ci sono le istruzioni "tecniche"
ottima reference

voi che programma usate come editor degli XML?


(ps: sapete che si possono definire degli hook su git che rifiutano ogni 
push che contenga xml non validi? non so se gitorious te lo lasci fare.. 
ma in locale si può certamente ottenere)



> http://www.gentoo.org/proj/en/gdp/doc/metadoc-guide.xml
>
> Lì trovi tutte le indicazioni sulla struttura e le regole dei documenti.
> Personalmente, l'unico elemento che ho trovato poco chiaro è cosa fare
> dell'header (che comunque è a carico di qualche hook CVS, credo).
> Basta non toccarlo.

rispetto all'header
si effettivamente non è chiaro

nessuno ha mai chiesto spiegazioni?

>> credo che la priorità sia il colore:
>> verde (nessuna priorità) ->  giallo ->  arancione ->  rosso (più prioritario)
>>
>> e che il numero di pallini indichi l'entità del lavoro?
> Nella pagina ufficiale c'è scritto tutto:
> http://dev.gentoo.org/~ago/trads-it.xml

ok perfetto sono gli stessi :)

>> * Diff: ok vado al diff con l'inglese
>>
>> * Versione En: dov'è scritta la versione?
>> * Versione it: dove la devo scrivere?
> Nel tag<version>  che tu stesso citi più avanti.
> C'è un secondo numero che non è la versione, ma il commit in CVS e non
> è a nostro carico.

k!

>> in realtà ho visto che queste due, così come le date, sono scritte in un
>> commento XML "HEADER"
>>
>> <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/contact.xml,v 1.6
>> 2010/09/10 14:49:41 nightmorph Exp $ -->
>>
>> quindi è lasciato al traduttore il compito di scrivere correttamente quel
>> dato a manina?
>
> No. Quei dati vengono scritti da qualche hook del CVS, che non ci compete.

k!


>> vedo poi un tag versione nel documento:
>> <version>3</version>
>> <date>2010-09-10</date>
> Qui devi scrivere le stesse cose del documento originale.

k!

non ci sono tag "data di traduzione" ?


ciao

Re: [gentoo-docs-it] Breviario del traduttore?

[HUjuice]

> mi è chiaro che la pagina ufficiale sia quella, mi era chiaro anche prima
C'è che questa è una mailing list che viene letta da molte persone e
conviene non usare termini che possono confondere.

> ma visto che hanno più o meno le stesse informazioni non era così assurdo
> pensare che il tuo script potesse essere usato da tutti qui "ufficiosamente"
Certo, perciò lo condivido. L'importante è sapere con cosa si sta lavorando.

> sia chiaro.. ho aperto questo thread per esser certo della procedura e per
> renderla più chiara anche a tutti i nuovi che, come me, sono stati
> accalappiati :P da Ago
Non so come siete stati «accalappiati» :)
È vero che noi abbiamo un po' più di esperienza, ma siamo qua.

> ok:
> 0: documento datato
> 1: tradotto e messo in bump
> 2: aperto ticket su bug.gentoo.org per richiederne la pubblicazione
> 3. pubblicato --> back to 0 quando qualcuno aggiorna l'originale inglese
>
> manca qualche passaggio?
No. Ci sei... Tra l'altro tu devi occuparti solo del punto 1.

Poi c'è quel discorso di tradurre man e messaggistica dei programmi.
Per quelli chiedi ad ago.

> che non abbia nulla di ufficiale OK, ma le domande su come leggerlo mi
> servivano per poterlo comunque sfruttare per estrarne informazioni utili.
Nello strumento non ufficiale ci sono tre colonne di pallini.
La prima ("Palle") sono le palle della pagina ufficiale, ottenuta
confrontando lo stato dei documenti pubblicai in inglese e in
italiano.
La second ("Valid") è ottenuta dai documenti in bump (che copio a mano
quando vedo un push in gitorious) e verificando la validità dell'XML e
la corrispondenza di data e versione col documento in inglese.
La seconda ("Pronto") è ottenuta guardando le prime due e il bugzilla.
In soldoni, se c'è la palla verde vuol dire che il documento è pronto
per il bump (sempre secondo i criteri con cui ho fatto gli script).

>> Per quanto riguarda i documenti, le regole per la loro gestione sono
>> http://www.gentoo.org/proj/en/gdp/doc/translators-howto.xml
>
>
> chi è il nostro Lead translator?
Queste cose può dirtele meglio ago, che se ho ben capito è all'interno
di un percorso.
Il reclutamento è complesso.

> alla pagina indicata c'è Davide Cendron che però so essersi dimesso (dalla
> lettura degli archivi della ML)
>
> Davide aveva indicato un'altra persona come responsabile (non ricordo il
> nome), mi par però di capire che non è qui dentro / non si occupa della
> traduzione italiana?
Se ti riferisci a Joshua Saddler, si tratta "semplicemente" del Team
Leader del progetto generale delle traduzioni. Ne manca uno specifico
per la lingua italiana:
http://www.gentoo.org/proj/en/gdp/international.xml

> forse la domanda dovrebbe essere "chi è il Follow-up" del Lead Translator?
>
> se ho ben capito non abbiamo ne l'uno ne l'altro ed infatti non abbiamo
> qualcuno con l'accesso a CSV, per questa ragione passiamo dal bug tracker
Yes, al momento... Ma c'è ago che si adopera.

> altra cosa: non mi era stato detto di iscrivermi alla ML del CSV per essere
> informato delle traduzioni inglesi che vengono committate...
> anche se la pagina lo consiglia suppongo che noi possiamo farne a meno
> grazie all'esistenza di:
> http://dev.gentoo.org/~ago/trads-it.xml
>
> o del tuo script in alternativa
Quello che trovi più comodo. A me piacerebbe anche fare un feed (RSS/Atom).

>> http://www.gentoo.org/proj/en/gdp/doc/doc-tipsntricks.xml
>
>
> ok
> qui ci sono le istruzioni "tecniche"
> ottima reference
>
> voi che programma usate come editor degli XML?
Io personalmente no.
Uso 'kate', in KDE, che è un editor leggero ma delizioso per molte
cose, ma non particolarmente utile in questo caso. Oppure uso vi.

> (ps: sapete che si possono definire degli hook su git che rifiutano ogni
> push che contenga xml non validi? non so se gitorious te lo lasci fare.. ma
> in locale si può certamente ottenere)
Questa è un'ottima idea.
Peccato che gitorious non ci conceda altrettanto.
Però potrebbe essere carino e semplice scriverne uno pre-commit e condividerlo.
In quattroequattrotto ho scritto questo che mi sembra funzionare:
.git/hooks/pre-commit
------------------------------
#!/bin/sh
for i in $(git diff --name-only); do
        if ! xmllint --valid --noout $i; then
                echo "Errori XML nel file $i"
                exit 0
        fi
done
-------
Secondo te si può migliorare?

> rispetto all'header
> si effettivamente non è chiaro
>
> nessuno ha mai chiesto spiegazioni?
Abbiamo tradotto tutto lasciano quel commento com'era.

Ciao ciao,
Sergio


HUjuice
mooodcast.net

Re: [gentoo-docs-it] Breviario del traduttore?

[Daniele Segato]

On 02/05/2012 11:30 PM, HUjuice wrote:
>> (ps: sapete che si possono definire degli hook su git che rifiutano ogni
>> push che contenga xml non validi? non so se gitorious te lo lasci fare.. ma
>> in locale si può certamente ottenere)
> Questa è un'ottima idea.
> Peccato che gitorious non ci conceda altrettanto.
> Però potrebbe essere carino e semplice scriverne uno pre-commit e condividerlo.
> In quattroequattrotto ho scritto questo che mi sembra funzionare:
> .git/hooks/pre-commit
> ------------------------------
> #!/bin/sh
> for i in $(git diff --name-only); do
>          if ! xmllint --valid --noout $i; then
>                  echo "Errori XML nel file $i"
>                  exit 0
>          fi
> done
> -------
> Secondo te si può migliorare?


exit 0 mi pare dica "tutto ok"

ti direi che farei l'exit alla fine del ciclo se ci sono stati errori in 
modo da controllare sempre tutti i file

mi documento sugli hook che non ho mai usato intensivamente e ti faccio 
sapere se c'è altro che si può fare

Re: [gentoo-docs-it] Breviario del traduttore?

[HUjuice]

>> .git/hooks/pre-commit
>> ------------------------------
>> #!/bin/sh
>> for i in $(git diff --name-only); do
>>         if ! xmllint --valid --noout $i; then
>>                 echo "Errori XML nel file $i"
>>                 exit 0
>>         fi
>> done
>> -------
>> Secondo te si può migliorare?

>
> exit 0 mi pare dica "tutto ok"

Ovviamente hai ragione. E poi manca un --cached (dentro la
sostituzione di comando).
.git/hooks/pre-commit
------------------------------
#!/bin/sh
for i in $(git diff --cached --name-only); do
        if ! xmllint --valid --noout $i; then
                echo "Errori XML nel file $i"
                exit 1
        fi
done
--------------------------------
Un check globale, come dici tu, è anche meglio.

C'è anche da dire che questo controllo potrebbe essere troppo serrato.
Un commit si può fare anche a metà lavoro (ma allora c'è git commit
--no-verify).
È proprio per queste cose che troverei utile un piccolo host di
lavoro, invece di gitorious.

Sergio


HUjuice
mooodcast.net

Re: [gentoo-docs-it] Breviario del traduttore?

[Daniele Segato]

On 02/06/2012 12:32 AM, HUjuice wrote:
>>> .git/hooks/pre-commit
>>> ------------------------------
>>> #!/bin/sh
>>> for i in $(git diff --name-only); do
>>>          if ! xmllint --valid --noout $i; then
>>>                  echo "Errori XML nel file $i"
>>>                  exit 0
>>>          fi
>>> done
>>> -------
>>> Secondo te si può migliorare?
>
>>
>> exit 0 mi pare dica "tutto ok"
>
> Ovviamente hai ragione. E poi manca un --cached (dentro la
> sostituzione di comando).
> .git/hooks/pre-commit
> ------------------------------
> #!/bin/sh
> for i in $(git diff --cached --name-only); do
>          if ! xmllint --valid --noout $i; then
>                  echo "Errori XML nel file $i"
>                  exit 1
>          fi
> done
> --------------------------------
> Un check globale, come dici tu, è anche meglio.


Allora..

prendendo dall'esempio di hook che ha git lo cambierei così:


#!/bin/sh
#
# XML validation of files that are about to be committed.
# Called by "git commit" with no arguments.  The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.

if git rev-parse --verify HEAD >/dev/null 2>&1
then
         against=HEAD
else
         # Initial commit: diff against an empty tree object
         against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

# If you want to allow non-ascii filenames set this variable to true.
allownonascii=$(git config hooks.allownonascii)

# Cross platform projects tend to avoid non-ascii filenames; prevent
# them from being added to the repository. We exploit the fact that the
# printable range starts at the space character and ends with tilde.
if [ "$allownonascii" != "true" ] &&
         # Note that the use of brackets around a tr range is ok here, (it's
         # even required, for portability to Solaris 10's /usr/bin/tr), 
since
         # the square bracket bytes happen to fall in the designated range.
         test "$(git diff --cached --name-only --diff-filter=A -z $against |
           LC_ALL=C tr -d '[ -~]\0')"
then
         echo "Error: Attempt to add a non-ascii file name."
         echo
         echo "This can cause problems if you want to work"
         echo "with people on other platforms."
         echo
         echo "To be portable it is advisable to rename the file ..."
         echo
         echo "If you know what you are doing you can disable this"
         echo "check using:"
         echo
         echo "  git config hooks.allownonascii true"
         echo
         exit 1
fi

XML_VALIDATION=0;
TMP_FILE="/tmp/tmp_check.xml"
TMP_LOG="/tmp/tmp_check.log"
rm -f "$TMP_FILE" "$TMP_LOG" 2> /dev/null

for file in ${git diff-index --cached $against};
do
	filename=${basename "$file"}
	extension=${filename##*.}
	if [[ extension = 'xml' ]] ; then
		echo "checking XML: $file ..." >> "$TMP_LOG"
		# copy the indexed version in a temporary file
		git show :"$file" > "$TMP_FILE"
		xmllint --valid --noout "$TMP_FILE" 2>> "$TMP_LOG"
		RESULT=$?
		if [[ ! $RESULT ]] ; then
			echo "XML non valido: $file"
			XML_VALIDATION=2;
		fi;
		rm -f "$TMP_FILE"
	fi
done;

if [[ XML_VALIDATION -ne 0 ]] ; then
	LOG_FILE="/tmp/git-commit-hook-log_`date '+%y%m%d%H%M%S'`.log"
	mv "$TMP_FILE" "$LOG_FILE"
	echo "See $LOG_FILE for details"
	echo "If you want to ignore this errors re commit with --no-verify option"
	exit $XML_VALIDATION
else
	rm -f "$TMP_LOG" 2> /dev/null
	exit 0;
fi





> C'è anche da dire che questo controllo potrebbe essere troppo serrato.
> Un commit si può fare anche a metà lavoro (ma allora c'è git commit
> --no-verify).

si... vero

si potrebbe usare un pre-push hook

la differenza nello script sopra è il calcolo dell'${against}
mi dicevano di usare "@{u}" al posto di "HEAD"

e subito prima fare un git fetch per essere sicuri di avere l'ultimo 
aggiornamento

lo dicono qui:
http://fclose.com/p/linux/man/7-gitrevisions/
git help gitrevisions


non correlato ma per completezza:
http://book.git-scm.com/4_git_treeishes.html

> È proprio per queste cose che troverei utile un piccolo host di
> lavoro, invece di gitorious.

si può anche creare un altro mirror, magari su github per non restare 
appiedati se uno dei due va giù...

il problema è che poi sta a noi tenere i mirror in sincrono :)

Re: [gentoo-docs-it] Breviario del traduttore?

[Daniele Segato]

On 02/06/2012 10:44 AM, Daniele Segato wrote:
> if [[ XML_VALIDATION -ne 0 ]] ; then
>      LOG_FILE="/tmp/git-commit-hook-log_`date '+%y%m%d%H%M%S'`.log"
>      mv "$TMP_FILE" "$LOG_FILE"

errore:
mv "$TMP_LOG" "LOG_FILE"

>      echo "See $LOG_FILE for details"
>      echo "If you want to ignore this errors re commit with --no-verify
> option"
>      exit $XML_VALIDATION
> else
>      rm -f "$TMP_LOG" 2> /dev/null
>      exit 0;
> fi

Re: [gentoo-docs-it] Breviario del traduttore?

[HUjuice]

> si potrebbe usare un pre-push hook
Il fatto è che il 'pre-push' non esiste, se ho capito bene.
Gli hook intervengono quando ci sono cambiamenti nel repository.
E infatti, come dicevi all'inizio, si può intervenire dall'altro lato,
quando il push viene ricevuto.
Ma non si può perché siamo in Gitorious.

> si può anche creare un altro mirror, magari su github per non restare
> appiedati se uno dei due va giù...
>
> il problema è che poi sta a noi tenere i mirror in sincrono :)
Non so bene che pensare.
In queste cose sono abituato al lavoro, dove ho almeno un'utenza sulle
macchine (quando non le amministro io stesso).
Il risultato è che viene fatto più lavoro manuale, che è fonte di
fatica e di errori.

Però ormai il grosso della fatica nello smazzarsi i file sembra fatto.
Vedremo come andiamo a regime...

Comunque il tuo script lo prendo.
Si può mettere nel wiki.

Sergio


HUjuice
mooodcast.net