1.2 Il modello GILT

Come esposto finora, la tecnologia può essere impiegata in molti modi al servizio delle attività di traduzione. È anche vero però, d'altra parte, che la traduzione, oggi più che mai, trova uno dei propri campi di applicazione proprio nella tecnologia informatica, nel cui ambito, infatti, è nato e si è sviluppato il concetto di localizzazione.

In questa sezione verrà definito e commentato brevemente questo processo, presentandone i risultati ma evidenziandone anche i requisiti necessari a livello di progettazione che rientrano nell'ambito dell'internazionalizzazione, all'interno del modello GILT (Globalizzazione, Internazionalizzazione, Localizzazione e Traduzione). Ancora, si tratta di considerazioni valide tanto per il software proprietario quanto per il software libero. Gli strumenti e le strategie per l'internazionalizzazione di quest'ultimo verranno trattati più approfonditamente nel capitolo 2. La distinzione fra traduzione e localizzazione, inoltre, è alla base di alcune divisioni fra le categorie di strumenti per la traduzione assistita contenuti nel capitolo 3.

1.2.1 La localizzazione

È normale, al giorno d'oggi, utilizzare i prodotti tecnologici che comportano in una certa misura l'interazione con l'utente in una lingua diversa da quella in cui sono stati originariamente sviluppati con l'aspettativa di ritrovarne intatte tutte le funzionalità di partenza. Questo è possibile grazie al fatto che tali prodotti sono stati localizzati prima di essere resi disponibili all'utilizzatore finale. Il termine ‘localizzazione’ all'inizio degli anni '90 indicava proprio la traduzione applicata all'high tech o al software, in risposta alle nuove esigenze nate con la diffusione dei ‘personal computer’ negli anni '80.

Nel corso del tempo, tuttavia, il termine ‘localizzazione’ è andato via via arricchendosi di nuovi significati e andando a coprire una serie di prodotti, dalle automobili ai telefoni cellulari, e un insieme di elementi che va ben al di là della componente puramente testuale del prodotto, estendendosi alle caratteristiche tecniche (come il voltaggio degli apparecchi elettrici), a elementi di grafica e design che poco hanno a che vedere con la lingua in sé e per sé [Lommel e Ray, 2007, p. 13].

La localizzazione — o l10n secondo l'abbreviazione inglese — può essere definita come il processo per cui un prodotto o un servizio vengono modificati nell'esigenza di adattarsi alle differenze dei diversi mercati [Lommel e Ray, op. cit.].

Lo scopo della localizzazione è quindi rendere accessibile un prodotto (e, di conseguenza, anche un prodotto software) a mercati o a una base di utenti diversi da quelli da quelli della lingua-cultura in cui è stato sviluppato. Per quanto riguarda il software, l'associazione definisce la localizzazione come il processo di adattamento di quest'ultimo a una particolare regione geografica (o locale).1

Quest'ultimo aspetto è particolarmente rilevante, in quanto va oltre il concetto di lingua ‘tradizionale’ ma rappresenta una combinazione specifica di lingua, regione, codifica caratteri, convenzioni ortografiche (formato dell'ora e della data, abbreviazioni dei nomi dei giorni della settimana e dei mesi) e simbolo valutario [Prudêncio, 2006, p. 27].

Di conseguenza la localizzazione implica una serie di processi e accorgimenti in più rispetto alla ‘semplice’ traduzione: grazie al processo di localizzazione l'utente è in grado di interagire con il software nella propria lingua indipendentemente dalla lingua in cui questo sia stato sviluppato (nella maggioranza dei casi l'inglese), non soltanto leggendo tutte le parti visibili dell'interfaccia utente (UI, dall'inglese User Interface) in lingua d'arrivo ma, ad esempio, potendo inserire dati utilizzando la mappatura della tastiera locale e utilizzando tutti i caratteri (con accenti, segni diacritici, ecc.) della propria lingua.

