[PLUTO-ildp] Linee guida - ILDP

[Eugenia Franzoni]

On Tue, May 13, 2003 at 12:29:51AM +0200, Ferdinando wrote:

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

Ci sono due aggiornamenti: uno e' la data del documento originale, uno
e' la data di post della traduzione. Il primo e' il tag date, il secondo
la data dell'upload

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

Ti assicuro, c'e' anche gente che non ne sa niente :-))

> 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?

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

Non si tratterebbe solo di conoscere le persone; avendo dei referenti fissi
per area, anche i revisori sarebbero sempre quelli, e quindi si avrebbe
una maggiore uniformita' nelle traduzioni. 

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

Ci deve essere comunque una revisione del codice SGML/XML o altro,
pero' si parte da una base di lavoro gia' pronto, che rende meno lungo
risolvere i problemi

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

Tenendo presente che il materiale va su CVS, meno modifiche si fanno durante
la lavorazione meglio e', per non far "incasinare" CVS. Ovviamente le 
modifiche da fare sono tutte quelle che migliorano il documento :-)

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

Fosse stato solo quello il problema non saremmo qui a discuterne ;-)

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

La selezione andrebbe fatta su tutte le figure. Fortunatamente sono figure
abbastanza complementari e si puo' trovare da far fare qualcosa a tutti :-)

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

Certo... la cosa da fare e' trovare solo una struttura per il resto
dei documenti, anche mantenendo le priorita' su quelli di TLDP, per evitare
che, come capita, qualcuno ci offra un documento gia' tradotto e non sappiamo
cosa farcene

> > ] * 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?

Sisi... solo che se si deve togliere e rimettere il codice SGML, ci vogliono
piu' persone che se il traduttore scrive tra i tag.

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

Mi sembra una buona idea

ciao

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