[PLUTO-ildp] Linee guida - ILDP

[Eugenia Franzoni]

On Mon, May 12, 2003 at 07:36:26PM +0200, Ferdinando wrote:

> Ho scritto un documento che, opportunamente affinato da voi tutti
> potrebbe rappresentare le future linee guida del progetto.

ottimo! :-))

> Gli ex-coordinatori dovrebbero poi rispondere alla sezione 4.1.1
> "Problemi" ...

Fatto :-) Ho iniziato le mie righe con "]"


  22..22..  PPrroobblleemmii

  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

  ·  Chiarire bene il formato da adottare, su tldp adesso usano DocBook
     con XML, qui ancora si usa LinuxDoc ... convertire i documenti e
     aprire due directory, sgml e docbook come su tldp e poi, con calma,
     provvedere alla conversione?  è anche questo un punto da chiarire
     subito perché per i nuovi documenti il problema si pone
     immediatamente ...

] Credo che la procedura corrente sia: si traduce nel formato del documento
] originale. Questo ha senso perche' diminuisce il lavoro di traduzione.

  33..  OOrrggaanniizzzzaazziioonnee

  L'organizzazione del progetto dovrebbe essere il più lineare, semplice
  ed efficiente possibile, dovrebbe impegnare relativamente poco il
  _c_o_o_r_d_i_n_a_t_o_r_e ed attrarre il maggior numero possibile di _n_e_w_b_i_e

] 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.

  Solamente il _c_o_o_r_d_i_n_a_t_o_r_e 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
] :-)

  Il sistema permetterà una traduzione o l'aggiornamento in maniera
  semplice di un documento perché il _t_r_a_d_u_t_t_o_r_e lavorerà direttamente su
  testo puro che rispedirà al _c_o_o_r_d_i_n_a_t_o_r_e o direttamente al _r_e_v_i_s_o_r_e 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 _t_e_c_n_i_c_o, 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 :-)

  _r_e_v_i_s_o_r_e. Per meglio chiarire, il documento che riceverà il _t_e_c_n_i_c_o,
  sarà stato realizzato dal _r_e_v_i_s_o_r_e, che lascerà nel testo entrambe le
  lingue, ovvero l'inglese originale e la traduzione.  Successivamente
  il _r_e_v_i_s_o_r_e, 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 :-)

  33..11..  RRiiffeerriimmeennttii wweebb

  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:// :-)

  <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

[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 :-)


  44..11..11..  PPrroobblleemmii

  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:
] * 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' ;-)))
] * l'aggiornamento dello stato traduzioni (risolvibile attraverso una
]   struttura almeno minimamente automatizzata)
] * i documenti fuori TLDP, che vanno comunque inseriti, ma necessitano
]   di una struttura diversa
] * 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 :-)
] * varie ed eventuali (mi verranno in mente, ma sto scrivendole anche
]   durante la discussione :-)

  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 :-)

  Spero che questo documento vi serva ...

] credo di si' :-)


  44..44..  IIll ttrraadduuttttoorree

  Sostanzialmente la figura più semplice ma forse la più importante è
  quella del _t_r_a_d_u_t_t_o_r_e, può essere tranquillamente un _n_e_w_b_i_e, (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 :-))


E.
-- 
Eugenia Franzoni
Pluto Free Software User Group
http://www.pluto.linux.it