[PLUTO-ildp] MSSQL-PHP qualche ultimo dubbio

[Hugh Hartmann]

Ciao Giulio e CM (Alias Contardo ... :-)
e un saluto decisamente "soporifero" a tutti i partecipanti alla lista,
ammesso che ce ne sia ancora qualcuno che non appartenga gia' al mondo di
Orfeo e Euridice ... :-))

On Fri, Mar 30, 2007 at 01:13:56AM +0200, Giulio Daprelà wrote:
> On 3/29/07, CM <contardm a gmail.com> wrote:
[...]

> > />Prima cosa assolutamente essenziale; verso la fine dell'abstract
> > (all'interno dei due tag <abstract> e </abstract>) di solito si scrive
> > il nome del traduttore e indirizzo email relativo, seguito dal nome del
> > revisore con il suo indirizzo email, qualcosa tipo:
> >  >Traduzione e adattamenti in italiano a cura di CM
> >  ><tt><htmlurl url="mailto:contardm a gmail.com"
> > name="contardm a gmail.com"></tt>.
> >  >Revisione a cura di Pinco Pallino
> >  ><tt><htmlurl url="mailto:ppallino a libero.it"
> > name="ppallino a libero.it"></tt>.
> > /
> > Ho seguito questa indicazione, ma l'effetto è (dopo averlo compilato con
> > "linuxdoc -B html nomedoc.sgml") che la scritta "traduzione ed
> > adattamenti..." si trova ad essere sulla stessa linea dell'abstract,
> > come fosse una parte di questo. Usando il tag <p> per dichiararlo come
> > paragrafo, linuxdoc ritorna messaggi del genere:

E' ormai una regola accettata che all'interno dell'abstract ci siano il
nome del traduttore e quello del revisore con l'idirizzi e-mail relativi
Come ha fatto gia' notare anche Giulio .... Ergo non si devono inserire i
tag del paragrafo <p> all'interno dell'abstract ... infatti anche
l'analizzatore sgml si lamenta .... :-)

> > //usr/bin/nsgmls:<OSFD>0:36:10:E: end tag for element "ABSTRACT" which
> > is not open
> > /usr/bin/nsgmls:<OSFD>0:39:4:E: document type does not allow element
> > "TOC" here
> > /
> > Guardando qua e là, per esempio sul doc Cluster-HOWTO.sgml, ho però
> > visto che tali note sono state riportate all'interno del tag <sect>.
> > Qual è la regola generale?
 
> Non preoccuparti,  normale che i nomi siano di seguito all'abstract
> sulla stessa linea. All'inizio le prime volte volevo fare anch'io
> quello che stai tentando tu, ma nell'abstract non si può. Quanto al
> Cluster howto in effetti non è del tutto corretto mettere i nomi
> nell'introduzione. A mia parziale giustificazione posso dire che erano
> le prime traduzioni di howto che curavo.
> L'email va bene metterla, ma non così in chiaro. Camuffala un po',
> togliendo il tag mailto e sostituendo @ con (at) o cose simili.

Si, conviene sostituire la @ con la (at), come si usa ormai da diverso
tempo .... 
 
> >
> >
> > ** Ndt e parentesi quadre
> > *
> > Mettendo la NdT all'interno di parentesi quadre, linuxdoc ritorna un
> > messaggio del genere:

Infatti le parentesi quadre come altri simboli fanno parte delle "famose
macro" della e commerciale & (chiamate anche entita' in alcuni testi),
ergo quando non si trovano all'interno tra i tag <tscreen><verb> e
</verb></tscreen> DEVONO essere rappresentate nel seguente modo:

[ = [ 

e 

] = ] 

Naturalmente non si devono scordare i ; ... :-)

Sebbene queste macro possano sembrare arcane sono l'acronimo
rispettivamente di:

lsqb = Left Square Bracket
rsqb = Right Square Bracket

> > *
> > *//usr/bin/nsgmls:<OSFD>0:154:179:E: document type does not allow
> > element "TT" here
> > /usr/bin/nsgmls:<OSFD>0:154:245:E: end tag for "F" omitted, but its
> > declaration does not permit this
> > /usr/bin/nsgmls:<OSFD>0:154:17: start tag was here
> > /
> > In pratica è come se linuxdoc andasse un attimo in crisi a causa delle
> > parentesi quadre, ma poi riuscisse a reagire e a costruire il
> > correttamente il documento (infatti nell'html vedo le quadre). Usando
> > invece le parentesi tonde funziona tutto. Come mi comporto? Lascio che
> > linuxdoc ritorni l'errore (brrrr) oppure metto le parentesi tonde oppure
> > devo lanciare linuxdoc con qualche altro parametro?
> 
> Qui lascio la spiegazione a Hugh o a chi conosce Linuxdoc meglio di me.

Come ho detto le parentesi quadre come molti altri simboli DEVONO essere
rappresentati come macro di &, a meno che non si trovino dentro alcuni
ambienti come <verb> o <code> ...

Forse ti converrebbe dare un'occhiata alla: Linuxdoc Guida dell'Utente o
anche SGML Tools Guida dell'utente, anche se datate, sono ancora molto
utili per le basi che, sostanzialmente sono rimaste le stesse (almeno
quelle ... :-))


> > ** FAQ.
> > *
> > Ci siamo detti che il documento dovrebbe essere tradotto in forma
> > impersonale, ma le FAQ di questo documento sembrano essere una specie di
> > domanda e risposta molto colloquiali. E' un po' come se io ponessi una
> > domanda e l'autore mi rispondesse (es: "Come faccio a...?", "Fai in
> > questo modo"). In questo caso come ci si comporta?
> > A sensazione, per non allontarsi troppo dall'idea iniziale dell'autore,
> > sarebbe il caso di lasciare l'impostazione colloquiale... ma potrebbe
> > essere ugualmente accettabile un discorso indiretto (es: "Come si fa
> > a....?", "Si faccia in questo modo").
 
> Ho dato un'occhiata alle FAQ e trovo molto difficile trasformarle in
> forma impersonale. Aprirò un dibattito a questo proposito anche sulla
> lista del TP, perché non sono sicuro di quale sia l'approccio più
> corretto.

Mah, per quello che mi ricordo, quando ho tradotto le FAQ Debian, ho
sempre usato l'impersonale .... 

Au Revoir
Hugh Hartmann

 

-- 
 ... Linux, Windows Xp ed MS-DOS 
     (anche conosciuti come il Bello, il Brutto ed il Cattivo).   
     -- Matt Welsh