MSDN Magazine in italiano: vale la pena?

Incuriosito dalla segnalazione di Emanuele, sono andato a vedermi la versione italiana di MSDN Magazine.


Sarò sincero: ero pronto al peggio. Poco più di un anno fa non ero stato tenero (perché non ve n’era motivo) con la traduzione automatica degli articoli di knowledge base (KB) di Microsoft. Visto il seguito (nullo) del mio civile dissenso che mi ha obbligato a modificare l’impostazione di Internet Explorer (che altrimenti mi farebbe vedere per default sempre la traduzione italiana di un qualsiasi articolo di KB…), capirete che ero pronto a vedere pubblicati in pompa magna titoli e contenuti prodotti da un software bello come esercizio di ricerca, ma ancora quasi inutile da un punto di vista pratico.


Invece, sorpresa, gli articoli sono tradotti da esseri umani (se non fosse così, dovrei parlare di miracolo). Questo significa che c’è dietro un investimento significativo (tradurre costa). Allo stesso tempo, però, torniamo a un problema che già ho affrontato qualche anno fa. Farò anche un po’ di storia personale per far capire meglio l’origine del mio ragionamento.


Il mercato editoriale in generale ha spesso bisogno di tradurre materiale straniero. Ovviamente, per un libro di Crichton, per un Harry Potter, per un best-seller qualsiasi, la cura nella traduzione è molto elevata. Nella letteratura in generale il traduttore è una persona, o al limite un team ristretto di persone che collaborano strettamente. Si può dire che l’opera tradotta sia, in alcuni casi, una specie di “seconda opera”, perché subentra la necessità di rendere in una lingua diversa espressioni idiomatiche, modi di dire e magari riferimenti culturali che non hanno equivalenti diretti. Difficile, ma non impossibile visto che i risultati sono decisamente apprezzati. Analogo discorso vale per il cinema, dove subentra un’ulteriore difficoltà data dalle necessità di doppiaggio – e noi italiani vantiamo una scuola di doppiaggio che forse non ha uguali nel mondo.


Chiaramente, quando ci si scontra con la necessità di produrre volumi elevati (di traduzioni) in tempi ristretti e con costi bassi, il discorso cambia. Qui ci sono due mondi paralleli che probabilmente spesso si incrociano. Da una parte, grandi società che offrono servizi di traduzione assorbendo volumi ciclopici di lavoro; queste società ovviamente dividono il tutto tra dipendenti e collaboratori (soprattutto collaboratori) e in pratica vendono come valore aggiunto la capacità di organizzare e coordinare il lavoro di un team molto ampio, che può parallelizzare tantissimo il lavoro e fornire risultati in tempi brevi. Dall’altra, singoli professionisti, a volte collaboratori a progetto, altre volte veri e propri lavoratori indipendenti (per me tale definizione implica di avere almeno 2 clienti, altrimenti dove sta l’indipendenza?), alcuni lavorano direttamente per gli editori, altri per le citate “grandi società”, succede anche che facciano entrambe le cose.


Questo modello è molto efficiente se si vogliono tradurre le istruzioni per gli elettrodomestici. Nessuno pretende di vedere un testo di letteratura, l’importante è che si capisca e in genere parliamo di operazioni più o meno semplici che devono essere spiegate a un pubblico molto vasto. Tutti avremo letto delle istruzioni simili che facevano un po’ ridere, ma in genere alla fine abbiamo capito come funzionava il dispositivo.


Estendendo il concetto, se dobbiamo scrivere un libro di istruzioni su come fare la manutenzione di un macchinario utensile, probabilmente seguiamo lo stesso modello. Se il macchinario è particolarmente costoso (o potenzialmente pericoloso), magari chiediamo a un esperto dell’argomento madrelingua di dare una valutazione finale sul risultato. Se al posto del macchinario utensile pensiamo a un aeroplano, forse l’esperto di avionica lo coinvolgiamo anche durante la fase di traduzione e non a opera finita.


