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.
> <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:
> ...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?
--
Fedora-trans-it mailing list
Fedora-trans-it@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-trans-it