Ho conosciuto quasi per caso la dott.ssa Veronica Papalia (Università di Padova) che ha realizzato una brillante tesi di laurea in linguistica sulla traduzione della manualistica tecnica (ottobre 2000).
La dott.ssa Papalia mi ha simpaticamente estorto un'intervista (che pubblico con il suo permesso), di cui la ringrazio.
Da parte mia, non credo di essere riuscito a dire nulla di particolarmente originale, ma mi ha aiutato a riflettere sulla mia stessa esperienza. Sembra scontato dirlo, ma è proprio così: l'intervista mi ha fatto scoprire cose che non sapevo di sapere, o meglio che non pensavo di pensare. (Che le mie considerazioni siano esatte, è tutto un altro paio di maniche...)
Pubblico queste note per chi si sta avvicinando all'attività di authoring editoriale (o desidera farlo), aggiungendo questa avvertenza: è solo un punto di vista. Un mio limitato punto di vista. Niente di epocale o stravolgente. La mia unica intenzione (e speranza) è che possa stimolare qualche idea in chi per caso stesse meditando appollaiato sul confine tra umanesimo e informatica. A me, a suo tempo, è successo qualcosa del genere. Le idee devono circolare e germogliare. Le idee sono di tutti.
Ultima nota: la mia intervista è senza pretese. Ma la ricerca di Veronica Papalia è ampia e interessantissima. Appena l'avrà pubblicata la inserirò tra le fonti di questo sito.

E-mail: fabrizio@comolli.it
© 1998-2005 - Fabrizio Comolli

Scrivere e tradurre manuali di informatica:
la mia esperienza
(ottobre 2000)

Torna a: Le mie attività

Indice dell'intervista:

1) Le chiederei subito un suo "identikit" culturale e professionale; potrebbe parlarmi della sua formazione accademica e delle sue esperienze professionali?

Ho 36 anni, mi sono laureato in filosofia (alla Cattolica di Milano) e in psicologia (a Torino). La mia formazione, iniziata in ambito prettamente umanistico, con un originario interesse per la psicologia clinica, nel corso degli anni si è progressivamente focalizzata sul rapporto tra fattori umani e nuove tecnologie. Ho concluso i miei studi concentrandomi sull'ergonomia psicologica, ossia sulle problematiche della "usabilità" del software e del Web.

Da cinque anni mi sono dedicato quasi del tutto a questo ambito, sia sul piano teorico (collaborando dal 1998 con la cattedra di ergonomia della facoltà di psicologia di Torino, prof. Alessandra Re) sia su quello professionale.

Dal 1997 ho iniziato a svolgere l'attività di formatore (corsi in aula e via Web) e, soprattutto, autore multimediale free lance.

Ho scritto una ventina di manuali di informatica, ho tradotto alcuni libri di informatica e new economy, ho realizzato guide in linea (help) per enciclopedie su CD-ROM, come Omnia De Agostini, e siti Web, come Poste.it.

Per quanto riguarda i manuali e i libri di informatica, in particolare, ho collaborato con alcuni dei principali editori italiani del settore: da quelli più "nazionalpopolari" come Jackson Libri a quelli più solidi, come Tecniche Nuove, o dinamici e raffinati, come Apogeo.

Dall'estate scorsa affianco alla mia (ridotta) attività free lance il ruolo di responsabile della comunicazione/web per una Net-company, ossia un'azienda che nasce proponendo servizi interattivi su Internet.

2) Non penso di essere la prima ad essere incuriosita dallo strano connubio tra la sua formazione accademica, decisamente umanistica, e la sua attività professionale in ambito informatico, seppur concernente l'editoria. Come e quanto contribuisce alla sua attuale occupazione il suo background culturale?

Indubbiamente la mia collocazione professionale può apparire ibrida, bizzarra (forse oggi meno che qualche anno fa). Io stesso ho a volte la sensazione di muovermi in una terra di confine con pochi punti fermi. Ma è un'esagerazione. Non mancano riferimenti ormai consolidati, sia come teorie e metodologie, sia come personaggi e "capi-scuola". Un esempio per tutti: Donald Norman, già brillante psicologo cognitivista e docente universitario, poi manager alla Apple, e ora consulente aziendale e autorità indiscussa a livello mondiale, insieme al suo amico e socio Jakob Nielsen, per quanto riguarda il tema della "usabilità" e il rapporto uomo/computer.

Ecco, il rapporto uomo/computer (o HCI: Human-Computer Interaction) è la chiave per descrivere il mio ambito di attività e, a mio avviso, ne derivano molte interessanti implicazioni per l'editoria informatica. Mi spiego meglio.

I computer e i relativi programmi sono tutt'altro che facili da utilizzare. Nonostante incessanti ricerche e sensibili progressi, ad esempio nella progettazione delle interfacce, resta il fatto che tuttora un principiante si trova in difficoltà al suo primo approccio con un PC o con una nuova applicazione, così come un utente esperto a volte fa fatica a sfruttare in profondità tutte le (sovrabbondanti) risorse/opzioni che gli odierni strumenti gli mettono a disposizione.