Saltiamo ora nel mondo dell’informatica. Qui le cose un po’ si complicano. Non dobbiamo spiegare come si usa un macchinario. Spesso è necessario spiegare dei concetti prima ancora che la loro esecuzione. Il modello “industriale” che ho descritto prima a questo punto entra un po’ in crisi. Credo che nessuno possa smentirmi se dico che un testo informatico tradotto è scritto, in genere, con un italiano che nessuno parla, scrive e che tantomeno è desideroso di leggere. Il motivo è che frazionando il lavoro e consegnandolo a dei traduttori professionisti, che hanno un’altissima produttività in termini di parole/ora ma che difficilmente hanno la completa padronanza di ogni specifico glossario (compreso quello informatico), si ottiene un risultato poco fedele. Per compensare questo problema, esistono dei software di ausilio alla traduzione che individuano pattern noti e ne propongono la traduzione automatica. In questo modo si riduce il rischio di tradurre in modi diversi lo stesso concetto, ma si appiattisce ulteriormente il livello linguistico. A ciò si aggiunge il fatto che il committente (per esempio Microsoft) potrebbe dare delle linee guida generali, che sono poi applicate senza considerare casi specifici. Un esempio è l’uso della terza persona, anche quando il testo originale parla direttamente al lettore (qui c’è un problema di fondo dovuto al fatto che you può voler dire indifferentemente tu/voi, ma spesso dal contesto si comprende il tono con cui va inteso).


Questi problemi non nascono certo oggi. Qualche anno fa ho avuto la possibilità di partecipare a un progetto interessante: Mondadori Informatica decise di creare una collana di libri tradotti da persone che facevano lo stesso mestiere di chi li scriveva e probabilmente di chi li leggeva. Personalmente ho tradotto il testo “Introduzione a C#” di Eric Gunnerson e conosco molti dei colleghi che hanno lavorato agli altri titoli della collana. Purtroppo questa iniziativa non ha avuto poi un enorme seguito, anche se la qualità del prodotto finale era decisamente migliore. Questo approccio, infatti, non è applicabile alla totalità dei libri, per una serie di motivi: non ci sono abbastanza persone disponibili a fare questo lavoro, costa meno far tradurre i libri da traduttori professionisti e soprattutto chi fa solo lavori di traduzione garantisce tempi di consegna più veloci. Nel mondo dell’informatica, dove l’obsolescenza di un prodotto è molto alta, questo è uno dei valori più importanti.


Dunque, il problema non è facilmente risolvibile. Qualche tempo dopo ho tradotto un altro libro di C# (Inside C# di Tom Archer – pubblicato da Microsoft Press) e ho dato consulenza sulla revisione della traduzione di Visual Studio (la prima versione .NET) – in pratica ho visto anche come funziona il lavoro nel modello “industriale” e quali sono i vincoli imposti da Microsoft nelle traduzioni. Tradurre la documentazione MSDN di Visual Studio è un’impresa enorme, normalmente uno non si rende conto della montagna di testi che ci sono. Molti sono ripetitivi, ma ci sono anche moltissime parti introduttive e guide passo-passo che, alla fine, “fanno volume”. Far uscire la versione localizzata in italiano a breve distanza dalla RTM inglese richiede un lavoro di anni fatto in parallelo allo sviluppo, il delta tempo è veramente dedicato solo alle rifiniture e al packaging. Capirete quindi che questo gigante che si muove ha un’inerzia enorme.


Se una traduzione è scritta nel glossario, difficilmente la si può cambiare. Il problema è che Microsoft fa Office e fa anche Visual Studio. Voi avete mai sentito un utente (uno vero, che non abbia mai aperto neanche Notepad ma solo Word, Excel e Outlook) parlare in termini di checkbox, combobox e listbox? Credo di no. E quanti programmatori conoscete che parlano al collega di caselle di controllo, caselle di testo, caselle di selezione, caselle di riepilogo e di elenchi a discesa? Io nessuno. Ultima domandina: quante persone conoscete che sono in grado di tradurre correttamente i termini che ho citato da una lingua all’altra secondo il glossario ufficiale Microsoft? Temo lo sappiano fare solo i software di supporto alla traduzione (scherzo, qualche eletto c’è sicuramente!).


