[PLUTO-ildp] Regole di buona traduzione ... :-))

Hugh Hartmann hhartmann a fastwebnet.it
Lun 22 Giu 2009 18:29:31 CEST


Un saluto "educativo" si propaga a tutti i partecipanti alla lista ... :-)

Memore di recenti e passate discussioni e pensando di fare cosa gradita 
ai nuovi "adepti" di ILDP, riporto qui, di seguito, un testo che 
considero assai importante, che, anche se datato, sono convinto, guiderà 
nel percorso dell'illuminazione! ... :-)))

-------------------------------------------------

Regole per la Buona Traduzione

   Emanuele Aina

Introduzione

   Lo scopo di questo documento è quello di delineare un insieme di linee
   guida alle quali cercare di attenersi quando si traduce un documento
   tecnico, un HOWTO, delle pagine di manuale o i messaggi di un
   programma, in seguito all'impegno di molti volontari in anni di
   traduzioni e revisioni sulle liste dei traduttori.

   Ovviamente i destinatari principali di questo documento sono i novelli
   traduttori che si cimentano per le prime volte con le traduzioni di
   documenti tecnici, ma può anche servire per stabilire una base comune
   di regole su cui i traduttori più esperti possano fare affidamento.

   È da tenere ben presente che queste regole non sono una verità
   rivelata, ma sono il frutto di discussioni avvenute negli anni e,
   pertanto, non pretendono di essere considerate assolute. Piuttosto, la
   validità di una traduzione non deve essere una condizione binaria,
   bensì un continuo di sfumature che attraversano l'intero spettro di
   verità.

