Guida alla realizzazione di un

localization kit Luigi Muzii

Avvertenze Le informazioni contenute in questa guida sono fornite senza garanzie di alcun tipo e non comportano alcun obbligo da parte dell'autore o dell'editore. L'autore e l'editore non si assumono nessuna responsabilità, diretta o indiretta, per questa guida o parte di essa, o su qualsiasi altro materiale supplementare successivamente pubblicato dall'autore. L'autore ha fatto il possibile per garantire accuratezza, correttezza e affidabilità delle informazioni contenute 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 comporti l'obbligo 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 o integralmente 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.

Introduzione

Destinatari Questa guida affronta un problema che affligge da sempre localization manager, localization vendor e project manager, ed è fruibile sia dai lettori con una certa esperienza nell'industria della localizzazione, sia dai neofiti. Non ha, tuttavia, l'ambizione di essere conclusiva, ma solo di offrire ai lettori alcune indicazioni utili per predisporre e aggiornare un localization kit in modo da agevolarne il lavoro.

Basterà, inoltre, fare astrazione delle sezioni specificatamente dedicate alla localizazione per ricavarne istruzioni utili 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 introduttive Quanto più si riesce a tracciare i requisiti e a comprendere le esigenze del cliente, tanto più sarà possibile soddisfarlo. Un localization kit è una raccolta di strumenti, istruzioni e risorse necessarie per localizzare un prodotto software.

Se completo e ben progettato, il kit consentirà a localizzatori, collaudatori e sviluppatori di portare a buon fine, in modo adeguato, un progetto di localizzazione.

Per rispettare le esigenze di time to market e favorire utili sinergie fra sviluppatori e traduttori è necessario che il lavoro di traduzione del software inizi il prima possibile; un localization kit consentirà ai traduttori di lavorare in modo più indipendente, verificando il proprio lavoro in corso d'opera.

La qualità finale e il successo di un progetto di localizzazione dipendono dalla quantità di conoscenze trasmesse al localization vendor; queste conoscenze riguardano:

l'affidabilità dei processi di preventivazione e pianificazione;

il tempo necessario ai project manager e ai tecnici;

l'accuratezza dei deliverable di progetto.

Un buon localization kit costituisce una soluzione relativamente semplice a questi problemi in quanto consente ai localization vendor di verificae che dispongano di tutto il necessario per svolgere il proprio lavoro in modo efficiente.

Anche se impegnativa, la preparazione di un localization kit e di una guida alla localizzazione per un determinato prodotto è un'operazione una tantum che offre vantaggi duraturi ed è di enorme aiuto a tutte le parti coinvolte in un progetto, raccogliendone tutti gli elementi essenziali ed esponendone requisiti e attese.

A cosa serve un localization kit Scrivere il codice tenendo conto delle esigenze di localizzazione permette agli sviluppatori di coinvolgere i localization 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 un'offerta (pianificazione, quotazione e programmazione) relativa alla localizzazione di un prodotto;

2. l'esecuzione 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.

L'ideale sarebbe sviluppare delle linee guida e una checklist per lo sviluppo del localization kit, così che questo possa mantenere una sua coerenza interna, a prescindere dal responsabile o dal prodotto. Ciò agevolerà la preparazione di un kit di alta qualità, eviterà laboriose rielaborazioni e migliorerà l'efficienza e la scalabilità dei processi di localizzazione. Inoltre, nel caso di un rapporto a lungo termine con un localization partner, consente di ridurre le tempistiche per la realizzazione di offerte e programmi di localizzazione, permettendo un più rapido avvio dei progetti.

Teoricamente, la realizzazione del localization kit dovrebbe seguire il rilascio del codice della versione principale del 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 del localization 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 un'offerta, l'azienda proponente è in grado di condurre un'attenta analisi del progetto e valutarne correttamente dimensioni, costi e durata. Il localization kit può, quindi, essere utilizzato in fase di avvio del progetto, avendone chiari obiettivi e requisiti.

Il kit, inoltre, può essere utilizzato per garantire che il materiale di ritorno sia il più completo possibile e di immediato 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 ad albero 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 e permettere a chiunque, all'interno della società, di assumere facilmente la responsabilità di gestire un progetto, disponendo, da subito, delle informazioni necessarie per un'analisi o per il suo avvio.

Struttura di un localization kit Un localization kit va preparato nelle fasi preliminari e durante l'implementazione in modo da poter condurre valutare e analizzare il progetto avendo sempre presente l'esigenza di evitare sorprese quali il mancato rispetto di una scadenza o lo sforamento del budget. Inoltre, poiché la maggior parte dei progetti di localizzazione software coinvolge un ampio numero di lingue di destinazione, disporre di un kit adeguato fin dall'avvio del progetto consentirà 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 dall'avvio del progetto, in modo da rudurre al minimo il rischio di problemi in seguito.

Tipicamente, la versione localizzata di un prodotto contiene soltanto gli elementi traducibili, le configurazioni del locale 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 realizzare la versione localizzata di un prodotto software senza assistenza da parte del gruppo di sviluppo originale. I vendor dovrebbero essere in grado di utilizzare il kit per la traduzione, l'integrazione e la verifica delle risorse, senza alcuna assistenza da parte del gruppo di sviluppo, e se il codice è predisposto per la localizzazione, è improbabile che 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 file binari e i file di risorse), oltre che le istruzioni, le linee guida, i suggerimenti e le annotazioni che gli sviluppatori mettono a disposizione dei membri del gruppo di progetto perché possano gestire adeguatamente i vari file e i vari tipi 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 kit In genere, la prassi corretta consiste nell' organizzare centralmente i file, poiché tutte le operazioni su ad essi devono essere ripetute tante volte quante sono le lingue in cui si devono localizzare. Una struttura ad albero ben fatta consentirà al vendor di risolvere in modo efficace eventuali problemi dovuti a rimandi non funzionanti, file mancanti 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 dati relativi all'ubicazione e alle proprietà di ciascun file, dopo la prima build. In questo senso può essere d'aiuto uno strumento CASE (Computer Aided Software Engineering) e il file di cui sopra può diventare la base per una distinta dei 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 distinta che riporti tutti i componenti. Spesso, qualche componente non è disponibile nella fase iniziale, quando il kit viene preparato per l'analisi e le richieste di offerta, ma lo sarà per l'avvio del progetto. Qualora si preveda di non poter inserire 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 localizzazione dovrebbero fornire un proprio input.

Utenti di un localization kit Sono molti gli attori all'interno del processo di localizzazione: localization manager, collaudatori, localizzatori e sviluppatori. Il localization manager segue il progetto e ne coordina attività, collaudatori e localization engineer effettuano i collaudi e modificano il codice sorgente per renderlo localizzabile, interfacciandosi con il localization manager 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 localization kit.

Anche collaudatori e sviluppatori necessitano di informazioni in merito ai file. Fornire specifiche di collaudo ai collaudatori insieme a una panoramica del progetto può garantire che i test siano condotti in modo approfondito.

Responsabili di progetto Per ottenere un piano di progetto efficace, i responsabili del progetto di localizzazione, devono poter disporre di stime sui volumi di testo, materiale grafico, video e audio da localizzare prima dell'assemblaggio 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.

