Conclusioni

Trattando degli strumenti liberi e open source per la traduzione assistita è emersa una serie di peculiarità diverse rispetto alle alternative esistenti nel campo del software proprietario come SDL-Trados, Wordfast, Déjà-Vu o Across. La più evidente, è che non è facile individuare uno strumento o una serie di strumenti che occupi una posizione di predominio sugli altri, come accade nel software proprietario in cui è possibile osservare una chiara leadership di mercato esercitata dal pacchetto SDL-Trados.

A creare questo panorama nel SL contribuisce senz'altro in maniera significativa l'adozione di standard aperti (XLIFF, TMX, TBX, SRX), che assicura la compatibilità fra strumenti diversi e incoraggia la libera scelta dell'utente senza vincoli, lock-in e restrizioni che ostacolano la ‘naturale’ evoluzione della tecnologia.196

Anche i costi nulli o estremamente ridotti delle soluzioni disponibili permettono di utilizzarne più di una allo stesso tempo a seconda delle proprie esigenze o combinando i punti di forza dei vari programmi grazie all'interoperabilità, senza dover a tutti i costi prediligere un programma in particolare.

Un'altra ragione della frammentazione, per certi versi intrinseca alla definizione di SL, è la tendenza alla ramificazione (fork) dei progetti resa possibile dalla disponibilità del codice sorgente. Un esempio è il rapporto OmegaT/OmegaT+, in cui un nuovo progetto è nato sulla base di un'applicazione preesistente, entrando in competizione più o meno diretta con essa.

Sebbene un simile fenomeno possa generare confusione o sembrare un grande svantaggio nel modello ‘open’ per la potenziale dispersione delle risorse, in realtà è garanzia di pluralismo e non è detto che i vari rami del progetto non possano trarre beneficio l'uno dall'altro come avviene, ad esempio, per le distribuzioni GNU/Linux.197

Inoltre non è detto che la frammentazione in progetti di piccole dimensioni comporti a tutti i costi una duplicazione del lavoro anzi, da quel che si può osservare la logica sembra piuttosto essere quella della suddivisione del lavoro in cui ciascuna componente si occupa di un solo compito cercando di svolgerlo nel miglior modo possibile.198

La classificazione su più livelli illustrata nella sezione 1.1.2, su cui si è più volte tornati nel corso di questo lavoro, è stata adottata proprio nel tentativo di dare una visione sistematica di questa ‘frammentazione’, assicurando quanto più possibile la presenza di un motivo conduttore.

Le soluzioni complete (o presunte tali) dei programmi proprietari si collocano su una posizione diametralmente opposta: hanno lo scopo di fornire all'utente una suite di programmi virtualmente onnicomprensiva, in cui ogni componente è progettato per funzionare in sinergia con gli altri al fine di gestire in un unico ambiente tutti i passaggi del workflow di traduzione: dall'allineamento alla gestione della terminologia, dalla traduzione con consultazione interattiva delle risorse al controllo qualità.199

L'utilizzo di formati non sempre compatibili fra un produttore e l'altro tende a impedire la scelta dell'utente di affidarsi ad altri strumenti anche se per determinate fasi (ad es. l'allineamento o la QA) queste hanno prestazioni migliori. Semmai sono i programmi di terze parti (emblematico è il caso di ApSIC Xbench) che devono adattarsi ai formati dei leader se vogliono avere una diffusione sul mercato.

Nel SL invece la tendenza prevalente è di sviluppare singoli applicativi, ciascuno progettato per lo svolgimento task specifico e ben definito, il cui output può essere in seguito elaborato da altri programmi sulla base degli standard aperti quali TMX, TBX, XLIFF, ecc.

Anche l'infrastruttura Okapi (sez. 4.4), che sembra contravvenire alla regola dal momento che le sue applicazioni sono state concepite per essere utilizzate insieme, da un lato ripropone al suo interno un'architettura fortemente modulare e dall'altro non intende in alcun modo sostituirsi agli applicativi esistenti ma, anzi, fungere da ‘raccordo’ fra le fasi del processo traduttivo facilitando la combinazione degli strumenti già disponibili.

