review

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

review

Agostino Sarubbo-2
Salve gente.

La seguente mail è per chiedere aiuto nella fase di review.
Visto che il lavoro di traduzione è quasi giunto al termine, sarebbe comodo se
qualcuno di voi contribuisse anche al review.

Metodo di lavoro usato:

bisognerebbe avere il repository cvs aggiornato localmente, oppure se si vuole
si può scaricare ogni volta il file da confrontare, quindi successivamente:
diff -ru $file_in_cvs_it $file_in_bump(it ovviamente)

Questo diff sarà successivamente confrontato con il diff che il cvs propone
(da dev.gentoo.org/~ago/trads-it.xml)

Quindi bisogna assicurarsi che la modifica alla nostra traduzione corrisponda
esattamente alla modifica che cvs propone, possibilmente rivedendo possibili
'typo'

Mi rendo conto che non è semplice confrontare e soprattutto è stancante, io
personalmente uso un metodo di lavoro analogo a http://ompldr.org/vY3F1ZA
dove sul terminale a comparsa ho il diff it e sul browser ho il diff en

Se qualcuno ha da proporre di meglio, come sempre, è ben accetto.

Se ci sono volontari propongo ulteriori dettagli per l'organizzazione sul
review
--
Agostino Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

HUjuice
> bisognerebbe avere il repository cvs aggiornato localmente, oppure se si vuole
> si può scaricare ogni volta il file da confrontare, quindi successivamente:
> diff -ru $file_in_cvs_it $file_in_bump(it ovviamente)

Quello che dici tu si fa con 'git-diff', ma ovviamente funziona solo
se il file prima esiste e poi lo modifico.
Ma con il sistema del bump che abbiamo adottato abbiamo perso lo strumento.

Inoltre, poiché non abbiamo un albero di directory corrispondente,
fare quel lavoro ora è un po' complicato.

Ho provato a farti questo:
http://gentoo-docs-it.inservibile.org/status.php?file=%2Fdoc%2Fit%2Fgentoo-x86-quickinstall-after-reboot.xml
Se guardi le "differenze tra la nuova e la vecchia versione" hai
qualcosa che ti aiuta.
(Ovviamente se torni alla home hai tutti i file.)

Lì ci sono i file del mio repository, copiati a mano dal bump.

Vedi un po'...
Sergio


HUjuice
mooodcast.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

HUjuice
In alternativa hai anche questo
http://git.inservibile.org/?p=gorg;a=blobdiff;f=gentoo/xml/htdocs/doc/it/gentoo-ppc-faq.xml;h=74a56e94c8765842006af2539f6d5b7b42fce7d3;hp=93d140d219ab1a0c0e0c4bf5600cb7737689eacb;hb=HEAD;hpb=52ecec2cb09d3ce0b3db2ab71be611586c40664e
e questo https://gitorious.org/documentazione-italiana-gentoo-linux/gorg
da cui puoi fare un clone e usare git-diff.
È comunque il mio repository.


HUjuice
mooodcast.net



Il 10 febbraio 2012 21:35, HUjuice <[hidden email]> ha scritto:

>> bisognerebbe avere il repository cvs aggiornato localmente, oppure se si vuole
>> si può scaricare ogni volta il file da confrontare, quindi successivamente:
>> diff -ru $file_in_cvs_it $file_in_bump(it ovviamente)
>
> Quello che dici tu si fa con 'git-diff', ma ovviamente funziona solo
> se il file prima esiste e poi lo modifico.
> Ma con il sistema del bump che abbiamo adottato abbiamo perso lo strumento.
>
> Inoltre, poiché non abbiamo un albero di directory corrispondente,
> fare quel lavoro ora è un po' complicato.
>
> Ho provato a farti questo:
> http://gentoo-docs-it.inservibile.org/status.php?file=%2Fdoc%2Fit%2Fgentoo-x86-quickinstall-after-reboot.xml
> Se guardi le "differenze tra la nuova e la vecchia versione" hai
> qualcosa che ti aiuta.
> (Ovviamente se torni alla home hai tutti i file.)
>
> Lì ci sono i file del mio repository, copiati a mano dal bump.
>
> Vedi un po'...
> Sergio
>
>
> HUjuice
> mooodcast.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Agostino Sarubbo-2
On Friday 10 February 2012 21:54:53 HUjuice wrote:
> In alternativa hai anche questo
> http://git.inservibile.org/?p=gorg;a=blobdiff;f=gentoo/xml/htdocs/doc/it/gen
> too-ppc-faq.xml;h=74a56e94c8765842006af2539f6d5b7b42fce7d3;hp=93d140d219ab1a
> 0c0e0c4bf5600cb7737689eacb;hb=HEAD;hpb=52ecec2cb09d3ce0b3db2ab71be611586c406
> 64e e questo https://gitorious.org/documentazione-italiana-gentoo-linux/gorg
> da cui puoi fare un clone e usare git-diff.
> È comunque il mio repository.
 