Questo è il primo problema: gli strumenti (hardware e software), nonostante tutto, non sono ancora né semplici né propriamente amichevoli (user friendly). Lo strumento ideale, dice Norman, dovrebbe essere "invisibile" e consentire all'utente di pensare solo al suo scopo, al suo lavoro, a quello che vuole ottenere. Siamo ancora lontani da questo obiettivo. E infatti, puntualmente, c'è bisogno di consultare il manuale del PC o del programma.

Qui nasce il secondo problema: i manuali istituzionali, quelli forniti dai produttori, non sono soddisfacenti. A volte non sono nemmeno disponibili, o magari (per ragioni di costi) vengono forniti soltanto in versione elettronica sul cd del programma, e non in versione cartacea. Così alcuni utenti ne ignorano del tutto l'esistenza; altri non riescono a sfruttarli a dovere. Spesso, inoltre, questi manuali standard sono mal realizzati, insufficienti, trascurati, per una serie di motivi. Ad esempio, perché vengono realizzati in fretta e furia, come ultima incombenza prima della commercializzazione dei prodotti, e tirati via alla svelta dalla stessa équipe di informatici che ha progettato e sviluppato quel certo software. Una pessima soluzione. Chi sviluppa un programma non è la persona più adatta a spiegarne il funzionamento a un principiante.

Senza nulla togliere alla sua competenza, un bravo informatico di solito non è un bravo istruttore, scrittore o traduttore di manuali. Paradossalmente, più un programmatore è bravo e calato nel suo lavoro, cioè più è un vero specialista, più gli riesce difficile raggiungere quel distacco che è essenziale, da un punto di vista psicologico, per tracciare una visione d'insieme dell'argomento e per immedesimarsi nel principiante, comprenderne e anticiparne le domande, i dubbi, le difficoltà, il percorso di apprendimento. Uno specialista dà troppe cose per scontate (deve farlo), senza rendersene conto. Inoltre, chi sa programmare non per questo sa scrivere o tradurre altrettanto bene: anzi, è molto difficile che questi due tipi di abilità, quella tecnica e quella linguistica o umanistica, convivano in una stessa persona. Ed è più che comprensibile.

Qui si apre lo spazio per l'editoria informatica: con l'accento sulla parola "editoria". I libri di informatica non sono un semplice surrogato dei manuali d'uso, sono qualcosa di diverso e di più. I manuali d'uso, quelli istituzionali, quelli cioè forniti dai produttori, sono quasi sempre di tipo "reference": rassegne di funzioni descritte e commentate con maggiore o minore abilità (vedi sopra), ma quasi sempre secondo una logica che è quella della macchina, non quella dell'utente.

Un buon libro di informatica, in linea del tutto generale, dovrebbe riuscire a combinare l'approccio di tipo "reference" con quello di tipo "tutorial": dovrebbe cioè esporre con completezza le funzioni di un programma, certo, ma seguire un percorso che rispecchi e faciliti lo stile di apprendimento di un tipico operatore umano che parte da zero. In parole povere, un buon libro di informatica deve rispondere non alla domanda "cosa può fare questo software?" ma alla domanda "che cosa vuole fare l'utente?": seguire quindi un percorso che rispetta la psicologia umana, non la celebrazione della tecnologia in sé.

Quando si parla di stile di apprendimento, entrano in gioco svariati fattori: il piano mentale che un utente si costruisce per operare con quel programma (quindi una "scaletta" di aspettative, obiettivi, sotto-obiettivi e operazioni per conseguirli); le prerogative e i limiti della percezione (leggibilità dei testi e delle illustrazioni); le prerogative e i limiti della memoria (quanti punti di un elenco, ad esempio quanti passaggi di un'operazione, può tenere a mente in media un soggetto?); i problemi di linguaggio (chiarezza, rischio di equivoci, gergo tecnico), e così via.

In breve, ecco che ci siamo spostati sul terreno della psicologia. In questo senso, per quello che riguarda la mia esperienza, una formazione umanistica può essere un grande vantaggio e una fonte di risorse.

Oltre all'utilità di competenze di ordine psicologico, una formazione umanistica in genere si accompagna a una certa familiarità con la scrittura. Il che non guasta, anche nel mondo dell'editoria informatica e specializzata. Il resto viene con l'esperienza sul campo: interesse (al limite, passione) per l'argomento, conoscenza ed esercizio, apprendimento grazie a esempi, tentativi, errori.

Aggiungo un'ultima osservazione. Quando si tratta non di scrivere ma di tradurre, sia che si tratti di un libro di informatica che di un romanzo, i fattori in gioco non sono più solo di tipo tecnico e di tipo psicologico ma anche di tipo culturale. Un buon libro di informatica americano può essere molto diverso da un buon libro di informatica italiano. Ma penso che di questo parleremo tra breve.

3) Qual è l'équipe ideale nella stesura di un testo di informatica, sia esso di traduzione o d'autore?

