Guida alla realizzazione di un localization kit

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 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.

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.

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

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.

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.

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

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:

 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.

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

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.

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 . 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.);

 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

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).

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;

 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;

 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.

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.

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.

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.

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

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.

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.

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"

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

il software "tradizionale" il che porta a disporre di file di risorse contenenti stringhe ed altri elementidellinterfaccia.Java è in generale il linguaggio di sviluppo preferito per palmari e dispositivi mobili proprio in virtù delle ridottedimensioni dei file e delleccellente supporto alla localizzazione, mentre WML (Wireless Markup Language) è illinguaggio usato per i servizi WAP e XHTML e XML quello per i contenuti. I problemi dunque sorgono solo con gliambienti di sviluppo che si servono di linguaggi e formati specifici.Palm OSLa tecnica più usata per localizzare i database di risorse Palm OS è quella degli overlay attraverso la quale èpossibile intervenire su un modulo software senza bisogno di ricompilare. Ciascun overlay costituisce un databasedistinto con le sue risorse relative a un singolo modulo (il file .prc o database di base) e relativo locale.Le ridotte dimensioni dello schermo causa problemi di troncamento delle stringhe e di ridimensionamento dellefinestre di dialogo e, purtroppo, catturare screenshot dal palmare può rivelarsi particolarmente difficile, per cui si èspesso costretti a ricorrere a emulatori per lo sviluppo e il collaudo.Unapplicazione Palm OS (.prc file) localizzabile si può, realizzare a partire da un .prc base non legato ad alcunlocale, associato a sua volta a un .prc di "overlay" contenente le informazioni relative al locale. Di conseguenza,per realizzare un file .prc localizzabile, occorre dividerlo in più .prc distinti: uno privo di riferimenti ad alcunlocale e tanti altri .prc quanti sono i locale di destinazione.Le risorse vanno organizzate tra più file .xrd contenenti gli elementi correlati al locale come i form. Ciascun file.xrd va quindi compilato (con PalmRC) in modo da avere altrettanti file .trc da collegare (con PRCMerge) perottenere i file .prc finali.In alternativa, è possibile produrre un file .prc non localizzato e un altro localizzato a partire da un unico file .xrdin cui le risorse relative a uno specifico locale siano identificate univocamente. Si dovrà poi filtrare il file .xrd perottenere più file .trc distinti (a .trc non localizzato e uno o più .trc di overlay).Le risorse sono descritte in un file .xrd (XML Resource Description) in codice sorgente indipendente dallapiattaforma. Per intervenire tanto sui marcatori XML quanto sulle finestre di dialogo in modalità grafica si può usareil Resource Editor per Palm OS che permette di operare in modalità drag & drop sui controlli dellinterfaccia utentea partire da un catalogo degli elementi.Il collaudo si può quindi effettuare direttamente sul palmare o tramite un emulatore in dotazione allambiente disviluppo, anche se gli emulatori funzionano su schermi di dimensioni maggiori e possono quindi falsare la resa finale.Inoltre, un emulatore potrebbe non visualizzare correttamente icone e spie varie (quali quella della batteria), e nonpermettere di eseguire alcuni test come quelli relativi allimpiego di accessori, dispositivi (come schede di memoriaaggiuntive, tastiere ecc.), altri programmi o plug-in.EPOC/SymbianDenominato in origine EPOC e progettato appositamente per i dispositivi mobili, il sistema operativo Symbian èdiffusissimo negli apparecchi Nokia, Sony ed Ericsson. A partire dalla versione 6.0, pur rimanendo basato su ROM,prevede anche il supporto Unicode e nuovi importanti componenti, tra cui le tabelle dei locale e diversi font.I file di risorse sono file di testo redatti in un linguaggio specifico della piattaforma Symbian e sono caratterizzatidallestensione .rss e successivamente compilati in formato binario. Questi file si possono localizzare senza bisognodi ricompilare il programma.I sorgenti dei file di risorse prevedono linclusione di un header (con estensione .rh) contenente le informazioninecessarie al launcher dellapplicazione o alla shell di sistema quali il nome del programma, una sua versioneabbreviata, il nome del file dellicona, informazioni opzionali sulle viste, tra cui titoli e icone.Le stringhe da localizzare di solito sono raccolte in file separati contrassegnati dallestensione .rls ciascuna su unasingola riga e contraddistinta dalla parola chiave rls_string, da un identificatore simbolico e dal testo.Per facilitare la localizzazione, il testo dellinterfaccia utente viene solitamente raccolto in un altro header(convenzionalmente contrassegnato con lestensione .loc) a sua volta incluso nel file di risorse. I file .loc sonoquelli inviati ai traduttori.