> Il 10 febbraio 2012 21:35, HUjuice <[hidden email]> ha scritto:
> >> bisognerebbe avere il repository cvs aggiornato localmente, oppure se
> >> si vuole si può scaricare ogni volta il file da confrontare, quindi
> >> successivamente: diff -ru $file_in_cvs_it $file_in_bump(it
> >> ovviamente)
> >
> > Quello che dici tu si fa con 'git-diff', ma ovviamente funziona solo
> > se il file prima esiste e poi lo modifico.
> > Ma con il sistema del bump che abbiamo adottato abbiamo perso lo
> > strumento.
> >
> > Inoltre, poiché non abbiamo un albero di directory corrispondente,
> > fare quel lavoro ora è un po' complicato.
> >
> > Ho provato a farti questo:
> > http://gentoo-docs-it.inservibile.org/status.php?file=%2Fdoc%2Fit%2Fgent
> > oo-x86-quickinstall-after-reboot.xml Se guardi le "differenze tra la
> > nuova e la vecchia versione" hai qualcosa che ti aiuta.
> > (Ovviamente se torni alla home hai tutti i file.)
> >
> > Lì ci sono i file del mio repository, copiati a mano dal bump.
> >
> > Vedi un po'...
> > Sergio
Grazie per la collaborazione e per l'impegno.

Personalmente mi trovo bene con quel metodo ma la mia non era una richiesta di
strumenti ma una richiesta di aiuto in quello specifico compito =)

Ho esposto il metodo di lavoro poiché qualcuno con poca esperienza poteva
mettersi a leggere l'intera guida quando non ce n'era bisogno

--
Agostino Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

HUjuice
> Personalmente mi trovo bene con quel metodo ma la mia non era una richiesta di
> strumenti ma una richiesta di aiuto in quello specifico compito =)

Provo a sgrossarti i documenti più semplici.
Cerco di evitare di rileggere me stesso.

HUjuice
mooodcast.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

HUjuice
>> Personalmente mi trovo bene con quel metodo ma la mia non era una richiesta di
>> strumenti ma una richiesta di aiuto in quello specifico compito =)
>
> Provo a sgrossarti i documenti più semplici.
> Cerco di evitare di rileggere me stesso.

Ho rivisto uno a uno tutti i documenti che seguono, cercando di
pizzicare quelli "semplici".
Parlo di quelli triviali o comunque con poche scritture.

In bump ci sono i documenti che ho ritoccato (poca roba).

Ti ricordo che visto che c'erano i link e che erano molto piccoli, ho
tradotto anche quattro documenti nuovi, che ti segno nell'elenco.

L'elenco è in fondo

Ciao,
Sergio