Localizzatori I localizzatori vorranno sapere quali sono i file da localizzare, i loro destinatari e, nella maggioranza dei casi, le cose da non modificare in ciascun file, ma ovviamente saranno interessati anche al conteggio sommario delle parole e al numero di parole in ciascun file e apprezzeranno ogni informazione, istruzione o commento sulle stringhe da localizzare e le relative caratteristiche.

Il testo, poi, deve essere definitivo.

Localization engineer Ai localization engineer vanno fornite istruzioni sulle modifiche da apportare al codice perché possa funzionare al meglio nel locale di destinazione. Per loro, inoltre, sono importanti l'hardware e il software necessari per la comipilazione, nonché le procedure e le istruzioni per la compilazione e il collaudo. Per poter effettuare eventuali interventi "cosmetici" sulle finestre di dialogo, le istruzioni per i test dovranno prevedere informazioni sulla versione del 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 localization engineer dovrebbero poter disporre di file batch per la configurazione automatica dei parametri di sistema e di compilazione per tutte le lingue. Questi file vanno collocati in un'apposita cartella.

Tutto il codice, infine, deve essere stabile a sufficienza per essere sottoposto a collaudo.

Realizzazione di un localization kit Un localization kit aiuta a rispettare le scadenze poste dal cliente e a raggiungere gli obiettivi di qualità e di servizio, esplicitando le attese e favorendo la comunicazione e l'organizzazione del progetto. Prima di procedere alla localizzazione, i prodotti da localizzare dovrebbero essere sottoposti a un test di internazionalizzazione, in modo 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 all'Internet e per l'acquisto del dominio nel caso di siti o applicazioni Web);

obblighi normativi (p. es. legislazione per la protezione dei dati e diritti d'autore).

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 dell'invio al

localization vendor; 5. sottoporre le bozze del kit ai localization vendor, perché pongano domande e avanzino suggerimenti prima

dell'invio della versione finale; 6. una volta concluso il progetto, condurre una revisione post-mortem per i progetti futuri.

Nell'aggiungere successivamente nuovi contenuti, conviene organizzarli come in un "mini" localization kit allegato a quello principale: un insieme di risorse, strumenti, documenti e codici che permettano di evitare di riorganizzare il kit 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' incertezza dei requisiti iniziali, molti problemi potranno essere risolti solo nel quadro di una corretta interazione fra cliente e fornitore. Per questo, appena il kit è pronto, è utile estrarne le parti descrittive e raccoglierle in un manualetto da distribuire al kick-off. Inoltre, può essere utile realizzare un sito web per il kit attraverso il quale mettere a disposizione in tempo reale tutto il materiale di progetto, e magari le informazioni post mortem, in particolare i problemi irrisolti e quelli risolti con le relative soluzioni.

Contenuto di un localization kit Gli attuali prodotti software sono composti da varie categorie di oggetti che devono essere archiviati per i rilasci successivi, per il porting su piattaforme differenti e per creare versioni speciali per i produttori di componenti hardware (OEM, Original Equipment Manufacturer), che possono essere pre-installate sui computer o vendute insieme ai componenti hardware.

Questi oggetti saranno riutilizzati anche per lo sviluppo di eventuali patch che dovranno successivamente integrare le raccolte.

La gestione di questi processi richiede un localization kit. Ogni cliente, poi, ha le sue esigenze, le sue scadenze, i suoi deliverable e le sue componenti. Di conseguenza, i localization kit differiscono non solo da un'azienda all'altra, ma anche da un progetto all'altro. 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 poter meglio comprendere le attese del cliente oltre che la natura e le dimensioni del progetto.

Per rilasciare un'applicazione, è necessario essere in possesso di tutte le risorse e di tutti i file di codice, che verranno compilati in un file binario o eseguibile, che potrà essere eseguito su un computer. Per questo, un localization 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 l'icona della stampante che permette di eseguire il comando di stampa. In molti casi, queste risorse non vanno modificate nelle versioni localizzate. Le informazioni traducibili, come i testi dei menu, le opzioni nelle finestre di dialogo e i messaggi 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. I localization engineer dovrebbero assicurarsi che i traduttori sappiano esattamente quali sono le operazioni da svolgere, 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à all'interno 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 di localizzazione, un localization kit dovrà essere provvisto di:

un diagramma di flusso dell'interfaccia 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 d'uso, 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 etichettatura del 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 sufficientemente dettagliata, il kit risulterà di difficile utilizzo e il tempo speso per rispondere ai vari quesiti e ripristinare le informazioni o le risorse mancanti si tradurrà in una spesa non preventivata e, quindi, inaccettabile.

Gestione del progetto Il localization kit dovrebbe essere diviso in due sezioni, specificamente costruite dal gruppo di progetto, secondo un'articolata struttura a cartelle, anche se le future versioni dei più comuni sistemi operativi avranno caratteristiche di 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 specifica dedicata proprio al progetto.

Ogni localization kit dovrà includere una lettera d'incarico che dovrà essere firmata da tutti i componenti del team di localizzazione e potrà eventualmente fungere anche da contratto tra le parti. La lettera d'incarico dovrà includere tutte le quotazioni raggruppate per componente, gli accordi sulla gestione delle modifiche, gli obiettivi intermedi 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 il relativo materiale di riferimento.

Descrizione dei lavori (SoW) Lo scopo del documento di descrizione dei lavori (SoW, Statement of Work) è quello di definire nel dettaglio i requisiti di lavoro, ovvero "ciò che va fatto" durante il progetto. Questo documento sarà il capitolato per l'aggiudicazione della commessa e, una volta divenuto specifica contrattuale, potrà essere utilizzato come riferimento per determinare se i fornitori soddisfino o meno i requisiti di prestazione prestabiliti. Il documento servirà, inoltre, al responsabile di progetto per quantificare l'impegno richiesto attraverso una WBS (Work Breakdown 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 dell'architettura 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 dell'intero 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 dell'ordine; 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 e il risultato dell'analisi dei file di log. Ciascun file di log deve riportare il numero di parole ripetute e non tradotte, l'eventuale memoria di traduzione, il numero di full match e di fuzzy match e di segmenti ricorrenti. Per quanto possibile, è utile disporre di una mappa che permetta di individuare gli elementi riutilizzabili e il modo in cui trarne vantaggio.

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 di riprodurre tutte le statistiche e applicare adeguatamente le memorie di traduzione.

Queste impostazioni andrebbero usate anche per produrre le statistiche per gli stati d'avanzamento e i diagrammi con 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 la rintracciabilità degli aggiornamenti ed essere corredato da una dettagliata distinta dei materiali (BoM) che dovrà includere:

un elenco dei file da localizzare, raggruppati per tipo;

un'immagine 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)

Nome file Tipo file Funzione Conteggio

parole Percorso Note e istruzioni

default.asp Script lato server (VBScript)

Pagina di inizio navigazione

30 directory principale Riga 37: la variabile

strRedirect non deve superare i 75 caratteri Riga 271: non localizzare

la variabile strLang

content.asp Script lato server (VBScript)

Pagina contenitore

1,830 directory principale Riga 58: Localizzatori spagnoli: utilizzare terminologia differente per i mercati spagnolo e messicano

style.css Foglio di stile (CSS2)

Gestisce la visualizzazione dei contenuti

\Style Riga 10: cambiare i caratteri Times New 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 semplice

file include 10,000 \Includes\En\Messages Stringhe di testo visualizzate nelle finestre di messaggio per segnalare un errore.

Materiale di riferimento Il 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 l'indicazione 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

file Percorso Problema Commenti Altro Nome Problema

risolto

main.rc menu principale

Linguistico Dopo una revisione accurata, alcuni oggetti 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 (Si/No)

Nome del file

Pagina Termine/Problema Contesto Termine (lingua di

destinazione) Risposta

Esempio di stato di avanzamento

Nome del file Conteggio

parole

Parole da

tradurre

Avanzamento %1

Risorse2 Produttività3 Giorni

correnti4 Data di inizio

Data di fine

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à)]