Termini e definizioniAcceleratore/tasto di scelta rapida Combinazione di tasti utilizzata per accedere alle funzioni dei menu e dei sottomenu rappresentata di solito da un simbolo mnemonico costituito da una sottolineatura sulla riga del menu e che normalmente è accostato alla lettera iniziale della funzione.Bug Errore persistente nel codice o in una routine di un programma che causa un malfunzionamento.Build Compilazione di file di risorse multipli in un unico prodotto finale che può essere eseguito da un computer.Ambiente di compilazione Gli strumenti, i metodi e le procedure utilizzate per la compilazione del software.CASE Computer-Aided Software Engineering; strumenti software utilizzati nello sviluppo del software per lanalisi, la progettazione, la programmazione e la manutenzione; forniscono supporti automatici alla progettazione e alla documentazione delle tradizionali tecniche di programmazione strutturata, nonché un linguaggio simbolico per la descrizione delle parti o dellintero software e la generazione del codice necessario.Charset/Set di caratteri 1. Insieme predefinito di caratteri utilizzato da uno specifico sistema informatico che non si serve di schemi di rappresentazione codificata. 2. Corrispondenza di caratteri tra un sistema di scrittura e un insieme di codici binari.Compilazione Conversione del codice sorgente di un programma in un programma eseguibile.Deliverable Risultato o prodotto tangibile e verificabile di un processo, da raggiungere al completamento di un progetto o di parte di esso.DTP Desktop publishing; software e tecniche utilizzate per impaginare e formattare i documenti e produrre materiale a stampa o fotoriproducibile di alta qualità come i manuali commerciali.Emulatore Dispositivo hardware o software che simula le condizioni di esecuzione di una piattaforma specifica, di un altro dispositivo o di un altro programma e la loro interazione con altri componenti del dispositivo originale.File di risorse File sorgenti contenenti le informazioni da compilare allinterno del programma e le parti di esso mostrate allutente.GUI Graphical User Interface (interfaccia grafica utente); combinazione di menu, finestre, comandi da tastiera, linguaggi di istruzioni e guida in linea che costituiscono le modalità di interazione tra uomo e macchina.Internazionalizzazione La pratica con cui si crea materiale sorgente indipendente dal locale, in virtù della quale tutto il contenuto linguistico e di mercato risiede al di fuori dellapplicazione e le informazioni sono presentate in un formato a cui lutente è abituato; linternazionalizzazione, inoltre, è anche il processo che rende un prodotto localizzabile.Leverage Porzione di materiale traducibile che si può riutilizzare in quanto proveniente da versioni precedenti; rappresentata solitamente con una percentuale.Locale 1. Regione linguistica e geografica internazionale che comprende anche informazioni linguistiche e culturali comuni; il locale si differenzia da una lingua per il fatto la stessa lingua si può parlare in più di un paese.

