[PLUTO-ildp] Linee guida - ILDP

[Ferdinando]

* Monday 12 May 2003, alle 20:06, Eugenia Franzoni scrive:
> 
>   2.2.  Problemi
> 
>   Tanti ...
> 
>   ·  Aggiornare il documento reperibile presso
>      http://www.pluto.linux.it/ildp/HOWTO/statoTraduzioni.html
>      <http://www.pluto.linux.it/ildp/HOWTO/statoTraduzioni.html> che
>      rappresenta una fotografia delle differenze tra ildp e tldp.
> 
> ] E la sua copia in FTP
> 
>   ·  Per rendere più semplice la gestione del documento di cui al
>      precedente punto è necessario dare priorità all'aggiornamento dei
>      documenti già tradotti.
> 
> ] E possibilmente creare un qualche strumento automatico per farlo,
> ] evitando quindi che il coordinatore lo debba fare a mano

Se mi spiegate per filo e per segno, esattamente quali pagine sarebbero
da confrontare forse e dico forse posso provare a chiedere aiuto su
Python.it (almeno è un linguaggio che si adatta, con un ottimo parser
...). Però è necessario che mi spiegate un po' di cose, per esempio la
data per stabilire l'aggiornamento ... ci si basa sulla data
dell'upload o si "apre" ogni singolo documento e si guarda il TAG
<date> ?

Vedi anche più avanti.

>   ·  Chiarire bene il formato da adottare, su tldp adesso usano DocBook
> 
> ] Credo che la procedura corrente sia: si traduce nel formato del documento
> ] originale. Questo ha senso perche' diminuisce il lavoro di traduzione.

Va bene.

>   3.  Organizzazione
> 
>   L'organizzazione del progetto dovrebbe essere il più lineare, semplice
>   ed efficiente possibile, dovrebbe impegnare relativamente poco il
>   coordinatore ed attrarre il maggior numero possibile di newbie
> 
> ] Dovrebbe evitare gli sforzi che possono essere evitati. Non so se 
> ] si deve attrarre il maggior numero possibile di newbie, se con questo
> ] intendi che piu' persone che non ne sanno niente di linux o di roba
> ] tecnica partecipano alle traduzioni. Se invece parli degli utenti,
> ] sono d'accordo, anche perche' chi ha un background tecnico in genere
> ] ha piu' possibilita' di leggere i documenti direttamente in inglese.

La vera novità. rispetto al passato sarebbe proprio dividere il gruppo
del progetto in due gerarchie e cioè "coordinatore" ed i suoi stretti
collaboratori, revisori e tecnici.
Naturalmente un newbie deve essere quantomeno utente però, se ti viene
voglia di dare una mano in questo campo, se hai già letto qualcosa, di
solito non sei o almeno, non dovresti essere uno che non sa proprio
niente su GNU/Linux.
Però, prima di essere pronti ad una eventuale "chiamata alle armi"
bisogna organizzare tutto ed essere pronti.

>   Solamente il coordinatore ha il potere di assegnare una traduzione o
>   un'aggiornamento. Potrà certamente, contrariamente a queste linee
>   guida, discostarsene per accettare un documento che sia stato
>   realizzato per intero da un "esterno" o da un membro del gruppo di cui
>   ha fiducia, che avrà svolto tutti i passi che ci accingeremo a
>   descrivere da solo, in autonomia.
> 
> ] Qui Frick, l'altro giorno, ha tirato fuori una questione interessante.
> ] Si puo' gestire la cosa anche come "gruppi di interesse", in modo da
> ] far gestire documenti di argomenti coerenti allo stesso gruppo di persone.
> ] E' una metodologia interessante, che porterebbe a risultati di buona
> ] qualita', ma la faccio esporre a lui :-) 
> ] Questo per dire che il punto qui sopra non e' necessariamente indispensabile
> ] :-)

Nell'introduzione al documento già dicendo che "il coordinatore in caso
di documenti di una certa dimensione potrà decidere di spezzarli ed
assegnarli a più traduttori" già consideravo scontata questa
possibilità. Se ho ben capito tu intendi un particolare
"sottoprogetto", per documento o per area?
Se intendi per documento come ripeto è già previsto. Aggiungo la
facoltà di delega ad un particolare revisore che coordina il
sottoprogetto, tanto per estendere il concetto.
Se invece intendi l'area, io considero scontato che il coordinatore
debba conoscere i suoi diretti collaboratori e quindi possa assegnare i
documenti in base a conoscenze pregresse ...