Qual è l'équipe ideale per scrivere o tradurre un libro di informatica? Darò una risposta semplice (che sembra provocatoria, ma non lo è): non esiste. Nel senso che questo lavoro, nel 99% dei casi, non viene fatto in équipe. Meglio parlare di una one-man-band: l'autore (o il traduttore) opera quasi sempre da solo.

Nel settore informatico, molti editori si limitano a distribuire il lavoro, raccogliere il prodotto finito e appiccicargli la copertina. Forse sto esagerando un po', ma questa è davvero una prassi quasi generalizzata. Solo in rari casi si crea un vero rapporto "maieutico" e creativo tra editore e autore.

Teoricamente, queste sono le figure coinvolte: l'editore (direttore editoriale e/o redazione) che pianifica le opere e compie una revisione del lavoro prima della stampa definitiva; l'autore (o traduttore) che si occupa dei testi; l'illustratore che realizza le figure; l'impaginatore che assembla il tutto e genera le pellicole o i file digitali da fornire allo stampatore.

Molto frequentemente, però, l'autore stesso realizza sia i testi che le illustrazioni; non è raro che si occupi in prima persona anche dell'impaginazione del libro.

Questa concentrazione di funzioni nella stessa persona (se ne ha le competenze), lungi dall'essere un cortocircuito o un'interferenza, è un grande vantaggio. La qualità di un testo trae notevoli benefici dalla coerenza interna e dall'equilibrio che deriva da un'unica paternità di tutte le varie componenti. La competenza cruciale resta sempre e comunque quella dell'autore o traduttore.

Come dicevo all'inizio, in genere è preferibile un'ottima competenza nella progettazione concettuale e nella stesura linguistica del testo, rispetto alla conoscenza minuziosa dei singoli argomenti. Come è ovvio, questa conoscenza è necessaria: bisogna avere la pazienza e l'umiltà di documentarsi e imparare ogni volta. Ma il punto, a mio modo di vedere, è che la conoscenza degli argomenti tecnologici può essere sviluppata in tempi ragionevolmente brevi e in modo mirato, caso per caso, una volta che si sono raggiunte solide basi. Al contrario, le competenze culturali-linguistiche non possono essere improvvisate, richiedono anni di preparazione e un incessante lavoro di messa a punto ed esercizio.

Direi comunque che, in caso di manuali poderosi o argomenti particolarmente complessi, può risultare molto utile aggiungere alla (ipotetica) équipe la figura di un consulente tecnologico esterno, un esperto dello specifico dominio che affianca l'autore, offre spunti e chiarimenti, verifica i passaggi più delicati.

4) Qual è la strategia nell'ideazione e creazione di un manuale di informatica?

Ogni anno, con parecchi mesi di anticipo, gli editori preparano il piano delle pubblicazioni per l'anno successivo: quanti libri, su quali argomenti e con quali tempi di uscita. Una prima questione strategica è quella degli argomenti.

La scelta degli argomenti (cioè, in generale, dei software) a cui dedicare uno o più libri è strettamente legata a un'ampia serie di variabili e alle tendenze del mercato informatico: ci sono argomenti consolidati, nuove versioni, novità assolute e così via. Il mercato informatico è talmente dinamico e tumultuoso che, in realtà, un editore si trova spesso costretto a elaborare una strategia al buio.

È difficile prevedere a priori quali argomenti funzioneranno e quali no. Anche perché gli argomenti "informatici" si evolvono con un ritmo frenetico, mentre i tempi dell'editoria sono medio-lunghi. Un esempio: per sapere se un certo libro ha avuto successo oppure no è necessario attendere mesi e mesi (il tempo di completare la distribuzione in tutte le librerie, attendere ed elaborare i risultati delle vendite eccetera). Nel frattempo, il software a cui quel libro era dedicato è probabilmente cambiato: è uscita una nuova versione, è saltato fuori un software concorrente, o chissà che altro. E gli utenti come avranno reagito? Come reagiranno? Compreranno ancora la nuova versione dello stesso software? Ne compreranno ancora più copie? Lo abbandoneranno?

L'editore informatico deve quasi sempre azzardare e giocare d'anticipo, seguendo il suo fiuto, in modo molto più spiccato di quanto avvenga in altri settori editoriali.

Un'altra scelta cruciale è: far scrivere libri d'autore (cioè in italiano da autori italiani) o tradurre opere straniere (nel 99,99% americane)? I costi sono diversi. Può sembrare assurdo, ma una traduzione può venire a costare all'editore più della stesura originale di un libro in italiano. D'altra parte, molti editori nutrono la convinzione che i libri di informatica americani siano tuttora un punto di riferimento (in termini di qualità, completezza, piacevolezza e via dicendo). Questo non è del tutto vero (e alcuni editori propongono intere collane realizzate da autori italiani), ma è un'idea che perdura.