2. Caratteristiche dellambiente legate allubicazione geografica, alla lingua e a elementi culturali che determinano talune convenzioni culturali e altre quali le regole di ordinamento, il formato della data, dellora e della valuta e la disposizione della tastiera.Materiale collaterale Tutto il materiale destinato alla pubblicazione e gli strumenti mediatici utilizzati da unazienda per la comunicazione.Metriche Sistema di parametri o modalità di stima quantitativa per la valutazione di un processo da sottoporre a misure con relativi processi.Milestone Fase cruciale e identificabile nel completamento di un progetto il cui fallimento potrebbe tradursi in rischi considerevoli; nel project management, una milestone è unattività di durata zero che di solito corrisponde alla fine di un periodo e al soddisfacimento di un importante deliverable.Palmare Dispositivo di dimensioni ridotte che, nella maggior parte dei casi, gli permettono di stare nel palmo della mano e di essere portato ovunque e che dispone di funzioni per archiviare e organizzare informazioni e documenti importanti.QA Quality assurance, assicurazione della qualità; processo per il quale, attraverso controlli in sequenza, si garantisce che il documento o lapplicazione tradotti somiglino il più possibile al documento o allapplicazione originali.Rebuild Ricompilazione del software dopo la traduzione e il ridimensionamento, per la realizzazione della versione localizzata di unapplicazione.Screenshot Immagine elettronica che riporta una particolare schermata di un prodotto software utilizzata nella guida in linea o nella documentazione per spiegare o illustrare allutente una particolare funzione del software.Sim-ship Simultaneous shipment; rilascio simultaneo di un particolare prodotto di tutte le versioni in lingua.Codice sorgente Codice in chiaro che viene compilato per creare un programma.Source file File contenente il codice sorgente utilizzato per la compilazione di un programma eseguibile.Stringa Insieme di caratteri (lettere, numeri, e/o segni di interpunzione) che richiedono una traduzione poiché contenengono il testo dei messaggi di errore, delle etichette dei pulsanti ecc.; le stringhe sono spesso racchiuse tra virgolette singole o doppie.Guida di stile Guida in cui si definisce lo stile da seguire per la traduzione in una certa lingua; può riguardare lo stile di scrittura, luso, la grammatica, la punteggiatura, i caratteri, luso delle maiuscole ecc.Script di test Schemi e istruzioni per il collaudo di un prodotto software (sorgente o localizzato).Interfaccia utente combinazione di menu, finestre, comandi da tastiera, linguaggi di istruzioni e guida in linea che costituiscono le modalità di interazione tra uomo e macchina.Voice-over Voce fuori campo; aggiunta dellaudio ad un video in cui i movimenti delle labbra di chi parla non sono visibili.

BibliografiaApple computer, Localizability Technical NoteApple computer, Inside Mac OS X, Project Builder HelpApple computer, Internationalization Programming TopicsBishop M., How to Build a Successful International Web Site: Designing Web Pages for Multilingual Markets at the National and International Level, The Coriolis Group, 1997, ISBN 15-761-0158-4Carmel E., Global software Teams: Collaborating Across Borders and Time Zones, Prentice Hall, 1999, ISBN 01-392- 4218-XCederqvist et al, Version Management with CVS, Free software Foundation, 2005Deitsch A., Czarnecki D., Java Internationalization, OReilly & Associates, 2001, ISBN 05-960-0019-7Dr. International, Developing International software, Microsoft Press, 2002, ISBN 07-356-1583-7Esselink B., A Practical Guide to Localization, John Benjamins Publishing Co., 2000, ISBN 90-2721-956-7Kano N., Developing International software for Windows 95 and Windows NT, Microsoft Press, 1995, ISBN 15-561- 5840-8Kaplan M. S., Internationalization With Visual Basic, Sams, 2000, ISBN 06-723-1977-2Luong T. V., Lok J. S. H., Driscoll K., Internationalization: Developing software For Global Markets, John Wiley & Sons, 1995, ISBN 04-710-7661-9Madell T., Parsons C., Abegg J., Developing and Localizing International software, Prentice Hall, 1994, ISBN 01-330- 0674-3Maxwell Chandler H., The Game Localization Handbook, Charles River Media, 2004, ISBN 1-58450-343-2OConner J., Internationalization Using the Java Platform, Addison-Wesley, 2002, ISBN 02-016-1568-1ODonnell S. M., Programming for the World: A Guide to Internationalization, Prentice Hall, 1994, ISBN 01-372-2190- 8Ott C., Global Solutions for Multilingual Applications: Real-World Techniques for Developers and Designers, John Wiley & Sons, 1999, ISBN 04-713-4827-9Sasikumar M., Aparna R., Naveen K., Rajendra Prasad M., Free/Open Source software Guide to Localization, UNDP- APDIP, 2005Schmitt D. A., International Programming for Microsoft Windows, Microsoft Press, 2000, ISBN 15-723-1956-9Symmonds N., Internationalization and Localization Using Microsoft .Net, APress, 2002, ISBN 15-905-9002-3Taylor D., Global software: Developing Applications for the International Market, Springer Verlag, 1992, ISBN 03- 879-7706-6Uren E., Howard R., Perinotti T., Software Internationalization and Localization, TGP Consulting, 1993, ISBN 04- 420-1498-8