Questa è solo la punta dell’iceberg, ma potete intuire che ci sono mille dettagli che potremmo svelare e che spiegano perché un testo tecnico tradotto sia così poco digeribile e leggibile, il più delle volte. Tornando alla versione italiana di MSDN Magazine, devo dire che dopo tutte queste mie considerazioni e in base alla mia esperienza, è stato fatto finora un buon lavoro. Purtroppo, nella mia modesta opinione, tutto questo è assolutamente insufficiente a rendere quel testo interessante e stimolante da leggere. Pensate, una rivista come MSDN Magazine ha redattori che sminuzzano il testo, lo correggono, lo adattano, lo fanno dimagrire, per trasmettere al meglio il messaggio; senza parlare della selezione a monte che viene fatta sugli autori (non è da tutti scrivere su MSDN Magazine). Tutto questo lavoro è in gran parte vanificato da un lavoro di traduzione che, per quanto encomiabile, falcia drasticamente e irrimediabilmente gran parte dell’espressività del testo originale.


Io vi confesso che alla fine mi sono arreso, e non sono uno che si arrende facilmente. Il problema è che il rapporto costo/benefici è assolutamente ingiustificato. Riuscire a rendere leggibile e gradevole un testo tecnico informatico nel processo di traduzione è un lusso che forse non possiamo permetterci. In Italia siamo circa 60 milioni. I programmatori sono in un numero che oscilla tra centomila (secondo me) e qualche milione (secondo alcune stime che mi è capitato di leggere). Probabilmente siamo qualche centinaio di migliaia se mettiamo nel conto chi lo fa per hobby ed escludiamo chi non scrive una riga di codice da almeno 3 anni (sorry, ma da qualche parte bisognerà mettere pure dei paletti). Se di questi prendiamo quelli che sono interessati a leggere articoli di MSDN Magazine… a seconda dell’argomento dell’articolo potrei ipotizzare un numero tra 100 e 10.000. Facciamo una media di 5.000, e credo di stare largo (chissà se qualcuno di Microsoft potrà smentirmi, so che queste cifre sono custodite gelosamente e personalmente non ne sono mai venuto a conoscenza, quindi non sto violando nessun NDA semplicemente perché sto inventando dei numeri). MSDN Magazine di gennaio 2007 (quello tradotto) conta 144 pagine stampate. Togliamo la pubblicità e le figure, diciamo che restano 50 pagine. Vogliamo pagare 50€ per pagina tradotta? Siamo a 2.500€ per numero. Se abbiamo 5.000 lettori in media sono 50 centesimi di Euro per lettore, su 12 numeri fa 6 Euro all’anno. Il costo per articolo sarebbe ovviamente più alto. Credo che tutti gli errori che sto facendo nel conto contribuiscano a tenere basso il valore finale.


Bene, ora provate un po’ a togliere dai 5.000 lettori medi di prima quelli che preferiscono (o si accontentano) della versione in lingua originale. Io direi la metà… stiamo parlando di MSDN Magazine, non di come faccio a fare un sito web con 4 clic del mouse. Questo è un altro fattore che fa raddoppiare il costo/lettore. A questo punto uno dice: ma allora chi glielo fa fare a Microsoft? Beh, per MSDN Magazine l’esigenza è istituzionale. Si tratta di un’operazione di divulgazione che Microsoft deve fare per promuovere l’uso dei suoi prodotti, quindi rientra nei costi di marketing, in fin dei conti. Ci rientra con le licenze. Ma non possiamo chiedere un risultato qualitativamente migliore di quello disponibile, perché non è possibile ottenerlo con i tempi con cui esce adesso il numero in italiano rispetto a quello in inglese (pochi giorni o qualche settimana dopo).


Ora, chiedetevi chi glielo fa fare a qualcuno che non è Microsoft? Nessuno. Da un punto di vista economico, è già difficile rientrare nei costi di traduzione di un libro, ma per una rivista mensile l’impresa è semplicemente anti-economica, giacché chi è interessato in genere compra la versione in lingua originale e chi sarebbe disposto a pagare (anche di più!) per la versione in italiano non fa sufficiente massa critica.


