Seu SlideShare está baixando. ×
Guida allarealizzazione di un  localization kit     Luigi Muzii
AvvertenzeLe informazioni contenute in questa guida sono fornite senza garanzie di alcun tipo e non comportano alcun obbli...
IntroduzioneDestinatariQuesta guida affronta un problema che affligge da sempre localization manager, localization vendor ...
A cosa serve un localization kitScrivere il codice tenendo conto delle esigenze di localizzazione permette agli sviluppato...
dal prodotto, il kit dovrebbe comprendere una versione perfettamente funzionale del software, almeno in beta.Infine, un lo...
LocalizzatoriI localizzatori vorranno sapere quali sono i file da localizzare, i loro destinatari e, nella maggioranza dei...
Realizzazione di un localization kitUn localization kit aiuta a rispettare le scadenze poste dal cliente e a raggiungere g...
tutti i testi traducibili sono archiviati nei file di risorse, semplificando così la localizzazione. Tuttavia, in molti ca...
 obiettivi di progetto;      o nome del prodotto;      o nome o codice del progetto;      o descrizione generale del prod...
Esempio di elenco di file localizzabili per una distinta dei materiali (BoM)                                              ...
Esempio di foglio per le domande        Foglio per le domande: < nome del progetto > Terminologia italiano        Urgente ...
Software InternetUn sito o unapplicazione Web sono sostanzialmente differenti da unapplicazione software "tradizionale" st...
   file di progetto della guida (.hpj);      modelli e fogli di stile per la guida in formato HTML/XML;      file bitma...
Esempio di elenco di file grafici per una distinta dei materiali                                            Testo da      ...
Esempio di elenco di file grafici per una distinta dei materiali                                               Testo da   ...
   istruzioni   per un corretto accento e una corretta pronuncia, e su tono e ritmo dei dialoghi;      istruzioni   per ...
 il file grafico delle etichette per CD con la relativa versione a stampa (di solito in formato EPS);    la versione com...
Stesura della guida alla                                                       localizzazioneLa guida alla localizzazione ...
Punti chiave del progettoDescrivere gli obiettivi generali di progetto, attraverso una sintesi generale del piano di proge...
DeliverableElencare e descrivere i deliverable di progetto. Fornire sempre un adeguato livello di dettaglio, in modo che i...
Modello di rapporto sullo stato del progetto                                       <Nome progetto>                        ...
Esempi di metriche         Categoria                                                     Metriche  Soddisfazione del      ...
Definire il flusso funzionale dellinterfaccia utente del software in modo che i collaudatori non debbano esaminaretutte le...
Le cartelle .lproj di un bundle contengono gli stessi file, mentre tutte le versioni di un file di risorse devono averelo ...
I commenti sono preceduti dal simbolo # e, laddove questo è seguito da qualche altro carattere speciale, come ilpunto (.) ...
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Próximos SlideShare
Carregando em...5
×

Guida alla realizzazione di un localization kit

2,371

Published on

Versione italiana di "Building a Localization Kit". Contiene indicazioni generali per predisporre e aggiornare un localization kit.

Published in: Educação
0 Comentários
0 pessoas curtiram isso
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Be the first to like this

Sem downloads
Visualizações
Visualizações totais
2,371
No Slideshare
0
A partir de incorporações
0
Número de incorporações
0
Ações
Compartilhamentos
0
Downloads
24
Comentários
0
Curtidas
0
Incorporar 0
No embeds

No notes for slide