AppendiceGuida alla localizzazione di <nome prodotto>AvvertenzaAlla consegna, ogni lavoro deve essere pienamente conforme a quanto di seguito specificato. Eventuali nonconformità potranno condurre a riduzioni del compenso o a interventi migliorativi, fino allesclusione dal databasedei nostri collaboratori.Introduzione<nome prodotto> si compone dei seguenti elementi da localizzare: 1. interfaccia utente; 2. database locale Microsoft Access; 3. script di Microsoft SQL Server; 4. schermate; 5. guida utente; 6. guida in linea. La localizzazione andrà eseguita in questordine. Il CD contiene tutti i file necessari archiviati nella cartella Source.RequisitiPer localizzare il <nome prodotto>, sono necessari i seguenti strumenti software e hardware:  <nome prodotto>;  il dongle del <nome prodotto>;  Microsoft Access 97 o superiore;  Crystal Report 9 o superiore;  Microsoft Word;  uno strumento per la gestione di memorie di traduzione come Trados;  uno strumento grafico per catturare le schermate come GIMP.Prima di dare avvio ai lavori, verificare di: 1. aver istallato una versione localizzata del <nome prodotto> con il suo dongle; 2. essersi esercitati per qualche ora nelluso del software.Interfaccia utenteLinterfaccia utente andrà localizzata per prima, anche se è forse lelemento più complesso da localizzare.StrumentoPer localizzare linterfaccia utente si dovrà utilizzare <nome srumento> che si trova nella cartella Tool<nomestrumento>Program nel CD. Per listallazione, lavvio e la configurazione di <nome strumento> e per istruzioni sucome lavorare con i file fare riferimento al relativo manuale utente nella cartella Tool<nomestrumento>Manual nel CD.RisorseLe risorse per linterfaccia utente si trovano nella cartella SourceResources<639> nel CD, in cui <639> è ilcodice linguistico a due caratteri stabilito dalla norma ISO 639. Copiare la cartella con i file da elaborare sul discorigido locale. Cliccare con il tasto destro del mouse sul proprio disco rigido, selezionare Proprietà e rimuoverelopzione di sola lettura della cartella, della sottocartella e dei file.

Localizzazione dei formI form saranno i primi ad essere localizzati. Fare riferimento al manuale utente di <nome strumento> nella cartellaTool<nome strumento>Manual nel CD per avere istruzioni sullutilizzo di <nome strumento>.[A seguire, le istruzioni su come localizzare i form]Disegno dellinterfaccia utenteSe una stringa appare incompleta nel form una volta tradotta, provare a spostare o a ridimensionare gli elementidirettamente dallinterno del form.RegoleNon tutte le proprietà e le finestre vanno tradotte.Non tradurre[A seguire, lelenco degli elementi e dei valori da non tradurre]Tasti di scelta rapidaAssegnare il carattere & alla lettera appropriata per indicare il tasto di scelta rapida. &Salva, ad esempio, significache premendo Alt+S si attiva questa voce di menu. Assicurarsi che lo stesso tasto di attivazione non sia statoassegnato a più di un elemento nello stesso menu.RaccomandazioniSalvare prima di cominciare a lavorare su una nuova finestra o un nuovo form.Script di risorseDopo aver completato la localizzazione dei form, localizzare le stringhe di risorse. Alcune non provengono da <nomeprodotto> ma dai componenti utilizzati. Localizzare soltanto le stringhe di <nome prodotto> che si possonoindividuare dalletichetta "<nome etichetta>".VariabiliAlcune stringhe possono contenere delle variabili come %s, %0:s, %1:s che vengono sostituite da altro testo durantelesecuzione del programma e, affinché questo funzioni in modo appropriato, dovranno essere comprese nellatraduzione. Tuttavia, se ne può cambiare lordine riformulando la frase.RaccomandazioniAssicurarsi che le traduzioni siano incluse sempre tra virgolette singole.Non dimenticarsi di salvare regolarmente.ConsegnaDopo aver terminato la traduzione dellinterfaccia utente, zippare la cartella <639> sul disco locale con tutte lesottocartelle assicurandosi di aver lasciato inalterata la struttura della cartella e inviare il file a <nome cliente>.RicompilazioneLa ricompilazione sarà effettuata da <nome cliente> con le risorse tradotte per produrre la versione localizzata,conducendo anche alcuni test per verificare che il programma funzioni.Una volta completati questi test, sarà possibile scaricare una nuova versione del software per condurre ulterioritest.

