Come affrontare la traduzione di software nel modo giusto

Differenza fra traduzione e localizzazione

Localizzare un software o un’app per dispositivi mobili non è un’operazione semplice.

Diversamente dalla traduzione tecnica, la localizzazione unisce alla componente linguistica le questioni tecniche: le stringhe di testo rivolte all’utente si alternano alle stringhe di codice di programmazione, rivolte unicamente alla macchina.

Quando si traduce è fondamentale riconoscere quest’ultime e tradurre solo il testo “puro”, per evitare di introdurre bug e di compromettere le funzionalità tecniche.

Sorgono poi questioni relative all’usabilità del prodotto localizzato:

• L’interfaccia risulta accessibile?
• I caratteri speciali sono correttamente visualizzati?
• C’è abbastanza spazio per i testi tradotti?

A livello di gestione del progetto, bisogna considerare anche la documentazione che accompagna il software: manuale utente, guida in linea, eventuali brochure e materiale pubblicitario. Tutti questi testi devono essere tradotti in modo da risultare coerenti tra loro e con il software di riferimento, oltre che in linea con i tempi di rilascio sul mercato imposti dall’azienda.

La localizzazione è quindi una high-tech translation che presenta sfide di varia natura, che devono essere gestite da professionisti altamente specializzati e provenienti da più settori: traduttori, localizzatori, project manager, ingegneri del software e tester. Ma cosa s’intende nello specifico con “localizzazione”?

Il paradigma GILT

Negli anni ottanta, le multinazionali informatiche vedevano la traduzione e l’adattamento in una lingua straniera come un processo a sé stante, scollegato sia dalla progettazione del prodotto che dai processi in corso per altre lingue.

Ciò provocava divergenze terminologiche, imprevisti tecnici, costi aggiuntivi per le modifiche strutturali e ritardi nel time-to-market. Negli anni novanta, con l’evoluzione delle tecnologie e l’aumento esponenziale dei contenuti da localizzare, si è ideato un processo più ampio che comprendesse tutte le fasi di commercializzazione di prodotti tecnologici su mercati esteri. La Localization Industry Standards Association (LISA) è stata una delle prime a parlare a tal proposito del paradigma GILT, che sta per Globalization, Internationalization, Localization, Translation.

Globalizzazione

Per globalizzazione s’intende la volontà di un’azienda di espandersi su mercati esteri proponendo prodotti e servizi che da locali diventano globali. In questa prima fase, gli sforzi si concentrano sulla pianificazione di attività promozionali e di un sistema di supporto alle vendite nei Paesi di interesse; le figure coinvolte sono il CEO e il reparto marketing dell’azienda.

Internazionalizzazione

Segue l’internazionalizzazione, cioè lo sviluppo del prodotto digitale in modo che sia adattabile a più mercati senza troppe modifiche tecniche o linguistiche. Tutti gli accorgimenti adottati in questa fase preparatoria vogliono rendere il processo di localizzazione più rapido, lineare ed economico.

Per esempio, anche se la lingua di partenza dei prodotti è quasi sempre l’inglese, non si può usare un set di 128 caratteri. Esso, infatti, non è sufficiente per rappresentare le lettere accentate delle lingue romanze, né può gestire alfabeti diversi da quello latino. Se non si fa uso in partenza di un sistema ampliato (come Unicode), in seguito si rischia di dover riscrivere il codice da zero, un’operazione economicamente dispendiosa che rallenta l’uscita del prodotto sul mercato.

L’interfaccia del software deve essere progettata in modo da tollerare un aumento del testo di almeno il 30% perché le traduzioni in una lingua romanza o con ideogrammi, come il cinese e il giapponese, occupano più spazio rispetto all’originale. A livello grafico si devono inserire icone e simboli che siano universalmente riconoscibili, mentre per quanto riguarda la veste linguistica si deve redigere un glossario monolingue che sarà usato come riferimento per le successive traduzioni.

Localizzazione

Con la localizzazione si vuole conformare il prodotto alla lingua, alla cultura e alle aspettative di un dato mercato affinché venga percepito come autentico.

Si adattano quindi parametri tecnici come l’espressione di data e ora, la valuta, le unità di misura (temperatura, peso, lunghezza, ecc.), la tastiera, la direzione di scrittura e il formato di indirizzi e numeri di telefono, ma anche le icone, i colori, le immagini e i riferimenti culturali.

