Il ruolo del project manager nei progetti di localizzazione

pagina iniziale

pagina 1 2 3 4 5 6 7 8 9

La localizzazione software e dei siti

La localizzazione di un software è il processo di adattamento di un applicativo ad uno specifico mercato internazionale. La cosa migliore ovviamente è quella di affiancare il cliente già nelle prime fasi del progetto. Questo permette lo sviluppo contemporaneo di prodotti multilingue in tempi estremamente ridotti.
Oltre alla mera traduzione, in questi progetti, è spesso necessario il ridimensionamento dei box e altri tipi di interventi che permetteranno un funzionamento e una visualizzazione corretti del programma o del sito.
È quasi sempre necessario prestare attenzione alla localizzazione dei formati data, ora, valuta, unità di misura, indirizzi. Inoltre, spesso, si rendono indispensabili attività specifiche per verificare ad esempio la conformità fra testi dell'interfaccia, help online, messaggi e documentazione e della pagina del sito. A volte è necessaria anche una verifica funzionale (font, debugging e testing).

AVVIAMENTO PROGETTO
I file che vengono tradotti in questo tipo di localizzazioni possono essere di tutti i formati: file di xls, htm, xml, file rc, txt e capita anche che vengano forniti direttamente file bilingui ad esempio ttx uncleaned di trados che il traduttore deve “ripassare” con trados. Il file ttx bilingue permette sempre di vedere sia il testo originale sia quello tradotto. In questi casi spesso viene richiesto di consegnare il file in questo formato, perché così è più facile revisionare il testo. Una volta corretto o approvato il file viene pulito (cleanup) e ritorna nel suo formato originale. L’attività di cleanup permette anche l'aggiornamento della memoria di traduzione. Altri tipi di file possono essere quelli in formato .bmp, cur, .dlg, dll, .ico, .inf, .mc, .mnu, . rc, .reg, .res (tutti localizzabili). Vi possono essere ovviamente formati non localizzabili che sono ancora più ostici da gestire .clw, .aps, .bat, .cpp, e altri ancora. La piattaforma su cui gira il software: Windows, Linux o MAC influenza il tipo di file da gestire e le attività per localizzarlo.
Per quanto riguarda la traduzione di siti e materiale simile di solito si parla di html e xml. Questi file e la maggior parte dei documenti inviati possono essere tradotti con sistemi CAT, anche se alcuni file necessitano di conversioni particolari per essere tradotti con un sistema CAT. Senza volermi dilungare troppo nell’analizzare ogni singolo formato, riporto solo un esempio pratico sulla gestione dei file rc. I file rc sono quelli di risorsa script e sono molto comuni nelle localizzazione.

Attraverso una procedura di conversione i cui passaggi sono chiaramente spiegati nell'help di Trados sotto la voce "Preparing:Windows RC files for translation”, è possibile con poche operazioni convertire il file rc in rtf. E’ indispensabile che sia presente nel computer l’apposita macro (tw4winPrepareRC). Il file ottenuto inoltre ha il pregio di mantenere sovrascrivibile il solo testo da tradurre e al contempo di proteggere tutti i codici da non manomettere. I tag esterni, che riguardano la struttura del documento, appariranno in grigio, i tag interni, riguardanti alla formattazione, saranno invece in rosso e potranno essere spostati, cancellati o aggiunti. Eseguita la traduzione e pulito il file è possibile eseguire la procedura all’inverso e riconvertire il file rtf in formato rc.

Inoltre, a volte, può rendersi necessaria la localizzazione di file in formato Avi, Breeze, Flash ecc., visualizzabili nel browser di ogni PC, che consentono a chiunque di accedere istantaneamente alla formazione online, il marketing, le vendite e le conferenze Web. Tali formati distribuiscono globalmente le informazioni, ma diventano dei potenti sistemi di comunicazione solo se compresi da un pubblico eterogeneo, culturalmente e linguisticamente differente. In questi casi sono necessari servizi tecnici, come la traduzione e localizzazione di presentazioni e filmati in formato Macromedia Breeze; Macromedia Flash e Swish e l'elaborazione di tutti i principali formati grafici (bitmap e vettoriali), formati audio (WAVE, MP3, MIDI AIFF, ecc.) e formati video (AVI, MPEG, Flash, ecc) e servizi multilingua come il doppiaggio, commenti fuori campo, sottotitolaggio. Inoltre tutti gli elementi a corredo di un software o di un prodotto (packaging, brochure, etichette, manuali…) sono di solito in programmi di grafica e necessitano attività DTP.

Ecco un elenco di possibili componenti di un pacchetto di localizzazione per un software internet:

- File risorsa e script
- File di testo e stringhe di dialogo e comandi
- Graphics (immagini editabili e non editabili, come GIF, JPEG…)
- File binari eseguibili…
- Elementi Java o Flash
- File di help
- Eventuali risorse audio, video. Per queste è necessario a volte estrarre il contenuto in formato editabile e organizzare attività di doppiaggio.
- Manuali e guide rapide
- Licenze e file ReadMe
- Brochure
- Packaging, etichette CD

Stringhe e comandi e box di immagini sono i primi elementi della localizzazione. Se quindi un cliente necessità della localizzazione delle brochure, del packaging e dei manuali vanno richieste le immagini delle schermate localizzate e ancora meglio di un glossario per i comandi.

