Traduzioni e procedure [Era: indovinello]

[Gianluca Sforna]

2009/4/17 Pierro Silvio <perplesso82(a)gmail.com&gt;:
>  Hai trovato un termine poco chiaro, ben fatto. 
No non è un
termine poco chiaro, è un termine che non c'entra proprio
nulla (ammesso che esista). Se non ci fosse stata anche la parola
"MinGW" non avrei proprio avuto idea del contenuto del gruppo.

Da notare che non voglio stigmatizzare in alcun modo i traduttori
della stringa specifica, l'ho usata solo come esempio per evidenziare
che nelle procedure mi sembra ci sia spazio per qualche
aggiustamento/miglioramento.

Per la cronaca, chi può decidere su eventuali variazioni?


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna

[Francesco Tombolini]

Gianluca Sforna ha scritto:
>  2009/4/17 Pierro Silvio <perplesso82(a)gmail.com&gt;:
>    
> > Hai trovato un termine poco chiaro, ben fatto.
> >     
>  No non è un termine poco chiaro, è un termine che non c'entra proprio
>  nulla (ammesso che esista). Se non ci fosse stata anche la parola
>  "MinGW" non avrei proprio avuto idea del contenuto del gruppo.
>  Da notare che non voglio stigmatizzare in alcun modo i traduttori
>  della stringa specifica, l'ho usata solo come esempio per evidenziare
>  che nelle procedure mi sembra ci sia spazio per qualche
>  aggiustamento/miglioramento.
>
>  Per la cronaca, chi può decidere su eventuali variazioni 
Il team si riunisce su
#fedora-trans-it per discutere eventuali
variazioni sulle procedure.
Solitamente ci si riuniva il mercoledi sera, con cadenza quindicinale,
cè una pagina di calendario degli incontri non aggiornata su:
https://fedoraproject.org/wiki/L10N/Teams/Italian/meetings
Il canale è quasi sempre solitario, a meno che non si indica una
riunione specifica.
Aggiungi un sunto dei temi da trattare come ordine del giorno
nell'ultima riga della tabella.
Poi stabiliamo una data per la riunione qui in ml.
Ciao

-- 
Francesco Tombolini <tombo(a)adamantio.net&gt; <tombo(a)fedoraproject.org&gt;
Key fingerprint = EDA9 7504 AA93 CEFC 5990  1356 8584 6B05 F140 5F73
http://www.adamantio.net

[Guido Grazioli]

Beh nessuno ti vieta di prendere un pacchetto per una seconda (o n-esima)
revisione; lo sforzo del primo traduttore è quello di cercare di capire e
rendere
il significato di una frase, da li in poi si correggono prima gli errori di
contenuto, poi la forma e cosi' via.

Purtroppo l'obiettivo di fare traduzioni al 100% spesso porta a fare
errori grossolani, e il nostro numero esiguo altrettanto spesso spinge
per motivi di tempo a tentare traduzioni parola per parola, piuttosto che
cercare di capire un concetto e riscriverlo in italiano.

Personalmente, consiglierei a tutti di skippare le msgstr su cui non si è
sicuri; se si tratta di moduli, il piu' delle volte sono i messaggi a
console
quelli più criptici, e chi se li trova davanti, sono sicuro che preferisce
la versione inglese piuttosto di una italiana che possa fuorviare un
significato. Se si tratta di documentazione utente, l'effetto è anche
peggiore

Ricapitolando, se sei sicuro di poter migliorare una traduzione di un
pacchetto
che ha finito il ciclo di traduzione/revisione, io sono per l' "avverti e
vai".
Stessimo pacchettizzando rpm, lì ci vorrebbe un manutentore per ogni
pacchetto, ma qui vedo la cosa collaborativamente più aperta.

guido


Il giorno 17 aprile 2009 13.21, Gianluca Sforna <giallu(a)gmail.com&gt; ha
scritto:

