GNOME - linee guida per la traduzione

[Emanuele Aina]

Luca Ferretti motiv=F2:

> Lasciamo da parte il mio stomaco.... era solo una sorta di tentativo di=

> richiamare l'attenzione. Mi spiego: condivido il principio [o comunque
> lo so voglia chiamare] di non rivolgersi direttamente all'utente, ma co=
n
> quali argomentazioni motivarlo in uno scritto che ambisce ad essere una=

> guida=20

Per me va benissimo l=EC dov'=E8. Era solo che mi chiedevo da dove avessi=

preso tutto il romanzo... :)


>>Gi=E0 il titolo non va. Perch=E9 non "Gli elementi dell'interfaccia" (n=
ota
>>l'apostrofo).
>=20
> Volevo cambiarlo in qualcosa di meglio....=20

Tipo?

>>> diverso  livello di visibilit=E0 da parte dell'utente. Ad esempio
>>> possiamo distingure le stringhe che sono l'help per la sintassi della=

>>
>>HELP? Cosa? "[...] sono la guida per la sintassi [...]"
>=20
> 'Guida' io lo attribuirei ad un qualcosa di pi=F9 esteso, non a quanto
> descritto qui. Cmq l'intera frase fa schifo:)=20

Proviamo:

"All'interno di un programma =E8 possibile suddividere le stringhe da
tradurre in diverse categorie, a seconda della loro visibilit=E0.
Una classe di stringhe =E8 quella costituita dalle istruzioni per la
sintassi della riga di comando del programma, che appaiono solamente
alla console, mentre un'altra pu=F2 essere quella che comprende tutti i
messaggi che andranno a corredare le finestre dell'interfaccia utente.
Tra queste =E8 possibile operare una ulteriore classificazione
distinguendo tra le normali informazioni e i messaggi di errori, i quali
non saranno rivolti direttamente all'utente, bens=EC allo sviluppatore
nella fase di identificazione dei problemi del programma."

>>La tua =E8 un'avversione motivata nei confronti del troncare le
>>preposizione articolate o =E8 meglio "nell'esecuzione"? :)
>=20
> Evidentemente s=EC. Spiacente =E8 una questione inconscia, non posso fa=
rci
> molto se questo =E8 il mio idioletto, solo sperare in una revisione:)=20
>=20
> Credo di troncarle solo se musicalmente brutte, quindi motivazioni
> pienamente soggettive.=20

Se non ti dispiace, io te le segnalo tutte: rimane a te scegliere quali
correggere e quali lasciare invariate.

>>(Revisione prima di spedire: ci ho ripensato, forse va meglio la forma
>>personale, quindi ignora miei commenti simili al precedente che trovera=
i
>>in seguito... :o)
>=20
> Ne ero anche io poco convinto e ho provato talvolta a riformare la fras=
e
> in forma impersonale. Peccato che era peggiore, costringendo talvolta a=

> inutili parafrasi.=20

Appunto. :)

>>Forse =E8 meglio mettere "[...] errore. La traduzione della stringa=20
>>rimanente, invece, presenta sia il vantaggio di essere comprensibile=20
>>all'utente che lo svantaggio di essere incomprensibile agli=20
>>sviluppatori, i quali riceveranno una segnalazione in una lingua divers=
a=20
>>dalla loro o ritradotta in maniera differente da quanto si apettano."
>>
>>Beh, forse neanche cos=EC =E8 il massimo, per=F2 incomincio ad essere
>>stanco...
>=20
> =C8 il problema di fondo a rendere penoso il tutto. O si mette in evide=
nza
> con una frase che lasci il dubboso lettore in cerca di conferme ancora
> pi=F9 dubbioso, o lo si tace del tutto.=20
>=20
> Certo, magari gli sviluppatori potrebbero anche consutlare il .po per
> trovare l'originale, ma chi informa l'utente di riportare l'esatta
> stringa che gli si para davanti e a quale localizzazione fa riferimento=
?

E qui le opinioni della lista dovrebbero farsi sentire numerose... :)

Io credo che sia meglio specificare, per=F2: qui ci stiamo riferendo a=20
errori *interni* del programma, *molto* interni e con messaggi *molto*=20
tecnici che, anche se tradotti, avrebbero ben poco significato per=20
l'utente finale (quello che non mette le mani nel codice).

Questi messaggi non sono da confondere con messaggi del tipo "Errore di=20
lettura dal file" o "Errore di lettura dalla pipe". Nonostante nel=20
secondo caso si tratti di un errore gi=E0 pi=F9 "tecnico", l'utente =E8 i=
n=20
grado di capire e, magari, risolvere il problema in maniera semplice.
In tal caso il messaggio *deve* essere tradotto.