Se gli utenti non trovano nell’interfaccia le convenzioni a cui sono abituati, la user experience si fa meno intuitiva; se non si adatta la posizione di pulsanti e immagini a lingue con una diversa direzione di scrittura, come l’arabo, la navigazione è difficoltosa. In alcuni casi, il mancato adeguamento alla cultura locale può persino risultare offensivo: si pensi alla rappresentazione del femminile in alcune realtà musulmane radicali o alla menzione di eventi geopolitici delicati.

Per riassumere, in questa fase si effettuano gli aggiustamenti atti a garantire l’equivalenza tecnica e culturale del prodotto localizzato rispetto all’originale.

Traduzione

La traduzione corrisponde alla trasposizione linguistica del testo del software da una lingua all’altra e incide solo per un terzo sul budget del progetto. L’utente deve avere sì poter accedere a contenuti tradotti correttamente, ma sono il project management e le necessarie modifiche strutturali a presentare problematiche e costi maggiori.

Le varie fasi del processo di localizzazione

Analisi

In una prima fase si analizza il localization kit fornito dal committente, che contiene i file eseguibili (in formato .exe, .com, .dll, .bat, .drv o .bin), l’ambiente di programmazione del software, glossari, memorie di traduzione pregresse ed eventuali note e linee guida.

La scelta dell’ambiente di localizzazione più indicato avviene principalmente in base al formato dei file.

La situazione ottimale si ha quando i file contengono sia il codice di programmazione sia le stringhe di testo, poiché il maggiore contesto linguistico facilita la traduzione degli elementi; per evitare di tradurre accidentalmente il codice, è necessario usare una piattaforma di localizzazione specifica che lo “blocchi”.

Se invece viene fornito solo un file di testo, si opta per uno strumento di traduzione assistita più generico che consenta comunque di mantenere coerenza nella terminologia e nello stile usato (nel caso in cui esistano traduzioni di versioni precedenti del software).

Nelle note alla traduzione, infine, il cliente può fare osservazioni di vario tipo. Per esempio, può specificare di non tradurre i nomi commerciali dei prodotti o alcune sequenze di caratteri, richiedere una traduzione in spagnolo latinoamericano anziché europeo o segnalare potenziali criticità del progetto.

Traduzione del testo

La fase successiva è la traduzione dei contenuti testuali del software. Solitamente si traducono prima gli elementi che compongono l’interfaccia grafica, cioè i riquadri di dialogo, i menu e le stringhe, e poi la guida in linea e il manuale utente, in modo da avere il tempo di creare eventuali schermate video da inserire nella documentazione tradotta.

Più frequentemente, però, i volumi di lavoro e il time-to-market portano i team di localizzazione a lavorare in contemporanea sulle risorse. La coerenza interna è comunque garantita dal riciclo di testi già tradotti e dalla condivisione di glossari e memorie di traduzione.

Quality control

Si controlla poi la qualità del lavoro mediante una revisione della traduzione e un collaudo del prodotto su tre livelli:

1. collaudo linguistico
2. collaudo della GUI
3. collaudo funzionale

Nel collaudo linguistico si controllano la consistenza terminologica e stilistica, la corretta visualizzazione del testo a livello di spazi e caratteri e che tutte le stringhe siano state tradotte. Nel collaudo dell’interfaccia grafica si verifica che la versione localizzata risulti esteticamente gradevole. Nel collaudo funzionale ci si assicura che il software abbia le stesse funzionalità dell’originale e che sia compatibile con i vari dispositivi hardware (processore, scheda grafica e audio) per i quali è stato progettato. Queste valutazioni sono cruciali perché una pessima localizzazione può cambiare le sorti commerciali di un prodotto con cospicue perdite economiche e di immagine.

Change report

Alla conclusione del progetto spesso al team di localizzazione viene chiesto di redigere un change report, cioè un resoconto delle problematiche emerse in una fase del progetto in cui costi e tempi non hanno permesso di effettuare modifiche. Le informazioni raccolte sono usate nella localizzazione di versioni successive del software per ottimizzare le varie fasi del processo.

Aspetti tecnici della localizzazione di software

Un software presenta due livelli di testo:

1. le stringhe visibili all’utente e
2. le stringhe di codice di programmazione necessarie per il funzionamento della macchina.

Solitamente gli ambienti di localizzazione, ovvero i programmi che si usano per tradurre e adattare un software, consentono di segnalarli graficamente in modo diverso, “bloccando” il codice e lasciando libero il traduttore di concentrarsi sul testo puro. In alcuni casi, però, esso presenta espressioni o combinazioni che richiedono un trattamento particolare.