>  2009/4/17 Pierro Silvio <perplesso82(a)gmail.com&gt;:
>  > Hai trovato un termine poco chiaro, ben fatto.
>  No non è un termine poco chiaro, è un termine che non c'entra proprio
>  nulla (ammesso che esista). Se non ci fosse stata anche la parola
>  "MinGW" non avrei proprio avuto idea del contenuto del gruppo.
>
>  Da notare che non voglio stigmatizzare in alcun modo i traduttori
>  della stringa specifica, l'ho usata solo come esempio per evidenziare
>  che nelle procedure mi sembra ci sia spazio per qualche
>  aggiustamento/miglioramento.
>
>  Per la cronaca, chi può decidere su eventuali variazioni?
>
>
>  --
>  Gianluca Sforna
>
>  http://morefedora.blogspot.com
>  http://www.linkedin.com/in/gianlucasforna
>
>  --
>  Fedora-trans-it mailing list
>  Fedora-trans-it(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-trans-it
>  


-- 
Guido Grazioli <guido.grazioli(a)gmail.com&gt;
Via Parri 11 48011 - Alfonsine (RA)
Mobile: [phone] (10-18)
Key FP = 7040 F398 0DED A737 7337  DAE1 12DC A698 5E81 2278
Linked in: http://www.linkedin.com/in/guidograzioli

[Francesco Tombolini]

Ottimo Guido, confermo

Guido ha scritto:
>  Beh nessuno ti vieta di prendere un pacchetto per una seconda (o
> n-esima)
>  revisione; lo sforzo del primo traduttore è quello di cercare di
>  capire e rendere
>  il significato di una frase, da li in poi si correggono prima gli
>  errori di
>  contenuto, poi la forma e cosi' via. 
Le revisioni di un pacchetto terminato
secondo le nostre procedure
possono essere effettuate anche dopo che il pacchetto è stato inviato su
transifex.

Le revisioni di un pacchetto terminato sono equivalenti ad una nuova
traduzione, per cui chi prende l'incarico dovrà cercare a sua volta un
revisore al fine di assicurare la qualità.

Comunque in tempo di rilascio di versione, il team concentra gli sforzi
sui pacchetti non tradotti, al fine di fornire la massima copertura
possibile, mantenendo al lavoro almeno due persone per modulo.

Una volta garantito l'obbiettivo minimo (aver tradotto se possibile
tutti i pacchetti) il team può concedersi alle revisioni di quei
pacchetti che notoriamente  (per il team) possono essere più imprecisi.

Comunque il presupposto per considerare il lavoro terminato, è il
completamento della traduzione del modulo, che una volta sottoposto alla
procedura di traduzione/revisione è considerato qualitativamente
accettabile.

Sarebbe interessante che una seconda revisione scaturisse  da qualcosa 
di più sistematico e tracciabile che da una lettura casuale o da una
mail indovinello, come ad esempio un errore in bugzilla od un esperienza
diretta.

Le segnalazioni in bugzilla ci consentono di ricevere contributi anche
da non appartenenti al team.

Le segnalazioni in bugzilla creano quella precedentazione necessaria al
team affinché si capisca quali sono i pacchetti completati che
richiedano maggior attenzione.

Gli errori poi possono essere risolti in maniera puntuale (risoluzione
della problematica specifica) o a livello di revisione dell'intero file.

>  Purtroppo l'obiettivo di fare traduzioni al 100% spesso porta a
> fare
>  errori grossolani, e il nostro numero esiguo altrettanto spesso spinge
>  per motivi di tempo a tentare traduzioni parola per parola, piuttosto che
>  cercare di capire un concetto e riscriverlo in italiano.
>
>  Personalmente, consiglierei a tutti di skippare le msgstr su cui non si è
>  sicuri; se si tratta di moduli, il piu' delle volte sono i messaggi a
>  console
>  quelli più criptici, e chi se li trova davanti, sono sicuro che preferisce
>  la versione inglese piuttosto di una italiana che possa fuorviare un
>  significato. Se si tratta di documentazione utente, l'effetto è anche
>  peggiore
>
>  Ricapitolando, se sei sicuro di poter migliorare una traduzione di un
>  pacchetto
>  che ha finito il ciclo di traduzione/revisione, io sono per l'
>  "avverti e vai". 
Il nodo fondamentale del team è proprio questo
"avverti e vai" sia per
tradurre che per revisionare.

>  Stessimo pacchettizzando rpm, lì ci vorrebbe un manutentore per ogni
>  pacchetto, ma qui vedo la cosa collaborativamente più aperta.
>  guido 
Ciao