Software Nello sviluppare un localization kit, il responsabile del progetto di localizzazione dovrà definire gli elementi che potrebbero essere culturalmente rilevanti e decidere se renderli culturalmente neutri o isolarli per la localizzazione. L'isolamento si ottiene trasferendo ogni riferimento culturale in un file di risorse e sostituendoli con una routine per la ricerca delle informazioni appropriate nel file di risorse. Se è necessario l'isolamento, il responsabile 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 poter disporre della terminologia atta a garantire una generale coerenza terminologica. Per questa ragione, al momento di raccogliere 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 di traduzione.

Prima di iniziare la localizzazione vera e propria, il responsabile del progetto di localizzazione dovrà garantire che il testo originale sia chiaro e conciso, grammaticalmente corretto e privo di espressioni gergali, anche tecniche, che possano essere causa di errori nella traduzione. Dovrà, inoltre, verificare la coerenza linguistica e dei riferimenti, oltre che l'integrità e la correttezza della memoria di traduzione.

Oltre alle risorse pronte per la traduzione, il localization kit dovrà contenere anche una versione eseguibile del software (come riferimento e per aiutare il traduttore a familiarizzare col prodotto), nonché l'intero ambiente di sviluppo, 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 per il software tradizionale e per quello Internet.

Inoltre, i localizzatori dovrebbero poter consultare i risultati di un eventuale progetto pilota per potervi rintracciare quegli elementi eventualmente tralasciati in fase di internazionalizzazione. A questo scopo può risultare utilissimo un elenco dei problemi di internazionalizzazione noti.

Software tradizionale Per "tradizionale" si intendono i programmi statici per computer da tavolo, portatili o tascabili, in opposizione alle applicazioni Internet. La sezione relativa al software tradizionale dovrà comprendere:

una copia dell'applicazione 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 dell'ambiente di sviluppo completo per il collaudo;

script di test;

gli strumenti proprietari e personalizzati utilizzati per la compilazione e il collaudo.

Software Internet Un sito o un'applicazione Web sono sostanzialmente differenti da un'applicazione software "tradizionale" statica, e difficilmente si possono localizzare in "modalità sicura" (vale a dire lavorando soltanto su binari, script di risorse o file di stringhe). Nella maggior parte dei casi, i localizzatori devono essere in grado di accedere ai file di risorse per poter replicare il sito o l'applicazione e, possibilmente, predisporre un test bed.

Per questo, la prima preoccupazione del responsabile di un progetto di localizzazione Web dovrebbe essere quella di proteggere il codice da modifiche accidentali e di organizzare un language pack. Se il prodotto è stato internazionalizzato correttamente, tutte le stringhe da tradurre dovranno essere estratte dal codice e il language pack sarà composto essenzialmente dalle tabelle di stringhe e dai file delle immagini per ciascuna lingua. I traduttori 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 negli

script lato server con un'istruzione <!-- # include file/virtual="percorsorelativo/nomefile"-->. Ogni modulo 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 dell'interfaccia 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 l'applicazione associata (p. es. Adobe Photoshop per i file .psd, Microsoft Access per

i file .mdb e Macromedia ColdFusion per i file .cfm).

Documentazione e guida in linea Una volta portata a termine anche la revisione della versione localizzata del software, i localization engineer dovranno reimportarla in uno strumento di traduzione e creare un glossario che contenga tutti gli elementi dell'interfaccia 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 nuovo glossario. 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 finale perfettamente impaginato; dovrebbe inoltre essere fornita anche una copia cartacea di tutti i documenti da tradurre.

I file facenti parte del localization kit dovranno esservi inseriti secondo una rigorosa struttura di directory. Si

potrebbe creare, per esempio, una cartella Documentation con due sottocartelle Product documentation e

Project 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 in formato "tagged" per il trattamento con strumenti di traduzione. Se è richiesta una versione tipografica, la cartella

User 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 l'assegnazione dei nomi, è bene stabilirne una per 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 distinta dei 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 copia del compilatore.

I file grafici della guida in linea potranno anche essere archiviati in una speciale sottocartella Graphics, all'interno

della cartella On-line help o in una sottocartella On-line help, all'interno di una più generica cartella

Graphics del localization kit.

La cartella Project documentation potrà contenere le direttive di progetto, la guida di stile con tutte le convenzioni stilistiche, tipografiche e per l'assegnazione dei nomi e tutti i template, nonché, se possibile, la guida di stile utilizzata dai redattori tecnici per i file sorgente. Peraltro, tramite opportune modifiche agli stili contenuti nei template, sarà possibile individuare e risolvere eventuali problemi di localizzazione prima dell'avvio dei lavori.

La cartella Project documentation potrà inoltre contenere la guida alla localizzazione con le regole per l'assegnazione dei nomi, le linee guida per la preparazione dei documenti, qualora se ne debbano creare copie diverse per ogni lingua o locale, la versione del driver della stampante e il file con la descrizione della stampante da utilizzare, le linee guida e le istruzioni per l'espansione del testo. Qualora vengano utilizzati font speciali, la guida alla localizzazione dovrà anche specificarne i dettagli. Infine, la guida alla localizzazione fornirà le istruzioni per il DTP e la versione del compilatore e per i test della guida in linea, con specificazione delle piattaforme, dei sistemi operativi, dei browser e delle relative versioni.

La cartella Project documentation potrà infine contenere un foglio elettronico con la distinta dei materiali elencante i nomi e il tipo dei file e una breve spiegazione della funzione di ciascuno di essi, e le annotazioni aggiuntive, compresi eventuali font speciali.

File grafici Le cartelle User documentation e On-line help potranno contenere ciascuna una sottocartella Graphics

opppure 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 per quelli non modificabili.

Quando si crea un'immagine 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 con le stringhe da tradurre nella stessa cartella di lavoro contenente il foglio relativo alla documentazione per

reimportarvele dopo la localizzazione. Questo foglio di lavoro potrà essere archiviato nella sottocartella Project

documentation, all'interno della cartella Documentation.

La stessa cartella di lavoro potrà contenere un foglio elettronico con le informazioni relative alle immagini richieste ordinate 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 l'espansione del testo e i simboli "riservati", insieme a eventuali informazioni su forme alternative.

Esempio di elenco di file grafici per una distinta dei materiali

Nome file Tipo file Funzione Testo da tradurre

Conteggio parole

Percorso Note e

istruzioni