In ogni piano editoriale, in generale, vengono perciò incluse sia opere originali che traduzioni, in proporzioni variabili. Molto spesso, la scelta si differenzia in base alla tipologia delle opere: Le collane di "grandi guide" (libri particolarmente corposi ed esaustivi, spesso rivolti a lettori esperti), nella maggioranza dei casi, sono basate su traduzioni: rimane una certa sfiducia di fondo, serpeggiante, verso gli autori nostrani a questo riguardo. Invece, i manualetti rapidi, tascabili, pratici vengono più facilmente affidati ad autori italiani. Un editore, inoltre, può acquistare i diritti per tradurre non solo singoli titoli ma anche intere collane, magari contrassegnate da un marchio (e una "immagine") particolarmente riconoscibile, che diventano il suo cavallo di battaglia, una volta dimostrato che hanno attecchito bene nel mercato librario italiano.

Questa mia panoramica è un po' una semplificazione, ma ritengo che renda con una discreta attendibilità il quadro d'insieme.

5) Ogni singolo editore ha particolari stili/esigenze/strategie?

Ci sono editori esigenti e altri meno. Ci sono editori con una spiccata personalità e altri più anonimi. Infine, ci sono editori più organizzati e altri più lassisti. Il compito dell'autore e del traduttore cambia molto da caso a caso.

A volte un editore fornisce in partenza una serie di specifiche molto dettagliate, relative a scelte redazionali (come i criteri per la formattazione dei termini tecnici) e linguistiche (forma impersonale o discorso diretto). In questo caso chi scrive è più vincolato ma anche più "appoggiato".

Quando così non è, l'autore (o il traduttore) ha maggiore libertà ma nello stesso tempo deve mantenere costantemente un più alto livello di controllo e auto-disciplina per garantire la coerenza del proprio testo.

6) Riguardo al target a cui viene indirizzato un manuale di informatica, vengono previste indagini di marketing per meglio identificarlo?

Di solito un editore informatico non si sobbarca i costi di specifiche indagini di mercato, salvo casi molto particolari. Il motivo è che, oltre a esigenze di risparmio (l'editoria è un campo in cui i margini di guadagno sono risicatissimi), i ritmi frenetici del mercato informatico scoraggiano simili imprese: come già abbiamo visto prima, i tempi sono strettissimi, e le indagini di marketing, se ben fatte, richiedono un impegno di qualche mese. In breve, ma questa è una mia supposizione poiché fuoriesce dalle mie competenze, un'indagine di marketing scatterebbe una fotografia (dei potenziali acquirenti/lettori) che sarebbe già vecchia prima ancora di essere sviluppata… E' difficile, quindi, che il target di un libro o di una collana sia raffigurabile come un preciso segmento di consumatori, identificabile per fascia di età, cultura eccetera.

Piuttosto, tutti gli editori tendono a differenziare libri e collane in base a una ipotetica e generica tripartizione dei lettori, sulla base del loro grado di competenza informatica: ci sono libri (o collane intere) dedicati ai principianti assoluti, altri dedicati a chi ha una discreta esperienza e altri ancora dedicati agli utenti espertissimi. Di solito il target di ogni libro viene evidenziato sulla copertina con apposite diciture, bollini o altri accorgimenti grafici. L'autore o il traduttore devono tenere conto innanzitutto di questa tipologia di destinatari, calibrando il più possibile l'approccio concettuale e linguistico.

7) La collana For Dummies (Apogeo) si allinea con un nuovo modo di intendere il technical writing. Facendo un confronto di massima, ammesso che sia possibile, tra il pubblico italiano e quello americano, si può parlare di aspettative diverse nei confronti di un manuale di informatica? E specificamente, in Italia serietà dell'argomento trattato significa ancora "seriosità" nel trattarlo?

Per una serie di ragioni, alcune delle quali già accennate, non è facile capire esattamente le caratteristiche, le aspettative e le reazioni del pubblico reale, cioè degli effettivi lettori di un libro. Almeno qui da noi: negli USA, dove l'alfabetizzazione informatica è molto più radicata, è più facile vedere forme di interazione tra editori, autori e lettori. Ad esempio nelle librerie virtuali su Internet, come Amazon, è abbastanza comune leggere all'interno della scheda di un libro, tra tutte le informazioni utili per orientare all'acquisto, anche le recensioni di lettori qualunque.