Database locale Microsoft AccessCreazioneCopiare il database locale Microsoft Access dalla cartella SourceDatabaseAccess<639> del CD, sul discolocale. Rimuovere le proprietà di sola lettura da questo file.AperturaAvviare <nome prodotto> nella lingua di destinazione per aprire il database locale Microsoft Access e tradurne icontenuti. Allapertura del database con qualsiasi versione di Microsoft Access, il programma richiederà unapassword. La password per il database è contenuta nel file dbpwd.dat nella cartellaSourceDatabaseAccess<639> nel CD. Se si apre il database con Microsoft Access 2000 o superiore, nonconvertirlo: il software potrebbe non funzionare più correttamente.Test linguisticoPartendo dal modulo di installazione, lanciare i moduli ad uno ad uno e verificare che non ci siano dati oltre quellinella lingua di destinazione. Qualora ve ne fossero, tradurli prima di condurre il test di funzionalità.Durante la traduzione del database, controllare che il testo in ogni modulo sia corretto e adattato. Per segnalareeventuali modifiche da apportare allinterfaccia utente servirsi del foglio delle domande sulla terminologia.ConsegnaDopo aver completato la traduzione del database locale di Microsoft Access zippare la cartellaSourceDatabaseAccess<639> sul disco locale e inviare il file a <nome cliente>.Script SQL ServerTutti gli script sono contenuti nei file RTF allinterno della cartella SourceDatabaseAccess<639> nel CD.Copiare la cartella sul disco locale. Rimuovere la proprietà di sola lettura da ogni file.Aprire i file con Microsoft Word e, dove possibile, tradurli con TRADOS che consente di visualizzare soltanto il testoda tradurre. Questo sarà di colore nero, mentre il testo che non deve essere tradotto sarà grigio.ConsegnaDopo aver completato la traduzione degli script del database di Microsoft SQL Server, zippare la cartellaRisorseDatabaseSQL_Server<639> sul disco locale e inviare il file a <nome cliente>.ScreenshotI manuali di <nome prodotto> contengono molti riferimenti al software attraverso gli screenshot. Raccogliere tuttigli screenshot prima di iniziare la traduzione dei manuali. Gli screenshot (circa 400) sono archiviati nella cartellaSourceDocumentationScreenshots nel CD. Prendere gli screenshot solo nel locale di destinazione, dopo avercompletato la localizzazione dellinterfaccia utente. Le schermate devo avere la stessa dimensione delle originali, anon più di 16 bit (65K) di profondità colore. Archiviare le nuove immagini nella cartellaSourceDocumentationScreenshots<639> nel disco locale.ConsegnaDopo aver terminato, zippare la cartella SourceDocumentationScreenshots<639> sul disco locale e inviareil file a <nome cliente>.Manuale utenteIl manuale utente si trova nella cartella SourceDocumentationUser_manual<639> nel CD. Copiare la cartellasul disco locale. Rimuovere la proprietà di sola lettura dal file usrman<639>.doc e aprirlo con Microsoft Word.Attivare lopzione di visualizzazione dei codici di campo e cercare la stringa"D://<product_code_name>//<version>//User_manual//Graphics//" per sostituirla con il percorso dei nuoviscreenshot.Disattivare lopzione di visualizzazione dei codici di campo per verificare che nel manuale appaiano i nuoviscreenshot.