A questo proposito, avete una se pur vaga idea di chi sono gli
"aficionados" in lista che possono diventare revisori vero?

>   Il sistema permetterà una traduzione o l'aggiornamento in maniera
>   semplice di un documento perché il traduttore lavorerà direttamente su
>   testo puro che rispedirà al coordinatore o direttamente al revisore se
>   già individuato.  (] ********** DECIDERE I PASSAGGI, SE PASSARE DAL
>   COORDINATORE O DELEGARE A REVISORE E TECNICO ] ***********) A questo
>   punto, aggiornato il post, con tanto di data e passaggio di mano del
>   documento, lo stesso verrà poi trasferito ad un tecnico, nella più
>   comoda versione in testo puro. Quest'ultimo controllerà la traduzione
>   dell'originale  e a lavoro ultimato, lo spedirà nuovamente al
> 
> ] Anche qui, vediamo :-)

Decidiamo, si può anche decidere di lasciare al coordinatore comunque
il potere di assegnare l'aggiornamento o la traduzione e lasciare la
sola figura del revisore. In questo caso il traduttore traduce
direttamente all'interno dei TAG, sicuramente si fa prima però c'è meno
revisione e secondo me qualcuno può avere problemi ...

Vedi il post di Massimo Soricetti, non capire che sezioni e caratteri
corsivi o comunque che non siano ASCII puro hanno dei caratteri di
controllo che rendono una visualizzazione diversa con un editor
significa essere a 0 con SGML, XML TAG o quant'altro.

>   revisore. Per meglio chiarire, il documento che riceverà il tecnico,
>   sarà stato realizzato dal revisore, che lascerà nel testo entrambe le
>   lingue, ovvero l'inglese originale e la traduzione.  Successivamente
>   il revisore, dopo aver ricevuto il testo, toglierà la parte in lingua
>   madre e revisionerà la restante parte in italiano.  Il documento sarà
>   così pronto per l'upload.
> 
> ] Oddio... perche' lasciare entrambe le lingue? Per il tecnico e' piu'
> ] comodo avere un altro documento con l'originale :-)

Come dicevo il procedimento è più lungo però considera che la prima
revisione la farebbe il revisore, la seconda il tecnico ed infine
nuovamente il revisore ... il documento finale sarebbe controllato
molto più approfonditamente. Comunque se ne può fare a meno, voi
sicuramente avete più esperienza di me in questo campo ...

>   3.1.  Riferimenti web
> 
>   Occorre inserire in questo spazio i riferimenti web di dove sono i
>   documenti da tradurre, quelli tradotti e quelli da aggiornare, questa
>   è la partenza, http://ftp.pluto.linux.it/pub/pluto/ildp/
> 
> ] Non http:// ma ftp:// :-)

Si, ma lynx mi abitua male ... ;-)

>   <http://ftp.pluto.linux.it/pub/pluto/ildp/>, se non ho capito male poi
>   ci dovrebbero essere ./HOWTO/sgml per i sorgenti degli HOWTO "pronti",
>   ./HOWTO/mini/sgml per i mini-HOWTO e ./Nuovi per i sorgenti "in
>   lavorazione", di cui fare successivamente l'upload.
> 
> ] Si dovrebbe seguire la stessa struttura di TLDP, unita ad una struttura
> ] parallela per la documentazione non appartenente ad LDP

Personalmente non ho ancora capito come sono le due strutture e quali
pagine sono da confrontare ...
 
> [Il coordinatore]
> 
>   I suoi compiti sono molteplici, i più importanti si possono così
>   sintetizzare:
> 
> [...]
> 
>   ·  Decidere a quali documenti dare priorità e richiederne la
>      traduzione o l'aggiornamento in lista.  (] ************** DARE
>      PRIORITA' AGLI AGGIORNAMENTI!!! ] ********)
> 
> ] Questo e' un altro punto che il coordinatore non puo' fare da solo.
> ] Non siamo tutti "imparati", quindi ci vogliono delle persone che
> ] abbiano competenze nei vari campi che possano decidere quali sono 
> ] i documenti piu' importanti. Anche questo puo' essere risolto con 
> ] la questione dei gruppi che diceva Frick :-)

Ma siamo così tanto indietro?!
Nel senso che occorre operare una scelta in un mare di roba non
tradotta?!