Regole grafiche

   Uno stile grafico coerente è indice di professionalità e permette
   all'utente di non venire distratto da quelle che per lui possono
   essere stranezze visive, ma di concentrarsi sul contenuto del
   messaggio.
     * Uso della spaziatura
       In un testo italiano vanno usati solo spazi singoli tra una parola
       e l'altra, anche dopo il punto al termine di un periodo, a
       differenza dell'uso inglese che consente anche di mettere due
       spazi. L'apostrofo non prevede che siano posti spazi né a
       precederlo né a seguirlo, a meno che si tratti di un troncamento,
       quale «va'», «po'», ecc.
     * Segni di interpunzione
       Tutti i segni di interpunzione (virgola, punto, punto e virgola,
       punto esclamativo, ecc.) seguono direttamente la parola che li
       precede, senza spazi, e vanno separati dalla parola successiva con
       uno spazio. Non fanno eccezione i punti alla fine di un periodo.
       es. "L'italiano, il francese e lo spagnolo sono lingue
       neo-latine."
     * La congiunzione "e"
       La congiunzione "e" non va preceduta dalla virgola, a meno che
       questa sia una virgola che chiude un inciso.
     * Parentesi
       Le parentesi di apertura hanno uno spazio che le precede mentre la
       parola successiva è attaccata ad esse. Il contrario è normalmente
       vero per le parentesi di chiusura, mentre non va messo alcuno
       spazio tra queste ed eventuali segni di punteggiatura.
       es. "Esempio (dell'uso) di parentesi."
       In particolare, la punteggiatura del testo circostante non va
       inserita all'interno delle parentesi ma va posta dopo la parentesi
       di chiusura.
       es. "Altro esempio (dell'uso di parentesi)."
     * Maiuscole
       Mentre in inglese è convenzione porre tutte le lettere iniziali
       delle parole componenti un titolo in maiuscolo, in italiano ciò è
       considerato errore, in quanto solo la prima parola usa l'iniziale
       maiuscola.
     * Nomi di programmi
       I nomi dei programmi esulano dalla precedente regola sulle
       maiuscole: se un nome di programma compare all'inizio della frase,
       la sua prima lettera non va forzata maiuscola, ma va scritto
       riportando esattamente la corretta grafia.
       Se tale grafia non possiede l'iniziale maiuscola è consigliabile
       tentare di modificare la frase affinché il nome non cada più
       all'inizio.
       es. "Mozilla", "apt", "GNOME", "giFT", "Konqueror", "GStreamer".
     * Accenti
       È da considerarsi errore l'uso di una vocale seguita da un
       apostrofo «'» o da un apice inverso «`» per simboleggiare una
       vocale accentata. Se la codifica lo consente, vanno sempre
       impiegati i simboli appositi, sia per le minuscole che per le
       maiuscole.
       Nell'ambiente X11 usato sui sistemi UNIX, le maiuscole accentate
       sono ottenibili usando il tasto BlocMaiusc insieme agli stessi
       tasti usati per le minuscole.
       Le vocali "a", "i" e "u" possiedono solo una possibile pronuncia e
       quindi vanno sempre poste con l'accento grave ("à", "ì", "ù").
       La vocale "o", invece, può essere sia aperta che chiusa ma, poiché
       non esistono parole tronche che terminano per "o" chiusa,
       l'accento alla fine della parola è sempre grave ("ò").
       In generale, è convenzione comune anche in editoria utilizzare
       esclusivamente l'accento grave sulle vocali "a", "i", "o" e "u".
       Per la vocale "e" la situazione è più complicata: normalmente va
       usato l'accento grave ("è") ma in alcuni casi va usato quello
       acuto ("é"): "perché", "affinché", "poiché" (in generale tutti i
       vocaboli che terminano in "ché"), "né", "sé".
     * Virgolette
       In italiano non sono da usare gli apici singoli «'». Al loro posto
       vanno usate le virgolette doppie, sia alte (" ") che basse (« »).
       La scelta tra i due tipi di virgolette rimane una scelta del
       traduttore nella maggiornaza dei casi, anche se è auspicabile
       mantenere una certa coerenza tra traduzioni appartenenti allo
       stesso ambiente.
       Senza dubbio le virgolette alte vanno usate quando si usa un
       termine con un significato diverso da quello corrente (come si usa
       dire, "tra virgolette"), mentre quelle basse (dette caporali)
       vanno usate per citazioni di discorsi diretti.
       Negli altri casi la scelta ricade sul traduttore, ma l'uso diffuso
       prevede l'impiego di virgolette basse per nomi di file, comandi di
       shell e, talvolta, per identificativi di elementi dell'interfaccia
       utente (ad es. voci di menù o pulsanti nelle interfacce grafiche).
       Nei casi in cui l'uso delle virgolette alte sia sconveniente, ad
       esempio se un apostrofo finisse vicino a una virgoletta, è
       consigliabile usare quelle basse per evitare confusione.
       In ambiente X Window le virgolette basse possono essere introdotte
       con le combinazioni di tasti <Alt-Gr>+z («) e <Alt-Gr>+x (»),
       oppure usando i loro codici Unicode (U+00AB per « e U+00BB per »).
     * Caratteri speciali
       Solitamente, nelle traduzioni italiane, la codifica usata è un
       superinsieme della codifica ASCII, pertanto diviene possibile
       usare alcuni caratteri speciali, dove appropriato.
       Per questo motivo è solitamente considerato errore simulare vocali
       accentate con apostrofi «'» o apici inversi «`». Inoltre, è
       caldamente raccomandabile la sostituzione delle stringhe "(c)" con
       il carattere "©" (e, analogamente, "®"), oppure l'uso del simbolo
       di moltiplicazione "×" dove fosse usata la lettera "x" in sua
       vece.
     * Uso della "h"
       Fatta eccezione per i casi in cui compaiono "gh" o "ch" e per il
       verbo avere, in italiano la lettera "h" compare solo a fine parola
       o tra due vocali. Questo è particolarmente vero per le
       esclamazioni come "ehi" (non "hei"), "ahi", "oh", "ah", "beh" (non
       "bhe").
     * Monosillabi accentati
       I monosillabi che in italiano esistono sia in forma semplice che
       in forma accentata sono pochi e ben definiti: "dà", "sé", "tè",
       "lì", "là", "sì", "né".
     * Troncamenti ed elisioni
       Quando si ha elisione è necessario porre l'apostrofo dopo la
       parola: ne sono un esempio i monosillabi «po'», «va'», «fa'» e
       «di'».
       Nei casi in cui si ha, invece, un troncamento l'apostrofo non va
       messo: un esempio corretto di tale pratica è l'uso di «qual è»
       invece dell'errato «qual'è».
     * Forme eufoniche
       Le forme eufoniche (ed, ad, od) vanno usate solo se la vocale che
       segue è la stessa (es. "Io ed Elisabetta").
       Se la vocale che segue è diversa, la presenza della "d" non è
       considerata errata ma non è neppure esempio del migliore stile
       (es. "Io e Alberto" invece che "Io ed Alberto").
     * Data e ora
       Il formato italiano numerico per la data è "GG/MM/AAAA" (es.
       "25/05/2004"), ma andrebbe preferito, se possibile, il formato
       esteso "ggg GG mese AAAA" (es. "mer 25 maggio 2004").
       Per quanto concerne il formato orario è da usare il formato
       HH.MM.SS,DD in cui il punto è usato come separatore per la parte
       sessagesimale e la virgola separa la parte decimale dei secondi
       (decimi, centesimi e così via).
       Questi formati vanno usati quando viene richiesta la
       rappresentazione localizzata della data, mentre se nel testo
       originale la data compare già nel formato internazionale, va
       lasciata la notazione ISO.