Modifiche semplicissime (max 3 righe)
=======================================================================
/doc/it/new-upgrade-to-gentoo-1.4.xml
/doc/it/gentoo-upgrading.xml
/doc/it/fluxbox-config.xml
/doc/it/nano-basics-guide.xml
/doc/it/gnupg-user.xml
/doc/it/mysql-upgrading.xml
/doc/it/mysql-upgrade-slotted.xml
/doc/it/portage-utils.xml
/doc/it/info-guide.xml
/doc/it/mysql-howto.xml
/doc/it/diskless-howto.xml
/doc/it/ltsp.xml
/doc/it/devfs-guide.xml
/doc/it/gentoo-sparc-obpreference.xml
/doc/it/home-router-howto.xml
/doc/it/jffnms.xml
/doc/it/ebuild-submit.xml
/doc/it/cvs-tutorial.xml
/proj/it/overlays/devguide.xml
/proj/it/hardened/hardenedxorg.xml
/proj/it/hardened/rsbac/overview.xml
/proj/it/hardened/rsbac/quickstart.xml
/security/it/index.xml
/doc/it/articles/making-the-distro-p1.xml
/doc/it/articles/making-the-distro-p2.xml
/doc/it/articles/making-the-distro-p3.xml
/doc/it/articles/bash-by-example-p1.xml
/doc/it/articles/bash-by-example-p2.xml
/doc/it/articles/bash-by-example-p3.xml
/doc/it/articles/lpi-101-fundamentals-p1.xml
/doc/it/articles/lpi-101-administration-p2.xml
/doc/it/articles/lpi-101-intermediate-p3.xml
/doc/it/articles/lpi-101-advanced-p4.xml
/doc/it/articles/partitioning-p1.xml
/doc/it/articles/partition-planning-tips.xml
/doc/it/articles/maximum-swappage.xml
/doc/it/articles/lvm-p1.xml
/doc/it/articles/lvm-p2.xml
/doc/it/articles/software-raid-p1.xml
/doc/it/articles/software-raid-p2.xml
/doc/it/articles/prompt-magic.xml
/doc/it/articles/openssh-key-management-p2.xml
/doc/it/articles/openssh-key-management-p3.xml
/doc/it/articles/l-afig-p8.xml
/doc/it/articles/dynamic-iptables-firewalls.xml
/doc/it/articles/l-sed1.xml
/doc/it/articles/l-sed2.xml
/doc/it/articles/l-sed3.xml
/doc/it/articles/l-awk1.xml
/doc/it/articles/l-awk2.xml
/doc/it/articles/l-awk3.xml
/doc/it/articles/l-posix1.xml
/doc/it/articles/l-posix2.xml
/doc/it/articles/l-posix3.xml
/doc/it/articles/afig-ct-ext3-intro.xml
/doc/it/articles/samba-p1.xml
/doc/it/articles/samba-p2.xml
/doc/it/articles/samba-p3.xml
/doc/it/articles/l-redesign-4.xml
/doc/it/articles/autotools-practices.xml
/doc/it/articles/hardware-stability-p1.xml
/doc/it/articles/hardware-stability-p2.xml
/proj/it/devrel/handbook/handbook.xml
/proj/it/devrel/handbook/hb-introduction-new-devs.xml
/proj/it/devrel/handbook/hb-guide-common-mistakes.xml
/proj/it/base/embedded/handbook/index.xml
    |
    -> /proj/it/base/embedded/handbook/boards-arm-beaglebone.xml
    -> /proj/it/base/embedded/handbook/boards-arm-trimslice.xml


Modifiche semplici (solo ritocchi, nessuna scrittura vera e propria)
=======================================================================
/main/it/contact.xml
/main/it/graphics.xml
    |
    -> /proj/it/desktop/artwork/artwork.xml
    -> /proj/it/desktop/artwork/colors.xml
/main/it/irc.xml
/main/it/stores.xml
/doc/it/gentoo-x86-quickinstall.xml
/doc/it/gentoo-x86-quickinstall-stage.xml *** Nel testo ci sono delle
date di esempio, che sono state modificate rispetto a en
/doc/it/gentoo-x86-quickinstall-after-reboot.xml
/doc/it/gentoo-x86+raid+lvm2-quickinstall.xml
/doc/it/migration-to-2.6.xml
/doc/it/grub-error-guide.xml
/doc/it/nvidia-guide.xml
/doc/it/multipath.xml
/doc/it/mailfilter-guide.xml
/doc/it/quick-samba-howto.xml
/proj/it/qa/automagic.xml
/proj/it/overlays/userguide.xml
/proj/it/infrastructure/dev-machines.xml
/doc/it/articles/l-redesign-3.xml
/doc/it/articles/l-redesign-4.xml
/proj/it/devrel/handbook/hb-guide-ebuild.xml
/proj/it/devrel/handbook/hb-policy-ebuild.xml