>   4.1.1.  Problemi
> 
>   Beh, ragazzi, chi ha fatto il coordinatore tiri fuori gli altarini!!!
> 
> ] Eccole :-)
> 
>   Io ho dato per scontato che i problemi maggiori siano state le e-mail
>   private che riceveva il coordinatore perché altrimenti serve a poco
>   discutere sul niente...
> 
> ] No, non e' questo: se si riesce a tenere aggiornato lo stato delle
> ] traduzioni non e' un problema avere email private. I problemi
> ] maggiori sono:

Pessima notizia, almeno per me.

> ] * la qualita' delle traduzioni (sia dal punto di vista tecnico che
> ]   da quello dell'italiano). Per questo sarebbe bene avere sia
> ]   revisori tecnici che revisori linguistici, e che a tradurre siano
> ]   solo persone almeno un minimo portate :-) (una volta ho provato a 
> ]   fare tradurre Simone Stevanin, il CapoTM, e ha rinunciato... si 
> ]   dovrebbe fare cosi' ;-)))

Ho capito però ... cosa vogliamo fare?
Mi sembra naturale che adesso la selezione vada fatta sulla figura del
revisore ...

> ] * l'aggiornamento dello stato traduzioni (risolvibile attraverso una
> ]   struttura almeno minimamente automatizzata)

Per questo occorre chiedere aiuto ... non demordiamo, magari con un
altro thread definiamo prima bene "cosa" un programma dovrebbe fare
(dove "parsare" e come) e poi ci muoviamo, io posso chiedere sulla ML
Debian-it e su quella di Python-it, è un bel po' che le frequento e
magari mi dicono di no ma almeno il post l'accettano.
Se poi mi dici che questo è il problema nr.1 in assoluto allora a costo
di spaccare i gioielli di famiglia a tutti il sistema occorre trovarlo.

> ] * i documenti fuori TLDP, che vanno comunque inseriti, ma necessitano
> ]   di una struttura diversa

E` vero, anche se prima forse è meglio pensare a quelli di tldp.
Intanto, temporaneamente un link accanto agli HOWTO con specificato che
per il momento sono così, allo stato dei fatti, senza essere curati,
magari in un solo formato ecc. ecc.

> ] * la questione formattazione: pochissimi qui hanno una SGML box 
> ]   (o una XML box) funzionante, e ancora pochi sanno scrivere SGML o XML.
> ]   Per questo finora i traduttori hanno tradotto tra i tag :-)

Beh, scusa ma _comunque_ con il metodo mio o con quello adottato finora
si scriverà tra i TAG, mica che documenti già in SGML vengono riscritti
da 0 ... o non ho capito?
Comunque per quanto riguarda il funzionamento corretto di DocBook ed
XML ancora il concetto chiaro non ce l'ho neanch'io (per quanto
riguarda la compilazione ...).

>   Il lavoro da fare più grosso è ora, perché, anche per avere una
>   manutenzione più semplice del "documento" è necessario fermarsi, fare
>   il punto ed aggiornare tutti i documenti già tradotti.  So che è una
>   palla però questa dovrebbe essere la priorità più urgente, dopo
>   dovrebbe diventare tutto più semplice.
> 
> ] Questo sicuramente :-)

Ok, intanto direi che potremmo fermarci ed iniziare ad usare la form.
Cominciando ad aggiornare i documenti già pronti.

>   4.4.  Il traduttore
> 
>   Sostanzialmente la figura più semplice ma forse la più importante è
>   quella del traduttore, può essere tranquillamente un newbie, (meglio
>   se lo fa presente ...), non vi sono problemi di sorta, l'unica
>   competenza richiesta è la volontà e la conoscenza dell'inglese. Con il
> 
> ] E, vi prego, dell'italiano :-)))
> ] Capita molte volte che le traduzioni che vengono fuori siano in italiano
> ] pessimo, e si debbano praticamente riscrivere. Per vedere se potete 
> ] fare una traduzione, provate a farne una e a dare il risultato a 
> ] qualcun altro, oppure a lasciarla nel cassetto per una settimana e poi
> ] riguardarla senza il testo a fronte... spesso vengono fuori delle
> ] sorprese :-))

Hai perfettamente ragione!

Decidiamo se convertire prima in txt o no, se decidiamo per il no
aggiorno le linee guida e tolgo il ruolo del tecnico.

Ciao
Ferdinando