La forma

     * Termini stranieri
       I termini stranieri vanno sempre lasciati nella loro forma pura,
       priva di flessione. Non debbono venire coniugati neppure al
       plurale, restando sempre nella loro forma singolare: questo è per
       evitare problemi con vocaboli dotati di plurale irregolare
       ("mouse" - "mice") o con lingue poco conosciute ("kamikaze",
       "pasdaran", ecc.).
       Lo stesso trattamento va riservato per le forme terminanti in
       -ing, in cui va lasciato solo l'infinito del verbo.
       es. "Eseguire il link" invece che "Eseguire il linking".
       Per quanto riguarda il genere, il termine assume quello che
       avrebbe se tradotto in italiano oppure quello che suona meglio
       dandogli un significato italiano. In caso di dubbio è
       consigliabile rifarsi all'uso comune (sempre che ne esista uno).
       es. "Ho comprato due mouse", "Mandami i tuoi file".
     * Italianizzazioni
       Termini stranieri "italianizzati" ("settare", "rebootare",
       "pingare") sono da evitare usando i termini corretti ("impostare",
       "riavviare") o aggirandoli con parafrasi ("effettuare il ping").
     * Rivolgersi all'utente
       Mentre i testi inglesi usano solitamente rivolgersi direttamente
       al lettore, in italiano è una cosa da evitare in ogni modo,
       essendo preferibile usare forme impersonali per esprimere gli
       stessi concetti. Detto ciò, è anche necessario limitare l'uso del
       "si" impersonale, il quale tende a rendere le frasi pesanti e poco
       scorrevoli, privilegiando l'uso dell'infinito.
       Si tenga, inoltre, presente che in inglese i programmi tendono a
       essere più educati dell'uso comune italiano, anteponendo molti
       "please" alle azioni che l'utente deve compiere. In italiano,
       invece, i programmi sono molto più freddi e si limitano a dire
       all'utente cosa deve fare.

        "Select another option"
                "Si selezioni un'altra opzione"
                "Selezionare un'altra opzione"

        "Please choose [...]"
                "Scegliere [...]"

     * Forma impersonale
       Mentre in inglese il programma si riferisce a sé stesso in prima
       persona, in italiano ciò è da evitare, usando costrutti
       impersonali o forme passive.

        "I'm going to ask you some questions"
                "Verranno poste alcune domande"

     * Verbi al gerundio
       Spesso nei testi da tradurre compaiono verbi posti al gerundio
       (es. "Installing GNOME") che, se tradotti con un gerundio italiano
       darebbero un'idea diversa dall'originale.
       In questi casi è raccomandabile tradurli sostantivizzando
       l'azione: "Installazione di GNOME" oppure "Installazione di GNOME
       in corso" se si volesse porre maggior accento sul contemporaneo
       svolgimento dell'operazione, anche se ciò appesantisce la frase.
       Altre volte è meglio usare il verbo all'infinito per evitare di
       dover creare nuovi sostantivi o di dover usare forme
       sostantivizzate poco scorrevoli: usando frasi come "Errore
       nell'installare GNOME" si riesce, inoltre, a mantenere una certa
       relazione tra la forma originale e quella tradotta, riducendo la
       probabilità di dover rigirare la frase.
     * Esclamative e interrogative
       Domande retoriche, frasi esclamative o interrogative e forme
       colloquiali sono da evitare, cercando di usare al loro posto una
       forma affermativa impersonale, che conferisce al programma un tono
       più professionale o, perlomeno, distaccato.
     * Periodi brevi
       Mentre in inglese è diffuso l'uso di brevi periodi in successione
       legati tra loro, in italiano è considerato un esempio di cattivo
       stile. Pertanto è consigliabile cercare di fondere questi periodi
       in periodi più lunghi, articolati in frasi principali e
       subordinate.
     * Incisi
       Nei testi anglofoni è consuetudine inserire incisi introdotti da
       un trattino ("-") o da due trattini ("--"): in italiano sono da
       evitare, sopperendo con l'uso delle virgole o dei due punti.
     * Disgiunzioni non esclusive
       In inglese è frequente incontrare la forma "and/or" per indicare
       la possibilità che due eventi possano o verificarsi entrambi
       oppure che se ne verifichi almeno uno dei due, in quanto la
       disgiunzione "or" ha un significato di mutua esclusione (EXOR).
       L'italiano, invece, deriva le proprie congiunzioni e disgiunzioni
       dal latino, in cui erano presenti:

        et, atque
                congiunzione (AND logico)

        vel
                disgiunzione (OR logico)

        aut ... aut ...
                esclusione (EXOR logico)

       Pertanto in italiano la forma "e/o" è da evitare, usando al suo
       posto una semplice "o", mentre per esprimere la mutua esclusione è
       possibile impiegare la forma "o ... o ...".

        "you can do this and that"
                "è possibile fare questo e quello"

        "you can do this or that"
                "è possibile fare o questo o quello"

        "you can do this and/or that"
                "è possibile fare questo o quello"

     * Traduzione letterale
       Compito del traduttore è di cercare di rimanere il più possibile
       fedele all'originale: questo non significa necessariamente
       tradurre letteralmente, bensì cercare di rendere perfettamente
       quanto esposto del documento originale. Più la traduzione è vicina
       all'originale, tanto questa è migliore, ma tale vicinanza non deve
       verificarsi a scapito della forma o della correttezza: a causa del
       diverso modo di costruire le frasi nelle varie lingue, spesso è da
       considerare migliore una traduzione che si distacca dall'originale
       ma è più scorrevole o più elegante.
     * Tradurre, non spiegare
       Questa è una massima valida per tutte le traduzioni tecniche. Una
       traduzione deve cercare di rendere esattamente ciò che è espresso
       dall'originale, senza sforzarsi di renderlo più chiaro o meno
       ambiguo, a meno di errori nell'originale che vanno corretti e
       segnalati agli autori.
       Ciò non vuol dire che le traduzioni debbano essere necessariamente
       letterali (anche se questo può essere comunque considerato un
       pregio): semplicemente non è compito del traduttore fare
       precisazioni su un testo ambiguo.
       Talvolta ciò può accadere in modo inevitabile per diversità della
       lingua: ad esempio il termine "free software" in italiano diviene
       "software libero". Con una tale traduzione, tuttavia, diviene
       pressoché impossibile tradurre anche la precisazione che spesso
       viene fatta tra gli anglofoni: "free as in speech, not as free
       beer".
       È per evitare casi come questi che il lavoro del traduttore non
       comprende la chiarificazione di un testo poco chiaro nella sua
       forma originale: in tali casi il comportamento migliore sarebbe
       quello di contattare l'autore originale e far presente che il
       testo contiene delle parti dubbie, sollecitandolo a chiarirle.