Nelle sequenze di caratteri speciali e variabili, si usano simboli come quello di percentuale (%) o di dollaro ($) per indicare alla macchina di interpretare ciò che segue in modo non letterale. Le variabili, chiamate anche placeholder e di solito indicate con lettere dell’alfabeto, rappresentano un elemento che il software sostituisce di volta in volta con il valore appropriato: un aggettivo, un nome di file, un valore numerico, una percentuale di caricamento e molto altro. Alcune combinazioni standardizzate sono:

• %s per una stringa di testo;
• %d per un numero decimale;
• %x per un numero intero in forma esadecimale;
• %g per un valore a virgola mobile;
• %u per un carattere Unicode;
• %p per un numero di pagina.

In fase di traduzione bisogna tenere conto delle implicazioni grammaticali e semantiche del termine mancante sul resto della frase.

Se si tratta di un aggettivo sono possibili quattro combinazioni (maschile o femminile, singolare o plurale), due nel caso di cifre; in entrambi i casi vanno modificati l’articolo che precede e il verbo che segue. Può essere anche necessario intervenire sulla sintassi: in inglese l'aggettivo precede il nome a cui si riferisce, al contrario dell’italiano. In questi casi il traduttore, per capire di cosa si tratta, deve affidarsi al contesto linguistico. Il cliente, a sua volta, deve segnalare la presenza di caratteri speciali nel software e i principali valori associati alle variabili (quantomeno numero e categoria grammaticale), così da evitare un pesante intervento di correzione nella fase successiva.

In alcuni casi si trova testo non traducibile, ossia termini che in realtà sono comandi interni al software o nomi di file. Ovviamente tradurli significherebbe introdurre bug o creare collegamenti a file inesistenti, quindi è fondamentale riconoscerli.

Si va da stringhe del tipo [x] o $x$, dove x indica il nome di un file con la sua estensione ($INPUT_List.csv$), a parole scritte in maiuscolo (COPY, EDIT) e/o con trattini bassi (TIME_OUT; NO_MORE_ENTRIES).

Uno dei problemi più spinosi nella localizzazione è la presenza di termini isolati, privi di contesto.

Il traduttore deve fare affidamento sul testo che precede e segue e, se gli è stato fornito il file eseguibile, sul relativo codice di programmazione, che può dare indicazioni preziose sulla natura del termine.

Un altro modo per sciogliere l’ambiguità è visionare l’interfaccia grafica del software, cosa non sempre possibile. Se si ha a disposizione solo un file di testo, si possono consultare il relativo manuale utente e la guida in linea oppure, in casi estremi, chiedere chiarimenti al cliente.

L’ambiguità dei termini isolati dipende anche dalla caratteristica dell’inglese di esprimere più categorie e valori grammaticali con una stessa forma grafica. Per esempio, in un software il termine “copy” può indicare sia un sostantivo che un verbo, a sua volta al modo imperativo oppure infinito. La posizione all’interno della GUI può suggerire l’accezione corretta (se si trova in un menu a tendina, probabilmente si tratta di un comando), ma resta un problema da non sottovalutare.

Le stringhe di testo si inseriscono in riquadri di dialogo, menu a tendina e messaggi di errore. La capienza di queste sezioni è più o meno limitata e ciò costituisce un problema nella localizzazione dall’inglese verso altre lingue, che porta con sé un aumento fisiologico del testo dal 30% a più del 200% per i nomi di comandi e icone. Se non si calcola in fase di internazionalizzazione dello spazio aggiuntivo, per rientrare nei limiti di spazio grafico il traduttore deve, in alcuni casi, ricorrere a sinonimi, abbreviazioni e anglicismi.

È essenziale però mantenere la coerenza nelle scelte terminologiche (inserendole quindi nel glossario di progetto) e usare espressioni comprensibili per l’utente, non termini in inglese poco diffusi o sigle oscure.

Alcune piattaforme di localizzazione consentono di generare un’anteprima dell’interfaccia dove si inseriscono in tempo reale le traduzioni, così da vedere lo spazio a disposizione. Nel caso in cui si disponga del file di solo testo e non di quello eseguibile, ci si può aiutare con la documentazione di supporto al software, sperando che il manuale utente contenga la schermata video della sezione di interesse.