La creazione di componenti modulari che possono essere riutilizzati e migliorati dalla comunità è infatti una delle caratteristiche principali su cui si basa la cultura del SL e che permettono lo sviluppo dello stesso, secondo il modello del ‘bazaar’ prospettato da Raymond.

Nei progetti di localizzazione questo permette di impiegare soluzioni software create da altri senza dover ogni volta ‘riscoprire l'acqua calda’ ed eventualmente migliorare o adattare alle proprie necessità i programmi esistenti.

I casi di GNU Gettext e del TTK presentati nella sezione 2.4 hanno, da questo punto di vista, una valenza fortemente paradigmatica: componenti nate per un certo scopo sono state integrate e adattate per funzionare in contesti diversi, rese disponibili sotto forma modulare e reimplementate in applicazioni di terze parti.200

Addirittura, nel caso dell'internazionalizzazione del SL, è accaduto che un formato non propriamente standard come il PO si sia imposto su tutti gli altri estendendosi a ogni aspetto della localizzazione (UI, documentazione, ecc…) e provocando la nascita di un insieme complesso di strumenti trasversale a tutte le fasi del workflow di traduzione, presentato nelle sezioni 3.2.4 (allineamento), 4.3.3 (memorie), 3.3 (traduzione), 3.4 (QA) e 4.2.2 (terminologia).