-- 
Francesco Tombolini <tombo(a)adamantio.net&gt; <tombo(a)fedoraproject.org&gt;
Key fingerprint = EDA9 7504 AA93 CEFC 5990  1356 8584 6B05 F140 5F73
http://www.adamantio.net

[Gianluca Sforna]

2009/4/17 Guido <guido.grazioli(a)gmail.com&gt;:
>  Beh nessuno ti vieta di prendere un pacchetto per una seconda (o
> n-esima)
>  revisione; lo sforzo del primo traduttore è quello di cercare di capire e
>  rendere
>  il significato di una frase, da li in poi si correggono prima gli errori di
>  contenuto, poi la forma e cosi' via.
>
>  Purtroppo l'obiettivo di fare traduzioni al 100% spesso porta a fare
>  errori grossolani, e il nostro numero esiguo altrettanto spesso spinge
>  per motivi di tempo a tentare traduzioni parola per parola, piuttosto che
>  cercare di capire un concetto e riscriverlo in italiano. 
Si, il punto è proprio che si ha l'impressione che l'obiettivo
quantità stia danneggiando la qualità.

>  Personalmente, consiglierei a tutti di skippare le msgstr su cui non si è
>  sicuri; se si tratta di moduli, il piu' delle volte sono i messaggi a
>  console
>  quelli più criptici, e chi se li trova davanti, sono sicuro che preferisce
>  la versione inglese piuttosto di una italiana che possa fuorviare un
>  significato. Se si tratta di documentazione utente, l'effetto è anche
>  peggiore 
Sono d'accordo. Io suggerirei anche di coinvolgere più spesso la
lista: mi pare che quando qualcono accetta la revisione eventuali
domande e/o ulteriori discussioni avvengano fuori lista. E' possibile
che qualcosa possa migliorare con più occhi ad osservare il processo.


>  Stessimo pacchettizzando rpm, lì ci vorrebbe un manutentore per ogni
>  pacchetto, ma qui vedo la cosa collaborativamente più aperta. 
Questo è un altro pensiero che mi ha sfiorato... Gli rpm hanno un
maintainer principale e un numero variabile di co-maintainer: mi pare
che assomigli al workflow che usiamo col wiki, per cui mi chiedo se
non si possa applicare anche al resto.

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna

[Gianluca Sforna]

2009/4/18 Francesco Tombolini <tombo(a)adamantio.net&gt;:
>  Le revisioni di un pacchetto terminato secondo le nostre procedure
>  possono essere effettuate anche dopo che il pacchetto è stato inviato su
>  transifex.
>
>  Le revisioni di un pacchetto terminato sono equivalenti ad una nuova
>  traduzione, per cui chi prende l'incarico dovrà cercare a sua volta un
>  revisore al fine di assicurare la qualità.
>
>  Comunque in tempo di rilascio di versione, il team concentra gli sforzi
>  sui pacchetti non tradotti, al fine di fornire la massima copertura
>  possibile, mantenendo al lavoro almeno due persone per modulo. 
Fin qui, tutto ok...

>  Una volta garantito l'obbiettivo minimo (aver tradotto se possibile
>  tutti i pacchetti) il team può concedersi alle revisioni di quei
>  pacchetti che notoriamente  (per il team) possono essere più imprecisi. 
Ma bisogna sapere quali sono (vedi sotto)

>  Comunque il presupposto per considerare il lavoro terminato, è il
>  completamento della traduzione del modulo, che una volta sottoposto alla
>  procedura di traduzione/revisione è considerato qualitativamente
>  accettabile.
>
>  Sarebbe interessante che una seconda revisione scaturisse  da qualcosa
>  di più sistematico e tracciabile che da una lettura casuale o da una
>  mail indovinello, come ad esempio un errore in bugzilla od un esperienza
>  diretta. 
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.

>  Le segnalazioni in bugzilla ci consentono di ricevere contributi anche
>  da non appartenenti al team.
>
>  Le segnalazioni in bugzilla creano quella precedentazione necessaria al
>  team affinché si capisca quali sono i pacchetti completati che
>  richiedano maggior attenzione. 
Sono d'accordo (e se fosse necessario mi scuso ancora per la mail
indovinello, che però pare abbia sortito l'effetto che speravo, ovvero
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.

Ogni commento/proposta è benvenuto

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna

[Guido Grazioli]

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?

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

Il giorno 21 aprile 2009 16.24, Gianluca Sforna <giallu(a)gmail.com&gt; ha
scritto:

>  2009/4/18 Francesco Tombolini <tombo(a)adamantio.net&gt;:
>  > Le revisioni di un pacchetto terminato secondo le nostre procedure
>  > possono essere effettuate anche dopo che il pacchetto è stato inviato su
>  > transifex.
>  >
>  > Le revisioni di un pacchetto terminato sono equivalenti ad una nuova
>  > traduzione, per cui chi prende l'incarico dovrà cercare a sua volta un
>  > revisore al fine di assicurare la qualità.
>  >
>  > Comunque in tempo di rilascio di versione, il team concentra gli sforzi
>  > sui pacchetti non tradotti, al fine di fornire la massima copertura
>  > possibile, mantenendo al lavoro almeno due persone per modulo.
>
>  Fin qui, tutto ok...
>
>  >
>  > Una volta garantito l'obbiettivo minimo (aver tradotto se possibile
>  > tutti i pacchetti) il team può concedersi alle revisioni di quei
>  > pacchetti che notoriamente  (per il team) possono essere più imprecisi.
>
>  Ma bisogna sapere quali sono (vedi sotto)
>
>  >
>  > Comunque il presupposto per considerare il lavoro terminato, è il
>  > completamento della traduzione del modulo, che una volta sottoposto alla
>  > procedura di traduzione/revisione è considerato qualitativamente
>  > accettabile.
>  >
>  > Sarebbe interessante che una seconda revisione scaturisse  da qualcosa
>  > di più sistematico e tracciabile che da una lettura casuale o da una
>  > mail indovinello, come ad esempio un errore in bugzilla od un esperienza
>  > diretta.
>
>  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.
>
>  >
>  > Le segnalazioni in bugzilla ci consentono di ricevere contributi anche
>  > da non appartenenti al team.
>  >
>  > Le segnalazioni in bugzilla creano quella precedentazione necessaria al
>  > team affinché si capisca quali sono i pacchetti completati che
>  > richiedano maggior attenzione.
>
>  Sono d'accordo (e se fosse necessario mi scuso ancora per la mail
>  indovinello, che però pare abbia sortito l'effetto che speravo, ovvero
>  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.
>
>  Ogni commento/proposta è benvenuto
>
>  --
>  Gianluca Sforna
>
>  http://morefedora.blogspot.com
>  http://www.linkedin.com/in/gianlucasforna
>
>  --
>  Fedora-trans-it mailing list
>  Fedora-trans-it(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-trans-it
>  


-- 
Guido Grazioli <guido.grazioli(a)gmail.com&gt;
Via Parri 11 48011 - Alfonsine (RA)
Mobile: [phone] (10-18)
Key FP = 7040 F398 0DED A737 7337  DAE1 12DC A698 5E81 2278
Linked in: http://www.linkedin.com/in/guidograzioli

[Francesco Tombolini]

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=tra...
,   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(a)gmail.com
>  <mailto:[e-mail]>> 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

-- 
Francesco Tombolini <tombo(a)adamantio.net&gt; <tombo(a)fedoraproject.org&gt;
Key fingerprint = EDA9 7504 AA93 CEFC 5990  1356 8584 6B05 F140 5F73
http://www.adamantio.net

[Guido Grazioli]

ok per i meeting, personalmente preferisco il weekend

Il giorno 22 aprile 2009 21.46, Francesco Tombolini <tombo(a)adamantio.net&gt; ha
scritto:

>  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=tra...
>  ,   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(a)gmail.com
>  > <mailto:[e-mail]>> 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
>
>  --
>  Francesco Tombolini <tombo(a)adamantio.net&gt; <tombo(a)fedoraproject.org&gt;
>  Key fingerprint = EDA9 7504 AA93 CEFC 5990  1356 8584 6B05 F140 5F73
>  http://www.adamantio.net
>
>
>
>  --
>  Fedora-trans-it mailing list
>  Fedora-trans-it(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-trans-it
>  


-- 
Guido Grazioli <guido.grazioli(a)gmail.com&gt;
Via Parri 11 48011 - Alfonsine (RA)
Mobile: [phone] (10-18)
Key FP = 7040 F398 0DED A737 7337  DAE1 12DC A698 5E81 2278
Linked in: http://www.linkedin.com/in/guidograzioli