Nella localizzazione è essenziale adattare il locale, cioè l’insieme di parametri tecnici usati da una comunità geografica, culturale e linguistica per rappresentare la realtà. La norma ISO 639-1 sulla classificazione delle lingue identifica ciascun locale con un codice di due lettere. Se per l’italiano ne esistono due, uno per l’Italia (it-IT) e uno per la Svizzera (it-CH), lingue come inglese, spagnolo e arabo hanno un repertorio maggiore dovuto all’ampio bacino di Paesi nei quali sono lingua ufficiale. Lingua e locale non hanno una corrispondenza univoca perché entrano in gioco convenzioni culturali. Le più importanti sono:

• la valuta e la posizione del simbolo grafico: si scrive £10 e $10, ma 10€;
• l’espressione della data: varia sia l’ordine degli elementi (mese-giorno-anno negli USA, giorno-mese-anno in Europa, anno-mese-giorno in alcuni Paesi asiatici) che l’uso grafico di barre (/), trattini (-) o punti;
• l’espressione dell’ora: accanto al sistema orario prevalente a 24 ore vi è quello statunitense a 12 ore;
• i sistemi di misurazione: i chilogrammi, i metri e i gradi Celsius del Sistema Internazionale diventano in ambito anglofono libbre, piedi e gradi Fahrenheit (con alcune differenze concettuali tra Regno Unito e USA);
• la rappresentazione dei numeri: le migliaia, le centinaia e i decimali possono essere segnalati con un punto (in alto o in basso), una virgola o uno spazio; una stessa percentuale si può scrivere come 1.5% oppure 1,5%;
• l’indicazione di indirizzi, codici postali e prefissi telefonici.

Adattando questi parametri si dà all’utente la sensazione di interagire con un prodotto pensato per le sue esigenze e si evitano potenziali fraintendimenti. In caso contrario, la user experience peggiora e può anche essere impossibile accedere ad alcune funzionalità. Se un software non presenta i codici postali o i prefissi telefonici di una data zona, l’utente può non riuscire a creare un account; se non si sono convertiti gli importi nella valuta locale, non potrà effettuare acquisti. Curarsi del locale significa quindi rispettare le aspettative dei parlanti e consentire loro di fruire delle stesse funzionalità dell’originale.

Aspetti linguistici e culturali

Nella progettazione di software la componente culturale è minoritaria, poiché un software è concepito per un uso pratico, come proteggere un dispositivo da virus, gestire le password o generare documenti. Tuttavia, l’inclusione di determinate funzionalità è riflesso di un tipo di cultura. Nell’internazionalizzazione del prodotto bisogna tenere conto di queste differenze, altrimenti si rischia che esso venga rifiutato dal mercato target perché non assimilabile alla cultura locale.

Questi aspetti non sono di competenza del traduttore in senso stretto. Tuttavia, più un prodotto digitale imita l’interazione umana, più vanno effettuati adattamenti linguistico-culturali.

Un software per la produzione industriale serve per eseguire azioni e attivare macchinari. L’interfaccia presenta domande rivolte all’utente (come “Sei sicuro di voler riavviare?”), ma la componente pragmatica passa in secondo piano.

Al contrario, l’app di una banca ricalca l’interazione tra cliente e dipendente su operazioni delicate come la gestione del conto e la sottoscrizione di servizi: l’utente vuole sentirsi “rassicurato” dal testo e trovare le convenzioni linguistiche a lui familiari. Il traduttore quindi deve rispettare le formule di cortesia radicate nella sua cultura.

L’inglese, per esempio, fa abbondante uso di espressioni come please e would you like to + verbo che in italiano possono essere omesse o modificate, per esempio passando dal modo condizionale all’indicativo. Allo stesso modo, il registro più informale dell’inglese può dover essere innalzato per un utente italiano. Un discorso a parte merita l’ordine dei componenti della frase.

In inglese si tendono a presentare prima le informazioni più specifiche e dopo quelle generiche, mentre in italiano la progressione informativa è opposta. La nostra lingua, inoltre, non è vincolata all’ordine rigido soggetto-verbo-oggetto, anzi spesso per frasi più fluide e naturali è necessario modificarlo.

Tradurre troppo alla lettera dall’inglese può portare in italiano a espressioni insolite che suonano, se non scorrette, innaturali e forzate. Infine non bisogna dimenticare che, in caso di frammenti di testo con finalità di marketing, può essere necessario riscrivere parzialmente il testo in funzione della sensibilità dei nuovi destinatari, operando la cosiddetta transcreation.