Transcript of "Guida alla realizzazione di un localization kit"

  1. 1. Guida allarealizzazione di un localization kit Luigi Muzii
  2. 2. AvvertenzeLe informazioni contenute in questa guida sono fornite senza garanzie di alcun tipo e non comportano alcun obbligoda parte dellautore o delleditore. Lautore e leditore non si assumono nessuna responsabilità, diretta o indiretta,per questa guida o parte di essa, o su qualsiasi altro materiale supplementare successivamente pubblicatodallautore. Lautore ha fatto il possibile per garantire accuratezza, correttezza e affidabilità delle informazionicontenute in questa guida e non si ritiene responsabile di eventuali errori tipografici o di altre imprecisioni,riservandosi il diritto di modificare il documento o le informazioni in esso contenute senza che questo comportilobbligo di avvisarne gli utenti.Tutti i nomi di prodotto citati in questo documento sono marchi registrati dei rispettivi fabbricanti.Ha collaborato alla traduzione Eleonora Bosi.Copyright © 2005 Luigi Muzii. Tutti i diritti riservati. Stampato in Italia.Questo documento è proprietà di Luigi Muzii. È vietato riprodurlo, trasmetterlo, trascriverlo, tradurlo in parte ointegralmente o depositarlo in un sistema di archiviazione, con qualsiasi mezzo, elettronico, meccanico, magnetico,ottico, chimico, manuale o qualsivoglia senza esplicito consenso scritto di Luigi Muzii.
  3. 3. IntroduzioneDestinatariQuesta guida affronta un problema che affligge da sempre localization manager, localization vendor e projectmanager, ed è fruibile sia dai lettori con una certa esperienza nellindustria della localizzazione, sia dai neofiti. Nonha, tuttavia, lambizione di essere conclusiva, ma solo di offrire ai lettori alcune indicazioni utili per predisporre eaggiornare un localization kit in modo da agevolarne il lavoro.Basterà, inoltre, fare astrazione delle sezioni specificatamente dedicate alla localizazione per ricavarne istruzioniutili a predisporre un translation kit.Questo documento è il risultato di un lavoro di ricerca, raccolta e selezione di informazioni, durato diciotto mesi:ogni commento o suggerimento da parte dei lettori è ben accetto.Note introduttiveQuanto più si riesce a tracciare i requisiti e a comprendere le esigenze del cliente, tanto più sarà possibilesoddisfarlo. Un localization kit è una raccolta di strumenti, istruzioni e risorse necessarie per localizzare unprodotto software.Se completo e ben progettato, il kit consentirà a localizzatori, collaudatori e sviluppatori di portare a buon fine, inmodo adeguato, un progetto di localizzazione.Per rispettare le esigenze di time to market e favorire utili sinergie fra sviluppatori e traduttori è necessario che illavoro di traduzione del software inizi il prima possibile; un localization kit consentirà ai traduttori di lavorare inmodo più indipendente, verificando il proprio lavoro in corso dopera.La qualità finale e il successo di un progetto di localizzazione dipendono dalla quantità di conoscenze trasmesse allocalization vendor; queste conoscenze riguardano:  laffidabilità dei processi di preventivazione e pianificazione;  il tempo necessario ai project manager e ai tecnici;  laccuratezza dei deliverable di progetto.Un buon localization kit costituisce una soluzione relativamente semplice a questi problemi in quanto consente ailocalization vendor di verificae che dispongano di tutto il necessario per svolgere il proprio lavoro in modoefficiente.Anche se impegnativa, la preparazione di un localization kit e di una guida alla localizzazione per un determinatoprodotto è unoperazione una tantum che offre vantaggi duraturi ed è di enorme aiuto a tutte le parti coinvolte inun progetto, raccogliendone tutti gli elementi essenziali ed esponendone requisiti e attese.
  4. 4. A cosa serve un localization kitScrivere il codice tenendo conto delle esigenze di localizzazione permette agli sviluppatori di coinvolgere ilocalization vendor, in modo più rapido, semplice e conveniente.Il materiale fornito con un localization kit permette di soddisfare due fasi del processo di localizzazione: 1. la preparazione di unofferta (pianificazione, quotazione e programmazione) relativa alla localizzazione di un prodotto; 2. lesecuzione di un progetto di localizzazione.Un buon localization kit è:  completo, perché contiene tutto ciò che il gruppo di sviluppo deve fornire riguardo al prodotto e servizi accessori;  fruibile, perché corredato di una documentazione chiara e completa su come è fatto e su come utilizzarlo.Lideale sarebbe sviluppare delle linee guida e una checklist per lo sviluppo del localization kit, così che questopossa mantenere una sua coerenza interna, a prescindere dal responsabile o dal prodotto. Ciò agevolerà lapreparazione di un kit di alta qualità, eviterà laboriose rielaborazioni e migliorerà lefficienza e la scalabilità deiprocessi di localizzazione. Inoltre, nel caso di un rapporto a lungo termine con un localization partner, consente diridurre le tempistiche per la realizzazione di offerte e programmi di localizzazione, permettendo un più rapido avviodei progetti.Teoricamente, la realizzazione del localization kit dovrebbe seguire il rilascio del codice della versione principaledel software, in modo da potersi basare su risorse e codice aggiornati. Il kit, inoltre, dovrebbe essere indipendente,ma nei casi di sim-ship (rilascio simultaneo di versioni originali e localizzate), si renderà necessario disporre dellocalization kit prima del rilascio del codice della versione principale.Disponendo di un pacchetto completo di file e requisiti già al momento di ricevere la richiesta di unofferta,lazienda proponente è in grado di condurre unattenta analisi del progetto e valutarne correttamente dimensioni,costi e durata. Il localization kit può, quindi, essere utilizzato in fase di avvio del progetto, avendone chiariobiettivi e requisiti.Il kit, inoltre, può essere utilizzato per garantire che il materiale di ritorno sia il più completo possibile e diimmediato utilizzo. La completezza è fondamentale per il successo del lavoro di localizzazione.Il localization kit aiuta i processi organizzativi documentando i requisiti di progetto attraverso una struttura adalbero e file perfettamente funzionanti, ed evitando la perdita di informazioni durante il trasferimento al vendor.Funge, inoltre, da archivio in cui conservare tutte le informazioni necessarie per localizzare un prodotto epermettere a chiunque, allinterno della società, di assumere facilmente la responsabilità di gestire un progetto,disponendo, da subito, delle informazioni necessarie per unanalisi o per il suo avvio.Struttura di un localization kitUn localization kit va preparato nelle fasi preliminari e durante limplementazione in modo da poter condurrevalutare e analizzare il progetto avendo sempre presente lesigenza di evitare sorprese quali il mancato rispetto diuna scadenza o lo sforamento del budget. Inoltre, poiché la maggior parte dei progetti di localizzazione softwarecoinvolge un ampio numero di lingue di destinazione, disporre di un kit adeguato fin dallavvio del progettoconsentirà di dare risposte univoche e sempre consultabili a eventuali domande dei traduttori.Ogni localization kit ha le proprie peculiarità riconducibili ai diversi requisiti di progetto; in tutti i casi, tuttavia, èfondamentale dare il massimo delle informazioni fin dallavvio del progetto, in modo da rudurre al minimo il rischiodi problemi in seguito.Tipicamente, la versione localizzata di un prodotto contiene soltanto gli elementi traducibili, le configurazioni dellocale e non i file binari e le librerie di prodotto.Un localization kit ben fatto dovrebbe contenere tutte le risorse necessarie a un localization vendor per realizzarela versione localizzata di un prodotto software senza assistenza da parte del gruppo di sviluppo originale. I vendordovrebbero essere in grado di utilizzare il kit per la traduzione, lintegrazione e la verifica delle risorse, senzaalcuna assistenza da parte del gruppo di sviluppo, e se il codice è predisposto per la localizzazione, è improbabileche sia necessario dover disporre del codice sorgente per creare la versione localizzata.Per questo, un localization kit dovrebbe contenere i file da localizzare, identificati e pronti per la traduzione (i filebinari e i file di risorse), oltre che le istruzioni, le linee guida, i suggerimenti e le annotazioni che gli sviluppatorimettono a disposizione dei membri del gruppo di progetto perché possano gestire adeguatamente i vari file e i varitipi di file. Il kit, inoltre, dovrebbe contenere informazioni circostanziate sul prodotto da localizzare. A prescindere
  5. 5. dal prodotto, il kit dovrebbe comprendere una versione perfettamente funzionale del software, almeno in beta.Infine, un localization kit dovrebbe contenere tutti gli strumenti necessari per poter trattare i file.Organizzazione di un localization kitIn genere, la prassi corretta consiste nell organizzare centralmente i file, poiché tutte le operazioni su ad essidevono essere ripetute tante volte quante sono le lingue in cui si devono localizzare. Una struttura ad albero benfatta consentirà al vendor di risolvere in modo efficace eventuali problemi dovuti a rimandi non funzionanti, filemancanti e immagini danneggiate, con modalità che variano a seconda della lingua!Per accelerare la riorganizzazione dei file nella fase preparatoria si può compilare un file contenente tutti i datirelativi allubicazione e alle proprietà di ciascun file, dopo la prima build. In questo senso può essere daiuto unostrumento CASE (Computer Aided Software Engineering) e il file di cui sopra può diventare la base per una distintadei materiali (BoM, Bill of Materials) del localization kit.Non tutti i progetti avranno tutte queste componenti e, allo stesso modo, non tutti i progetti avranno una distintache riporti tutti i componenti. Spesso, qualche componente non è disponibile nella fase iniziale, quando il kit vienepreparato per lanalisi e le richieste di offerta, ma lo sarà per lavvio del progetto. Qualora si preveda di non poterinserire alcune componenti nel kit iniziale, sebbene debbano far parte del progetto, può essere utile inserirvi,comunque, qualsiasi informazione disponibile al riguardo, anche se vaga.Teoricamente, per ottenere la massima efficientza, tutte le persone che partecipano al processo di localizzazionedovrebbero fornire un proprio input.Utenti di un localization kitSono molti gli attori allinterno del processo di localizzazione: localization manager, collaudatori, localizzatori esviluppatori. Il localization manager segue il progetto e ne coordina attività, collaudatori e localization engineereffettuano i collaudi e modificano il codice sorgente per renderlo localizzabile, interfacciandosi con il localizationmanager e gli sviluppatori, mentre i localizzatori eseguono la traduzione delle risorse.Localizzatori, collaudatori, sviluppatori e capi/responsabili di progetto sono tutti potenziali utenti di un localizationkit.Anche collaudatori e sviluppatori necessitano di informazioni in merito ai file. Fornire specifiche di collaudo aicollaudatori insieme a una panoramica del progetto può garantire che i test siano condotti in modo approfondito.Responsabili di progettoPer ottenere un piano di progetto efficace, i responsabili del progetto di localizzazione, devono poter disporre distime sui volumi di testo, materiale grafico, video e audio da localizzare prima dellassemblaggio del software.I responsabili di progetto che lavorano per i localization vendor hanno bisogno delle seguenti informazioni:  servizi e attività richieste;  panoramica degli obiettivi di progetto; o lingue di progetto; o componenti; o numero di file; o file da localizzare; o numero di parole da localizzare (per file); o file da ingegnerizzare; o numero di pagine in DTP; o numero di aggiornamenti previsti;  piano di rilascio del progetto; o milestone (obiettivi intermedi di progetto); o trasferimenti; o cicli di revisione; o deliverable; o consegne;  controlli di qualità; o obiettivi di collaudo e validazione del software; o numero di revisioni linguistiche; o numero di collaudi; o piattaforme e sistemi operativi.
  6. 6. LocalizzatoriI localizzatori vorranno sapere quali sono i file da localizzare, i loro destinatari e, nella maggioranza dei casi, lecose da non modificare in ciascun file, ma ovviamente saranno interessati anche al conteggio sommario delle parolee al numero di parole in ciascun file e apprezzeranno ogni informazione, istruzione o commento sulle stringhe dalocalizzare e le relative caratteristiche.Il testo, poi, deve essere definitivo.Localization engineerAi localization engineer vanno fornite istruzioni sulle modifiche da apportare al codice perché possa funzionare almeglio nel locale di destinazione. Per loro, inoltre, sono importanti lhardware e il software necessari per lacomipilazione, nonché le procedure e le istruzioni per la compilazione e il collaudo. Per poter effettuare eventualiinterventi "cosmetici" sulle finestre di dialogo, le istruzioni per i test dovranno prevedere informazioni sulla versionedel sistema operativo da utilizzare e sui parametri di configurazione (p.es. la risoluzione video).Qualora gli interventi di ingegnerizzazione e il collaudo cosmetico siano affidati al localization vendor, i localizationengineer dovrebbero poter disporre di file batch per la configurazione automatica dei parametri di sistema e dicompilazione per tutte le lingue. Questi file vanno collocati in unapposita cartella.Tutto il codice, infine, deve essere stabile a sufficienza per essere sottoposto a collaudo.
  7. 7. Realizzazione di un localization kitUn localization kit aiuta a rispettare le scadenze poste dal cliente e a raggiungere gli obiettivi di qualità e diservizio, esplicitando le attese e favorendo la comunicazione e lorganizzazione del progetto. Prima di procederealla localizzazione, i prodotti da localizzare dovrebbero essere sottoposti a un test di internazionalizzazione, inmodo da poterne ricavare materiale da riutilizzare con più locale.Prima di cominciare a lavorare, i localizzatori dovrebbero essere informati su alcuni aspetti quali:  attese degli utenti e del cliente;  concorrenza sul mercato di destinazione;  questioni culturali, religiose o sociologiche;  requisiti tecnici (p. es. banda ed eventuali costi di accesso allInternet e per lacquisto del dominio nel caso di siti o applicazioni Web);  obblighi normativi (p. es. legislazione per la protezione dei dati e diritti dautore).Quando si assembla un localization kit è necessario attenersi a questi principi: 1. stabilire una norma per i vari tipi di informazioni da inserire e il livello di dettaglio, le linee guida generali di presentazione e le istruzioni su cosa inserire nel kit, cosa è importante e su come comunicare le informazioni al vendor; 2. creare sezioni separate per ciascun componente del prodotto, in modo da distinguere gli obiettivi per deliverable, siti Web e materiale collaterale; 3. 3. elencare tutti i documenti esterni indicandone la versione e le informazioni su come accedervi; 4. richiedere sempre al cliente di approvare il kit e tutti i deliverable in esso contenuti prima dellinvio al localization vendor; 5. sottoporre le bozze del kit ai localization vendor, perché pongano domande e avanzino suggerimenti prima dellinvio della versione finale; 6. una volta concluso il progetto, condurre una revisione post-mortem per i progetti futuri.Nellaggiungere successivamente nuovi contenuti, conviene organizzarli come in un "mini" localization kit allegato aquello principale: un insieme di risorse, strumenti, documenti e codici che permettano di evitare di riorganizzare ilkit originale solo per includervi gli aggiornamenti.Tuttavia, anche se un localization kit può servire a ridurre i costi, la frustrazione e i ritardi derivanti dall incertezzadei requisiti iniziali, molti problemi potranno essere risolti solo nel quadro di una corretta interazione fra cliente efornitore. Per questo, appena il kit è pronto, è utile estrarne le parti descrittive e raccoglierle in un manualetto dadistribuire al kick-off. Inoltre, può essere utile realizzare un sito web per il kit attraverso il quale mettere adisposizione in tempo reale tutto il materiale di progetto, e magari le informazioni post mortem, in particolare iproblemi irrisolti e quelli risolti con le relative soluzioni.Contenuto di un localization kitGli attuali prodotti software sono composti da varie categorie di oggetti che devono essere archiviati per i rilascisuccessivi, per il porting su piattaforme differenti e per creare versioni speciali per i produttori di componentihardware (OEM, Original Equipment Manufacturer), che possono essere pre-installate sui computer o venduteinsieme ai componenti hardware.Questi oggetti saranno riutilizzati anche per lo sviluppo di eventuali patch che dovranno successivamente integrarele raccolte.La gestione di questi processi richiede un localization kit. Ogni cliente, poi, ha le sue esigenze, le sue scadenze, isuoi deliverable e le sue componenti. Di conseguenza, i localization kit differiscono non solo da unazienda allaltra,ma anche da un progetto allaltro. Tuttavia, alcune componenti sono comuni alla maggior parte dei kit.Di norma, un localization kit è composto da centinaia di file, alcuni dei quali traducibili e molti altri no.Mettere insieme i file, però, è solo il primo passo: è essenziale fornire indicazioni su come servirsene per potermeglio comprendere le attese del cliente oltre che la natura e le dimensioni del progetto.Per rilasciare unapplicazione, è necessario essere in possesso di tutte le risorse e di tutti i file di codice, cheverranno compilati in un file binario o eseguibile, che potrà essere eseguito su un computer. Per questo, unlocalization kit completo dovrà comprendere il software di compilazione e/o i file della relativa guida in linea.Come esempi di risorse si possono citare i file bitmap utilizzati nelle barre strumenti, per esempio licona dellastampante che permette di eseguire il comando di stampa. In molti casi, queste risorse non vanno modificate nelleversioni localizzate. Le informazioni traducibili, come i testi dei menu, le opzioni nelle finestre di dialogo e imessaggi di errore sono conservate nei file di risorse. In un prodotto software adeguatamente internazionalizzato
  8. 8. tutti i testi traducibili sono archiviati nei file di risorse, semplificando così la localizzazione. Tuttavia, in molti casi,i file che contengono i testi traducibili si trovano un po dappertutto.È responsabilità del localization engineer individuare tutti i file traducibili e prepararli per la traduzione. Ilocalization engineer dovrebbero assicurarsi che i traduttori sappiano esattamente quali sono le operazioni dasvolgere, così da poter iniziare il lavoro prima possibile.Per assemblare un localization kit completo occorre seguire alcuni passi generali: 1. preparare il progetto; 2. rintracciare le difficoltà allinterno delle specifiche; 3. identificare gli obiettivi; 4. individuare gli utenti; 5. redigere le istruzioni per ogni gruppo di persone che lavora al progetto; 6. raccogliere e organizzare tutte le risorse, gli strumenti e i documenti necessari; 7. avviare un progetto pilota per collaudare il localization kit.Per aiutare il responsabile di progetto nella compilazione delle istruzioni per i componenti del team dilocalizzazione, un localization kit dovrà essere provvisto di:  un diagramma di flusso dellinterfaccia utente (e possibilmente dei messaggi di errore) che descriva come interagiscono le varie interfacce e definisca il contesto dei termini; spesso sono sufficienti i diagrammi (UML) dei casi duso, delle attività e di sequenza;  specifiche hardware e software che definiscano eventuali programmi proprietari necessari per la localizzazione, con le istruzioni su come procurarseli, installarli, eseguirli e utilizzarli;  documentazione documentazione utente, guida in linea (in versione originale e compilata) e documentazione di progetto;  strumenti specifici necessari per la localizzazione;  elementi traducibili tutti i testi, le illustrazioni, il materiale multimediale, il materiale collaterale e altro materiale da tradurre, nella lingua di partenza.In un progetto hardware, poi, è necessario disporre di informazioni quali le dimensioni delle aree di etichettaturadel prodotto, dei nomi da utilizzare per pulsanti e leveraggi e dei requisiti di sicurezza. Anche in questo caso,disporre di un prototipo permette di ricavare preziose note contestuali.Se viene a mancare una qualunque delle componenti di un localization kit, o si rivela non sufficientementedettagliata, il kit risulterà di difficile utilizzo e il tempo speso per rispondere ai vari quesiti e ripristinare leinformazioni o le risorse mancanti si tradurrà in una spesa non preventivata e, quindi, inaccettabile.Gestione del progettoIl localization kit dovrebbe essere diviso in due sezioni, specificamente costruite dal gruppo di progetto, secondounarticolata struttura a cartelle, anche se le future versioni dei più comuni sistemi operativi avranno caratteristichedi indicizzazione profondamente integrate, tali da rendere obsoleti i sistemi a cartelle.La responsabilità principale del capo progetto è quella di integrare il localization kit con una sezione specificadedicata proprio al progetto.Ogni localization kit dovrà includere una lettera dincarico che dovrà essere firmata da tutti i componenti del teamdi localizzazione e potrà eventualmente fungere anche da contratto tra le parti. La lettera dincarico dovràincludere tutte le quotazioni raggruppate per componente, gli accordi sulla gestione delle modifiche, gli obiettiviintermedi e i "punti di congelamento" del ciclo di sviluppo.Il kit dovrà contenere una descrizione dei lavori in cui siano elencati tutti i servizi e i deliverable attesi, e tutto ilrelativo materiale di riferimento.Descrizione dei lavori (SoW)Lo scopo del documento di descrizione dei lavori (SoW, Statement of Work) è quello di definire nel dettaglio irequisiti di lavoro, ovvero "ciò che va fatto" durante il progetto. Questo documento sarà il capitolato perlaggiudicazione della commessa e, una volta divenuto specifica contrattuale, potrà essere utilizzato comeriferimento per determinare se i fornitori soddisfino o meno i requisiti di prestazione prestabiliti. Il documentoservirà, inoltre, al responsabile di progetto per quantificare limpegno richiesto attraverso una WBS (WorkBreakdown Structure o diagramma di suddivisione del lavoro) e nello stabilire un piano di consegna.Lo stesso documento dovrebbe anche indicare, senza limitarvisi:
  9. 9.  obiettivi di progetto; o nome del prodotto; o nome o codice del progetto; o descrizione generale del prodotto e degli utenti di destinazione; o descrizione dellarchitettura base del prodotto; o elenco dei componenti del localization kit; o servizi richiesti, attività e deliverable; o lingue; o componenti di progetto; o conteggio delle parole;  requisiti di consegna; o periodo di prestazione (data di inizio e data di fine dellintero progetto);  date di consegna;  milestone organizzati per deliverable; o luogo in cui il lavoro sarà fisicamente eseguito; o standard di produttività; o dotazioni e strumenti; o metodi di consegna;  e-mail;  CD/DVD (eventualmente specificando il tipo di corriere);  FTP;  ciclo di aggiornamento; o numero di aggiornamenti; o dimensione degli aggiornamenti; o piano di aggiornamento previsto;  aspettative di qualità (qualità accettabile del prodotto);  condizioni di pagamento; o importo totale dellordine; o importo complessivo computato per ciascun lavoro/attività/deliverable; o tariffe unitarie; o accordo di riservatezza; o accordo di manleva;  contatti; o nome/i, e-mail e numero/i di telefono del/i responsabile/i di progetto.Per evitare discussioni sul conteggio delle parole, è bene fornire indicazioni sugli strumenti e sui metodi di calcolo eil risultato dellanalisi dei file di log. Ciascun file di log deve riportare il numero di parole ripetute e non tradotte,leventuale memoria di traduzione, il numero di full match e di fuzzy match e di segmenti ricorrenti. Per quantopossibile, è utile disporre di una mappa che permetta di individuare gli elementi riutilizzabili e il modo in cui trarnevantaggio.Tutte le impostazioni degli strumenti di traduzione (p. es. regole di segmentazione, valore di minimum match,numero massimo di hit, penalità ecc.) dovrebbero essere specificate al fine di consentire ai membri del team diriprodurre tutte le statistiche e applicare adeguatamente le memorie di traduzione.Queste impostazioni andrebbero usate anche per produrre le statistiche per gli stati davanzamento e i diagrammicon le proiezioni dei tempi di consegna.Distinta dei materiali (BoM, Bill of Materials)Il documento di descrizione dei lavori (SoW) dovrebbe riportare il numero di versione in modo da assicurare larintracciabilità degli aggiornamenti ed essere corredato da una dettagliata distinta dei materiali (BoM) che dovràincludere:  un elenco dei file da localizzare, raggruppati per tipo;  unimmagine della struttura di directory dei file di risorse, dei sorgenti, dei file compilati e di quelli della documentazione raggruppati in base al locale;  i requisiti della struttura di directory per i deliverable;  un elenco dei deliverable previsti;  un elenco dei driver per la creazione dei deliverable;  un elenco degli ambienti di sviluppo e dei sorgenti;  un elenco dei file della documentazione.
  10. 10. Esempio di elenco di file localizzabili per una distinta dei materiali (BoM) Conteggio Nome file Tipo file Funzione Percorso Note e istruzioni parole default.asp Script lato Pagina di inizio 30 directory principale Riga 37: la variabile server navigazione strRedirect non deve (VBScript) superare i 75 caratteri Riga 271: non localizzare la variabile strLang content.asp Script lato Pagina 1,830 directory principale Riga 58: Localizzatori server contenitore spagnoli: utilizzare (VBScript) terminologia differente per i mercati spagnolo e messicano style.css Foglio di Gestisce la Style Riga 10: cambiare i stile visualizzazione caratteri Times New (CSS2) dei contenuti Roman con SimSun per il Cinese Semplificato (2052), PMingLiu per il Cinese Tradizionale (1028), MS Mincho per il Giapponese (1041) e Batang per il Coreano (1042) errmsg.inc Testo file include 10,000 IncludesEnMessages Stringhe di testo semplice visualizzate nelle finestre di messaggio per segnalare un errore.Materiale di riferimentoIl capo progetto è responsabile anche della preparazione del materiale di riferimento che di solito prevede:  tutti i dati storici sul prodotto;  descrizione generale del prodotto e informazioni di riferimento;  la più recente versione localizzata del prodotto nella/e lingua/e richiesta/e;  guide di stile per ogni lingua di destinazione relative ad aspetti redazionali e di progettazione;  file di documentazione;  memorie di traduzione complete e aggiornate per tutti i componenti con lindicazione del relativo formato per ciascuna lingua;  un glossario di progetto aggiornato;  modelli per la gestione dei quesiti;  file della guida e del programma compilati, collaudati e perfettamente funzionanti. Esempi di rapporto di correzione degli errori Rapporto di correzione degli errori: < nome prodotto > GUI italiano Problema file Percorso Problema Commenti Altro Nome risolto main.rc menu Linguistico Dopo una revisione accurata, alcuni oggetti principale suonano meglio in italiano se resi al plurale: Contatto > Contatti, Fornitore > Fornitori, Preventivo > Preventivi, Cliente > Clienti, Strumento > Strumenti, Progetto > Progetti
  11. 11. Esempio di foglio per le domande Foglio per le domande: < nome del progetto > Terminologia italiano Urgente Nome del Termine (lingua di Pagina Termine/Problema Contesto Risposta (Si/No) file destinazione) Esempio di stato di avanzamento Parole Conteggio Avanzamento Giorni Data di Data di Nome del file da Risorse2 Produttività3 parole %1 correnti4 inizio fine tradurre rc1_en_olh.rtf 32.914 3.724 88,7% 6 333 1,9 10/3/2005 1/7/2005 1. 100-[(parole tradotte)*100/(parole da tradurre)] 2. persone coinvolte 3. (numero di parole al giorno)/(risorse) 4. (parole da tradurre)/[(risorse)*(produttività)]SoftwareNello sviluppare un localization kit, il responsabile del progetto di localizzazione dovrà definire gli elementi chepotrebbero essere culturalmente rilevanti e decidere se renderli culturalmente neutri o isolarli per lalocalizzazione. Lisolamento si ottiene trasferendo ogni riferimento culturale in un file di risorse e sostituendoli conuna routine per la ricerca delle informazioni appropriate nel file di risorse. Se è necessario lisolamento, ilresponsabile del progetto rimanderà indietro il codice agli sviluppatori con le istruzioni per la correzione.La traduzione delle risorse deve precedere quella della guida in linea e della documentazione in modo da poterdisporre della terminologia atta a garantire una generale coerenza terminologica. Per questa ragione, al momento diraccogliere il materiale di riferimento, il responsabile del progetto, insieme agli esperti software del cliente,provvederà anche a preparare le risorse per la traduzione, per permetterne il trattamento con uno strumento ditraduzione.Prima di iniziare la localizzazione vera e propria, il responsabile del progetto di localizzazione dovrà garantire che iltesto originale sia chiaro e conciso, grammaticalmente corretto e privo di espressioni gergali, anche tecniche, chepossano essere causa di errori nella traduzione. Dovrà, inoltre, verificare la coerenza linguistica e dei riferimenti,oltre che lintegrità e la correttezza della memoria di traduzione.Oltre alle risorse pronte per la traduzione, il localization kit dovrà contenere anche una versione eseguibile delsoftware (come riferimento e per aiutare il traduttore a familiarizzare col prodotto), nonché lintero ambiente disviluppo, nel caso in cui siano necessarie la compilazione e il collaudo finali.Il localization kit va composto in base agli obiettivi di progetto e deve eventualmente prevedere sezioni distinte peril software tradizionale e per quello Internet.Inoltre, i localizzatori dovrebbero poter consultare i risultati di un eventuale progetto pilota per potervi rintracciarequegli elementi eventualmente tralasciati in fase di internazionalizzazione. A questo scopo può risultare utilissimoun elenco dei problemi di internazionalizzazione noti.Software tradizionalePer "tradizionale" si intendono i programmi statici per computer da tavolo, portatili o tascabili, in opposizione alleapplicazioni Internet. La sezione relativa al software tradizionale dovrà comprendere:  una copia dellapplicazione completa;  i file di risorse (.rc) contenenti tutte le stringhe di testo traducibili;  i file "header" (.h);  i file delle librerie dinamiche contenenti le risorse (.dll);  i file e gli script di installazione con le relative risorse;  una copia dellambiente di sviluppo completo per il collaudo;  script di test;  gli strumenti proprietari e personalizzati utilizzati per la compilazione e il collaudo.
  12. 12. Software InternetUn sito o unapplicazione Web sono sostanzialmente differenti da unapplicazione software "tradizionale" statica, edifficilmente si possono localizzare in "modalità sicura" (vale a dire lavorando soltanto su binari, script di risorse ofile di stringhe). Nella maggior parte dei casi, i localizzatori devono essere in grado di accedere ai file di risorse perpoter replicare il sito o lapplicazione e, possibilmente, predisporre un test bed.Per questo, la prima preoccupazione del responsabile di un progetto di localizzazione Web dovrebbe essere quella diproteggere il codice da modifiche accidentali e di organizzare un language pack. Se il prodotto è statointernazionalizzato correttamente, tutte le stringhe da tradurre dovranno essere estratte dal codice e il languagepack sarà composto essenzialmente dalle tabelle di stringhe e dai file delle immagini per ciascuna lingua. Itraduttori dovranno "soltanto" tradurre le relative colonne della tabella delle stringhe.In un prodotto ben internazionalizzato, il testo da tradurre di solito è contenuto in un file di testo incluso negliscript lato server con unistruzione <!-- # include file/virtual="percorsorelativo/nomefile"-->. Ognimodulo del sito dovrà avere una cartella contenente questi file, separata dalle cartelle principali del sito Web.Un tipico language pack per una sezione Internet comprende:  file di risorse per i file binari e gli script;  file di testo e il catalogo messaggi contenenti le stringhe dellinterfaccia utente;  file grafici in formato sorgente in più livelli e nel formato Internet (GIF, JPEG, PNG);  file binari accessibili via Internet (eseguibili, librerie, componenti, servlet ecc.);  file lato server non compilati;  applet Java e file Flash;  database di back-end.Per ogni oggetto va specificata lapplicazione associata (p. es. Adobe Photoshop per i file .psd, Microsoft Access peri file .mdb e Macromedia ColdFusion per i file .cfm).Documentazione e guida in lineaUna volta portata a termine anche la revisione della versione localizzata del software, i localization engineerdovranno reimportarla in uno strumento di traduzione e creare un glossario che contenga tutti gli elementidellinterfaccia utente nella lingua di partenza e in quella di arrivo.Il localization kit dovrà, quindi, essere aggiornato con la documentazione, i file della guida in linea e il nuovoglossario. Anche la descrizione dei lavori dovrà essere aggiornata con i nuovi dati del piano di progetto.La documentazione del software dovrà essere disponibile tanto nel formato originale quanto in quello finaleperfettamente impaginato; dovrebbe inoltre essere fornita anche una copia cartacea di tutti i documenti datradurre.I file facenti parte del localization kit dovranno esservi inseriti secondo una rigorosa struttura di directory. Sipotrebbe creare, per esempio, una cartella Documentation con due sottocartelle Product documentation eProject documentation.La cartella Product documentation potrà contenere una cartella User documentation e una On-line help.La cartella User documentation dovrà contenere la versione impaginata con i file originali e una versione informato "tagged" per il trattamento con strumenti di traduzione. Se è richiesta una versione tipografica, la cartellaUser documentation dovrà contenere anche una copia del compilatore.I caratteri e i tipi di carattere da utilizzare dovranno essere chiaramente specificati e, se insoliti o proprietari,dovranno essere inseriti nel kit. Al momento di definire le regole per lassegnazione dei nomi, è bene stabilirne unaper i nomi dei caratteri in modo che siano coerenti con quelli usati nel locale di destinazione.Infine, la cartella User documentation del localization kit dovrà contenere un foglio elettronico con la distintadei materiali che specifichi:  i file da localizzare, la loro posizione e le indicazioni sul testo da lasciare nella lingua di origine;  il formato dei sorgenti, gli strumenti di autoria e di test e le versioni usate per realizzarli;  i formati dei file di output, gli strumenti di autoria e di test e le versioni necessarie per realizzarli;  i font utilizzati nei file sorgente e quelli utilizzati nella versione localizzata. La cartella On-line help dovrà contenere:  una guida in linea compilata (.hlp, HTML, AppleGuide, ecc.);  sorgenti in formato rich-text (.rtf, .doc, ecc.);
  13. 13.  file di progetto della guida (.hpj);  modelli e fogli di stile per la guida in formato HTML/XML;  file bitmap (.bmp);  file ipergrafici segmentati (.shg);Nel caso in cui sia necessaria una versione compilata, la cartella On-line help dovrà contenere anche una copiadel compilatore.I file grafici della guida in linea potranno anche essere archiviati in una speciale sottocartella Graphics, allinternodella cartella On-line help o in una sottocartella On-line help, allinterno di una più generica cartellaGraphics del localization kit.La cartella Project documentation potrà contenere le direttive di progetto, la guida di stile con tutte leconvenzioni stilistiche, tipografiche e per lassegnazione dei nomi e tutti i template, nonché, se possibile, la guida distile utilizzata dai redattori tecnici per i file sorgente. Peraltro, tramite opportune modifiche agli stili contenuti neitemplate, sarà possibile individuare e risolvere eventuali problemi di localizzazione prima dellavvio dei lavori.La cartella Project documentation potrà inoltre contenere la guida alla localizzazione con le regole perlassegnazione dei nomi, le linee guida per la preparazione dei documenti, qualora se ne debbano creare copiediverse per ogni lingua o locale, la versione del driver della stampante e il file con la descrizione della stampanteda utilizzare, le linee guida e le istruzioni per lespansione del testo. Qualora vengano utilizzati font speciali, laguida alla localizzazione dovrà anche specificarne i dettagli. Infine, la guida alla localizzazione fornirà le istruzioniper il DTP e la versione del compilatore e per i test della guida in linea, con specificazione delle piattaforme, deisistemi operativi, dei browser e delle relative versioni.La cartella Project documentation potrà infine contenere un foglio elettronico con la distinta dei materialielencante i nomi e il tipo dei file e una breve spiegazione della funzione di ciascuno di essi, e le annotazioniaggiuntive, compresi eventuali font speciali.File graficiLe cartelle User documentation e On-line help potranno contenere ciascuna una sottocartella Graphicsopppure si potrà creare una generica cartella Graphics nella cartella principale del localization kit.In ogni caso, si potranno creare una cartella Source per i file grafici in formato sorgente e una cartella Final perquelli non modificabili.Quando si crea unimmagine con sistemi di autoria grafica a livelli, il testo deve essere inserito su livelli distinti.Con le illustrazioni disponibili solo in formati non modificabili, si dovranno estrarre tutti i testi e creare un foglio conle stringhe da tradurre nella stessa cartella di lavoro contenente il foglio relativo alla documentazione perreimportarvele dopo la localizzazione. Questo foglio di lavoro potrà essere archiviato nella sottocartella Projectdocumentation, allinterno della cartella Documentation.La stessa cartella di lavoro potrà contenere un foglio elettronico con le informazioni relative alle immagini richiesteordinate per area:  i nomi dei file in formato sorgente e finale;  strumento grafico e versione utilizzati per creare il file sorgente;  specifiche per la creazione di immagini nel formato di output; o font; o tavolozza dei colori; o risoluzione video e risoluzione di stampa;  combinazioni di tasti o menu di ogni schermata per la cattura. Inoltre, nella sezione grafica della guida alla localizzazione, dovranno essere fornite istruzioni su come gestire lespansione del testo e i simboli "riservati", insieme a eventuali informazioni su forme alternative. Esempio di elenco di file grafici per una distinta dei materiali Testo da Conteggi Note e Nome file Tipo file Funzione Percorso tradurre o parole istruzioniintro.bmp BMP, 8-bit, Immagine Premere un 5 GraphicsFinalMain Usare Arial 24 nessuna visutalizzat tasto per grassetto per compression a allavvio continuare.. il testo; colore e del . del testo programma #FF9900
  14. 14. Esempio di elenco di file grafici per una distinta dei materiali Testo da Conteggi Note e Nome file Tipo file Funzione Percorso tradurre o parole istruzioniback_off.jp JPEG, Immagine GraphicsFinalMain Collegamentog compression di sfondo in e 25% per la default.asp. pagina di è unimmagine benvenuto molto difficile del sito da riprodurre. internet Se si (back dimostrasse office) non adatta al vostro locale, riempire il relativo spazio con unimmagine vuota.scr01_en.gi Standard Schermata GraphicsFinalScreensho Ognif GIF, 256 del menu ts schermata colori principale dellinterfaccia utente deve essere riprodotta a localizzazione avvenuta. Accertarsi di avere qualche record valido nel database per ottenere unimmagine significativa. Utilizzare Windows XP, Fedora Red Hat o Mac OS X per realizzare le schermate.workflow.gi Standard Diagramma Vedere le 155 GraphicsFinalArtwork Collegamentof GIF, 256 di flusso etichette di in colori che testo nel workflow.as fornisce un file p. Il sorgente quadro sorgente di questa generale immagine è del workflow.xc processo di f (vedi sotto), produzione realizzato con GIMP (GNU Image Manipulation Program).
  15. 15. Esempio di elenco di file grafici per una distinta dei materiali Testo da Conteggi Note e Nome file Tipo file Funzione Percorso tradurre o parole istruzioniworkflow.xc GIMP image Diagramma 155 GraphicsSourceArtwork Sorgente dif di flusso workflow.gi che f (vedi sopra). fornisce un Localizzare il quadro livello di testo generale nel file con del GIMP (GNU processo di Image produzione Manipulation Program, lambiente grafico GNU) e salvarlo in formato GIF. GIMP è un programma gratuito per il fotoritocco e la grafica.File multimedialiPoiché sono sempre più numerosi i progetti di localizzazione che includono una componente audio/video, èimportante disporre di capacità tecniche e, più in generale, di studio di produzione.La multimedialità abbraccia una vasta gamma di "documenti" che sono il risultato della combinazione di testo,immagini, suoni, video e animazioni; per questo, nella creazione di file multimediali si segue un principio base checonsiste nel mantenere separati gli elementi localizzabili digitali luno dallaltro in tracce diverse sulla timeline.Lideale sarebbe fornire ai localizzatori i file di progetto e i parametri di progetto con cui si è costruita lapresentazione. Nei filmati MPEG e AVI correttamente codificati, i flussi audio e video si possono estrarre e separare,per riaccoppiarli dopo averli ritoccati o localizzati.In breve, la sezione multimediale di un localization kit dovrà contenere:  una copia dei dialoghi, nella lingua dorigine e di destinazione, in ordine cronologico;  flussi audio e video non compressi e separati (musica, effetti sonori, tracce audio);  tracce separate per effetti sonori e audio;  tutti i codec specifici e i visualizzatori, necessari per realizzare e riprodurre le versioni compresse dei filmati;  una copia dei video non compressi con il testo da localizzare. Alcuni progetti potrebbero richiedere la divisione dei dialoghi in singoli paragrafi, a seconda della grandezza del progetto, così che i file risultanti si possano gestire singolarmente in modo più semplice, con lo stesso codice, nella lingua di origine e in quella di destinazione. Ognuno di questi elementi dovrà, quindi, essere inserito nella distinta dei materiali, con il relativo nome file. Anche in questo caso sarà utile disporre una copia cartacea di tutti i documenti da tradurre e un foglio elettronico con tutte le informazioni disponibili sui file multimediali da archiviare nella cartella Project documentation, allinterno della cartella Documentation del localization kit; lobiettivo è produrre:  un elenco delle applicazioni utilizzate con particolare riferimento agli ambienti multimediali dedicati o misti;  indicazioni per eventuale spazio aggiuntivo sui CD o DVD da distribuire;  specifiche tecniche per il voice-over; o formato dei file audio originali voice-over; o formato dei file audio localizzati.La sezione multimediale della guida alla localizzazione deve fornire:  indicazioni per la sostituzione dei file audio in lingua originale con le tracce audio localizzate;  indicazioni per lespansione del testo, il voice-over e la sincronizzazione;
  16. 16.  istruzioni per un corretto accento e una corretta pronuncia, e su tono e ritmo dei dialoghi;  istruzioni per leliminazione dei rumori;  istruzioni sul livello e la coerenza del volume;  istruzioni sui silenzi. Esempio di elenco di file multimediali per una distinta dei materiali Frequenza Rateo di Tipo di Note eNome file Funzione campioname Piattaforma Percorso file campioname istruzioni nto ntowelcome. WAV 8 bit 44 kHz PC MultimediaAudio Associato alwav - Main menu Mono principale. Suono di benvenuto.intro.wm WMA Presentazion 24 bit 22 kHz Windows MultimediaAudio Collegamenta - e Web o in Ster dellapplicazi default.as eo one Web p. file sorgente non disponibile. Dialoghi in intro_en.r tf. Usare Windows Media per ricreare il file audio.sample.m MPE Video 16 bit stereo 44 kHz Multipiattafo MultimediaVideo Collegamentpeg G-1 campionato rma Web o in training.a sp. Dialoghi in intro_en.r tf. Per ragioni di supporto, per ricreare il file audio utilizzare possibilment e Adobe Premiere, Ulead Video Studio o Pinnacle Liquid Edition.Per i file MPEG, potrebbe essere estrememente utile una versione del tutto aderente agli standard con time code einformazioni per la sottotitolazione.Materiale collateraleIl materiale secondario viene, in genere, chiamato "collaterale". Si tratta, spesso di file grafici e, a volte, didocumenti DTP.Il localization kit dovrà essere provvisto di una cartella Collaterals contenente:  le versioni compilate (DTP) o il file grafico della confezione;  i file sorgente o in formato "tagged" del file (DTP) della confezione;
  17. 17.  il file grafico delle etichette per CD con la relativa versione a stampa (di solito in formato EPS);  la versione compilata (DTP) o il file grafico degli opuscoli e dellaltro materiale di marketing;  il file sorgente o la versione in formato "tagged" del file in DTP degli opuscoli e dellaltro materiale di marketing;  il file Leggimi in formato solo testo o rich-text;  laccordo di licenza in formato solo testo o rich-text;  i font utilizzati nei file sorgente e quelli utilizzati nella versione localizzata. Ancora una volta, se possibile, dovrà essere fornita una copia cartacea di tutto il materiale da tradurre. Quindi dovrà essere creato un foglio elettronico con tutte le informazioni disponibili sul materiale collaterale che potrà essere aggiunto al foglio di lavoro con le specifiche nella cartella Project documentation allinterno della cartella Documentation del localization kit e servirà a fornire:  i nomi dei file in formato sorgente e finale;  strumenti grafici o DTP, con relativa versione, utilizzati per la creazione dei file sorgente;  tutti i requisiti aggiuntivi in merito ai font;  specifiche per la creazione di immagine nel formato di output; o font; o tavolozza dei colori; o risoluzione video e risoluzione di stampa;  informazioni sulla versione del driver della stampante e il file di descrizione della stampante da utilizzare.Inoltre, nella sezione della guida alla localizzazione relativa al materiale collaterale dovranno essere fornite lelinee guida e le istruzioni per lespansione del testo, le istruzioni per la compilazione in DTP, compresa la versionedel compilatore, e le istruzioni per la gestione delle questioni legali, fiscali o finanziarie.ConsegnaInsieme alle istruzioni per la creazione e la consegna di un language pack a partire dai file localizzati si dovrà dareuna descrizione generica dei contenuti delle cartelle.Prima della pubblicazione, il localization kit dovrebbe essere sottoposto a verifica da parte di terzi, per individuareeventuali stumenti e informazioni mancanti e necessari alla localizzazione; questa verifica dovrebbe riguardare: 1. ricerca dei file corrotti; 2. ricerca ed eliminazione di eventuali virus; 3. ricerca ed eliminazione di eventuali file non necessari; 4. verifica che non vi siano file mancanti; 5. verifica che i file siano tutti aggiornati allultima versione.Infine, il localization kit dovrà essere archiviato su CD o DVD ed etichettato con:  nome del prodotto;  versione e numero di build;  piattaforma;  data di creazione;  sommario.Se il localization kit viene aggiornato con patch o contenuti aggiuntivi dopo il rilascio del prodotto, sarà opportunocreare un mini localization kit archiviando gli elementi critici in un disco a parte sulla cui etichetta siano riportatele stesse informazioni del localization kit originario e su cui sia collocata unetichetta aggiuntiva che specifichi chesi tratta di unintegrazione.
  18. 18. Stesura della guida alla localizzazioneLa guida alla localizzazione dovrà essere redatta prima delleffettivo inizio del progetto, insieme al piano di progettoe contiene le istruzioni per la localizzazione di un prodotto. Le direttive contenute nella guida di localizzazionedipendono dal prodotto o sono dettate dallazienda.Anche se può sembrare un lavoro lungo e impegnativo, una buona guida può adattarsi bene a molti progetti; perquesto, nella maggior parte dei casi, la si può preparare una sola volta e riutilizzarla in progetti successivi,apportandovi solo lievi modifiche.In un progetto di localizzazione, il numero di problemi diminuisce con laumentare della qualità delle informazioni:per scrivere una buona guida alla localizzazione è quindi necessario:  determinare lutente del kit e le sue esigenze;  illustrare i contenuti del kit e spiegare come utilizzarli;  assicurarsi che il kit sia completo e fruibile.Andranno poi fornite istruzioni su come organizzare e formattare il materiale localizzato. Per ogni duplicazionedovrà esserci una corrispondenza e si dovrà spiegare in che modo i file sono correlati. Le istruzioni contenute nellaguida alla localizzazione dovranno essere sufficientemente chiare e precise da permettere di ricomporre i file inmodo da reintrodurli nel prodotto.La guida alla localizzazione allinterno del localization kit dovrà elencare e chiarire accuratamente tutti gliargomenti e indicare con precisione ogni modifica. Per essere utili al lavoro, gli elenchi dovranno essere aggiornati.La guida alla localizzazione dovrà, inoltre, essere sempre aggiornata con le risposte alle domande sollevate e lesoluzioni ai problemi riscontrati, indicando:  indicazioni per la localizzazione e informazioni sul programma;  istruzioni su come trattare le stringhe concatenate;  istruzioni speciali per il trattamento dei file, comprese quelle sulle applicazioni da utilizzare e sulla relativa versione, piattaforma ecc. e su ogni altro processo speciale o manuale;  istruzioni per gestire lespansione delle stringhe di testo;  istruzioni per il ridimensionamento delle finestre di dialogo e degli altri elementi decorativi;  linee guida per lutilizzo dei tasti di scelta rapida;  convenzioni per lassegnazione dei nomi dei file (possibilità di utilizzare nomi di file lunghi, contenenti spazio o caratteri speciali, oppure secondo lo schema 8.3);  tipi di file previsti per la consegna.La guida alla localizzazione dovrà, infine, descrivere in modo dettagliato le procedure di comunicazione eregistrazione dei dati di progetto.Quello che segue è uno schema di stesura per una guida alla localizzazione. Un breve esempio, certamenteincompleto, è disponibile in appendice.IntroduzioneFornire una panoramica generale di tutto il documento, descrivendo i dati, i requisiti funzionali e i comportamentirichiesti. Descrivere i contenuti del kit.Organizzazione del progettoElencare i ruoli principali allinterno del progetto e le persone coinvolte, possibilmente attraverso un graficoorganizzativo. Lelenco che segue traccia un esempio di struttura organizzativa di progetto:  capo progetto (da cui dipende il responsabile di progetto);  responsabile della localizzazione;  responsabili di progetto (lato cliente e vendor);  coordinatori;  componenti del gruppo di progetto.
  19. 19. Punti chiave del progettoDescrivere gli obiettivi generali di progetto, attraverso una sintesi generale del piano di progetto che riporti le stimedei costi e un programma di massima.Campo di applicazioneDefinire la portata e i limiti del lavoro da svolgere, non le modalità per svolgerlo. Descrivere il progetto e ilsoftware con principali funzionalità e vincoli. Collocare il software in un contesto aziendale o produttivo, mettendoin evidenza le questioni strategiche, in modo da fornirne un quadro complessivo al lettore. Ove possibile, indicareun contesto applicativo descrivendo le varie interfacce verso il mondo esterno, e le strutture di controllo delsistema.Contenuti del kitFornire le istruzioni per il ritiro, illustrare lorganizazione del kit e fornire istruzioni su come installarlo.Requisiti di risorseIndicare i requisiti hardware, software, di documentazione, del personale e di dati servendosi di un modellocontestuale dellarchitettura di sistema.I requisiti di risorse dovranno specificare nel dettaglio:  materiale hardware;  strumenti di interfaccia (IME);  strumenti speciali;  sistemi operativi;  impostazioni del computer (hardware, piattaforma, percorsi di sistema, memoria);  specifiche di eventuali database di back-end e dei dati che è necessario estrarre per realizzare la versione localizzata.Strumenti, tecniche e metodologieStrumentiIl kit dovrà contenere una cartella Tools con tante cartelle quanti sono gli strumenti, ciascuna con il nome dellostrumento.Specificare i linguaggi, gli script, i compilatori e gli strumenti utilizzati per sviluppare il software e fornire un elencodegli strumenti, delle tecniche e dei metodi da utilizzare per la localizzazione e le attività di testing.TecnicheDescrivere la procedura per la localizzazione dei vari tipi di file e per utilizzare gli strumenti proprietari inclusi nelkit. Specificare se tra i deliverable è richiesta la memoria di traduzione ed eventualmente in quale formato.Fornire istruzioni su come gestire i messaggi di errore, le stringhe composite, lordine delle parole, i generi, gliarticoli, i plurali e lespansione del testo.Quando la localizzazione si può effettuare solo traducendo le stringhe decontestualizzate dei file di risorse,illustrare la sintassi dei file di risorse e le modalità di gestione dei caratteri di controllo e allegare le schermatenella lingua di partenza per facilitarne linterpretazione.Fornire istruzioni sulla gestione delle questioni legali, fiscali o finanziarie.MetodologieElencare i compiti di lavoro specifici necessari a soddisfare i requisiti di progetto e permettere allacquirente eallofferente di valutare i costi e al secondo di determinare i livelli di competenza, manodopera e altre risorsenecessarie per portare a termine lincarico. Nel caso in cui si adotti una struttura di suddivisione del lavoro (WorkBreakdown Structure, WBS) organizzare i compiti in base ad essa.Secificare quali sono i doveri del vendor, in modo che sappia cosa gli viene richiesto e possa portare a termine tuttigli incarichi per ladempimento del contratto.
  20. 20. DeliverableElencare e descrivere i deliverable di progetto. Fornire sempre un adeguato livello di dettaglio, in modo che illettore possa comprendere ciò che si sta producendo. Inserire un grafico che mostri i deliverable in relazione aiprincipali obiettivi intermedi di progetto (milestone).RischiElencare e descrivere le circostanze o gli eventi che potrebbero sfuggire al controllo del gruppo di progetto e chepotrebbero avere un impatto negativo sul progetto, così che tutti gli stakeholder del progetto possano prevenirli egestirli riducendone la probabilità di accadimento.Elencare inoltre i rischi con la relativa probabilità di occorrenza e le conseguenze negative, definendo, per ognirischio, le attività per la sua eliminazione o mitigazione.ComunicazioneI responsabili di progetto devono comunicare regolarmente con gli stakeholder, informandoli sullo stato del progettoin modo da indirizzare le loro aspettative. La mancata informazione sullandamento del progetto farà crescere laprobabilità che insorgano problemi a vari livelli, dipendenti, in molti casi, dal fatto che il cliente o gli stakeholdervengono colti di sorpresa.È quindi necessario stabilire un piano di comunicazione per determinare le necessità comunicative di tutte lepersone partecipanti al progetto o che dipendono da esso, e fornire informazioni coerenti e puntuali a tutti glistakeholder del progetto.Fornire uno schema di rapporto sullo stato del progetto da far compilare regolarmente ad ogni componente delgruppo di progetto.Quello che segue è un modello di rapporto sullo stato del progetto da integrare, eventualmente, con un rapportosullo stato di avanzamento, come quello nel Materiale di riferimento. Modello di rapporto sullo stato del progetto <Nome progetto> Rapporto sullo stato del progetto n. <X> <Data> Responsabile di progetto <Nome> Obiettivi di progetto Breve descrizione degli obiettivi di progetto Sommario del progetto Breve riepilogo delle prestazioni di progetto non trattate nel resto del rapporto Obiettivi intermedi raggiunti Milestone Data di baseline Data di fine Risultati dallultimo rapporto e prestazioni in contrasto Descrizione delle gg/mm/aaaa gg/mm/aaaa gg/mm/aaaa milestone Milestone previste per il Data di fine Data di fine prossimo periodo di Milestone Data di baseline precedente corrente avanzamento e loro modifiche in relazione al piano Descrizione delle gg/mm/aaaa gg/mm/aaaa gg/mm/aaaa precedente milestone Effetti del (mancato) Milestone Impatto raggiungimento delle milestone per il restante Descrizione delle milestone Breve descrizione delle modifiche periodo di progetto interessate da apportare al piano di progetto in conseguentza delle nuove milestone Informazioni generali Aggiungere eventuali commenti di carattere generale a supporto o integrazione delle sezioni precedenti.
  21. 21. Modello di rapporto sullo stato del progetto <Nome progetto> Rapporto sullo stato del progetto n. <X> <Data> Budget Spese Data Spese effettive Avanzo/Disavanzo pianificate gg/mm/aaaa Piano gestione rischi di Rischio Probabilità Gravità Grado Variazione progetto (rispetto al rapporto precedente) Breve descrizione dei rischi Bassa Bassa A Aumento principali. Media Media B Riduzione Alta Alta C Novità Problemi Breve descrizione di tutte i problemi afferenti il progetto sorti dopo il precedente rapporto e che richiedono una soluzione. Raccomandazioni Brevi considerazioni da formulare o sottoscrivere.Piano di assicurazione della qualitàDefinire le attività da condurre per garantire la qualità del progetto e indicare come vadano coordinate, in funzionedelle milestone di progetto. Riportare gli standard e le linee guida cui attenersi durante il progetto e indicare comeconformarvisi. Includere o riportare ogni manufatto pertinente.Obiettivi, controlli, strumenti e metriche di qualitàDefinire il livello di qualità attesa per il prodotto e il livello di qualità minimo per ogni deliverable.Descrivere le attività associate alla realizzazione dei deliverable di progetto, per accertare che la loro qualitàrisponda ai livelli previsti e che soddisfino i criteri prestabiliti di completezza e correttezza.Elencare gli strumenti per la qualità utilizzati allinterno del progetto.Descrivere le metriche di prodotto, di progetto e di processo da seguire e calcolare durante il progetto. Descrivere ivari documenti relativi alla qualità utilizzati nel corso del progetto, comprese le modalità e il luogo in cui archiviarlie per quanto tempo.In un progetto di localizzazione, si fa solitamente ricorso a due tipi di metriche: di produzione e aziendali. Lemetriche di produzione sono incentrate sulla misurazione dellefficienza, quelle aziendali sono incentrate sullamisurazione del valore.Ogni metrica richiede la maggior quantità possibile di dati che, per poter essere raccolti, devono essere chiari eidentificabili. Esempi di metriche Categoria Metriche Valore dimpresa  vantaggi derivanti dallanalisi costi/benefici in seguito allapprovazione del progetto Costi  costi effettivi vs. budget (varianza) di progetto, per le varie fasi, per lattività, ecc.  costi di lavorazione totali vs. costi non di lavorazione (vs. budget)  costo totale dipendenti vs. lavori a contratto vs. consulenti (vs. budget)  costo sviluppo componenti per riuso  idee per la riduzione dei costi implementate e risparmi realizzati
  22. 22. Esempi di metriche Categoria Metriche Soddisfazione del  disponibilità dei deliverable cliente  difetti dei deliverable  affidabilità dei deliverable  responsabilità del gruppo di progetto  competenza del gruppo di progetto  cortesia del gruppo di progetto  comunicazione  credibilità del gruppo di progetto  affidabilità del gruppo di progetto rispetto agli impegni  professionalità del gruppo di progetto  tempi di risposta a quesiti e problemi  tempi medi di risoluzione dei problemi  numero di richieste di modifiche soddisfatte entro il budget e le scadenze iniziali di progetto Durata  durata effettiva vs. budget (varianza) Lavoro  lavoro effettivo vs. budget (varianza)  ore lavorate dal responsabile di progetto vs. ore di lavoro totali Produttività  ore lavorative per unità di prodotto  unità di prodotto per ora di lavoro  ore di lavoro in meno rispetto ai normali processi di progetto  ore di lavoro risparmiate attraverso il riutilizzo di componenti preesistenti  numero di idee implementate per il miglioramento dei processi  numero di ore risparmiate grazie al miglioramento dei processi Qualità dei  percentuale di deliverable sottoposta a controllo di qualità deliverable  percentuale di controlli sui deliverable superati al primo passaggio  numero di difetti riscontrati dopo laccettazione iniziale  percentuale di deliverable che soddisfano al 100% i requisiti  numero di modifiche richieste dal cliente  numero di ore di rielaborazione dei deliverable precedentemente completati  numero di best practice applicate  numero di rischi gestiti con successoPiano di collaudo e criteri di validazioneIn un progetto di localizzazione, lindividuazione e la diagnosi di eventuali bug è essenziale così come la mancanza dicollaudi iniziali può rivelarsi fatale. Perciò, anche se si decide di lasciare il collaudo ai localization engineer, sidovrebbe mettere in grado ogni componente del gruppo di progetto di compilare e collaudare lapplicazionelocalizzata per trovare, e in caso risolvere, eventuali problemi.Per questo, lambiente di localizzazione deve contenere tutti gli strumenti che permettano di individuare gli erroriche possano aver causato eventuali bug.Descrivere come affrontare le questioni relative alla validazione legate al collaudo funzionale e il tipo di collaudi daeffettuare con il maggior livello possibile di dettaglio. Specificare le risorse hardware e software, le impostazioni disetup, i requisiti produttivi e i risultati attesi in seguito ai collaudi. Indicare chi ha la responsabilità di correggere glierrori.Fornire le istruzioni per lesecuzione di eventuali script da utilizzare per i collaudi automatici per riprodurre ilcomportamento degli utenti.
  23. 23. Definire il flusso funzionale dellinterfaccia utente del software in modo che i collaudatori non debbano esaminaretutte le funzionalità di ciascun segmento.Affinché il vendor possa installare e gestire una piattaforma di collaudo specifica per il progetto, fornire le seguentiinformazioni:  nomi delle piattaforme su cui gira il prodotto;  eventuali requisiti hardware e software particolari per linstallazione e il collaudo;  nome e versione del compilatore;  compilatori;  driver di prova;  generatori di dati di collaudo;  documentazione di collaudo, riferimenti tecnici;  dimensioni, tipologia e composizione dei dati a supporto dei test di accettazione;  elenco degli errori noti;  livello dei test di internazionalizzazione eseguiti;  istruzioni per la compilazione del prodotto su una macchina "pulita";  elenco di piattaforme, visualizzatori, browser con cui collaudare il software localizzato. Infine, per valutare correttamente i benefici derivanti dal collaudo, fornire istruzioni per laccesso al database di registrazione degli errori.Aspetti della localizzazione per il WebLa localizzazione Web presenta una serie di problemi specifici da affrontare separatamente.Nonostante la localizzazione di documenti HTML sia relativamente semplice, specialmente con laiuto di strumenti ditraduzione che consentono di proteggere i marcatori, è necessario fornire informazioni precise su come individuaree accedere ai contenuti localizzabili allinterno degli script che gli stessi strumenti di traduzione hanno difficoltà atrattare. Indicare come separare interfaccia utente, contenuti ed elementi di codice, e come individuare il codiceper le funzionalità di back-end e quello di governo dellinterfaccia utente, poiché le funzionalità di back-end di unsito producono gli oggetti visibili dallutente e devono quindi essere identiche in tutte le lingue.Fornire indicazioni per ladattamento del codice in funzione della nuova struttura di directory, del charset ecc.Fissare rigorose convenzioni per lassegnazione dei nomi in modo da evitare differenze di comportamento trapiattaforme Windows e Unix e derivate (sensibili alla cassa), e nel modo in cui i server Web trattano le estensionidei file.Fornire informazioni utili allanalisi strutturale del sito/applicazione, relativamente a:  piattaforma;  sistema operativo;  Internet server;  application server;  tecnologie.Fornire istruzioni su come gestire i contenuti dinamici, ossia la parte del sito o dellapplicazione Web che vieneaggiornata di frequente o in base a eventi, spesso archiviata in un database in formati diversi.Infine, dare istruzioni su come gestire parole chiave, tassonomie, elenchi di esclusione e profanity filter.Aspetti della localizzazione per MacUna tipica applicazione Mac non è composta da un solo file eseguibile, ma da una cartella (bundle) contenente, disolito, leseguibile e le relative risorse a supporto organizzate gerarchicamente.I file di risorse relativi a una lingua sono raccolti tutti in una cartella allinterno del bundle contrassegnata dalcodice ISO 639 della lingua seguito dallestensione .lproj.La struttura del bundle permette di aggiungere facilmente una versione localizzata a unapplicazione, aggiungendole necessarie risorse di interfaccia alla cartella Resources.La struttura interna dei bundle è piuttosto simile. Dal punto di vista della localizzazione, gli eseguibili con associatainterfaccia utente devono essere distribuiti in bundle, mentre alcuni contenuti non possono far parte della strutturadi bundle.
  24. 24. Le cartelle .lproj di un bundle contengono gli stessi file, mentre tutte le versioni di un file di risorse devono averelo stesso nome. Una risorsa da non localizzare va nella cartella Resources, non in una .lproj che deve conteneresolo risorse localizzabili.In generale, sono da localizzare i seguenti tipi di file:  InfoPlist.strings contenenti i puntatori (key) dellelenco delle proprietà da localizzare, associati al file Info.plist;  Localizable.strings contenenti le coppie "key" = "value" ("puntatore" = "stringa");  .nib contenenti gli elementi di interfaccia;  Localized.rsrc contenenti solo le risorse localizzabili.Aspetti della localizzazione per LinuxTecnicamente, la localizzazione di FOSS (Free/Open Source software) non è diversa da quella del softwarecommerciale.Il processo di sviluppo del software open source è basato sulliniziativa degli utenti, sparsi un po ovunque nelmondo, che intervengono alloccorrenza spinti dallesigenza per un certo prodotto; sono gli utenti stessi a proporre eimplementare le nuove funzionalità. Il processo risulta aperto e trasparente, con carichi di lavoro distribuiti il piùpossibile e i rilasci sono rapidi e frequenti. Questo rende la localizzazione del software open source un processoininterrotto affidato per lo più allimpegno spontaneo e gratuito dei singoli, ma il risultato sono sorgenticostantemente in divenire.Il sistema operativo GNU/Linux è stratificato in livelli di sottosistemi che operano uno sullaltro. Ogni livello svolgele sue funzioni in base a un certo locale ed è quindi possibile attivare una lingua solo intervenendo su tutti i livelli.Questi si possono rappresentare, dal basso verso lalto, nel modo seguente 1. le librerie C; 2. X Window, lambiente grafico; 3. i toolkit, le librerie "intermedie" che interagiscono con lambiente grafico a basso livello fornendo gli elementi dellinterfaccia grafica; 4. il desktop.Secondo i dettami della "OpenI18N Globalization Specification", la localizzazione della maggior parte dei progettiopen source interessa i messaggi ed è gestita a partire dalle libreria Gettext, che produce due formati di file:  il formato Portable Object (PO): una tabella di testo in cui sono riportate le stringhe da localizzare;  il formato Machine Object (MO): rappresentazione binaria della tabella di stringhe precedente utilizzata dallapplicazione per selezionare a run time le stringhe localizzate.I file .poNel FOSS, GNU gettext è lambiente di traduzione usato in oltre il 90% delle postazioni GNU/Linux.I messaggi contenuti nel codice sorgente non vengono estratti in file di risorse, il che rende possibile eseguirelapplicazione nella lingua predefinita così comè. Lindividuazione e lestrazione dei messaggi localizzati è affidata aGettext che li carica in fase di inizializzazione e che vengono successivamente visualizzati in fase di esecuzione.Gettext estrae i messaggi in file in formato testo contraddistinti dallestensione .po che vengono poi normalmenteinviati ai localizzatori per la traduzione. Di solito, per lavorarli, è necessario un editor Unicode giacché la codificastandard oggi è UTF-8.In questi file le stringhe originali sono contrassegnate dalla chiave msgid e sono racchiuse tra virgolette alte (" "),mentre la relativa traduzione è contrassegnata dalla chiave msgstr ed è ugualmente racchiusa tra virgolette alte(" ").La struttura generale di file .po è la seguente: white-space # translator-comments #. automatic-comments #: reference... #, flag... msgid "stringa non tradotta" msgstr "stringa tradotta" #: reference... #, flag... msgid "stringa non tradotta" msgstr "stringa tradotta"
  25. 25. I commenti sono preceduti dal simbolo # e, laddove questo è seguito da qualche altro carattere speciale, come ilpunto (.) e il punto e virgola (;), i commenti sono stati inseriti automaticamente durante il procedimento diestrazione.Gettext estrae le stringhe da localizzare dal codice sorgente in una tabella che viene quindi combinata con unaltratabella dello stesso tipo contenente le stringhe già tradotte. Le stringhe nuove sono confrontate con quelle esistentiin un Compendium, unaltra tabella di stringhe che costituisce una sorta di memoria di traduzione, contenente lestringhe provenienti da diversi file .po. Ai traduttori spetta tradurre ed effettuare la revisione delle stringhe primache il file .po sia convertito in un file .mo.Nel formato .po, le stringhe "sorgenti" (msgid) sono usate anche come identificatori, secondo un approccioradicalmente diverso da quello usato normalmente nei file di risorse come quelli del Java Resource Bundle o dellapiattaforma .NET, che utilizzano una chiave logica. È per questo che sempre più progetti rinunciano a servirsi diGettext e impiegano formati specifici o quelli della piattaforma Java.I CVSSolitamente lo sviluppo di unapplicazione e la sua localizzazione procedono in parallelo e capita che i file deimessaggi siano continuamente aggiornati con nuove stringhe. Per evitare intoppi nellincorporazione di nuovestringhe negli stessi file .po su cui stanno lavorando i traduttori, si usano i CVS (Concurrent Versions System),sistemi in cui si conserva tutto il codice sorgente di unapplicazione, la documentazione e tutto il restante materialeperché lo si possa aggiornare e controllare con un meccanismo che verifica le modifiche apportate ai file (ASCII)anche da utenti diversi e da punti diversi della rete. Un CVS, quindi, deve essere sempre accessibile. Inoltre, i file sipossono solitamente scaricare liberamente, ma solo alcuni utenti autorizzati possono convalidare le modifiche.In un CVS i file sono disposti in strutture ad albero, con una radice (root) e dei rami che si articolano su più livelli.La radice è il luogo in cui viene condotto lo sviluppo della release successiva a quella in corso, mentre la correzionedegli errori e la manutenzione delle versioni precedenti viene condotta nei rami che si dipartono dalla radice inparallelo con gli altri aggiornamenti.Quella illustrata nella figura seguente è la struttura tipica di un CVS.Quando si usa un CVS, i localizzatori devono mantenere le proprie postazioni in sincrono con il server che ospita ilCVS; questo replica la sua struttura ad albero su tutte le postazioni remote collegate in modo che da queste ilocalizzatori possano trasferirvi il loro lavoro come e quando necessario.Quando si usa un CVS, è necessario fornire e far rispettare indicazioni precise e rigorose che vanno tenutecostantemente aggiornate, a cominciare dalle cartelle in cui sono conservati i file .po e gli account dei localizzatoriper finire con gli strumenti da utilizzare e le regole di validazione e verifica delle traduzioni.Aspetti della localizzazione per palmari e dispositivimobiliSebbene non si tratti semplicemente di versioni ridotte di quello tradizionale, il software per palmari e dispositivimobili presenta difficoltà di localizzazione analoghe a quello "tradizionale" con problemi derivanti in gran partedalle ridotte dimensioni degli schermi che impongono numerose vincoli di progettazione e di disegno dellinterfacciautente e limitazioni nelluso delle icone e nella traduzione delle stringhe. Queste ultime, in particolare, consistononella necessità di mantenersi sintetici ed esaurienti, resa critica allorigine per le stesse ragioni.Tuttavia, lampia diffusione commerciale ha fatto sì che tutti i sistemi operativi per palmari e dispositivi mobilidispongano del supporto Unicode. Inoltre, i principi per linternazionalizzazione sono più o meno gli stessi seguiti per

×