Iniziare a tradurre il documento con uno strumento di traduzione che consenta di salvare una memoria di traduzioneper le future versioni del prodotto, rispettando lo stile e la formattazione del documento originale. Salvare lamemoria di traduzione nella stessa cartella del manuale.Una versione compilata (in formato PDF) del manuale è disponibile nella cartellaSourceDocumentationUser_manualEn nel CD.ConsegnaA lavoro ultimato, zippare la cartella SourceDocumentationUser_manual<639> sul disco locale e inviare ilfile a <nome cliente>.Guida in lineaI file di risorse per la guida in linea si trovano nella cartella SourceDocumentationOnline_help<639> nelCD. Tradurre entrambi i file con uno strumento di traduzione, utilizzando lo stesso database del manuale utente.I file della guida in linea sono entrambi in formato standard per Windows. Una versione compilata è disponibile nellacartella SourceDocumentationOnline_helpEn nel CDNote a pie di paginaUn file della guida in linea ha tre tipi di note a pie di pagina:  $, titolo (Non tradurre)  #, ID argomento (Non tradurre)  K, keyword (da tradurre)La nota delle keyword può essere estesa o ridotta.Collegamenti graficiCollegamenti grafici come {bmc graphicsfloating_menu.bmp} non vanno tradotti. Il compilatore della guida liriconoscerà e in fase di compilazione vi collegherà limmagine corrispondente.Topic jumpIl topic jump permette al lettore di cliccare su un collegamento ed essere reindirizzato al capitolo in cui vienetrattato largomento correlato. Un topic jump ha due componenti. La prima parte, in verde, con sottolineaturadoppia, viene visualizzata dal lettore e deve essere tradotta. La seconda parte è un testo nascosto e non vatradotto. Non lasciare mai spazi tra la prima e la seconda parte di un topic jump.SommarioQuando si apre un file della guida in linea, il lettore si troverà davanti il sommario che è archiviato in un fileseparato con estensione .cnt. Si tratta di un file di testo che si può lavorare con uno strumento di traduzione.La prima riga di un file .cnt dovrà essere modificata in modo da mostrare il nome del file della guida; sulla secondariga andrà tradotto solo il testo dopo "Title". Nelle righe successive non modificare il numero iniziale, tradurre iltesto precedente il simbolo = e lasciare inalterata la seconda parte.ConsegnaA lavoro ultimato, zippare la cartella SourceDocumentationOnline_help<639> sul disco locale e inviare ilfile a <nome cliente>.Piano di consegna Data di Nome del documento Data di scadenza Consegnare a inizioInterfaccia utente 7/11/2005 21/11/2005 (14:00 george.brown@l10nco.com GMT) (inviare in copia a

Data di Nome del documento Data di scadenza Consegnare a inizio john.smith@l10nco.com)Database locale Microsoft 21/11/2005 23/11/2005 (14:00Access GMT)Script SQL Server 23/11/2005 24/11/2005 (14:00 GMT)Screenshot 24/11/2005 25/11/2005 (14:00 GMT)Manuale utente 25/11/2005 09/12/05 (14:00 GMT)Guida in linea 9/12/2005 19/12/05 (14:00 GMT)Istruzioni per il download e lupload dei file da e sul server FTP diL10NCo.Per scaricare o caricare i file di progetto da o sul nostro server FTP, servirsi di un normale client FTP, utilizzando iseguenti paramentri: Hostname ftp.l10nco.com Username vendor Password l10nco Percorso di download to_l10nco Percorso di upload from_l10ncoNota: una volta allinterno della directory di download (from_l10nco) saranno visibili i nomi dei file che, invece,non saranno visibili nella directory di upload (a_l10nco).SupportoTutte le comunicazioni di progetto dovranno essere redatte in lingua inglese, così da poter essere eventualmenteinoltrate a tutti i membri del team. Problemi tecnici l10nco Supporto tecnico L10NCo. (techsupp@l10nco.com) Problemi linguistici George Brown (george.brown@l10nco.com) Problemi di pianificazione e di onorario John Smith (john.smith@l10nco.com) Problemi di DTP e di sviluppo Mary Jones (mary.jones@l10nco.com)

Guida alla realizzazione di un localization kit

by Luigi Muzii on May 07, 2011

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Guida alla realizzazione di un localization kit Document Transcript