Localizzare un prodotto equivale a gestire un progetto complesso, composto da diverse attività spesso dipendenti le une dalle altre come la traduzione e il test del software nelle lingue d'arrivo, la traduzione e la produzione (‘compilazione’ o conversione) delle guide in linea, la traduzione e il desktop publishing (DTP) della documentazione cartacea, la traduzione e l'adattamento dei contenuti d'esempio a scopo didattico, la verifica del funzionamento delle applicazioni localizzate e la gestione di contenuti in più lingue nelle relative pagine web (figura 1).

In tutto questo, la ‘traduzione’ intesa come descritto nella sezione precedente (estrazione e ricerca terminologica, editing, revisione, proofreading, impaginazione) non è che un sottoinsieme delle attività nel loro complesso che, peraltro, deve essere ripetuta almeno in tre punti all'interno di un singolo processo di localizzazione: a livello di interfaccia utente (menu, messaggi di stato, messaggi d'errore, tooltip, ecc…), per la guida in linea e per la documentazione stampata relativa al software in questione. Inoltre la localizzazione, in genere, ha inizio prima che lo sviluppo del prodotto software sia ultimato (per esempio quand'è ancora in versione beta), quindi prima che l'originale abbia raggiunto la sua forma definitiva. Questo rappresenta un'ulteriore differenza fra il concetto di localizzazione e quello di traduzione intesa in modo tradizionale.

Affinché tutto questo possa essere svolto al meglio, cioè con la migliore qualità e nel minor tempo possibile, tuttavia, è necessario che competenze di natura molto diversa confluiscano in un unico processo (ad es. competenze linguistiche, di programmazione, grafiche e tipografiche, ecc…).

Non solo non è pensabile aspettarsi di trovare tali abilità riunite in un un singolo individuo, ma è anche inconcepibile ormai che esse coesistano all'interno di una sola impresa od organizzazione secondo il paradigma diffuso negli anni '80, in cui la localizzazione veniva svolta da uno specifico settore in-house contestualmente allo sviluppo del software.

Non è infatti possibile chiedere agli sviluppatori del codice di conoscere tutte le lingue in cui il software dovrà essere localizzato e di produrne un corrispondente numero di versioni. D'altro canto, non è nemmeno pensabile affidare ai traduttori l'incarico di modificare il codice sorgente isolando al suo interno le stringhe visibili all'utente finale e apportando a esso le modifiche necessarie a permettere che il programma possa essere eseguito nelle varie versioni localizzate (ad es. ricevendo dati di input con un set di caratteri diverso dall'ASCII di base, con lettere accentate o a dimensione multipla.2

1.2.2 Internazionalizzazione e globalizzazione

La spinta verso l'internazionalizzazione ha origine dall'esigenza di risolvere le questioni enunciate nel paragrafo precedente. L'internazionalizzazione — o i18n, secondo l'abbreviazione usata in inglese — infatti è considerata come il prerequisito necessario a rendere la localizzazione quanto più facile e meno dispendiosa in termini di tempo. Secondo Esselink l'internazionalizzazione può essere definita come in [Esselink, 2000, p. 2]: The progess of generalizing a product so that it can handle multiple languages and cultural combinations without the need for re-design3 dove il termine ‘prodotto’ non si riferisce soltanto al programma ma anche alla documentazione, alle pagine web, alla guida in linea e a tutti gli elementi che lo accompagnano, in accordo con le considerazioni precedenti relative alla localizzazione.

Nell'ambito del software, ad esempio, una buona internazionalizzazione prevede che fin dalla fase di progettazione ancor prima che durante lo sviluppo vengano considerate codifiche di caratteri indipendenti dalla lingua e dalla piattaforma (es. Unicode) o la possibilità di espansione sia orizzontale che verticale delle finestre di dialogo e dei pulsanti in modo da adattarsi agli spazi richiesti da ogni lingua.

In questo contesto assumono una grande importanza anche accorgimenti in apparenza secondari, come inserire testo nelle immagini solo in casi eccezionali e, se possibile, immettendo le scritte su un livello diverso, evitare riferimenti a realia nei materiali d'esempio, prestare attenzione agli elementi grafici dell'interfaccia (parti del corpo, gesti, simboli) e scegliere con attenzione i colori (che potrebbero avere un significato differente nel contesto di destinazione): una serie di questioni legate alle sfide della localizzazione associate nell'immaginario comune più alla traduzione ‘letteraria’ che alla traduzione ‘tecnica’ ma da cui è impossibile prescindere anche in quest'ultimo caso.

Il principio su cui si fonda l'internazionalizzazione, grazie al quale è possibile rispondere all'interrogativo posto dalle esigenze di localizzazione, consiste nella separazione della componente traducibile, ossia quel che sarà visibile all'utente finale, dal codice sorgente del programma vero e proprio4 all'interno di file di risorse contenenti esclusivamente testo.

L'esigenza di abbandonare il modello di sorgente ‘monolitico’ separandolo in più parti a seconda della zona di destinazione era inizialmente legata agli aspetti funzionali del software quando era necessario introdurre nuove funzioni in modo da modificarne le regole di funzionamento a seconda della zona geografica di distribuzione. È il caso, ad esempio, dei programmi di contabilità, in cui era necessario che le regole relative agli aspetti monetari fossero differenti a seconda del paese di esportazione in modo da tenere conto, ad esempio del cambio della valuta.

Queste nuove funzioni comportavano, fra le altre cose, l'introduzione di nuove stringhe di testo nell'interfaccia del programma, referenziate all'interno del codice sorgente mediante speciali indicatori passati come parametri alle funzioni in questione. In tal modo, i testi da tradurre passarono a essere contenuti in file separati dal codice sorgente (file di risorse), ciascuno dei quali contenente al proprio interno l'identificatore corrispondente.

Adattando questa strategia alla totalità delle stringhe localizzabili, divenne possibile produrre molto più facilmente le versioni localizzate dei programmi fino al punto in cui oggi, con la capacità di elaborazione dei computer moderni, è possibile caricare la lingua dell'interfaccia in fase di esecuzione senza più necessità di ricompilare il programma tante volte quanti sono i file di risorse rendendo più ‘lineare’ il processo di sviluppo [Prudêncio, op. cit., p. 23].

Rispetto a intervenire direttamente sul codice sorgente del programma, questo espediente produce un immediato vantaggio, dal momento che il traduttore non potrà in nessun modo apportare dei cambiamenti involontari che potrebbero comprometterne il funzionamento. In questo modo diviene impossibile, per i localizzatori, scambiare per stringhe traducibili parti del codice sorgente che non devono o che non necessitano di essere modificate (comandi, nomi di funzioni, istruzioni, commenti) o, viceversa, non riconoscere tutte le stringhe visibili all'utente e, di conseguenza, omettere la traduzione di alcune porzioni di testo.

Un altro enorme vantaggio è dovuto al fatto che il processo di localizzazione si svolge, almeno in parte, in parallelo con lo sviluppo del software accorciando così i tempi necessari per la produzione e rendendo possibile il simship (simultaneous shipment), cioè la distribuzione in contemporanea, o entro un termine molto ravvicinato, delle versioni localizzate almeno del primo gruppo di lingue (il cosiddetto tier one: francese, italiano, tedesco e spagnolo) e del rilascio della versione in lingua di partenza. Inoltre, il fatto di utilizzare gli stessi sorgenti per tutte le versioni localizzate rende più facile il debugging evitando l'insorgenza di problemi o regressioni specifiche per locale, dal momento che tutte le versioni derivano dallo stesso codice.

Questo però rendeva necessario affrontare il crescente livello di complessità derivante dalla gestione di progetti multilingui di grandi dimensioni. Tale scenario, assieme all'introduzione della distinzione fra il codice sorgente e i file di risorse localizzabili separatamente, ha favorito a partire dalla metà degli anni '80 la nascita e lo sviluppo di modelli basati sull'outsourcing, cioè sull'esternalizzazione delle attività di localizzazione e del project management a soggetti esterni specializzati, i cosiddetti fornitori di servizi di localizzazione (in inglese LSPs, Localization Service Providers o LVs, Localization Vendors) con la conseguente scomparsa dei reparti linguistici interni alle case produttrici di software, le quali possono continuare a occuparsi solo del QA delle versioni localizzate.

La pratica dell'outsourcing ha permesso agli sviluppatori software di dedicarsi alla loro attività principale, lasciando che le questioni di natura linguistica e di localizzazione fossero trattate dai professionisti del settore con le dovute competenze.

Ciò che viene a delinearsi in questo modo è, quindi, una bipartizione: da un lato una prima fase di sviluppo in cui diviene cruciale la progettazione del software per rendere più facile l'adattamento a utenze di lingua diversa, dall'altro una seconda fase di adattamento vera e propria agli specifici bacini d'utenza locali, con la verifica della qualità finale e la distribuzione del prodotto.

A sua volta, però, la localizzazione comporta delle ripercussioni sulla sede iniziale dello sviluppo e dell'internazionalizzazione, in termini di feedback o di servizi (pagine web, assistenza, manutenzione) in un contesto multilingue. Dall'integrazione fra la localizzazione e internazionalizzazione in un ciclo che prevede lo sviluppo, la traduzione, l'adattamento, la distribuzione e l'erogazione di servizi in più paesi del mondo ha origine il processo di globalizzazione (figura 2).

Il termine globalizzazione — o g11n, secondo l'abbreviazione inglese — è utilizzato soprattutto in ambito economico o, nell'ambito della tecnologia, in riferimento ai siti web. Nella prima accezione, si riferisce all'attività previa all'internazionalizzazione che comprende l'identificazione delle aree di destinazione del prodotto, lo studio delle specificità di ciascuna di queste in relazione alle caratteristiche del prodotto da offrire, le decisioni strategiche riguardo al marketing e ai metodi di distribuzione, vendita, supporto e manutenzione del prodotto in un contesto internazionale.

La globalizzazione, in questo senso, occupa un livello concettuale ‘a monte’ rispetto all'internazionalizzazione, in quanto una determinata strategia di globalizzazione può anche non prevedere la localizzazione della totalità delle caratteristiche del prodotto (considerandone il ciclo di vita, i problemi dello specifico mercato) a seguito di una valutazione dei costi e dei benefici derivati [Minazzi, 2005, p. 5].

Nella seconda accezione, il termine ‘globalizzazione’5 è invece inteso come sinonimo di internazionalizzazione del software. Nel caso delle pagine web si tratta di implementare un'architettura multilingue in modo da permettere la localizzazione del contenuto della pagina (talvolta statico ma oggi sempre più spesso dinamico, cioè generato dal server in fase di consultazione) ad esempio inviando automaticamente ai traduttori i nuovi contenuti non appena vengono inseriti [Esselink, 2000, p. 40].

Non a caso oggi si parla sempre più di ‘global content management systems’ (GCMS) [Lommel e Ray, 2007] a lato dei ‘content management systems’ (CMS) generici, cioè delle applicazioni che si occupano di organizzare la produzione dei contenuti dal lato database (back end) e di permettere la fruizione degli stessi dal lato utente (front end).6

Le quattro macro-attività definite fino a ora, dal livello più alto al livello più basso, vengono a essere di conseguenza: Globalizzazione (a livello strategico-decisionale), Internazionalizzazione (a livello di progettazione/sviluppo astratto), Localizzazione (a livello di sviluppo e contenuti) e Traduzione (a livello testuale e terminologico). Il modello concettuale che ne risulta è quel che viene comunemente chiamato, appunto, ‘modello GILT’.

In tale contesto è da considerare la costituzione della LISA, nata dall'esigenza di riunire i vertici del settore dell'informatica e della fornitura di servizi di localizzazione per favorire la globalizzazione nel segno di una serie di standard comunemente accettati da entrambe le componenti.