intro.bmp BMP, 8-bit, nessuna compressione

Immagine visutalizzata all'avvio del programma

Premere un tasto per continuare...

5 \Graphics\Final\Main Usare Arial 24 grassetto per il testo; colore del testo #FF9900

Esempio di elenco di file grafici per una distinta dei materiali

Nome file Tipo file Funzione Testo da tradurre

Conteggio parole

Percorso Note e

istruzioni

back_off.jp

g JPEG, compressione 25%

Immagine di sfondo per la pagina di benvenuto del sito internet (back office)

\Graphics\Final\Main Collegamento in

default.asp. è un'immagine molto difficile da riprodurre. Se si dimostrasse non adatta al vostro locale, riempire il relativo spazio con un'immagine vuota.

scr01_en.gi

f Standard GIF, 256 colori

Schermata del menu principale

\Graphics\Final\Screensho

ts Ogni schermata dell'interfaccia utente deve essere riprodotta a localizzazione avvenuta. Accertarsi di avere qualche record valido nel database per ottenere un'immagine significativa. Utilizzare Windows XP, Fedora Red Hat o Mac OS X per realizzare le schermate.

workflow.gi

f Standard GIF, 256 colori

Diagramma di flusso che fornisce un quadro generale del processo di produzione

Vedere le etichette di testo nel file sorgente

155 \Graphics\Final\Artwork Collegamento in workflow.as

p. Il sorgente di questa immagine è workflow.xc

f (vedi sotto), realizzato con GIMP (GNU Image Manipulation

Program).

Esempio di elenco di file grafici per una distinta dei materiali

Nome file Tipo file Funzione Testo da tradurre

Conteggio parole

Percorso Note e

istruzioni

workflow.xc

f GIMP image Diagramma

di flusso che fornisce un quadro generale del processo di produzione

155 \Graphics\Source\Artwork Sorgente di workflow.gi

