[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-it
Subject:    Re: Anarchia
From:       "Andrea RIZZI" <rizzi () sns ! it>
Date:       2003-09-26 14:44:37
[Download RAW message or body]

On Fri, 26 Sep 2003 14:50:48 +0200
>
> Il topic proposto da Andrea è ovviamente assurdo e la
> logica delle modifiche
> apportate sul CVS è stata la seguente:

Risponderò punto per punto.

> a) non toccare i file dei commit-ers che hanno mostrato
> attività recente (< di
> un mese)
Siamo passati all'HEAD da 15 giorni, praticamente nessuno
ha ancora iniziato a lavorarci  visto che il freeze è
ancora lontano, il che non vuol dire che  un file senza
recente attività sia abbandonato. Inoltre chi non ha
l'account CVS (molti) lavora di solito in locale e non mi
manda gli aggiornamenti ogni minuto.

> b) aggiornare i fuzzy, tradurre le voci (generalmente
> quando ne mancavano meno
> di una trentina) dei file intoccati da oltre un mese (la
> media era ~5 mesi)
> che rispettassero il punto a)
Vedi la risposta al punto a) 5 mesi non vogliono dire nulla
specialmente considerando che quelle date si riferiscono
alle modifche sul branch (visto che li abbiamo
sovrascritti) il quale è stabile da mesi e quindi non
necessita di modifiche. Inoltre è normale che in mezzo alle
major release ci siano lunghi periodi in cui il gruppo è
meno attivo (almeno per la GUI).
.
> c) aggiungere i nuovi file e completarne, nel limite del
> possibile, la
> traduzione.
Non si capisce per quale motivo tutti noi dobbiamo
utilizzare il sistema di assegnazione per i nuovi file e tu
no.

> Riconosco di aver peccato di comunicazione verso i
> singoli traduttori, anche
> se nella maggior parte dei casi le modiche erano
> irrisorie per completare la
> traduzione (..poche "fuzzy").
Non in tutti i casi, per kio.po non solo non erano pochi
fuzzy ma hai anche deciso di modificare delle voci già
tradotte tra l'altro con una traduzione che sapevi che non
piaceva al responsabile del file in question.
Inoltre kdelibs_color era parzialmente tradotto sul mio HD
e lo stavo usando per testare una nuova
funzione[CapitalLetterSplitting] di kbabel (del serach
engine nuovo).

> Per chi lavora in locale: non siamo in freeze, quindi con
> file da tradurre
> fortemente mutabili, mi chiedo come si possa lavorare
> senza tempi "rapidi"
> tra checkout-commit o senza giornalieri "cvs update" che
> aggiornino i file
> con label nuove o altre modifiche.
Purtroppo i tempi "rapidi" del CVS non sono accessibili a
tutti visto che non tutti hanno l'account CVS e la
procedura per mettere il file sul CVS tipicamente e
spedirlo a me che poi lo metto sul CVS il che può portare
attese anche di qualche giorno. Questo sistema non è quindi
utilizzabile dalla maggior parte dei traduttori e si
preferisce da sempre il seguente schema:
-il traduttore traduce la sua copia, quando è a buon punto
la manda a me che la metto sul CVS e si aspetta qualche
giorno in modo che gli script facciano il loro lavoro e i
CVS anonimi si aggiornino (forse sora sono sempre
aggiornati ma un tempo non era cosi)
-quando ci si avvicina alla relase le spedizioni a me si
intensificano e io dedico diverse ore al giorno a
controllare la posta e mettere sul CVS (oltre che a
tradurre) in modo da fornire anche a chi non ha accesso al
CVS la comodita' di tempi quasi-CVS-like.
Inoltre i traduttori più volenterosi si fanno il msgmerge
da soli (visto che gli script sono disponibili per tutti) e
non hanno bisogno del CVS se non alla fine (ipoteticamente
anche 1 ora prima della release)

> Aggiornare dal CVS è
> anche una delle
> raccomandazioni da seguire prima di qualsiasi commit.
Solo per chi ha l'accesso al CVS.

>
> IL SISTEMA DI GESTIONE
>
> il sistema di gestione presenta NOTEVOLI problemi e non
> mi stupisco che non
> sia stato ancora adottato da i18n.kde.org.
Non ci è stato messo perché io non ho mai chiesto di
mettere quello chifo scritto da uno che vedeva il php per
la prima volta sul sito ufficiale.
Io avevo chiesto a claudiu di fare qualcosa di simile ma
non credo avesse tempo per farlo.

>Per tale
> ragione suggerisco le
> seguenti modifiche per migliorare e rendere più
> efficiente le attività:
>
> a) Togliere la responsabilità su un pacchetto se il
> numero di "fuzzy" o voci
> non tradotte è superiore a un dato valore di percentuale.
> Segnalare la cosa
> con una mail automatica in lista, richiamando nuovi
> traduttori.
Questa di per se come regola non funziona visto che il
nuovo traduttore sarebbe subito rimosso dall'incarico in
quanto il file sarebbe ancora troppo fuzzy (al momento
della nuova assegnazione) quindi bisognerebbe dare un tempo
minimo per migliorarne lo stato...quanto? dipende dal file,
dal traduttore e dai suoi tempi liberi, dalla distanza
della release.

