Guido ha scritto:
mmh, bugzilla già scoppia così com'è, se ci si mettono ache gli utenti
a compilare report
di errore sulle traduzioni, è la fine; d'altra parte anche usarlo tra
di noi secondo me è
controproducente, ci siamo costituiti in team e abbiamo una mailing
list proprio
per collaborare no?
L'utente finale ha diversi modi per segnalare gli errori, chat irc
(raro), mail diretta ad uno di noi (grazie alle tracce che lasciamo
sulla wiki https://fedoraproject.org/wiki/L10N/Teams/Italian/Manutentori
, visto che con l'abbandono di damned lies in favore di transifex stiamo
tendendo a perdere l'uso delle pagine dei team), mailing list (che
comunque è al momento una risorsa riservata ai soli iscritti), svariati
bugzilla (sia quelli di rh con la possibilità di aprire i bug verso il
linguaggio in generale
https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=trans-it
, sia quelli specifici dei pacchetti ovunque si trovino).
Sicuramente che bugzilla sia saturo è un problema oggettivo, per questo
fedora si è dotata dei bug-zappers (gruppo fas) per cercare di unificare
e chiudere i bug duplicati od obsoleti, ciò nonostante rimane lo
strumento di riferimento per l'invio delle segnalazioni d'errore.
Infatti, come progetto fedora, ne riportiamo il link in tutti i
software, nei documenti, nelle pagine di presentazione dei team di
traduzione etc...
Ma è anche fuori discussione proprio come indica Guido, che per gli
appartenenti al progetto, ed a maggior ragione per gli appartenenti al
team, la segnalazione di un errore in mailing list, rappresenti una
segnalazione sufficiente, che deve accendere un azione di correzione.
a proposito di infrastruttura, quello che manca è la possibilità di
cercare un termine
in lingua tra le traduzioni già effettuate che lo contengono, ed avere
cosi' un
elenco di riferimento di traduzioni *contestualizzato*; sarebbe un
valore aggiunto non da poco
rispetto a un semplice thesaurus
se questo poi si trovasse all'interno di una applicazione web che
permette di inserire
le traduzione riga a riga agli utenti autenticati, e che in automatico
scarica e fa
il merge dei pot aggiornati......
guido
Su questo punto concordo, ed aggiungo che queste sono tematiche che
vanno affrontate a livello di intero progetto, e non di team.
Come team ritengo che abbiamo il compito di organizzarci al meglio per
garantire traduzioni di qualità con gli strumenti offerti dalle
infrastrutture fedora.
Vi stimolo a partecipare agli incontri di gruppo (che sono aperti a tutti)
https://fedoraproject.org/wiki/L10N/Meetings
per tenervi aggiornati sugli sviluppi in atto, e se opportuno, apportare
il vostro contributo in quella sede.
Il giorno 21 aprile 2009 16.24, Gianluca Sforna <giallu@gmail.com
<mailto:giallu@gmail.com>> ha scritto:
Il fatto è che se un modulo è al 100% di copertura (e abbiamo detto
che questo è l'obiettivo numero uno) difficilmente viene riaperto per
farne una seconda revisione. Quindi l'unico modo per accorgersi di una
traduzione farlocca è inciamparci come utilizzatore (credo sia questo
a cui ti riferisci con "esperienza diretta") come è successo a me per
i cross compilatori. Nel mio caso, so dove guardare/come contribuire
per risolvere, ma ho paura che un utente scrolli le spalle e passi ad
altro, rimanendo con una impressione di scarsa competenza.
Credo che tu abbia descritto una cosa normale. Come team-it abbiamo
assunto che i files precedentemente lavorati fossero già
qualitativamente accettabili (prescindendo dal metodo con cui si
lavorasse in precedenza).
Bene, detto questo, credo sia arrivato il momento di valutare una
pianificazione per la revisione totale di tutti(!) i pacchetti che ne
hanno bisogno.
Ho aggiornato la wiki dei meeting per il nostro team:
https://fedoraproject.org/wiki/L10N/Teams/Italian/meetings
...parlare della qualità) sul migliorare la tracciabilità dei
problemi.
Purtroppo bugzilla non è proprio il tool più facile da usare per il
neofita, quindi assumendo che il grosso degli utenti non sia troppo
tecnico, è difficile che riporteranno qualcosa con quel mezzo (quanti
bug ci sono aperti al momento?)
Inoltre, anche se avessimo qualche centinaio di bug report, non
sarebbe facile estrarre le statistiche necessarie, visto che il
componente non è fra i campi filtrabili del report, per cui anche se
l'idea è buona ci servirebbe qualche nuovo pezzo di "infrastruttura"
Riassumendo, la mia opinione è che bisognerebbe cercare di aumentare
la qualità della prima revisione, in modo che alle successive sia
sufficiente concentrarsi sulle stringhe nuove/fuzzy.
Oggi come oggi abbiamo centinaia di cataloghi in produzione, fedora è
tradotta in italiano (per quanto riguarda la nostra sfera d'azione) al
90%, perciò di solito abbiamo a che fare con file po che riportano
parziali modifiche per qualche decina di stringhe, quindi quasi nulla è
"nuovo".
Direi di sviscerare meglio questi contenuti in riunione che ne dite di
mercoledì prossimo o nel weekend?
Ciao
--
Fedora-trans-it mailing list
Fedora-trans-it@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-trans-it