In linea di massima si dà per scontato che l'approccio made in USA sia caratterizzato da un tono più leggero e sdrammatizzante, denso di battute, metafore, toni colloquiali e via dicendo. In effetti la lingua inglese si presta bene: è la lingua "tecnologica" per eccellenza, la koiné o l'esperanto dell'informatica, e in più offre innumerevoli occasioni per divertirsi con le assonanze e i giochi di parole. È anche una lingua molto sintetica, che consente una certa libertà d'azione. Di fatto, è facile trovare questi toni un po' sopra le righe persino nei manuali più voluminosi e complessi. Addirittura, ci sono intere collane dedicate (letteralmente) agli "imbranati", agli "idioti totali" eccetera. I lettori americani devono solo scegliere in quale categoria riconoscersi, e si divertono.

Altrettanto scontato, per molti, è che il pubblico italiano ed europeo sia molto diverso: più serio (o serioso), forse anche meno spiritoso. In effetti, a volte è vero. Mi viene in mente un caso concreto.

Mi è capitato di partecipare a un progetto per l'innovazione dei libretti di istruzioni di una nota marca italiana di elettrodomestici. La documentazione che avevamo a disposizione includeva un'indagine di mercato svolta in precedenza mediante focus group (gruppi di discussione) di consumatori. Erano state preparate e presentate tre bozze del nuovo prototipo di manualetto: una serissima e tecnologica, una semplice e divulgativa e una molto creativa. Quest'ultima bozza era basata su un progetto grafico in stile fumetto, secondo l'ipotesi che occorreva sdrammatizzare un argomento così serio e noioso come l'utilizzo di una lavatrice, e che inoltre il destinatario del messaggio era una casalinga senza competenze o propensioni tecnologiche. Le istruzioni erano perciò presentate da un personaggio da cartoon, una lavatrice "umanizzata", con un tratto grafico e linguistico simpatico e spiritoso. In partenza, quasi tutti scommettevano che questo sarebbe risultato il progetto vincente. Invece, il responso dei focus group fu esattamente l'opposto: le casalinghe e gli altri intervistati manifestavano una certa insofferenza per questo approccio. "Mi trattano come un/una deficiente", "Non sono mica un/una bambino/a", "Voglio imparare a usare questo aggeggio, non voglio leggere un fumetto": queste erano state le reazioni prevalenti.

Dunque è legittimo sostenere che le americanate non pagano. Eppure, non è un dogma, non è sempre così. Facendo per anni formazione in aula, ho potuto constatare che moltissimi principianti, nel loro approccio al computer e a Internet, in realtà apprezzano davvero i toni rilassanti e sdrammatizzanti.

Probabilmente il computer è un oggetto tecnologico particolare, che viene vissuto in modo differente rispetto ai comuni elettrodomestici. Gli elettrodomestici sono ormai acquisiti come compagni quotidiani, restano (devono restare) invisibili e limitarsi a fare bene il loro lavoro. Il computer invece è ancora, per molti, un totem tecnologico: incute soggezione, diffidenza o senso di inferiorità (almeno in certe fasce generazionali).

In questo caso, perciò, il principiante apprezza le strizzatine d'occhio e le battute "liberatorie". Forse è il lettore esperto ad avere gusti più difficili: quando legge un manuale complesso vuole andare al sodo. Ha obiettivi precisi e poco tempo da perdere. Le battute non sono da escludere, ma devono essere assolutamente ben scelte, ben dosate, appropriate e non invadenti.

In breve, direi (ma è un'ipotesi) che la differenza va fatta non tanto tra i lettori USA e quelli italiani, presi in blocco, ma tra i target distinti per competenza e obiettivi. Per il principiante, il libro/manuale deve essere un compagno di avventura (l'avventura dell'apprendimento) e dunque non deve essere avaro di commenti, incoraggiamenti, persino distrazioni. Viceversa, per l'esperto il libro/manuale è sostanzialmente uno strumento di lavoro: una battuta ogni tanto va benissimo; basta non esagerare.

8) Nella stesura di un manuale, quali sono le tappe che segue?

Ogni libro nasce da un embrione: un'idea, una scaletta. Cioè una bozza di indice che rispecchia il progetto editoriale nel suo complesso. La scaletta richiede già una certa percezione globale dell'argomento, anche se all'inizio non è indispensabile avere chiari tutti i dettagli.

Con questo riferimento di massima, inizio una fase di esplorazione dell'argomento (supponiamo: un certo software). Se non lo conosco ancora, lo installo, lo provo, approfondisco le funzioni e le opzioni principali. Contemporaneamente ritocco la scaletta e preparo uno schema via via più preciso del libro, calibrando la segmentazione degli argomenti in capitoli e paragrafi.

In questa fase esplorativa cerco di mettermi nei panni del principiante e mi chiedo in quale ordine io stesso vorrei trovare esposte le spiegazioni. C'è anche un immediato risvolto operativo: comincio subito a catturare alcune schermate (immagini) del programma, alcune perché in seguito sarebbero impossibili da ricatturare (quelle dell'installazione), altre perché mi aiutano a farmi un'idea degli ingombri o sono un promemoria per le descrizioni da sviluppare in seguito sotto forma testuale.