> b) Togliere la responsabilità su un pacchetto se l'ultima
> modifica è superiore
> a una COSTANTE che indica i giorni di inattività.
> Segnalare la cosa con una
> mail automatica in lista, richiamando nuovi traduttori.
Non ci importa di avere i file aggiornati in mezzo alle
relase anzi io trovo inutile portare tutto al 100% a due
mesi dalla release rischiando di vedere il mio lavoro
buttato da un cambio di stringhe.
L'unica cosa rilevante è riuscire ad avere completate le
cose per il giorno della release.

> c) Segnalare in lista, con una mail, l'apparsa di nuovi
> templates liberi e
> disponibili per la traduzione richiamando nuovi
> traduttori.
L'automatizzazione della disponibiltà dei nuovi file è un
argomento di cui stavamo già discutendo..
Per ora comunque io ho segnalato 15 giorni fa all'apertura
dell'HEAD
che c'erano nuovi file (sono facilmente riconoscibili dallo
status "no translation" nel sistema di assegnazione) e ho
anche detto ai nuovi traduttori che era il momento buono
per chiederli (dicendo anche che era presto per iniziare a
tradurre l'HEAD visto che siamo ben lontani dal freeze)...
peccato che molti di questi file te li sei presi tu senza
neanche degnarti di usare il sistema di assegnazione.

> d) Inviare una mail diretta che solleciti ogni singolo
> traduttore a terminare
> il proprio lavoro su [la lista dei file non completamente
> tradotti]: sulla
> mail dovrà essere riportato un collegamento web dove è
> possibile:
>
>        "Declinare" la responsabiità su singoli file e la
> possibilità di aggiungere
> una motivazione (es. "non ho tempo", "ho altro da fare")
> che sarà prontamente
> riassuna in lista con una mail e rimetterà in gioco i
> file senza
> responsabile.
Con questa tua politica (unita al punto b di questo elenco)
io non dovrei avere neanche un file visto che li faccio
tutti nelle ultime settimane eppure i miei file nel momento
in cui conta (alla release) sono sempre tradotti al 100%.

>       "Accettare", per proseguire la traduzione.
>
> L'invio dovrà essere ripetuto "n" volte (una costante) e
> inviato in
> corrispondenza di date predetermiante (es. freeze o
> prossime scadenze per
> l'invio). Se latita una scelta tra declinare/accettare il
> sistema dovrà
> inviare in lista una mail e richiamare un nuovo
> traduttore.
Cosi floodiamo sia la lista che le mailbox dei traduttori,
non solo li opprimiamo fino a quando non si stufano e ci
dicono va be allora declino tutto pur che non mi rompiate
le scatole.

> PERCHE' QUESTE MODIFICHE?
>
> Bisogna evitare che i file si riducano in pessimo stato
> senza ricevere
> modifiche da parecchi mesi (se non anni),
Il fatto che un file resti "abbandonato" per mesi non vuol
dire niente visto che conta SOLO lo stato al momento della
release e non è quasi (indovina le eccezioni..) mai
successo che un file arrivi non tradotto al 100% alla
release..

>lasciando che
> persone veramente
> interessate evolvano lo stato dell'arte in maniera
> efficiente in tempi
> rapidi.
COn questo vuoi dire che persone come me,Federico o
Astarita (che mi manda il pacchetto kdenetowrk sempre nelle
ultime due settimane :-)) non siamo interessati alle
traduzioni visto che "lasciamo i pacchetti abbandonati per
mesi"? E allora chi era che traduceva KDE negli ultimi 5
anni? Mago merlino?

> La disponibilità di ognuno di noi può variare nel
> tempo, ma è
> opportuno evitare che queste "assenze" blocchino
> l'evoluzione.
Forse non hai capito che spesso si tratta di una SCELTA, io
non traduco adesso perché molte traduzioni finirebbero nel
cesso causa cambio di stringhe mentre mi impegno per la
release.

Ci sono un po' di cose inoltre che mi lasciano perplesso:
1-Perché fai queste proposte di riforma adesso e non hai
detto prima che il sistema non ti piaceva
2-Perché proponi di aumentare l'automatizzazione del
processo ma già allo stato attuale ignori il sistema di
assegnazione... cosa mi dovrebbe far pensare che
utilizzeresti il tuo nuovo sistema di assegnazione visto
che già ora te ne freghi e lavori senza dir niente a
nessuno su file che potresti tranquillamente richiederecon
tre click.
3-Con che spirito ci fai una predica sui file abbandonati
quando sei l'unico ad aver abbandonato un file con 400
messaggi nell'unico momento che conta cioè ad un paio di
giorni dalla release

Io credo che il sistema di assegnazione sia una cosa utile
per ricordarsi chi fa cosa non per farci da cane da guardia
o da poliziotto, il rispettare quelle assegnazioni, le
discussioni su "a chi assegnare cosa" ecc.. sono lasciate a
noi come persone non ad uno script PHP nel pieno spirito
della comunità di KDE (non ci sono ACL sul CVS di KDE). Si
tratta di essere persone che si rispettano tra di loro, che
hanno fiducia le une nelle altre e che hanno un certo senso
di responsabilità. Credo che siamo riusciti, nel corso
degli anni, ad avere sempre queste condizioni soddisfatte e
non abbiamo mai problemi come quelli sorti ultimamente.

Ciao


_______________________________________________
Traduzioni di KDE in italiano: http://i18n.kde.org/teams/it
http://mail.kde.org/mailman/listinfo/kde-i18n-it
[prev in list] [next in list] [prev in thread] [next in thread]