Testi modificati, ma non troppo
=======================================================================
/doc/it/gentoo-x86-quickinstall-system.xml
/doc/it/gnome-config.xml



HUjuice
mooodcast.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Agostino Sarubbo-2
In reply to this post by Agostino Sarubbo-2
On Friday 10 February 2012 20:59:26 Agostino Sarubbo wrote:
> Se ci sono volontari propongo ulteriori dettagli per l'organizzazione sul
> review

Ho deciso che per una migliore organizzazione delle revisioni è meglio avere
un file dove tenere traccia di ciò.

Il file sta nella home del repository git e si chiama revisioni.txt

Dopo aver revisionato, voi scriverete in revisioni.txt il nome del file con
accanto il vostro nick.

Esempio:
name_logo.xml quizzlo

Se io revisiono un file già revisionato da altri, aggiungerò il mio nick dopo
quizzlo, quindi:
name_logo.xml quizzlo ago

Se un file è nella cartella bump si può usare la sintassi succitata, mentre,
se il file si trova in sottocartelle di bump(tipo handbook o articles), è
opportuno fare:
handbook/file.xml ago
articles/file2.xml ago


Se trovate errori nei file revisionati da qualcuno, semplicemente correggete
l'errore e a fine revisione aggiornate revisioni.txt

@Sergio, ti dispiacerebbe aggiornare con quello che hai già revisionato?
grazie :)

--
Agostino Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Daniele Segato
On 02/16/2012 07:31 PM, Agostino Sarubbo wrote:

> On Friday 10 February 2012 20:59:26 Agostino Sarubbo wrote:
>> Se ci sono volontari propongo ulteriori dettagli per l'organizzazione sul
>> review
>
> Ho deciso che per una migliore organizzazione delle revisioni è meglio avere
> un file dove tenere traccia di ciò.
>
> Il file sta nella home del repository git e si chiama revisioni.txt
>
> Dopo aver revisionato, voi scriverete in revisioni.txt il nome del file con
> accanto il vostro nick.
>
> Esempio:
> name_logo.xml quizzlo
>
> Se io revisiono un file già revisionato da altri, aggiungerò il mio nick dopo
> quizzlo, quindi:
> name_logo.xml quizzlo ago
>
> Se un file è nella cartella bump si può usare la sintassi succitata, mentre,
> se il file si trova in sottocartelle di bump(tipo handbook o articles), è
> opportuno fare:
> handbook/file.xml ago
> articles/file2.xml ago
>
>
> Se trovate errori nei file revisionati da qualcuno, semplicemente correggete
> l'errore e a fine revisione aggiornate revisioni.txt
>
> @Sergio, ti dispiacerebbe aggiornare con quello che hai già revisionato?
> grazie :)
>

questo comando non ti piace?

$ git shortlog -- bump/gnome-config.xml
Sergio Vaccaro (1):
       Review di molti documenti e qualche correzione

k01 (1):
       Traduzioni ati-faq change-chost fluxbox-config gnome-config
nvidia-guide openbox udev-guide xfce-config xorg-config pronte     per
bump ;-)





non c'è rischio che l'informazione sia sbagliata e non richiede a
nessuno di fare nulla in più che i commit



ps: quando vi serve qualcosa di tecnico invece di "decidere" perché non
esponete ciò che serve in modo che si possa discutere su come farlo?
non sto riuscendo a dedicarmi alle traduzioni ma forse su questo posso
essere d'aiuto :)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Agostino Sarubbo-2
On Friday 17 February 2012 11:12:19 Daniele Segato wrote:

> questo comando non ti piace?
>
> $ git shortlog -- bump/gnome-config.xml
> Sergio Vaccaro (1):
>        Review di molti documenti e qualche correzione
>
> k01 (1):
>        Traduzioni ati-faq change-chost fluxbox-config gnome-config
> nvidia-guide openbox udev-guide xfce-config xorg-config pronte     per
> bump
>
>
>
>
>
> non c'è rischio che l'informazione sia sbagliata e non richiede a
> nessuno di fare nulla in più che i commit
>
>
>
> ps: quando vi serve qualcosa di tecnico invece di "decidere" perché non
> esponete ciò che serve in modo che si possa discutere su come farlo?
> non sto riuscendo a dedicarmi alle traduzioni ma forse su questo posso
> essere d'aiuto
no, io voglio avere un file con scritto chiaramente i documenti revisionati,
in modo tale che invece di andare alla ricerca nel log, i documenti che
committerò su bugzilla saranno quelli più revisionati
--
Agostino Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Daniele Segato
On 02/17/2012 11:12 AM, Agostino Sarubbo wrote:
> no, io voglio avere un file con scritto chiaramente i documenti revisionati,
> in modo tale che invece di andare alla ricerca nel log, i documenti che
> committerò su bugzilla saranno quelli più revisionati


scusa
l'informazione che ti serve è "quanti hanno lavorato su un documento" ?


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Agostino Sarubbo-2
On Friday 17 February 2012 11:19:22 Daniele Segato wrote:
> scusa
> l'informazione che ti serve è "quanti hanno lavorato su un documento" ?
no, quanti lo hanno revisionato dopo essere stato tradotto
--
Agostino Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Daniele Segato
On 02/17/2012 11:16 AM, Agostino Sarubbo wrote:
> On Friday 17 February 2012 11:19:22 Daniele Segato wrote:
>> scusa
>> l'informazione che ti serve è "quanti hanno lavorato su un documento" ?
> no, quanti lo hanno revisionato dopo essere stato tradotto

revisione = quanti hanno guardato il file (non necessariamente
modificandolo) per verificare se fosse tutto in ordine e lo hanno
considerato *buono* ?



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

HUjuice
In reply to this post by Agostino Sarubbo-2
>> l'informazione che ti serve è "quanti hanno lavorato su un documento" ?
> no, quanti lo hanno revisionato dopo essere stato tradotto

Ago, io capisco che le relazioni formali con gentoo.org siano
complesse e che il lavoro che stai facendo è molto impegnativo, ma c'è
un ma.
L'ulteriore burocratizzazione del processo che ci stai proponendo non
è commisurata al lavoro stesso, in molti casi.

Il numero di revisioni dovrebbe essere subordinato all'entità
dell'aggiornamento.

Una buona parte dei documenti sono estremamente semplici e
l'aggiornamento consiste nel ritoccare una riga.
Spesso consiste nell'eliminare l'attributo
link="/doc/it/nano-basics-guide.xml" dal tag guide.
Come tu ben sai i documenti in questa condizione sono diverse decine.
Ma ci chiedi di fare un lavoro tortuosissimo tutto intorno.

Per iniziare, la "tua" pagina ormai non serve a molto per capire cosa
c'è da fare.
I documenti con palle non verdi sono ormai un po' tutti in lavorazione
e potrebbero essere in bump come potrebbero essere in bugzilla.
In più i percorsi non corrispondono e insomma per capire a che punto è
un file bisogna guardare in tre posti.
Ci stai chiedendo di guardare nel quarto posto.

Ancora, scaricare il file, modificarlo, portarlo in gitorious sono
lavori da fare.
Ora ci aggiungiamo quello delle revisioni (in generale
ragionevolissimo), magari solo per l'attributo 'link'.

Io ti pregherei di fare un lavoro orientato a due obiettivi, che trovo
fondamentali.
1) aggiornare il manuale, che è importantissimo per le new entry e per
l'immagine di Gentoo;
2) sgrossare la lista, che importantissimo per noi.