A questo punto passo a imbastire lo scheletro del libro: un file per ogni capitolo, in cui inizio a scrivere soltanto i titoli della gerarchia di paragrafi e sottoparagrafi. Già così è possibile iniziare a valutare le dimensioni relative di ogni capitolo; inoltre, diventa molto più facile scrivere il testo, procedendo in modo non sequenziale ma a spirale, per accumulazione progressiva.

In altre parole, dopo aver preparato la struttura (dettagliata) dei capitoli, inizio a scrivere qua e là i paragrafi su cui mi sento più pronto, poi torno indietro a colmare i vuoti, salto avanti per aggiunte o proseguimenti, e così via. Un po' come tessere una ragnatela.

Nel frattempo realizzo man mano tutte le altre illustrazioni: schermate del programma ma anche, quando necessario, schemi e diagrammi per illustrare aspetti concettuali o di metodo. Gli schemi in forma grafica per me sono molto importanti (li uso io stesso quando devo memorizzare qualcosa): vanno studiati bene, e di solito li realizzo a metà del lavoro, quando ho raggiunto una buona visione d'insieme dell'argomento. Nel mio caso, poi, il rapporto tra testo e illustrazioni è dinamico, flessibile, non preordinato: a volte mi viene spontaneo prima scrivere e poi illustrare, a volte faccio il contrario (prima realizzo le illustrazioni e poi ne traggo ispirazione per stendere le relative spiegazioni).

In tutto questo processo, il tempo scorre in modo non omogeneo.

La prima fase, quella dell'esplorazione e della sperimentazione, porta via un 50% della durata complessiva (dall'accettazione dell'incarico alla consegna dell'opera finita).

Poi stendo la struttura del libro, preparando lo scheletro dei singoli capitoli: una serie di titoli con semplici segnaposto (delle belle file di "xxxxxxxx"!) dove dovrò inserire i testi. Anche questa fase di strutturazione analitica va pensata e richiede un 10-20% del tempo globale.

Fatto questo, per me tutto è risolto. Resta il tempo materiale per la stesura: meno della metà del tempo globale. Di solito, infatti, inizio a scrivere piuttosto tardi: solo quando ho le idee chiare.

Partendo da una valida struttura, e avendo già metabolizzato gran parte dei contenuti, il lavoro della scrittura in sé mi porta via poco tempo, e procede in accelerazione. All'inizio riesco a scrivere al massimo cinque pagine al giorno, mentre nelle fasi avanzate arrivo a dieci-quindici pagine. Aggiungendo le immagini (che realizzo in parallelo), il numero di pagine aumenta, a volte si raddoppia.

In genere riesco a realizzare un libro nel giro di un mese, un mese e mezzo. Questo è il quadro d'insieme, quando scrivo un testo originale. Quando invece traduco, lo schema e i tempi di lavoro sono molto diversi.

9) Come diceva, è stato anche coinvolto nella traduzione di manuali dall'americano all'italiano. In quel caso, ha lavorato nell'ambito di un team? Come ha vissuto le sue esperienze in veste di traduttore?

Ho avuto esperienze di traduzione polarizzate verso i due estremi di un'ipotetica scala di argomenti. Infatti ho tradotto sia manuali estremamente tecnici (sui protocolli di rete) sia libri più discorsivi, creativi, divulgativi (sulla new economy e sulle implicazioni culturali-filosofiche delle nuove tecnologie).

Cominciamo dal primo caso, quello dei manuali iper-tecnici. Sinceramente è un'impresa che non mi sentirei di ripetere a cuor leggero. Volumi imponenti, dedicati ad argomenti specialistici: poco testo descrittivo, infinite sequenze di istruzioni, un'elevatissima densità di termini tecnici da rendere con assoluta accuratezza. In breve, ecco quei casi a cui accennavo, in cui la competenza tecnica deve plausibilmente prevalere su quella linguistica. Anche se è difficile scinderle: sarebbe inutile ottenere un'accuratezza totale sul piano lessicale (i singoli termini tecnici), se poi la trama delle spiegazioni e i costrutti linguistici fossero inaccurati o addirittura fuorvianti (e a volte succede). Comunque non mi dilungo: è stata una gran fatica!

Diverso è il caso delle traduzioni più sostanziose e di qualità. Tradurre un bel testo, che richiede una comprensione di contenuti concettualmente stimolanti, è davvero piacevole.

Rispetto al lavoro di scrittura originale, tutto procede in modo più lineare. Di solito, leggo rapidamente una volta l'intero libro, o almeno lo sfoglio selettivamente per farmi un'idea d'insieme. Poi inizio a tradurre, seguendo l'ordine del testo (anche se a volte, ovviamente, occorre tornare sui propri passi e rivedere qualche passaggio o qualche criterio). Il tempo scorre in modo relativamente omogeneo: non si può dire che sia routine, ma sicuramente tradurre è un compito più prevedibile e costante rispetto al puro scrivere.