In altri casi, quale pu=F2 essere la mancata inizializzazione di un
particolare oggetto (ne era saltata fuori una recentemente nella
traduzione di rhythmbox/gstreamer), =E8 meglio *non* tradurre il
messaggio, in quanto la traduzione non comporta un sensibile vantaggio
per l'utente (linguaggio troppo tecnico, quelli in grado di capirlo
dovrebbero sapere alemno un minimo di inglese) ma comporta un sensibile
svantaggio per lo sviluppatore, in quanto nella segnalazione del bug,
invece di trovarsi il suo messaggio (che sa esattamente dove =E8
collocato) se ne trova uno differente (ritradotto in inglese
dall'italiano).

Come regola generale, =E8 meglio tradurre tutto, anche in caso di
incertezza. Questo per consentire all'utente di non trovarsi spaesato e
di capire che il problema riscontrato =E8 di tipo tecnico. In tal modo
l'utente potrebbe riportare un messaggio che lo sviluppatore non sa dove
collocare, ma potrebbe anche collaborare con lo sviluppatore in mdo da=20
localizzare meglio il problema (spesso il solo messaggio d'errore non =E8=
=20
sufficiente comunque, essendo necessarie altre informazioni come=20
librerie installate, versioni, condizioni in cui il problema si =E8=20
verificato, ecc.)

Solo quando si =E8 sicuri che il messaggio non sar=E0 *mai* utile ad un
utente (o quando lo sviluppatore insiste molto :) allora si pu=F2 evitare=
=20
di tradurre il messaggio.

Meglio sarebbe includere sia traduzione che errore.  Qualcuno pi=F9=20
addentro a GNOME del sottoscritto non potrebbe pensare qualcosa da=20
mettere nello HIG per aiutare noi poveri traduttori?

Chess=F2, qualcosa del tipo "Nelle finestre preposte alla segnalazione di=

messaggi di errore, =E8 consigliato lasciare spazio disponibile per
visualizzare sia l'originale che il massaggio localizzato, in modo da
venire incontro alle esigenze dell'utente e a quelle dello
sviluppatore."

Commenti?


> Blocco qualunqe discussione su parse: solo che mi sembrava l'esempio pi=
=F9
> in vista proprio perch=E9 presente in un ipotetico messaggio di errore =
e
> perch=E9 tradotto o traducibile in modi un po' diversi.=20

Puoi suggerire le due o tre soluzioni pi=F9 adottate (non si sa mai cha a=
=20
qualcuno salti in mente di usare strane circonlocuzioni... :)


>>>Ci=F2 =E8 dovuto al fatto che l'utente non deve/pu=F2 a priori conosce=
re le=20
>>> funzionalit=E0 di un programma
>>
>>Perch=E9 il "deve"?
>=20
> Nel senso "non =E8 dovuto a [...]", solo che non mi andava di stare a
> trovare un sinonimo adeguato.=20

Secondo me puoi lasciare solo il "pu=F2" o rigirare la frase: "Ci=F2 =E8 =

dovuto alla possibilit=E0 che l'utente non conosca a priori [...]".


>>>1. quelle il cui nome =E8 descrittivo (e non suggestivo) delle=20
>>>    funzionalit=E0;
>>
>>Frase strana %-)
>>
>=20
> becera traduzione dell'originale:))) esempio di ci=F2 che non andrebbe
> fatto secondo i miei consigli=20

:)

>>> composta dal nome della applicazione seguita dalla breve
>>> descrizione. Il suggerimento =E8 quello di tradurre queste due
>>> parti separandole con un trattino. [!!mio suggerimento da
>>> sottoporre a revisione; l'alternativa =E8 invertire NOME DESCR!!]
>>
>>Cio=E9?
>=20
> in inglese "GIMP Image Editor" ha un certo senso. In italiano "GIMP
> Editor di immagini" mi sembra brutto.=20
>=20
> 1) "Editor di immagini GIMP"=20
> 2) "GIMP - Editor di immagini"=20
 >
 > Sono la stessa cosa, ma visivamente hanno una diversa valenza. Il
 > trattino spezza e distingue nettamente NOME e DESCR; inoltre scrivere
 > il nome prima credo aiuti a familiarizzare con l'applicazione, a
 > partire dall'apprendere il nome (Gnumeric =E8 pu=F9 figo di "Editor di=


Giusto. Solo sii pi=F9 "verbose" nelle spiegazioni. :)

Per esempio includendo quanto hai detto a me.

 > fogli di calcolo".... ora che ci penso: "Gnumeric - Editor di fogni di=

 > calcolo" occupa mezzo schermo...ora che ci penso meglio ma si potr=E0
 > tradurre editor? "Editore" =E8 per lo meno ambiguo, "Modificatore" fa
 > tenerezza, "Programma per la modifica" direi che =E8 un suicidio).


"Editore" =E8 sbagliato (ci assomiglia solo acusticamente).

Al amssimo "redattore", ma credo che sia uno di quei casi ottimi da
presentare come esempio di parola da non tradurre...


>>Perch=E9 non "finestre di dialogo e di avviso"? O qualcosa di simile?
>=20
> Perch=E8 ho dimenticato di chiedere quale tradizione fosse la pi=F9 com=
une.
> Direi che queste possono andare, ma mi rimane un solo dubbio: nello hig=

> si parla di finestre di avviso, ma non si accenna per niente a possibil=
i
> stili da seguire per le finestre di dialogo. Le taglio tout-court o
> accenno qualcosa? E cosa?

"Dialog windows" =E8, per quanto ne sappia io, sempre stato tradotto con
"finestre di dialogo".