Queste applicazioni esemplificano il fatto che ciò che nasce per una determinata necessità («Every good work of software starts by scratching a developer's personal itch» [Raymond, 1997]) può venire applicato a contesti anche radicalmente diversi ed è solo la sua validità a decretarne il successo, caso non infrequente nell'ambito del SL. L'apparato di convertitori necessario a trasferire le fasi del processo basato su PO alla documentazione o a progetti che utilizzavano storicamente file di risorse in formato diverso è la testimonianza tangibile di come un modello vincente si sia esteso a beneficio di tutti mentre d'altra parte i convertitori inversi consentono di mantenere la compatibilità e impiegare (es. passando da PO a XLIFF e viceversa) lo strumento che si preferisce in ogni caso.

L'ultima differenza fra SL per la traduzione assistita e software proprietario è rappresentata dai ‘fornitori’: mentre quest'ultimo è commercializzato da aziende for profit, il primo è sviluppato da una pluralità di progetti distinti, alcuni dei quali realizzati con il patrocinio di istituzioni non governative, come nel caso di Bitext2tmx e del TTK, da volontari singoli od organizzati in gruppi.

Oltre all'adeguatezza delle funzionalità alle proprie esigenze, cui si è accennato all'inizio di questa parte, un altro aspetto da non sottovalutare nella scelta dei programmi è quindi la dimensione della comunità alla base del programma che può rivelarsi un elemento decisivo in quanto fonte di peer support e condivisione delle conoscenze a beneficio di tutti.

Data la mancanza di un'azienda alla radice di questi programmi, non esiste infatti un servizio assistenza inteso in senso tradizionale, cosa che potrebbe rappresentare un problema per l'adozione dei programmi in ambito aziendale ma, nella maggior parte dei casi, non rappresenta un problema per il freelance. Nello ‘spirito’ del SL è la comunità a rivestire il ruolo di protagonista e gli utenti sono liberi di aiutarsi a vicenda, contattare gli sviluppatori in caso di malfunzionamenti e, se possibile, non limitarsi al semplice bug report ma contribuire in maniera pro-attiva alla risoluzione del problema: più grande e più attiva è la comunità e più facile è che i bug vengano segnalati e risolti.

Per questo motivo, contestualmente alla presentazione delle varie applicazioni e delle rispettive funzionalità, è stato specificato quali progetti sono attualmente più attivi sia dal punto di vista dello sviluppo che della comunità di supporto, dal momento che questo fattore è molto importante.201

Come ulteriore conseguenza dello sviluppo da parte di una comunità di volontari, contrariamente a quanto accade per il software proprietario, l'aggiornamento dei programmi liberi per la traduzione non è sempre regolare, i progetti possono talvolta rallentare, rimanere in fase di stallo o addirittura essere interrotti se si riduce o viene a mancare il contributo su base volontaria degli sviluppatori. Anche su questo criterio si è cercato di operare una selezione delle applicazioni più rilevanti per il traduttore presentando progetti fermi o in fase di stallo solo quando non erano disponibili alternative.

I programmi sviluppati da aziende attive nel campo dell'IT e utilizzati internamente alle stesse per la localizzazione, come nel caso di Open Language Tools di Sun Microsystems oppure OpenTM2 di IBM rappresentano una parziale eccezione a quanto detto finora.

È da tenere presente però che si tratta di soluzioni sviluppate a uso interno come software ‘privato’ (non ceduto a terze parti) o non propriamente libero e rilasciati in un secondo momento per essere utilizzati da chiunque quando non più necessarie al proprietario e ormai superate. Data la loro obsolescenza e l'origine estranea all'ecosistema del SL (per certi versi contraria ai principi di condivisione della conoscenza alla base di quest'ultimo), i programmi in questione sono stati volutamente esclusi da questo lavoro.

Dopo aver esplicitato le differenze sopraelencate, è opportuno ora chiedersi quanto sia realmente applicabile il SL nell'attività ‘quotidiana’ del traduttore. Come si è avuto modo di osservare nei due capitoli precedenti, in 3.2 e 4.2 in particolare, accanto a soluzioni brillanti e molto promettenti per la traduzione rimangono delle ‘zone d'ombra’ ai margini del processo traduttivo e in particolare all'estremità superiore, vale a dire l'allineamento e l'estrazione/gestione della terminologia.

In particolare, per l'allineamento nessuna delle applicazioni si rivela del tutto soddisfacente e anche le due più avanzate, Bitext2tmx e po4a-gettextize pongono seri limiti all'efficienza e all'effettiva utilizzabilità in un contesto lavorativo. Volendo utilizzare a tutti i costi SL in questi casi è più conveniente portare a termine l'allineamento manualmente, eventualmente pre-segmentando i testi con Rainbow, se si dispone delle opportune regole SRX, oppure utilizzando i consueti sistemi di manipolazione testo Unix (magari creando opportuni script awk) o ancora un editor con supporto alle espressioni regolari. In nessun caso, purtroppo, come SL è disponibile un'applicazione di facile utilizzo come le corrispondenti in ambiente proprietario.

Anche riguardo l'estrazione, ma sopratutto la gestione della terminologia, le applicazioni considerate non si rivelano all'altezza dei corrispettivi proprietari (per quanto non esenti da bug e non sempre comodi). TermBase era un progetto molto interessante e per certi versi migliore dei consueti applicativi, basti pensare alla possibilità di modificare gli attributi strutturali e di aggiungere lingue in corso d'opera. Purtroppo però lo sviluppo del programma è fermo da dieci anni e non vi sono segnali di ripresa né per l'ambiente nativo dell'applicazione (MSWindows) né per eventuali port a GNU/Linux.

Per quanto riguarda invece l'estremità inferiore, e cioè il controllo qualità, la maggior parte dei problemi sono risolti a livello di TTK — per la localizzazione in particolare ma anche più in generale dato il supporto di pofilter a TMX/XLIFF — e soprattutto dall'infrastruttura Okapi che, grazie a CheckMate mette a disposizione uno strumento sufficientemente completo e ricco di potenzialità per il futuro (es. i controlli di coerenza terminologica basati sui glossari).

La principale utilità di QA per la localizzazione nel SL è pofilter, a sua volta nata dal TTK come integrazione agli strumenti di GNU Gettext (es. msgfmt).

Le 46 verifiche garantite dal programma sono flessibili ed efficienti, sia in termini di personalizzazione manuale (termini obbligatoriamente da tradurre, termini da non tradurre, ortografia) che di rilevamento automatico (uso delle maiuscole, spaziature o termini ripetuti, variazioni consistenti nella lunghezza dei segmenti, utilizzo dei caratteri di citazione in rapporto alle convenzioni ortografiche della lingua).

Alcuni controlli, tuttavia, perdono di significato se applicati al di fuori del contesto della localizzazione di software (acceleratori, sequenze di escape, placeholder) e, intimamente legato a questo problema, anche il ridotto numero di formati in ingresso rappresenta un limite all'utilizzo. La soluzione fornita da Okapi è il cosiddetto ‘Quality Check Step’ implementato in Rainbow o, come applicazione stand-alone, in CheckMate che invece è adatto a tutti i tipi di documenti supportati da Okapi ed è in grado di estendersi ben oltre la sola localizzazione di file di risorse.

Sebbene molti dei controlli di quest'ultimo siano simili a quelli dell'omologo programma TTK, CheckMate integra un'ottima interfaccia grafica, permette la personalizzazione del comportamento in presenza di specifiche sequenze di caratteri (con espressioni regolari), integra il controllo della terminologia in base a glossari anche TBX e permette inoltre di interfacciarsi con un server LanguageTool (cfr. 4.4.3).

La situazione richiamata poc'anzi è particolarmente esemplificativa di quel che più volte è stato riscontrato: strumenti più recenti (Okapi) colmano le lacune dei loro predecessori e si integrano perfettamente nel processo. Okapi perciò rappresenta una soluzione molto promettente e interessante, dalle infinite potenzialità e che, soprattutto, permette di trasferire il workflow ideale degli strumenti più avanzati a qualsiasi editor compatibile con XLIFF: segmentazione con SRX, conversione del formato, leveraging dei segmenti, pretraduzione automatica se lo si desidera QA e, al termine della traduzione, ricostruzione del formato originale.

La conseguenza più grande di ciò è che non solo è possibile estendere ulteriormente le funzionalità di programmi come OmegaT202 ma anche utilizzare strumenti di per sé meno avanzati nell'ambito della traduzione ‘generica’ che possono però essere rivalutati grazie all'integrazione con Rainbow (aggiungendo quindi il supporto a SRX e alla MT).

È molto interessante notare, d'altra parte, che per tutti gli aspetti dove il SL mostra alcune carenze si siano diffusi strumenti e risorse online che permettono di colmare le lacune. Nel caso degli allineatori, ad esempio, sono disponibili grandi banche dati di TM, come MyMemory o TAUS Data Association203 alcune delle quali pubbliche e gratuite.

Per la gestione delle terminologia, non è possibile non citare Open-Tran.eu, basato sull'API del TTK e utile soprattutto per la localizzazione di software al punto da essere già integrato in maniera predefinita in molti strumenti CAT (come Virtaal e Gtranslator).

Per i controlli di QA esistono strumenti come LanguageTool204 in grado di fornire controlli dettagliati sensibili anche alle specificità di ogni lingua e non solo alle regole ‘statiche’ e generali che è possibile impostare con pofilter o CheckMate.

In merito alla creazione e consultazione di corpora, come si è visto, è da rilevare che TextSTAT integra un web spider per la raccolta di materiale in modo semiautomatico mentre uno strumento libero più avanzato per la raccolta di materiale testuale da internet è BootCAT205 che, pur rimanendo una procedura automatizzata, permette un più ampio margine di controllo sui risultati.

Riguardo CWB, nonostante la preparazione autonoma del corpus sia decisamente fuori dalla portata del singolo traduttore, già è stato segnalato che esistono corpora remoti liberamente consultabili e già allineati che rappresentano una miniera di informazioni utilissima per traduttori e studenti di lingue al solo prezzo di acquisire un po' di dimestichezza con la sintassi del CQP.

Per quanto riguarda, invece, le fasi centrali del processo di traduzione, emerge un pesante sbilanciamento delle applicazioni CAT disponibili in favore degli editor di file di risorse per la localizzazione di software. Questo è chiaramente dovuto alla tendenza degli sviluppatori a colmare per prima cosa il posto vacante nella ‘nicchia ecologica’ del SL (che è anzitutto software e quindi necessita anch'esso di essere localizzato) mentre le funzionalità utili per scopi più generali vengono aggiunte in un secondo momento.

A questo è da ricondurre il fatto che gli strumenti di localizzazione più avanzati siano nati come editor di file di risorse ma supportino anche documenti in formato XLIFF, come Virtaal, integrino al proprio interno un'interfaccia di conversione, come Wordforge oppure ancora offrano filtri interni per altri formati, com'è il caso invece di Lokalize. In tutti i casi, il solo supporto XLIFF è sufficiente affinché il programma possa essere utilizzato per scopi ‘altri’ dalla localizzazione di software, dal momento che le utilità Okapi permettono la conversione e retroconversione in maniera molto facile (cfr. creazione dei pacchetti in sec:rainbow).

Se da un lato infatti è innegabile che molte delle soluzioni disponibili come SL sono legate a un formato di file di risorse proprio (il PO), nato a uso e consumo degli applicativi FLOSS e quindi naturale candidato per tutte le applicazioni di traduzione assistita rilasciate sotto licenza aperta, dall'altro nulla toglie che grazie a Okapi questi strumenti siano utilizzabili anche in contesti diversi, riutilizzando le competenze e gli strumenti stessi.206

Ancora una volta, dunque, Okapi si rivela indispensabile in quanto permette di ottimizzare le risorse a disposizione sfruttando il meglio della tecnologia ‘aperta’, i formati standard (grazie ai suoi numerosi filtri) e una serie di componenti modulari che garantiscono la massima flessibilità e portabilità.

Nell'ambito CAT/TM, per quanto riguarda le alternative basate su web, è interessante notare come le soluzioni disponibili come SL (i già citati Pootle, Rosetta e Transifex) siano ancora rivolte principalmente a localizzatori di software207 mentre per il traduttore generico non è ancora disponibile niente di simile a quanto avviene ad esempio nel software proprietario con il progetto ‘Wordfast Anywhere’,208 vale a dire un sistema interamente basato su web che ripropone un'interfaccia simile a quella del celebre strumento CAT semplificando molto la gestione dei progetti e permettendo a chiunque di avere accesso alla sua personal cloud.

Anaphraseus e OmegaT rappresentano un'eccezione nel panorama dei TEnT liberi in quanto nascono direttamente come strumenti CAT ad uso dei traduttori, in diretta competizione con gli strumenti proprietari (anche se solo il secondo si dimostra all'altezza della sfida).

Il primo infatti, a causa della mancanza di una forte comunità di utenti e di qualche decisione infelice degli sviluppatori, comprende una serie limitata di funzionalità di base e non sembra avere una precisa direzione di sviluppo come testimonia il fatto che è disponibile tanto come applicazione indipendente (ma il cui sviluppo non è attivo) quanto come estensione per OpenOffice.org. In quest'ultimo caso la situazione è resa ancor più precaria dal delicato stato in cui versa la celebre suite per l'ufficio, dopo l'acquisizione di SunMycrosystems da parte di Oracle, la scissione della comunità di sviluppatori e la creazione del fork LibreOffice verso cui sta migrando la maggior parte delle distribuzioni GNU/Linux.

OmegaT, invece, è lo strumento più avanzato disponibile come SL ed è per questo che la sua trattazione (sez. 3.3.1) è leggermente più approfondita rispetto alle altre utilità. In particolare, in questo lavoro si è cercato di mettere in luce le funzionalità più interessanti del programma dal punto di vista del traduttore che già abbia avuto esperienze di traduzione assistita in ambito proprietario.

Fra queste sono senza dubbio da evidenziare la possibilità di inserire un numero indefinito di TM e di glossari, la compatibilità nativa con gli standard TMX e TBX, il gran numero di formati supportati e le buone prestazioni, con la resa quasi in tempo reale di layout e strutture anche complesse di documenti basati su XML (OOXML e ODF) o HTML.

Ma ancor più degne di interesse sono le funzionalità relative all'implementazione di procedure di analisi morfologica ai fini del riconoscimento delle corrispondenze tanto nel database delle unità di traduzione che nelle voci terminologiche e l'integrazione ‘out of the box’ con strumenti di correzione ortografica, enciclopedie e dizionari off-line e motori di traduzione automatica, funzionalità queste ultime poco comuni anche nel campo delle applicazioni proprietarie, almeno quelle di cui ho avuto esperienza come studente di traduzione (Across e SDL-Trados 2007).

È interessante osservare, infine, come i problemi rilevati per il SL in generale siano riproposti su scala ridotta per OmegaT. Il workflow con le estensioni di questo programma mostra infatti i problemi maggiori nell'allineamento, dove gli script creati dagli autori di OmegaT si limitano a produrre la memoria finale lasciando la maggior parte del lavoro preliminare all'utente (cfr. 3.2.2); nella gestione della terminologia, in cui il programma prevede una rudimentale interfaccia di creazione di nuove voci ma non supporta completamente lo standard TBX; e nella QA, dove viene eseguita solo una verifica sui tag di formattazione e sui placeholder che è del tutto inutile se il programma viene impiegato al di fuori della localizzazione di software.209

Da un punto di vista personale, questo lavoro è stato una grande occasione per leggere, documentarmi, fare qualche nuova conoscenza e, in parole povere, iniziare a vivere sul serio la mia passione personale per il SL da tempo coltivata in interiore homine. Inoltre, mi ha dato la possibilità di scoprire nuovi strumenti CAT poco conosciuti anche da me stesso nonostante sia da diverso tempo un utente GNU/Linux.

Gettare uno sguardo sulle varie soluzioni offerte dal SL è stato fonte di inaspettate (e piacevoli) scoperte dal momento che alcuni programmi si sono rivelati molto al di sopra delle mie aspettative come, ad esempio, OmegaT o Lokalize (che prima non avevo avuto modo di utilizzare assiduamente) oppure Okapi, che in precedenza conoscevo solo per Olifant e che ho scoperto nascondere molte più potenzialità di quanto non credessi.

Rendersi conto che al di là dei ‘soliti noti’ esistono altre possibilità ed esplorare le funzionalità offerte dai programmi liberi è stato un buon esercizio di flessibilità mentale e valutazione critica, utile soprattutto per mettere a fuoco i pregi e i difetti delle soluzioni di traduzione assistita senza affidarsi ciecamente alla prima proposta senza considerare se l'investimento in termini di denaro, tempo e pazienza, potrebbe essere effettivamente ripagato in futuro.

Inoltre, questo lavoro mi ha portato a collaborare con alcune comunità di localizzazione: la squadra di traduzione di KDE, il PLUTO-ILDP e i localizzatori di OpenOffice.org. Nella mia (purtroppo ancora) limitata esperienza si è trattato di un'occasione per imparare cose nuove, per ragionare su molti problemi traduttivi ‘reali’ e imparare a lavorare in sinergia sia con gli altri membri del gruppo di localizzazione sia, in qualche caso, con gli autori dei testi originali.

Questo mi ha inoltre permesso di confrontarmi con diversi aspetti della localizzazione, dall'elaborazione dei file di risorse per le interfacce grafiche al contenuto delle guide in linea, dai manuali d'uso delle applicazioni agli storici HOWTO del TLDP, toccando con mano molti degli aspetti e dei problemi studiati sino ad allora solo dal punto di vista teorico: procedure di consegna, richieste di chiarimenti, contesto delle stringhe, aggiornamenti dell'originale, ecc…

Nonostante l'apparente distanza dalla localizzazione in ambito proprietario, infatti, i problemi da affrontare nel SL, almeno per quel che ho potuto osservare, sono gli stessi descritti in [Esselink, 2000]. Questi riguardano sia questioni di ordine ‘pratico’, come le scadenze imposte dal ciclo di sviluppo delle applicazioni e il rilascio simultaneo in più lingue, che questioni di natura ‘teorica’, come il principio della separazione dei file di risorse, la gestione dei plurali, degli elementi di markup, degli acceleratori e dei placeholder.

Sarebbe stato interessante, come sviluppo di questo lavoro, trattare dettagliatamente le procedure che vengono realmente adottate nei gruppi di localizzatori volontari a cui, nel mio piccolo, ho prestato il mio contributo in questi mesi.

Tuttavia per esigenze di spazio e di tempo mi è stato impossibile includere questa parte ‘applicativa’, seppur originariamente prevista, privilegiando gli aspetti teorici e la descrizione degli strumenti disponibili che è un requisito imprescindibile per affrontare la pratica (anche se la maggior parte dei gruppi italiani lavora con OmegaT, Lokalize, Gtranslator e agli strumenti online citati nel cap. 2).

Oltre a queste considerazioni positive, restano alcune riflessioni di natura più problematica maturate nel corso delle esperienze di questi mesi. Una prima questione è il rapporto fra la traduzione volontaria e la traduzione professionale, poiché prima e durante la redazione lavoro sono entrato a far parte di questo ambiente e ho avuto modo di conoscere (e utilizzare come TM) molto materiale tradotto da volontari.

Osservando da vicino queste comunità, ho avuto la possibilità di notare che la maggior parte di queste persone ha una preparazione tecnica, molto superiore a quella di uno studente di lingue straniere. Inoltre, i volontari prestano il loro contributo mossi da una forte motivazione personale (passione, interesse) e questo fattore, unito al precedente, fa sì che la qualità finale del lavoro non sia per nulla inferiore (anzi!) rispetto a quella dei professionisti della traduzione.

L'essere una comunità di traduttori, piuttosto che un singolo, ha inoltre il vantaggio del controllo incrociato, della revisione e dell'approvazione da parte del gruppo. Ammettendo che anche per la traduzione valga il principio fondamentale del «given enough eyes, all bugs are shallow», cioè che più occhi ci sono più facile diventa individuare (e correggere) gli errori, ne consegue che anche da questo punto di vista il singolo traduttore esce sconfitto se in competizione con la comunità virtuale (crowdsourcing).

Da questo punto di vista sarebbe stato certamente interessante osservare più da vicino le piattaforme di traduzione collaborativa basate sul web come il più volte citato Pootle — ma anche Rosetta e Transifex — al fine di confrontare il metodo di lavoro così diverso rispetto ai tradizionali strumenti off-line considerati in questo lavoro ma anche e soprattutto valutare la qualità dei risultati che questo modello comporta.

Un'altra riflessione, in parte correlata, riguarda l'importanza delle risorse di traduzione (TM e TB), dal momento che se di buona qualità di partenza e di sufficienti dimensioni permettono a chiunque di produrre un lavoro di alto livello, dal punto di vista del corretto utilizzo della terminologia e della coerenza a livello di segmenti e sottosegmenti (fuzzy), ecc… indipendentemente dalla preparazione linguistica del soggetto. Può l'elevata qualità della TM essere più importante dell'abilità del traduttore? E, se così fosse, quanto tempo si dovrà aspettare prima che sia sufficiente un computer a svolgere tutta la procedura partendo dal giusto input?

I database di grandi dimensioni che raccolgono traduzioni professionali, messi in comune dalle aziende per ridurre i costi e accorciare i tempi necessari alla localizzazione ‘tradizionale’ sono già da anni una realtà. Per quanto tempo ancora sarà possibile pensare alla traduzione così come viene intesa comunemente? E, soprattutto, può definirsi traduzione automatica una traduzione basata su TM alimentate da segmenti del mondo reale e prodotte da professionisti?

Più volte mentre scrivevo queste pagine ho provato a mettermi nei panni di un lettore con un minimo di conoscenze informatiche e chiedermi quale sarebbe stata la sua reazione di fronte alle probabili inesattezze concettuali e imprecisioni (più o meno consapevoli) da me inserite.

Poiché l'evoluzione non ha fine, ritengo tuttavia di poter rimediare in futuro alle eventuali inesattezze e approssimazioni, forse determinate dalla mia formazione umanistica, affiancando in futuro alla stessa una cultura più tecnica. Spero, comunque, di aver posto un ‘mattoncino’ all'edificio della traduzione assistita spezzando una lancia a favore del SL.