2009/4/17 Pierro Silvio perplesso82@gmail.com:
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 ha scritto:
2009/4/17 Pierro Silvio perplesso82@gmail.com:
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
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@gmail.com ha scritto:
2009/4/17 Pierro Silvio perplesso82@gmail.com:
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-trans-it
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
2009/4/18 Francesco Tombolini tombo@adamantio.net:
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
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@gmail.com ha scritto:
2009/4/18 Francesco Tombolini tombo@adamantio.net:
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-trans-it
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-... , 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
ok per i meeting, personalmente preferisco il weekend
Il giorno 22 aprile 2009 21.46, Francesco Tombolini tombo@adamantio.net 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=trans-... , 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 diuna
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@adamantio.net tombo@fedoraproject.org Key fingerprint = EDA9 7504 AA93 CEFC 5990 1356 8584 6B05 F140 5F73 http://www.adamantio.net
-- Fedora-trans-it mailing list Fedora-trans-it@redhat.com https://www.redhat.com/mailman/listinfo/fedora-trans-it
2009/4/17 Guido guido.grazioli@gmail.com:
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.
trans-it@lists.fedoraproject.org
-
Daniele Catanesi -
Francesco Tombolini -
Gianluca Sforna -
Guido Grazioli