Il primo lavoro, se non ti basta il lavoro fatto finora, va fatto
concentrandosi. Potremmo circoscriverci a quello (non è rimasto così
tanto) e cercare di mettere in "archivio" un task di soddisfazione
generale che ci riporterebbe a un senso di normalità.

Il secondo può essere fatto pubblicando senza troppe revisioni i file semplici.
Per quello, giorni fa, ti ho mandato una lista in cui distinguevo la
rilevanza dei casi.
Ci sono diverse decine di file troppo semplici per essere sottoposti a
tutto questo lavoro, davvero.

Se seguissimo questa strada, nel giro di pochi giorni potremmo
trovarci con poche decine di documenti ancora da esaminare, con il
risultato che potremmo stabilire nuove priorità e il lavoro di tutti
sarebbe molto più agevole e gradevole.

Il file, nella forma che dici tu, nel frattempo l'ho mandato.
Ma ti pregherei almeno di tener conto del mio invio precedente per
capire quali sono i casi elementari
Un 'diff -u 0 fileA fileB |wc -l' ti aiuterà ulteriormente (non sono
sicuro di quel '-u 0').

Ciao,
Sergio


HUjuice
mooodcast.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Marco Paolone
In reply to this post by Agostino Sarubbo-2
Il giorno 10 febbraio 2012 20:59, Agostino Sarubbo <[hidden email]> ha scritto:

> bisognerebbe avere il repository cvs aggiornato localmente, oppure se si vuole
> si può scaricare ogni volta il file da confrontare, quindi successivamente:
> diff -ru $file_in_cvs_it $file_in_bump(it ovviamente)
>
> Questo diff sarà successivamente confrontato con il diff che il cvs propone
> (da dev.gentoo.org/~ago/trads-it.xml)
>
> Quindi bisogna assicurarsi che la modifica alla nostra traduzione corrisponda
> esattamente alla modifica che cvs propone, possibilmente rivedendo possibili
> 'typo'

Forse abbiamo un po' sottovalutato git per l'uso che volevamo farne. Il metodo
migliore in questo caso sarebbe stato evitare di creare due cartelle distinte
(gentoo/ e bump/), in modo da modificare un singolo file e con 'git diff'
(aiutandoci anche con --stat) andare dritti al punto, rendendo anche più facile
il lavoro di revisione.

A questo punto, invece di dare un --unified, non converrebbe mostrare il diff
su due colonne distinte? Ad esempio:

diff -W 200 --suppress-common-lines -y
gentoo/xml/htdocs/doc/it/guide-to-mutt.xml bump/guide-to-mutt.xml

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Daniele Segato
On 02/19/2012 11:27 AM, Marco wrote:
> Forse abbiamo un po' sottovalutato git per l'uso che volevamo farne.

è normale quando non si conosce uno strumento

> Il metodo
> migliore in questo caso sarebbe stato evitare di creare due cartelle distinte
> (gentoo/ e bump/), in modo da modificare un singolo file e con 'git diff'
> (aiutandoci anche con --stat) andare dritti al punto, rendendo anche più facile
> il lavoro di revisione.

non è mai tardi per tornare indietro

ma se lo si fà e meglio prima pensarla bene in modo da valutare ogni
necessità :)


io, aimhe, non avendo ancora tradotto nulla non ho abbastanza chiaro
tutto il giro per poter pensare a qualcosa

la struttura sotto gentoo/
è la stessa di csv?

l'abbiamo ripresa noi uguale?
per qualche ragione?

da quel che vedo bump/ corrisponde a gentoo/xml/htdocs/doc/en/

per noi è necessario mantenere tutta la struttura htdocs/doc/en ?

come viene usata la copia inglese oltre alla mera "traduzione" ?

e perché htdocs/doc/en e htdocs/doc/it differiscono nella struttura?

cosa c'è dentro
htdocs/doc/it


sono tutte cose che mi sono poco chiare

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

HUjuice
> la struttura sotto gentoo/
> è la stessa di csv?

Sostanzialmente quella directory non è utilizzata.
Di fatto stiamo usando solo bump, come se fosse una dropbox.