Ma non è un compito meno creativo: tradurre, si sa, è un po' tradire. E deve esserlo. Le peggiori traduzioni sono quelle letterali. Sia chiaro: stiamo parlando comunque di manualistica, o di saggistica di carattere tecnologico. In altri campi valgono probabilmente regole diverse. Nel caso di libri, manuali o saggi su temi di informatica e nuove tecnologie, l'obiettivo è far comprendere i concetti-chiave.

La formulazione linguistica non è sacra, è solo un mezzo e non un'espressione artistica da salvaguardare. Là dove possibile, cerco di rispettare la personalità dell'autore e lo stile complessivo dell'opera. Ma una volta che riesco a immedesimarmi, mi sento assolutamente libero di riscrivere, letteralmente, interi paragrafi, se ritengo che in italiano ci sia un modo migliore per rendere lo stesso concetto. Una traduzione di questo genere deve essere, secondo me, un'opera di mediazione intelligente e lungimirante, più che un lavoro meticolosamente filologico. Ed è un impegno spesso appassionante.

Per usare una metafora olimpionica, direi in sintesi che scrivere un libro originale assomiglia al triathlon: una serie di impegni di natura differente, un ritmo variabile, in cui si alternano tempi lunghi e scatti brucianti. Tradurre un testo del genere è invece una maratona, o meglio un lungo percorso a ostacoli: un impegno più costante, una concentrazione omogenea, qualche impennata ogni tanto.

Giusto per proseguire la metafora, bisognerebbe citare infine la staffetta: i casi in cui si traduce a più mani. Qui le difficoltà aumentano, per via della necessità di sincronizzarsi sul piano linguistico. Di solito, l'ideale è che i due (o più, ma raramente) traduttori inizino subito a costruire un glossario comune, a uso interno, man mano che entrambi incontrano termini specifici, con un incessante scambio di pareri, consigli, riflessioni, in modo che le scelte finali siano assolutamente coerenti e il libro sembri tradotto da un'unica persona. Ma qui l'argomento si dilungherebbe ulteriormente.

10) Il problema delle "culture" diverse a cui accennava prima, come viene affrontato?

Abbiamo già toccato la controversa questione dell'ipotetico "approccio americano" rispetto a un "approccio italiano". Posta questa premessa, direi che molto dipende dalla sensibilità del traduttore e dalle scelte dell'editore.

Alcuni editori hanno una politica linguistica abbastanza precisa: prediligono cioè uno stile impersonale, senza discorso diretto (nessun soggetto in prima persona, né singolare né plurale, e indicazioni in forma indiretta: "aprire il menu…" oppure "si deve fare clic…", "si faccia attenzione…" eccetera).

Altri editori lasciano libertà di scelta al traduttore e restano abbastanza aperti o indifferenti a questi aspetti. Alcuni, ma è raro, preferiscono esplicitamente un approccio diretto e colloquiale. Anche nei confronti delle battute e delle espressioni gergali l'atteggiamento degli editori varia da caso a caso.

In generale, se il traduttore non riceve direttive in proposito, deve scegliere da solo la sua strategia. L'importante, secondo me, è che non si senta schiavo del testo originale e non si appiattisca su una traduzione letterale.

11) Il problema della traduzione di termini tecnici. Qual è l'atteggiamento da assumere?

Questo è un aspetto problematico. Esistono alcuni dizionari tecnici, su carta, ma tutti quelli che conosco sono pessimi: scadenti, generici e poco aggiornati. Ci si trovano riferimenti alla preistoria dell'informatica (come il linguaggio Cobol o altri termini vetusti e ormai abbandonati) mentre mancano totalmente voci oggi cruciali, come in generale quelle relative alle tecnologie Internet. Molto meglio divorare le riviste del settore (mensili su informatica e Web), che pullulano di glossari aggiornati, mirati e ragionati. Questo come risorsa di base. Nello specifico, alcuni editori (pochi, in verità) e soprattutto alcuni service editoriali, che spesso sono i mediatori tra l'editore e il traduttore, forniscono glossari specifici, magari in formato elettronico. Qui si trovano le traduzioni "canoniche" dei termini più specialistici, a cui occorre rigorosamente attenersi.

In molti casi, comunque, il traduttore deve ingegnarsi e aggiornarsi spontaneamente, cercando sempre le fonti più accurate. Una risorsa interessantissima, per inciso, sono i dizionari online presenti su Internet, come quella famosissimo della Logos: riferimenti vivi perché costruiti dagli stessi operatori del settore e in continua evoluzione/accrescimento. A volte, peraltro, occorre tenere conto dei precedenti storici: se in un'edizione precedente un certo termine è stato tradotto in un certo modo, può essere opportuno restare fedeli a quella traduzione (che gli utenti potrebbero aver assimilato stabilmente), piuttosto che scegliere una nuova soluzione, per quanto sembri in astratto più appropriata. Dipende dalle circostanze. Abbondano comunque le idiosincrasie, sia da parte dei traduttori che degli editori e persino delle software house (ad esempio, Microsoft ha un suo rigoroso glossario ufficiale).