Io direi proprio "finestre di dialogo e di avviso"...


>>"toolbar"????
>>
>>"Barra degli strumenti", please. :)
>=20
> Uffa, era pi=F9 breve e non mi andava si scrivere:<

Installa un programma di riconoscimento vocale... :)

> E poi considera quanto =E8 bello l'inglese informatico: puoi=20
 > inventarti parole come 'toolbar' e nessuno ti dice niente.
 > Figurati che per nautilus hanno mutato i "sidebar panel" in "side
 > pane", ma penso che la traduzione italiana non dovrebbe risentirne.

Amo le abbreviazioni informatico-anglofone. <g>


>>Ho solo una richiesta da fare, riguardante la licenza: non aggiungere
>>parti invarianti (consentite dalla fdl).
>>
>>Sono in violazione con la DFSG e renderebbero la guida non-free...
>>
>>Non mi va di aggiungere anche quelli al sources.list di apt. :o)
>=20
> OK: non ho capito. Quindi riavvolgiamo il nastro. Come gi=E0 detto sto

Agvsssssssssss. [Rumore di nastro che si riavvolge...]

> usando lo sgml, in particolare come modello di partenza ho preso il fil=
e
> gnome-app-template.sgml in gnomecvs//gnome-docu/gdp/templates

Ah. Allora non so. Dovr=F2 leggermela... :(

Anzi, no. Ho letto il tuo legalnotice.txt:

 > [...] under the terms of the GNU Free Documentation License, Version
 > 1.1 or any later version published by the Free Software Foundation
 > with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
 > Texts.

Ottimo. Questo pezzo mi solleva da ogni preoccupazione...

Spiegazione: la gfdl (GNU Free Documentation License) consente=20
l'introduzioni di sezioni invarianti opzionali, le quali, per
definizione, non possono essere modificate.

Questo fatto rende i documenti che ne fanno uso non completamente=20
liberi, in quanto io non posso modificarli a mio piacere (come, invece,=20
posso fare con i programmi sotto gpl).

Ad esempio, non mi consente di correggere l'ortografia del documento,=20
nel caso riscontrassi un errore.

Nonostante che io capisca lo sforzo fatto dalla FSF (Free Software
Foundation) nel redigere questa licenza, sono contrario all'introduzione =

della possibilit=E0 di impiegare sezioni invarianti.

In tal modo, infatti, sapendo che un documento =E8 rilasciato sotto gfdl,=
=20
non =E8 possibile sapere a priori se si tratta di un documento=20
completamente libero oppure no. Diviene necessario leggersi tutta la=20
licenza. Scomodo soprattutto se si =E8 una distribuzione con 10000
pacchetti da gestire e per la quale il tempo necessario per leggersi le
licenze di chiss=E0 quanti pacchetti di documentazione diviene improponib=
ile.

Scomodo anche per il fatto di dover accedere a due distinti archivi per=20
scaricare un programma e la sua documentazione.

(Ogni riferimento a cose o Debian realmente esitenti =E8 da considerarsi
puramente casuale).


> Nella intestazione del file in questione, ci sono due "tipi" di licenza=

>     ^^^^ =E8 inconscio...

:)

> o meglio di modi di riferirsi alla FDL: una "for online documents which=

> depend on core GNOME packages", l'altra "for documents which are placed=

> on the web, shipped in any way other than online documents (eg. PS, PDF=
,
> or RTF), or which do not depend on the core GNOME distribution."
 >
 > Poich=E9 non credo sussista la condizione "depend on the core GNOME" h=
o
 > seguito quanto indicato per il secondo, con i risultati che si vedono.=


Non ho idea della differenza. Comunque la tua scelta mi sembra la
migliore.

> E poi che cosa =E8 DFSG?

La DFSG (Debian Free Software Guidelines) =E8 la raccolta di regole alle =

quali la licenza di un programma deve sottostare per poter essere=20
distribuita ufficialmente da Debian. In sostanza dice che il programma=20
deve poter essere modificato da chiunque in ogni sua parte.

<http://www.debian.org/social_contract.html#guidelines>

Tutti i programmi (o la documentazione) che non corrispondono a queste=20
norme ma che possono essere liberamente distribuiti vengono detti=20
"non-free" e mantenuti in un archivio a parte, /non-free appunto,=20
separato da quello principale (/main).

> Cmq, piazzo nel file legalnotice.txt la parte del modello sgml in una
> directory GNOME/stuff sul mio sito.
>=20
> Se debbo modificare qualcosa, ditemi cosa....

No, fortunatamente va tutto bene cos=EC com'=E8. :o)

>>Cmq, grande lavoro!
>=20
> Grazie, vale pi=F9 di una confezione di psicofarmaci;>
>=20
> E per ringraziare nella gi=E0 citata cartella GNOME/stuff potrete trova=
re
> un candido file gorilla_stock.tar.gz, assieme ad una gradevole schermat=
a
> di gedit

Ahhhhh, voglio anch'io GNOME2 (perch=E9 non ho un'ADSL, perch=E9? :~( )


--=20
Buongiorno. Complimenti per l'ottima scelta.
Lele...