f (vedi sopra). Localizzare il livello di testo nel file con GIMP (GNU Image Manipulation Program, l'ambiente grafico GNU) e salvarlo in formato GIF. GIMP è un programma gratuito per il fotoritocco e la grafica.

File multimediali Poiché 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 che consiste nel mantenere separati gli elementi localizzabili digitali l'uno dall'altro in tracce diverse sulla timeline.

L'ideale sarebbe fornire ai localizzatori i file di progetto e i parametri di progetto con cui si è costruita la presentazione. 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 d'origine 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,

all'interno della cartella Documentation del localization kit; l'obiettivo è 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 l'espansione 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 l'eliminazione dei rumori;

istruzioni sul livello e la coerenza del volume;

istruzioni sui silenzi.

Esempio di elenco di file multimediali per una distinta dei materiali

Nome file Tipo file

Funzione Rateo di

campionamento

Frequenza di

campionamento

Piattaforma Percorso Note e

istruzioni

welcome.

wav WAV - Mono

8 bit 44 kHz PC \Multimedia\Audio

\Main Associato al menu principale. Suono di benvenuto.

intro.wm

a WMA - Stereo

Presentazione dell'applicazione Web

24 bit 22 kHz Windows \Multimedia\Audio

\Web Collegamento in default.as

p. file sorgente non disponibile. Dialoghi in intro_en.r

tf. Usare Windows Media per ricreare il file audio.

sample.m

peg MPEG-1

Video campionato

16 bit stereo 44 kHz Multipiattaforma

\Multimedia\Video

\Web Collegamento in training.a

sp. Dialoghi in intro_en.r

tf. Per ragioni di supporto, per ricreare il file audio utilizzare possibilmente 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 e informazioni per la sottotitolazione.

Materiale collaterale Il materiale secondario viene, in genere, chiamato "collaterale". Si tratta, spesso di file grafici e, a volte, di documenti 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 dell'altro materiale di marketing;

il file sorgente o la versione in formato "tagged" del file in DTP degli opuscoli e dell'altro materiale di marketing;

il file Leggimi in formato solo testo o rich-text;

l'accordo 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 all'interno 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 le linee guida e le istruzioni per l'espansione del testo, le istruzioni per la compilazione in DTP, compresa la versione del compilatore, e le istruzioni per la gestione delle questioni legali, fiscali o finanziarie.

Consegna Insieme alle istruzioni per la creazione e la consegna di un language pack a partire dai file localizzati si dovrà dare una descrizione generica dei contenuti delle cartelle.

Prima della pubblicazione, il localization kit dovrebbe essere sottoposto a verifica da parte di terzi, per individuare eventuali 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 all'ultima 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à opportuno creare un mini localization kit archiviando gli elementi critici in un disco a parte sulla cui etichetta siano riportate le stesse informazioni del localization kit originario e su cui sia collocata un'etichetta aggiuntiva che specifichi che si tratta di un'integrazione.

Stesura della guida alla localizzazione

La guida alla localizzazione dovrà essere redatta prima dell'effettivo inizio del progetto, insieme al piano di progetto e contiene le istruzioni per la localizzazione di un prodotto. Le direttive contenute nella guida di localizzazione dipendono dal prodotto o sono dettate dall'azienda.

Anche se può sembrare un lavoro lungo e impegnativo, una buona guida può adattarsi bene a molti progetti; per questo, 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 l'aumentare della qualità delle informazioni: per scrivere una buona guida alla localizzazione è quindi necessario:

determinare l'utente 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 duplicazione dovrà esserci una corrispondenza e si dovrà spiegare in che modo i file sono correlati. Le istruzioni contenute nella guida alla localizzazione dovranno essere sufficientemente chiare e precise da permettere di ricomporre i file in modo da reintrodurli nel prodotto.

La guida alla localizzazione all'interno del localization kit dovrà elencare e chiarire accuratamente tutti gli argomenti 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 le soluzioni 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 l'espansione delle stringhe di testo;

istruzioni per il ridimensionamento delle finestre di dialogo e degli altri elementi decorativi;

linee guida per l'utilizzo dei tasti di scelta rapida;

convenzioni per l'assegnazione 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 e registrazione dei dati di progetto.

Quello che segue è uno schema di stesura per una guida alla localizzazione. Un breve esempio, certamente incompleto, è disponibile in appendice.

Introduzione Fornire una panoramica generale di tutto il documento, descrivendo i dati, i requisiti funzionali e i comportamenti richiesti. Descrivere i contenuti del kit.

Organizzazione del progetto Elencare i ruoli principali all'interno del progetto e le persone coinvolte, possibilmente attraverso un grafico organizzativo. L'elenco 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 progetto Descrivere gli obiettivi generali di progetto, attraverso una sintesi generale del piano di progetto che riporti le stime dei costi e un programma di massima.

Campo di applicazione Definire la portata e i limiti del lavoro da svolgere, non le modalità per svolgerlo. Descrivere il progetto e il software con principali funzionalità e vincoli. Collocare il software in un contesto aziendale o produttivo, mettendo in evidenza le questioni strategiche, in modo da fornirne un quadro complessivo al lettore. Ove possibile, indicare un contesto applicativo descrivendo le varie interfacce verso il mondo esterno, e le strutture di controllo del sistema.

Contenuti del kit Fornire le istruzioni per il ritiro, illustrare l'organizazione del kit e fornire istruzioni su come installarlo.

Requisiti di risorse Indicare i requisiti hardware, software, di documentazione, del personale e di dati servendosi di un modello contestuale dell'architettura 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 metodologie

Strumenti Il kit dovrà contenere una cartella Tools con tante cartelle quanti sono gli strumenti, ciascuna con il nome dello strumento.

Specificare i linguaggi, gli script, i compilatori e gli strumenti utilizzati per sviluppare il software e fornire un elenco degli strumenti, delle tecniche e dei metodi da utilizzare per la localizzazione e le attività di testing.

Tecniche Descrivere la procedura per la localizzazione dei vari tipi di file e per utilizzare gli strumenti proprietari inclusi nel kit. 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, l'ordine delle parole, i generi, gli articoli, i plurali e l'espansione 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 schermate nella lingua di partenza per facilitarne l'interpretazione.

Fornire istruzioni sulla gestione delle questioni legali, fiscali o finanziarie.

Metodologie Elencare i compiti di lavoro specifici necessari a soddisfare i requisiti di progetto e permettere all'acquirente e all'offerente di valutare i costi e al secondo di determinare i livelli di competenza, manodopera e altre risorse necessarie per portare a termine l'incarico. Nel caso in cui si adotti una struttura di suddivisione del lavoro (Work Breakdown 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 tutti gli incarichi per l'adempimento del contratto.

Deliverable Elencare e descrivere i deliverable di progetto. Fornire sempre un adeguato livello di dettaglio, in modo che il lettore possa comprendere ciò che si sta producendo. Inserire un grafico che mostri i deliverable in relazione ai principali obiettivi intermedi di progetto (milestone).

Rischi Elencare e descrivere le circostanze o gli eventi che potrebbero sfuggire al controllo del gruppo di progetto e che potrebbero avere un impatto negativo sul progetto, così che tutti gli stakeholder del progetto possano prevenirli e gestirli riducendone la probabilità di accadimento.

Elencare inoltre i rischi con la relativa probabilità di occorrenza e le conseguenze negative, definendo, per ogni rischio, le attività per la sua eliminazione o mitigazione.

Comunicazione I responsabili di progetto devono comunicare regolarmente con gli stakeholder, informandoli sullo stato del progetto in modo da indirizzare le loro aspettative. La mancata informazione sull'andamento del progetto farà crescere la probabilità che insorgano problemi a vari livelli, dipendenti, in molti casi, dal fatto che il cliente o gli stakeholder vengono colti di sorpresa.

È quindi necessario stabilire un piano di comunicazione per determinare le necessità comunicative di tutte le persone partecipanti al progetto o che dipendono da esso, e fornire informazioni coerenti e puntuali a tutti gli stakeholder del progetto.

Fornire uno schema di rapporto sullo stato del progetto da far compilare regolarmente ad ogni componente del gruppo di progetto.

Quello che segue è un modello di rapporto sullo stato del progetto da integrare, eventualmente, con un rapporto sullo 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 dall'ultimo rapporto e prestazioni in contrasto

Milestone Data di baseline Data di fine Risultati

Descrizione delle milestone

gg/mm/aaaa gg/mm/aaaa gg/mm/aaaa

Milestone previste per il prossimo periodo di avanzamento e loro modifiche in relazione al piano precedente

Milestone Data di baseline Data di fine precedente

Data di fine corrente

Descrizione delle milestone

gg/mm/aaaa gg/mm/aaaa gg/mm/aaaa

Effetti del (mancato) raggiungimento delle milestone per il restante periodo di progetto

Milestone Impatto

Descrizione delle milestone interessate

Breve descrizione delle modifiche 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 Data

Spese pianificate

Spese effettive Avanzo/Disavanzo

gg/mm/aaaa

Piano gestione rischi di progetto (rispetto al rapporto precedente)

Rischio Probabilità Gravità Grado Variazione

Breve descrizione dei rischi principali.

Bassa Media Alta

Bassa Media Alta

A B C

Aumento Riduzione

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 funzione delle milestone di progetto. Riportare gli standard e le linee guida cui attenersi durante il progetto e indicare come conformarvisi. 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 all'interno del progetto.

Descrivere le metriche di prodotto, di progetto e di processo da seguire e calcolare durante il progetto. Descrivere i vari documenti relativi alla qualità utilizzati nel corso del progetto, comprese le modalità e il luogo in cui archiviarli e per quanto tempo.

In un progetto di localizzazione, si fa solitamente ricorso a due tipi di metriche: di produzione e aziendali. Le metriche di produzione sono incentrate sulla misurazione dell'efficienza, quelle aziendali sono incentrate sulla misurazione del valore.

Ogni metrica richiede la maggior quantità possibile di dati che, per poter essere raccolti, devono essere chiari e identificabili.

Esempi di metriche

Categoria Metriche

Valore d'impresa vantaggi derivanti dall'analisi costi/benefici in seguito all'approvazione del progetto

Costi costi effettivi vs. budget (varianza) di progetto, per le varie fasi, per l'attività, 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 cliente

disponibilità dei deliverable

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 deliverable

percentuale di deliverable sottoposta a controllo di qualità

percentuale di controlli sui deliverable superati al primo passaggio

numero di difetti riscontrati dopo l'accettazione 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 successo

Piano di collaudo e criteri di validazione In un progetto di localizzazione, l'individuazione e la diagnosi di eventuali bug è essenziale così come la mancanza di collaudi iniziali può rivelarsi fatale. Perciò, anche se si decide di lasciare il collaudo ai localization engineer, si dovrebbe mettere in grado ogni componente del gruppo di progetto di compilare e collaudare l'applicazione localizzata per trovare, e in caso risolvere, eventuali problemi.

Per questo, l'ambiente di localizzazione deve contenere tutti gli strumenti che permettano di individuare gli errori che possano aver causato eventuali bug.

Descrivere come affrontare le questioni relative alla validazione legate al collaudo funzionale e il tipo di collaudi da effettuare con il maggior livello possibile di dettaglio. Specificare le risorse hardware e software, le impostazioni di setup, i requisiti produttivi e i risultati attesi in seguito ai collaudi. Indicare chi ha la responsabilità di correggere gli errori.

Fornire le istruzioni per l'esecuzione di eventuali script da utilizzare per i collaudi automatici per riprodurre il comportamento degli utenti.

Definire il flusso funzionale dell'interfaccia utente del software in modo che i collaudatori non debbano esaminare tutte le funzionalità di ciascun segmento.

Affinché il vendor possa installare e gestire una piattaforma di collaudo specifica per il progetto, fornire le seguenti informazioni:

nomi delle piattaforme su cui gira il prodotto;

eventuali requisiti hardware e software particolari per l'installazione 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 l'accesso al database di registrazione degli errori.

Aspetti della localizzazione per il Web La localizzazione Web presenta una serie di problemi specifici da affrontare separatamente.

Nonostante la localizzazione di documenti HTML sia relativamente semplice, specialmente con l'aiuto di strumenti di traduzione che consentono di proteggere i marcatori, è necessario fornire informazioni precise su come individuare e accedere ai contenuti localizzabili all'interno degli script che gli stessi strumenti di traduzione hanno difficoltà a trattare. Indicare come separare interfaccia utente, contenuti ed elementi di codice, e come individuare il codice per le funzionalità di back-end e quello di governo dell'interfaccia utente, poiché le funzionalità di back-end di un sito producono gli oggetti visibili dall'utente e devono quindi essere identiche in tutte le lingue.

Fornire indicazioni per l'adattamento del codice in funzione della nuova struttura di directory, del charset ecc. Fissare rigorose convenzioni per l'assegnazione dei nomi in modo da evitare differenze di comportamento tra piattaforme Windows e Unix e derivate (sensibili alla cassa), e nel modo in cui i server Web trattano le estensioni dei file.

Fornire informazioni utili all'analisi 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 dell'applicazione Web che viene aggiornata 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 Mac Una tipica applicazione Mac non è composta da un solo file eseguibile, ma da una cartella (bundle) contenente, di solito, l'eseguibile e le relative risorse a supporto organizzate gerarchicamente.

I file di risorse relativi a una lingua sono raccolti tutti in una cartella all'interno del bundle contrassegnata dal codice ISO 639 della lingua seguito dall'estensione .lproj.

La struttura del bundle permette di aggiungere facilmente una versione localizzata a un'applicazione, aggiungendo le necessarie risorse di interfaccia alla cartella Resources.

La struttura interna dei bundle è piuttosto simile. Dal punto di vista della localizzazione, gli eseguibili con associata interfaccia utente devono essere distribuiti in bundle, mentre alcuni contenuti non possono far parte della struttura di bundle.

Le cartelle .lproj di un bundle contengono gli stessi file, mentre tutte le versioni di un file di risorse devono avere lo stesso nome. Una risorsa da non localizzare va nella cartella Resources, non in una .lproj che deve contenere solo risorse localizzabili.

In generale, sono da localizzare i seguenti tipi di file:

InfoPlist.strings contenenti i puntatori (key) dell'elenco 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 Linux Tecnicamente, la localizzazione di FOSS (Free/Open Source software) non è diversa da quella del software commerciale.

Il processo di sviluppo del software open source è basato sull'iniziativa degli utenti, sparsi un po' ovunque nel mondo, che intervengono all'occorrenza spinti dall'esigenza per un certo prodotto; sono gli utenti stessi a proporre e implementare 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 processo ininterrotto affidato per lo più all'impegno spontaneo e gratuito dei singoli, ma il risultato sono sorgenti costantemente in divenire.

Il sistema operativo GNU/Linux è stratificato in livelli di sottosistemi che operano uno sull'altro. Ogni livello svolge le 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 l'alto, nel modo seguente

1. le librerie C; 2. X Window, l'ambiente grafico; 3. i toolkit, le librerie "intermedie" che interagiscono con l'ambiente grafico a basso livello fornendo gli

elementi dell'interfaccia grafica; 4. il desktop.

Secondo i dettami della "OpenI18N Globalization Specification", la localizzazione della maggior parte dei progetti open 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 dall'applicazione per selezionare a run time le stringhe localizzate.

I file .po Nel FOSS, GNU gettext è l'ambiente 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 eseguire l'applicazione nella lingua predefinita così com'è. L'individuazione e l'estrazione dei messaggi localizzati è affidata a Gettext 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 dall'estensione .po che vengono poi normalmente inviati ai localizzatori per la traduzione. Di solito, per lavorarli, è necessario un editor Unicode giacché la codifica standard 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 il

punto (.) e il punto e virgola (;), i commenti sono stati inseriti automaticamente durante il procedimento di estrazione.

Gettext estrae le stringhe da localizzare dal codice sorgente in una tabella che viene quindi combinata con un'altra tabella dello stesso tipo contenente le stringhe già tradotte. Le stringhe nuove sono confrontate con quelle esistenti in un Compendium, un'altra tabella di stringhe che costituisce una sorta di memoria di traduzione, contenente le

stringhe provenienti da diversi file .po. Ai traduttori spetta tradurre ed effettuare la revisione delle stringhe prima

che il file .po sia convertito in un file .mo.

Nel formato .po, le stringhe "sorgenti" (msgid) sono usate anche come identificatori, secondo un approccio radicalmente diverso da quello usato normalmente nei file di risorse come quelli del Java Resource Bundle o della piattaforma .NET, che utilizzano una chiave logica. È per questo che sempre più progetti rinunciano a servirsi di Gettext e impiegano formati specifici o quelli della piattaforma Java.

I CVS Solitamente lo sviluppo di un'applicazione e la sua localizzazione procedono in parallelo e capita che i file dei messaggi siano continuamente aggiornati con nuove stringhe. Per evitare intoppi nell'incorporazione di nuove

stringhe 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 un'applicazione, la documentazione e tutto il restante materiale perché 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 si possono 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 correzione degli errori e la manutenzione delle versioni precedenti viene condotta nei rami che si dipartono dalla radice in parallelo 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 il CVS; questo replica la sua struttura ad albero su tutte le postazioni remote collegate in modo che da queste i localizzatori 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 tenute

costantemente aggiornate, a cominciare dalle cartelle in cui sono conservati i file .po e gli account dei localizzatori per finire con gli strumenti da utilizzare e le regole di validazione e verifica delle traduzioni.

Aspetti della localizzazione per palmari e dispositivi mobili Sebbene non si tratti semplicemente di versioni ridotte di quello tradizionale, il software per palmari e dispositivi mobili presenta difficoltà di localizzazione analoghe a quello "tradizionale" con problemi derivanti in gran parte dalle ridotte dimensioni degli schermi che impongono numerose vincoli di progettazione e di disegno dell'interfaccia utente e limitazioni nell'uso delle icone e nella traduzione delle stringhe. Queste ultime, in particolare, consistono nella necessità di mantenersi sintetici ed esaurienti, resa critica all'origine per le stesse ragioni.

Tuttavia, l'ampia diffusione commerciale ha fatto sì che tutti i sistemi operativi per palmari e dispositivi mobili dispongano del supporto Unicode. Inoltre, i principi per l'internazionalizzazione sono più o meno gli stessi seguiti per

il software "tradizionale" il che porta a disporre di file di risorse contenenti stringhe ed altri elementi dell'interfaccia.

Java è in generale il linguaggio di sviluppo preferito per palmari e dispositivi mobili proprio in virtù delle ridotte dimensioni dei file e dell'eccellente supporto alla localizzazione, mentre WML (Wireless Markup Language) è il linguaggio usato per i servizi WAP e XHTML e XML quello per i contenuti. I problemi dunque sorgono solo con gli ambienti di sviluppo che si servono di linguaggi e formati specifici.

Palm OS La 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 database

distinto 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 delle finestre 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.

Un'applicazione Palm OS (.prc file) localizzabile si può, realizzare a partire da un .prc base non legato ad alcun

locale, 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 alcun

locale 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) per

