Perché dovresti localizzare il tuo software per il mercato estero, anziché tradurlo soltanto

(1 voto)
Perché dovresti localizzare il tuo software per il mercato estero, anziché tradurlo soltanto

Localizzare un software o un’app per dispositivi mobili non è un’operazione semplice. Diversamente dalla traduzione tecnica in senso stretto, alla componente linguistica si affianca quella tecnica: le stringhe di testo rivolte all’utente si alternano alle stringhe di codice di programmazione, rivolte unicamente alla macchina. Nella trasposizione linguistica è fondamentale riconoscere queste 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. Questa high-tech translation presenta perciò 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, agli albori della localizzazione, 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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

Bibliografia consigliata

Se hai domande o dubbi su quanto esposto nell’articolo puoi lasciare un messaggio nella sezione Commenti sottostante. La localizzazione di software o app è uno dei servizi offerti da Qabiria: se ne hai bisogno, contattaci.

prenota una consulenza gratuita di 15 minuti senza impegno

Qabiria white logo

Crediamo nell’aumento della produttività attraverso l’uso creativo della tecnologia.

il traduttore insostituibile

Ultime notizie

Contatti

Qabiria Studio SLNE
Carrer Lleida, 3 1-2
08912 Badalona
(Barcelona)
SPAGNA

+34 675 800 826

qabiria

Inviaci un messaggio

Ricevi la newsletter

Vuoi leggere gli articoli e le novità di Qabiria direttamente nella posta?