Il problema, è che comunque ci organizziamo, tener conto dello "stato"
di un file non è immediato.
Un file infatti può essere:
1. da aggiornare
2. in corso di aggiornamento
3. da revisionare
4. in corso di revisione
5. in corso di pubblicazione
6. aggiornato

Attualmente è così:
- un documento è aggiornato (6) se ha la palla verde in
http://dev.gentoo.org/~ago/trads-it.xml
- un documento è in corso di pubblicazione (5) se appare in
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
- un documento è in corso di revisione (4) se appare in
https://gitorious.org/documentazione-italiana-gentoo-linux/documentazione-italiana-gentoo-linux/blobs/master/revisioni.txt
- un documento da revisionare (3) se appare in
https://gitorious.org/documentazione-italiana-gentoo-linux/documentazione-italiana-gentoo-linux/trees/master/bump
ma non appare in
https://gitorious.org/documentazione-italiana-gentoo-linux/documentazione-italiana-gentoo-linux/blobs/master/revisioni.txt
- un documento è in corso di aggiornamento (2) o da aggiornare (1)
se... non appartiene a nessuno degli altri 4 casi.

Quello che ci vorrebbe è uno strumento capace di fare automaticamente
questa analisi e produrre dei rapporti sullo stato dei documenti.
Sembra facile, ma poi non lo è.

Sergio


HUjuice
mooodcast.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: review

Daniele Segato
On 02/21/2012 06:51 PM, HUjuice wrote:
>> la struttura sotto gentoo/
>> è la stessa di csv?
>
> Sostanzialmente quella directory non è utilizzata.
> Di fatto stiamo usando solo bump, come se fosse una dropbox.

scusa ma non mi è chiaro cosa intendete per "revisione"
cosa fate?

io mi immagino che la traduzione venga letta e valutata buona / non buona

> Il problema, è che comunque ci organizziamo, tener conto dello "stato"
> di un file non è immediato.
> Un file infatti può essere:
> 1. da aggiornare

--> traduzione obsoleta

> 2. in corso di aggiornamento

--> qualcuno sta traducendolo

> 3. da revisionare

--> qualcuno ha tradotto e ha fatto commit + push

> 4. in corso di revisione

--> qualcuno ha cominciato a leggerlo / guardare le modifiche per capire
se vanno bene
e quindi ha modificato revisioni.txt, ha fatto commit e push per far
sapere che lo sta revisionando

> 5. in corso di pubblicazione

--> qualcuno ha tolto da revisioni.txt il file, considerato come OK per
la pubblicazione e ha aperto un ticket su bugs.gentoo.org per
richiederne la pubblicazione

> 6. aggiornato

--> il documento ha raggiunto l'online e la versione corrisponde a
quella inglese


> Attualmente è così:
> - un documento è aggiornato (6) se ha la palla verde in
> http://dev.gentoo.org/~ago/trads-it.xml
> - un documento è in corso di pubblicazione (5) se appare in
> 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
> - un documento è in corso di revisione (4) se appare in
> https://gitorious.org/documentazione-italiana-gentoo-linux/documentazione-italiana-gentoo-linux/blobs/master/revisioni.txt
> - un documento da revisionare (3) se appare in
> https://gitorious.org/documentazione-italiana-gentoo-linux/documentazione-italiana-gentoo-linux/trees/master/bump
> ma non appare in
> https://gitorious.org/documentazione-italiana-gentoo-linux/documentazione-italiana-gentoo-linux/blobs/master/revisioni.txt
> - un documento è in corso di aggiornamento (2) o da aggiornare (1)
> se... non appartiene a nessuno degli altri 4 casi.


grazie della spiegazione


> Quello che ci vorrebbe è uno strumento capace di fare automaticamente
> questa analisi e produrre dei rapporti sullo stato dei documenti.
> Sembra facile, ma poi non lo è.


il problema è che si basa su ciò che viene scritto dalle persone, giusto?
* è una persona a modificare revisioni.txt --> soggetto ad errori / non
essere aggiornato
* il testo del bug report è scritto da qualcuno
* ... altro

giusto?

Loading...