Su alcuni argomenti ci sono punti fermi: un button su cui fare clic (ad esempio, un OK button) è un "pulsante" (il pulsante OK); solo un dilettante lo tradurrebbe come "bottone". Le finestre dei programmi e tutti i loro componenti (caselle di opzioni, menu eccetera) obbediscono a una terminologia standard che bisogna conoscere e rispettare.

In altri casi ci sono diatribe ancora aperte. Ad esempio, secondo la scuola di pensiero condivisa da Microsoft e dai puristi del settore, per quanto riguarda l'utilizzo del mouse l'espressione corretta è "fare clic" (N.B.: "clic" è italiano, "click" è americano!), e non l'obbrobrioso neologismo "cliccare". Il che sembra sensato: infatti, quando è necessario si può anche dire "fare doppio clic" o "fare clic col pulsante destro", evitando di doversi inventare forme improponibili come "doppiocliccare" o "destrocliccare". Una discussione senza fine riguarda il verbo appropriato per l'utilizzo dello scanner (dispositivo per digitalizzare le immagini), che in inglese è semplicemente to scan: "scannerizzare"? "scansionare"? "scandire"? "scannare"?… Le unità di misura restano invariate (un byte è un byte), ma l'hard disk è il disco fisso (anticamente detto anche disco rigido…). Il dischetto però resta preferibilmente floppy disk anche in italiano. E via dicendo.

Possono sembrare disquisizioni buffe o persino assurde, una specie di versione hi-tech dell'Accademia della Crusca. Ma conta anche questo. E poi, a ben vedere, in Italia siamo ancora ragionevoli: basta pensare allo sciovinismo francese, che impone una localizzazione di tutti i termini informatici, con esiti davvero maniacali e ridicoli.

In ogni caso, trovo singolare, divertente ma anche molto interessante il fatto che, dietro le quinte, un argomento freddamente tecnico come l'informatica stia animando un vivo dibattito su questioni linguistiche e culturali, inducendo gli autori e i traduttori a ripensare criticamente la stoffa del loro lavoro. Che una lingua sia viva lo si vede anche da questi retroscena.

12) Esistono casi di manuali di informatica italiani tradotti all'estero, e nello specifico in inglese/americano?

Non che io sappia. Credo che questo sia per ora un primato (o un tabu?) inviolato nel campo della manualistica informatica.

13) Per concludere, ci può accennare a particolari esperienze o aneddoti che corrono tra i "corridoi" delle traduzioni di manuali di informatica?

Di esempi e aneddoti ce ne sarebbero a bizzeffe. I più gustosi, comunque, riguardano probabilmente l'abisso che corre tutt'oggi tra la traduzione effettuata da un essere umano e la traduzione effettuata da una macchina. Potremmo propriamente parlare di un confronto fra traduzione umana e traduzione disumana…

I software per la traduzione automatica sono ben lontani dalla perfezione. Nessuno si azzarda a utilizzarli in ambito professionale, se non alcune software house che ritengono economicamente vantaggiosa questa soluzione. Non tanto nel caso dei manuali cartacei, quanto piuttosto nel caso delle guide in linea e dei manuali in formato elettronico, capita di vedere esempi di drammatica o esilarante inefficacia: invariabilmente, la ragione è che il produttore ha avuto l'ardire di effettuare in proprio e all'origine la traduzione (ricorrendo pesantemente a traduttori automatici), anziché affidarla a un'équipe professionale del Paese di destinazione. Lo stesso problema affligge la traduzione (in gergo: localizzazione) di molti programmi: nomi dei menu, comandi e opzioni risultano spesso comici o incomprensibili.

Qualche esempio dei risultati finali? "Passeggiata" invece di "percorso" (path: la posizione di un file nella gerarchia di cartelle e sottocartelle di un disco fisso), "Produzione libraio" invece di "Libreria di produzione" (production library: una raccolta di file, icone, materiali vari per integrare un progetto), "Lettore filmato attivo" invece di "Lettore ActiveMovie" (ActiveMovie è un termine tecnico legato ai file video), e così via (scheda 1).

Ci sono esempi ben noti agli addetti ai lavori, come l'indimenticabile "bastoncino della gioia" (più noto come joystick) o un famosissimo pseudo-manuale IBM per la manutenzione dei mouse zeppo di involontari doppi sensi ed esilaranti equivoci (scheda 2). In gran parte però si tratta di leggende metropolitane.

Altri esempi reali, invece, tratti da un programma per il montaggio video su PC, sono illustrati nella scheda 3, che mi permetto di scegliere come chiusura semi-seria di questa nostra "chiacchierata".

(N.B. - a proposito di traduzione automatica online, vedere anche il profilo di Alois Haba)