Regole per la buona traduzione - Emanuele Aina
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Regole per la buona traduzione
Emanuele AinaRegole per la buona traduzione Emanuele Aina Pubblicato 23 giugno 2009 Copyright © 2003, 2004, 2005 Emanuele Aina 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 HOW-TO, delle pagine di manuale o i messaggi di un programma.
Sommario
1. Introduzione ...........................................................................................................................................1
2. Regole grafiche .......................................................................................................................................2
2.1. Uso della spaziatura ....................................................................................................................2
2.2. Segni di interpunzione.................................................................................................................2
2.3. La congiunzione "e"....................................................................................................................2
2.4. Parentesi ......................................................................................................................................2
2.5. Maiuscole ....................................................................................................................................3
2.6. Nomi di programmi.....................................................................................................................3
2.7. Accenti ........................................................................................................................................3
2.8. Virgolette.....................................................................................................................................4
2.9. Caratteri speciali .........................................................................................................................4
2.10. Uso della "h" .............................................................................................................................4
2.11. Monosillabi accentati ................................................................................................................5
2.12. Troncamenti ed elisioni.............................................................................................................5
2.13. Forme eufoniche........................................................................................................................5
2.14. Data e ora ..................................................................................................................................5
3. La forma .................................................................................................................................................7
3.1. Termini stranieri ..........................................................................................................................7
3.2. Italianizzazioni ............................................................................................................................7
3.3. Rivolgersi all’utente ....................................................................................................................7
3.4. Forma impersonale......................................................................................................................8
3.5. Verbi al gerundio .........................................................................................................................8
3.6. Esclamative e interrogative .........................................................................................................8
3.7. Periodi brevi ................................................................................................................................8
3.8. Incisi............................................................................................................................................9
3.9. Disgiunzioni non esclusive..........................................................................................................9
3.10. Traduzione letterale.................................................................................................................10
3.11. Tradurre, non spiegare.............................................................................................................10
4. Traduzione di termini tecnici..............................................................................................................11
4.1. Tradurre, non spiegare...............................................................................................................11
4.2. Non sorprendere gli utenti esperti .............................................................................................11
4.3. Corrispondenza 1:1 ...................................................................................................................11
4.4. Autosufficienza .........................................................................................................................11
4.5. Riconoscibilità ..........................................................................................................................11
4.6. Eleganza ....................................................................................................................................12
4.7. Coerenza....................................................................................................................................12
5. Ringraziamenti.....................................................................................................................................13
iiiLista degli Esempi
2-1. ..............................................................................................................................................................2
2-2. ..............................................................................................................................................................2
2-3. ..............................................................................................................................................................3
2-4. ..............................................................................................................................................................3
3-1. ..............................................................................................................................................................7
3-2. ..............................................................................................................................................................7
ivCapitolo 1. 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, raccolte grazie 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à.
1Capitolo 2. 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.
2.1. 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’», eccetera.
2.2. Segni di interpunzione
Tutti i segni di interpunzione (virgola, punto, punto e virgola, punto esclamativo, eccetera) 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.
Esempio 2-1.
"L’italiano, il francese e lo spagnolo sono lingue neo-latine."
2.3. La congiunzione "e"
La congiunzione "e" non va preceduta dalla virgola, a meno che questa sia una virgola che chiude un
inciso.
2.4. 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.
Esempio 2-2.
"Esempio (dell’uso) di parentesi."
2Capitolo 2. Regole grafiche
In particolare, la punteggiatura del testo circostante non va inserita all’interno delle parentesi ma va posta
dopo la parentesi di chiusura.
Esempio 2-3.
"Altro esempio (dell’uso di parentesi)."
2.5. 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.
2.6. 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.
Esempio 2-4.
"Mozilla", "apt", "GNOME", "giFT", "Konqueror", "GStreamer".
2.7. 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 ("ò").
3Capitolo 2. Regole grafiche
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é".
2.8. 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 (http://www.x.org/) le virgolette basse possono essere introdotte con le
combinazioni di tasti +z («) e +x (»), oppure usando i loro codici Unicode
(U+00AB per « e U+00BB per »).
2.9. 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.
4Capitolo 2. Regole grafiche
2.10. 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").
2.11. 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é".
2.12. 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’è».
2.13. 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").
2.14. 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).
5Capitolo 2. Regole grafiche
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.
6Capitolo 3. La forma
3.1. 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.
Esempio 3-1.
"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).
Esempio 3-2.
"Ho comprato due mouse", "Mandami i tuoi file".
3.2. Italianizzazioni
Termini stranieri "italianizzati" ("settare", "rebootare", "pingare") sono da evitare usando i termini
corretti ("impostare", "riavviare") o aggirandoli con parafrasi ("effettuare il ping").
3.3. 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.
7Capitolo 3. La forma
Ê "Select another option"
Ë "Please choose [...]"
Ê "Si selezioni un’altra opzione"
Ê "Selezionare un’altra opzione"
Ë "Scegliere [...]"
3.4. 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"
3.5. 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.
3.6. 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.
8Capitolo 3. La forma
3.7. 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.
3.8. 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.
3.9. 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
Ë vel disgiunzione
Ì aut ... aut ... esclusione
Ê (AND logico)
Ë (OR logico)
Ì (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"
Ë "you can do this or that"
Ì "you can do this and/or that"
Ê "è possibile fare questo e quello"
Ë "è possibile fare o questo o quello"
9Capitolo 3. La forma
Ì "è possibile fare questo o quello"
3.10. 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.
3.11. 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.
10Capitolo 4. Traduzione di termini tecnici
4.1. 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.
4.2. 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.
4.3. 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.
4.4. 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.
11Capitolo 4. Traduzione di termini tecnici
4.5. Riconoscibilità
Una buona traduzione deve essere riconoscibile da un tecnico in quanto la parola tradotta (in ordine di
importanza):
• è comunemente usata dai tecnici del settore;
• traduce l’originale in maniera semanticamente fedele;
• traduce l’originale in maniera letteralmente fedele;
• assomiglia all’originale.
4.6. 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.
4.7. 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 "Il glossario">glossario dei traduttori di programmi liberi"
(http://nerd.ocracy.org/em/glossario/glossario.html) o, se si stessero traducendo elementi di una
interfaccia grafica, le "Le linee guida di GNOME" (http://www.firenze.linux.it/%7Ealgol/linee-guida/) di
Luca Ferretti.
12Capitolo 5. Ringraziamenti
Alcune regole sono state prese in prestito dalle pagine dei "traduttori di KDE" (http://kde.gulp.linux.it/)
redatte da Andrea Rizzi, altre provengono da "Il manuale di stile SUN"
(http://developer.gnome.org/projects/gtp/style-guides/pdf/styleguide-it.pdf) (Manuale di stile per la
traduzione) per i traduttori di "SUN Microsystems" (http://www.sun.it/), mentre la maggior parte delle
norme proviene dal glossario dei "traduttori di programmi liberi" (http://tp.linux.it/), redatto da Marco
d’Itri, Francesco Potortì e molti altri.
13Puoi anche leggere