ottenere i file .prc finali.

In alternativa, è possibile produrre un file .prc non localizzato e un altro localizzato a partire da un unico file .xrd

in cui le risorse relative a uno specifico locale siano identificate univocamente. Si dovrà poi filtrare il file .xrd per

ottenere 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 dalla piattaforma. Per intervenire tanto sui marcatori XML quanto sulle finestre di dialogo in modalità grafica si può usare il Resource Editor per Palm OS che permette di operare in modalità drag & drop sui controlli dell'interfaccia utente a partire da un catalogo degli elementi.

Il collaudo si può quindi effettuare direttamente sul palmare o tramite un emulatore in dotazione all'ambiente di sviluppo, 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 non permettere di eseguire alcuni test come quelli relativi all'impiego di accessori, dispositivi (come schede di memoria aggiuntive, tastiere ecc.), altri programmi o plug-in.

EPOC/Symbian Denominato 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 caratterizzati

dall'estensione .rss e successivamente compilati in formato binario. Questi file si possono localizzare senza bisogno di ricompilare il programma.

I sorgenti dei file di risorse prevedono l'inclusione di un header (con estensione .rh) contenente le informazioni necessarie al launcher dell'applicazione o alla shell di sistema quali il nome del programma, una sua versione abbreviata, il nome del file dell'icona, informazioni opzionali sulle viste, tra cui titoli e icone.