Come ho detto, io mi sono arreso. Ho sempre letto testi in inglese, ma ho sempre preteso che ci fossero traduzioni in italiano all’altezza, visto che ho conosciuto molte persone che non erano così abili con tale lingua. Ricordiamoci che la scuola dell’obbligo in Italia non prevede l’inglese per tutti (o almeno non lo prevedeva fino a qualche anno fa). C’è chi ha studiato francese, chi il tedesco (sempre che lo studio “scolastico” abbia una reale utilità). Però, dopo aver visto tutte le facce del problema, sono arrivato alla conclusione che è più facile (anche economicamente) favorire la diffusione dell’inglese che non cercare di tradurre tutto.


La conclusione di questo mio lungo post (era tempo che non ne facevo così) è un appello destinato a chi continua a chiedere versioni in italiano di prodotti e documentazione di strumenti di sviluppo.


Fermatevi.


State conducendo una guerra persa che però fa consumare risorse (tempo e soldi) che non saranno impiegati diversamente. Per quanto si possa mettere a disposizione un budget sempre più grande per tradurre montagne di documentazione, avrete sempre un handicap come lettori. Lo sforzo fatto per illustrare i concetti in un certo modo è stato in parte (a volte grande) vanificato da una traduzione che rarissimamente si cura della trasmissione dei concetti, il più delle volte si ferma (perché non potrebbe fare diversamente) al rispetto delle regole formali, sintattiche e contrattuali. Personalmente preferirei un solo articolo in più, scritto in italiano e calato sulla realtà italiana, così diversa da quella americana, piuttosto che un nuovo numero di MSDN Magazine italianizzato.


So che non sarò popolare con questa mia posizione, ma ho cercato di esporre un punto di vista argomentato… ma se polemica dev’essere, che polemica sia… 🙂

Visual Studio 2005 e SQL Server 2005: tempo di Service Pack

Da qualche giorno è stato rilasciato il Service Pack 1 di Visual Studio 2005. L’installazione è veramente molto lunga, dove per lunga si intende che può superare i 60 minuti anche su una macchina ben carrozzata. Esistono alcune note per accorciare l’installazione, ma su un PC ho avuto problemi a seguire i consigli (e non valeva la pena perdere altro tempo per identificare le cause, ho seguito il setup normale).


A breve è seguita una nuova CTP (dec06) del Service Pack 2 di SQL Server 2005. Non ho incontrato problemi particolari nel setup, non ho ancora un riscontro sulla portata di alcune delle novità introdotte da questo SP.


Una menzione particolare va al Data Mining Addin for Office 2007 che si può installare con quest’ultimo SP2 e la RTM di Office 2007. Purtroppo esiste un problema che ho segnalato nel forum e che impedisce l’uso dell’Addin con la versione inglese di Excel e le impostazioni internazionali in Italiano. Spero che questo venga risolto o che almeno si trovi un workaround (non saranno in tanti ad avere questa configurazione, ma per me rappresenta la norma). Problemi a parte, consiglio a tutti di provare questo componente, anche se non si hanno esperienza di Data Mining: può essere il modo migliore per cominciare.

Wiki su MSDN

Ho appena dato un’occhiata al Wiki di MSDN, che consente di aggiungere commenti e informazioni alla documentazione (per ora una parte) on-line di MSDN.


Sinceramente da una parte è una cosa che fa piacere (ascoltano i clienti…), dall’altra incute qualche timore perché la mancanza di un vaglio preventivo di tali aggiunte alla documentazione potrebbe consentire la pubblicazione di vere e proprie “Worst Practice”. Ma, nel dubbio, molto meglio provare piuttosto che rinunciare prima ancora di aver cominciato.


Una cosa ottima sarebbe avere una sorta di “board” di controllo che vagli tutti i commenti inviati e magari li classifichi, o classifichi gli utenti che collaborano. Chiaramente la secondo strada sembra la più promettente, visto che non richiede investimenti particolari. La mancanza di una “redazione” e di un “progetto editoriale” è qualcosa che ancora limita la reale utilità di progetti simili.