In fase preliminare vanno subito chiariti alcuni punti pratici e generici col cliente, oltre al budget a disposizione e la data di consegna finale.
Innanzitutto è bene assicurarsi col cliente che i file che verranno inviati siano internazionalizzati e localizzabili. Come ho spiegato precedentemente non tutti i file sono facilmente gestibili. Per fare un esempio pratico i file devono poter supportare i caratteri accentati delle lingue in cui si vuole localizzare il prodotto. Devono anche avere degli spazi disponibili vuoti da occupare. L’ingombro dello stesso messaggio cambia se lo si esprime in una lingua piuttosto che in un’altra. Questo serve ad evitare malintesi: è spiacevole ritrovarsi a metà progetto a dover segnalare che è impossibile eseguire una parte del lavoro per problemi tecnici. Inoltre, scoprendolo all’inizio si dà la possibilità eventualmente di modificare i file.
Le informazioni necessarie al Project Manager possono essere elencate in quattro punti principali.
Il primo riguarda ovviamente le attività e i servizi richiesti.
Il secondo è una panoramica generale del progetto:
- Lingua di partenza e lingua/e di arrivo
- Elenco dei componenti da localizzare
- Numero di file
- Conteggio delle parole da localizzare
- Numero di pagine soggette ad attività grafica (DTP)
Il terzo è il calendario del progetto: sia come consegna finale, che come consegne intermedie. Il calendario deve scadenzare tutte le attività del progetto, compresi ovviamente i tempi per revisioni e correzioni.
Il quarto riguarda i controlli qualità. Nella sua guida Muzii (2005: 6) si riferisce a testing e verifiche che però io non ho mai seguito e di cui non mi occuperò.

Oltre a un’analisi tecnica dei file a inizio progetto, come ho avuto modo di dire, è fondamentale chiarire alcuni punti qualitativi col cliente . La prima cosa che il cliente dovrebbe fare presente, e che nel caso non venga data deve essere sollecitata dal PM, è una spiegazione chiara del prodotto oggetto della traduzione. Sembra banale, eppure è importante che il traduttore abbia chiaro che cosa ha davanti e, a volte, capita vengano inviati testi senza dare la minima informazione al riguardo. Questo è molto negativo ai fini della qualità  in ogni caso, ma è soprattutto pericoloso nel caso di una stringa di testo quando una frase o di un messaggio resta avulso da un contesto. Aggiungo che quasi sempre per questi testi ormai si parte dalla lingua inglese, ma il problema è che non sempre si tratta di inglese lingua madre. Ci si trova molto spesso di fronte a messaggi tradotti parola per parola in inglese ed è quindi bene anche cercare di approfondire e venire a conoscenza della reale origine dei testi e capire da dove nascono.
Comunque questa non è la regola. Anzi nel caso dei software di solito si parte da incontri e briefing preliminari e si ha a disposizione materiale di riferimento. Anche il materiale di riferimento va valutato così come va valutata l’utilità di una memoria di traduzione.
Si tratta di vere e proprie armi a doppio taglio. Se è un risparmio di tempo enorme avere già la traduzione giusta di un segmento ripetuto centinaia di volte in un testo è una perdita di tempo inimmaginabile trovarsi a correggere alla fine quella stringa perché si è scoperto che c’è un errore.  Ricordiamoci che spesso parliamo di file che sono in formati in cui un semplice “trova e sostituisci” non è praticabile o se lo è ha dei ritmi così rallentati che vale piuttosto la pena magari rifare tutto da capo.

Nei casi poi di localizzazione legata alle grandi realtà dell’informatica ci sono guide di stile e glossari condivisi per settori specifici. Col cliente in fase preliminare si chiarisce già come si vuole procedere: se intende investire e quanto e se ci sarà tempo a disposizione per una revisione e/o testing oppure no. Il testing nel caso dei software è proprio una simulazione finale di funzionamento dei file e chiaramente svolge anche l’ultima prova del fuoco per la traduzione. Nel caso dei comandi, dei box coi messaggi durante la simulazione di utilizzo risulterà lampante qualsiasi errore o traduzione da sistemare. Il progetto per la società di traduzione può escludere la revisione e/o il testing per accordo contrattuale con il cliente ma, questo non significa affatto che ciò non avverrà, semplicemente verrà effettuato su responsabilità del cliente (molto probabilmente in maniera interna). La mia esperienza con grandi realtà dell’informatica/web è che spesso tendono poi a smembrare il progetto su più realtà ognuna responsabile di un singolo passaggio. Se da un certo punto di vista questo arricchisce il team che lavora su un progetto  unico, dall’altro il ruolo dei briefing, conference call, guide di stile e glossari diventa fondamentale e richiede più tempo di quanto magari non si dedichi nelle attività operative. Personalmente trovo inoltre molto rischioso questo modo di impostare l’attività e credo che il fatto che oggi stia prendano piede dipenda dal desiderio di “esternalizzare” le attività per ragioni economiche.

La revisione può prevedere anche una revisione, almeno di parte dei testi, da parte di uno specialista legale. In particolare quest’attività è richiesta per le licenze dei software e anche per alcune note da inserire sulle scatole del prodotto. In generale le informazioni almeno per il mercato europeo non si discostano più di tanto da un paese all’altro.
Nel testo “Translation is not enough. Considerations for global Internet development”, di John Harris e Ryan McCormack (2000: 40), si evidenziano l’importanza di analizzare bene alcuni aspetti legali nei progetti di localizzazioni come la giurisdizione, la tassazione e il pagamento. Continua...