Le stringhe da localizzare di solito sono raccolte in file separati contrassegnati dall'estensione .rls ciascuna su una

singola riga e contraddistinta dalla parola chiave rls_string, da un identificatore simbolico e dal testo.

Per facilitare la localizzazione, il testo dell'interfaccia utente viene solitamente raccolto in un altro header

(convenzionalmente contrassegnato con l'estensione .loc) a sua volta incluso nel file di risorse. I file .loc sono quelli inviati ai traduttori.

Termini e definizioni Acceleratore/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 l'analisi, 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 dell'intero 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 all'interno del programma e le parti di esso mostrate all'utente.

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 dell'applicazione e le informazioni sono presentate in un formato a cui l'utente è abituato; l'internazionalizzazione, 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 dell'ambiente legate all'ubicazione geografica, alla lingua e a elementi culturali che determinano talune convenzioni culturali e altre quali le regole di ordinamento, il formato della data, dell'ora e della valuta e la disposizione della tastiera.

Materiale collaterale

Tutto il materiale destinato alla pubblicazione e gli strumenti mediatici utilizzati da un'azienda 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 è un'attività 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 l'applicazione tradotti somiglino il più possibile al documento o all'applicazione originali.

Rebuild

Ricompilazione del software dopo la traduzione e il ridimensionamento, per la realizzazione della versione localizzata di un'applicazione.

Screenshot

Immagine elettronica che riporta una particolare schermata di un prodotto software utilizzata nella guida in linea o nella documentazione per spiegare o illustrare all'utente 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, l'uso, la grammatica, la punteggiatura, i caratteri, l'uso 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 dell'audio ad un video in cui i movimenti delle labbra di chi parla non sono visibili.

Bibliografia Apple computer, Localizability Technical Note

Apple computer, Inside Mac OS X, Project Builder Help

Apple computer, Internationalization Programming Topics

Bishop 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-4

Carmel E., Global software Teams: Collaborating Across Borders and Time Zones, Prentice Hall, 1999, ISBN 01-392-4218-X

Cederqvist et al, Version Management with CVS, Free software Foundation, 2005

Deitsch A., Czarnecki D., Java Internationalization, O'Reilly & Associates, 2001, ISBN 05-960-0019-7

Dr. International, Developing International software, Microsoft Press, 2002, ISBN 07-356-1583-7

Esselink B., A Practical Guide to Localization, John Benjamins Publishing Co., 2000, ISBN 90-2721-956-7

Kano N., Developing International software for Windows 95 and Windows NT, Microsoft Press, 1995, ISBN 15-561-5840-8

Kaplan M. S., Internationalization With Visual Basic, Sams, 2000, ISBN 06-723-1977-2

Luong T. V., Lok J. S. H., Driscoll K., Internationalization: Developing software For Global Markets, John Wiley & Sons, 1995, ISBN 04-710-7661-9

Madell T., Parsons C., Abegg J., Developing and Localizing International software, Prentice Hall, 1994, ISBN 01-330-0674-3

Maxwell Chandler H., The Game Localization Handbook, Charles River Media, 2004, ISBN 1-58450-343-2

O'Conner J., Internationalization Using the Java Platform, Addison-Wesley, 2002, ISBN 02-016-1568-1

O'Donnell S. M., Programming for the World: A Guide to Internationalization, Prentice Hall, 1994, ISBN 01-372-2190-8

Ott C., Global Solutions for Multilingual Applications: Real-World Techniques for Developers and Designers, John Wiley & Sons, 1999, ISBN 04-713-4827-9

Sasikumar M., Aparna R., Naveen K., Rajendra Prasad M., Free/Open Source software Guide to Localization, UNDP-APDIP, 2005

Schmitt D. A., International Programming for Microsoft Windows, Microsoft Press, 2000, ISBN 15-723-1956-9

Symmonds N., Internationalization and Localization Using Microsoft .Net, APress, 2002, ISBN 15-905-9002-3

Taylor D., Global software: Developing Applications for the International Market, Springer Verlag, 1992, ISBN 03-879-7706-6

Uren E., Howard R., Perinotti T., Software Internationalization and Localization, TGP Consulting, 1993, ISBN 04-420-1498-8

Appendice

Guida alla localizzazione di <nome prodotto>

Avvertenza Alla consegna, ogni lavoro deve essere pienamente conforme a quanto di seguito specificato. Eventuali non conformità potranno condurre a riduzioni del compenso o a interventi migliorativi, fino all'esclusione dal database dei 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 quest'ordine.

Il CD contiene tutti i file necessari archiviati nella cartella Source.

Requisiti Per 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 nell'uso del software.

Interfaccia utente L'interfaccia utente andrà localizzata per prima, anche se è forse l'elemento più complesso da localizzare.

Strumento Per localizzare l'interfaccia utente si dovrà utilizzare <nome srumento> che si trova nella cartella Tool\<nome

strumento>\Program nel CD. Per l'istallazione, l'avvio e la configurazione di <nome strumento> e per istruzioni su

come lavorare con i file fare riferimento al relativo manuale utente nella cartella Tool\<nome

strumento>\Manual nel CD.

Risorse Le risorse per l'interfaccia utente si trovano nella cartella \Source\Resources\<639> nel CD, in cui <639> è il codice linguistico a due caratteri stabilito dalla norma ISO 639. Copiare la cartella con i file da elaborare sul disco rigido locale. Cliccare con il tasto destro del mouse sul proprio disco rigido, selezionare Proprietà e rimuovere l'opzione di sola lettura della cartella, della sottocartella e dei file.

Localizzazione dei form I form saranno i primi ad essere localizzati. Fare riferimento al manuale utente di <nome strumento> nella cartella

Tool\<nome strumento>\Manual nel CD per avere istruzioni sull'utilizzo di <nome strumento>.

[A seguire, le istruzioni su come localizzare i form]

Disegno dell'interfaccia utente

Se una stringa appare incompleta nel form una volta tradotta, provare a spostare o a ridimensionare gli elementi direttamente dall'interno del form.

Regole

Non tutte le proprietà e le finestre vanno tradotte.

Non tradurre

[A seguire, l'elenco degli elementi e dei valori da non tradurre]

Tasti di scelta rapida

Assegnare il carattere & alla lettera appropriata per indicare il tasto di scelta rapida. &Salva, ad esempio, significa che premendo Alt+S si attiva questa voce di menu. Assicurarsi che lo stesso tasto di attivazione non sia stato assegnato a più di un elemento nello stesso menu.

Raccomandazioni

Salvare prima di cominciare a lavorare su una nuova finestra o un nuovo form.

Script di risorse Dopo aver completato la localizzazione dei form, localizzare le stringhe di risorse. Alcune non provengono da <nome prodotto> ma dai componenti utilizzati. Localizzare soltanto le stringhe di <nome prodotto> che si possono individuare dall'etichetta "<nome etichetta>".

Variabili

Alcune stringhe possono contenere delle variabili come %s, %0:s, %1:s che vengono sostituite da altro testo durante l'esecuzione del programma e, affinché questo funzioni in modo appropriato, dovranno essere comprese nella traduzione. Tuttavia, se ne può cambiare l'ordine riformulando la frase.

Raccomandazioni

Assicurarsi che le traduzioni siano incluse sempre tra virgolette singole.

Non dimenticarsi di salvare regolarmente.

Consegna Dopo aver terminato la traduzione dell'interfaccia utente, zippare la cartella <639> sul disco locale con tutte le sottocartelle assicurandosi di aver lasciato inalterata la struttura della cartella e inviare il file a <nome cliente>.

Ricompilazione La 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 ulteriori test.

Database locale Microsoft Access

Creazione Copiare il database locale Microsoft Access dalla cartella \Source\Database\Access\<639> del CD, sul disco locale. Rimuovere le proprietà di sola lettura da questo file.

Apertura Avviare <nome prodotto> nella lingua di destinazione per aprire il database locale Microsoft Access e tradurne i contenuti. All'apertura del database con qualsiasi versione di Microsoft Access, il programma richiederà una

password. La password per il database è contenuta nel file dbpwd.dat nella cartella

\Source\Database\Access\<639> nel CD. Se si apre il database con Microsoft Access 2000 o superiore, non convertirlo: il software potrebbe non funzionare più correttamente.

Test linguistico Partendo dal modulo di installazione, lanciare i moduli ad uno ad uno e verificare che non ci siano dati oltre quelli nella 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 segnalare eventuali modifiche da apportare all'interfaccia utente servirsi del foglio delle domande sulla terminologia.

Consegna Dopo aver completato la traduzione del database locale di Microsoft Access zippare la cartella

\Source\Database\Access\<639> sul disco locale e inviare il file a <nome cliente>.

Script SQL Server Tutti gli script sono contenuti nei file RTF all'interno della cartella \Source\Database\Access\<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 testo da tradurre. Questo sarà di colore nero, mentre il testo che non deve essere tradotto sarà grigio.

Consegna Dopo aver completato la traduzione degli script del database di Microsoft SQL Server, zippare la cartella

Risorse\Database\SQL_Server\<639> sul disco locale e inviare il file a <nome cliente>.

Screenshot I manuali di <nome prodotto> contengono molti riferimenti al software attraverso gli screenshot. Raccogliere tutti gli screenshot prima di iniziare la traduzione dei manuali. Gli screenshot (circa 400) sono archiviati nella cartella

\Source\Documentation\Screenshots nel CD. Prendere gli screenshot solo nel locale di destinazione, dopo aver completato la localizzazione dell'interfaccia utente. Le schermate devo avere la stessa dimensione delle originali, a non più di 16 bit (65K) di profondità colore. Archiviare le nuove immagini nella cartella

\Source\Documentation\Screenshots\<639> nel disco locale.

Consegna Dopo aver terminato, zippare la cartella \Source\Documentation\Screenshots\<639> sul disco locale e inviare il file a <nome cliente>.

Manuale utente Il manuale utente si trova nella cartella \Source\Documentation\User_manual\<639> nel CD. Copiare la cartella

sul disco locale. Rimuovere la proprietà di sola lettura dal file usrman<639>.doc e aprirlo con Microsoft Word. Attivare l'opzione di visualizzazione dei codici di campo e cercare la stringa "D://<product_code_name>//<version>//User_manual//Graphics//" per sostituirla con il percorso dei nuovi screenshot.

Disattivare l'opzione di visualizzazione dei codici di campo per verificare che nel manuale appaiano i nuovi screenshot.

Iniziare a tradurre il documento con uno strumento di traduzione che consenta di salvare una memoria di traduzione per le future versioni del prodotto, rispettando lo stile e la formattazione del documento originale. Salvare la memoria di traduzione nella stessa cartella del manuale.

Una versione compilata (in formato PDF) del manuale è disponibile nella cartella

\Source\Documentation\User_manual\En nel CD.

Consegna A lavoro ultimato, zippare la cartella \Source\Documentation\User_manual\<639> sul disco locale e inviare il file a <nome cliente>.

Guida in linea I file di risorse per la guida in linea si trovano nella cartella \Source\Documentation\Online_help\<639> nel CD. 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 nella

cartella \Source\Documentation\Online_help\En nel CD

Note a pie' di pagina Un 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 grafici Collegamenti grafici come {bmc graphics\floating_menu.bmp} non vanno tradotti. Il compilatore della guida li riconoscerà e in fase di compilazione vi collegherà l'immagine corrispondente.

Topic jump Il topic jump permette al lettore di cliccare su un collegamento ed essere reindirizzato al capitolo in cui viene trattato l'argomento correlato. Un topic jump ha due componenti. La prima parte, in verde, con sottolineatura doppia, viene visualizzata dal lettore e deve essere tradotta. La seconda parte è un testo nascosto e non va tradotto. Non lasciare mai spazi tra la prima e la seconda parte di un topic jump.

Sommario Quando si apre un file della guida in linea, il lettore si troverà davanti il sommario che è archiviato in un file

separato 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 seconda

riga andrà tradotto solo il testo dopo "Title". Nelle righe successive non modificare il numero iniziale, tradurre il

testo precedente il simbolo = e lasciare inalterata la seconda parte.

Consegna A lavoro ultimato, zippare la cartella \Source\Documentation\Online_help\<639> sul disco locale e inviare il file a <nome cliente>.

Piano di consegna

Nome del documento Data di inizio

Data di scadenza Consegnare a

Interfaccia utente 7/11/2005 21/11/2005 (14:00 GMT)

george.brown@l10nco.com (inviare in copia a

Nome del documento Data di inizio

Data di scadenza Consegnare a

Database locale Microsoft Access

21/11/2005 23/11/2005 (14:00 GMT)

john.smith@l10nco.com)

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 l'upload dei file da e sul server FTP di L10NCo. Per scaricare o caricare i file di progetto da o sul nostro server FTP, servirsi di un normale client FTP, utilizzando i seguenti paramentri:

Hostname ftp.l10nco.com

Username vendor

Password l10nco

Percorso di download to_l10nco

Percorso di upload from_l10nco

Nota: una volta all'interno della directory di download (from_l10nco) saranno visibili i nomi dei file che, invece,

non saranno visibili nella directory di upload (a_l10nco).

Supporto Tutte le comunicazioni di progetto dovranno essere redatte in lingua inglese, così da poter essere eventualmente inoltrate 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)