Traduzione di termini tecnici

     * Tradurre, non spiegare
       Anche per i singoli termini vale questa regola: bisogna guardarsi
       dal precisare più di quanto il termine stesso dica, onde evitare
       spiacevoli malintesi. Anche per questo una traduzione deve essere
       succinta, onde evitare di implicare più di quanto non sia
       necessario.

     * Non sorprendere gli utenti esperti
       Quando si trova davanti alla traduzione di un termine, un utente
       esperto deve trovarla naturale e deve poter risalire subito al
       termine originale.
       I tecnici generalmente conoscono il termine originale, pertanto la
       traduzione non deve essere fuorviante o più difficile da leggere
       di quest'ultimo, altrimenti è meglio lasciare il termine
       invariato.
       È da evitare soprattutto l'introduzione di termini arbitrari, in
       quanto questi rischiano di essere diversi da un testo all'altro,
       confondendo il lettore.

     * Corrispondenza 1:1
       Una traduzione tecnica deve essere l'unica traduzione possibile di
       un termine, in quanto il suo significato è talmente preciso e ben
       delimitato che chi la legge si aspetta di trovarla sempre uguale,
       come sempre uguale è il concetto che essa esprime.
       Oltre ad essere l'unica traduzione possibile di un termine, la
       buona traduzione traduce solo quel termine e non può essere
       confusa con null'altro, in modo che il termine originale e quello
       tradotto siano perfettamente equivalenti.

     * Autosufficienza
       Una buona traduzione non deve richiedere spiegazioni poste tra
       parentesi o di giri di parole per poter essere utilizzata; deve,
       anzi, fare in modo che non sia affatto necessario rigirare la
       frase originale.

     * Riconoscibilità
       Una buona traduzione deve essere riconoscibile da un tecnico in
       quanto la parola tradotta (in ordine di importanza):
         1. è comunemente usata dai tecnici del settore;
         2. traduce l'originale in maniera semanticamente fedele;
         3. traduce l'originale in maniera letteralmente fedele;
         4. assomiglia all'originale.

     * Eleganza
       Per essere una buona traduzione, la traduzione deve essere
       elegante in italiano: molte traduzioni per altri motivi molto
       valide sono pressoché inutilizzabili a causa della loro bruttezza
       e goffaggine.

     * Coerenza
       Effettuando una traduzione bisogna sforzarsi di restare omogenei
       con le traduzioni già fatte, in quanto traduzioni non coerenti tra
       loro diventano facilmente fonte di confusione per l'utente.
       Oltre alla lettura delle traduzioni di programmi e documenti
       relativi all'oggetto della traduzione è possibile consultare guide
       apposite come il glossario dei traduttori di programmi liberi o,
       se si stessero traducendo elementi di una interfaccia grafica, le
       linee guida di Luca Ferretti.

Ringraziamenti

   Alcune regole sono state prese in prestito dalle pagine dei traduttori
   di KDE redatte da Andrea Rizzi, altre provengono dal «Manuale di stile
   per la traduzione» per i traduttori di SUN Microsystems, mentre la
   maggior parte delle norme proviene dal glossario dei traduttori di
   programmi liberi, redatto da Marco d'Itri, Francesco Potortì e molti
   altri.

   Copyright © 2003, 2004, 2005 Emanuele Aina.

   Valid XHTML 1.0 Strict
   Emanuele Aina - Thu, 24 Feb 2005 15:58:02 +0100


Questo è tutto (per oggi, naturalmente .. :-))

Au Revoire
Hugh Hartmann





Maggiori informazioni sulla lista pluto-ildp