SlideShare una empresa de Scribd logo
1 de 34
Descargar para leer sin conexión
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)

                                                   Conteggio
    Nome file       Tipo file       Funzione                             Percorso                 Note e istruzioni
                                                    parole

  default.asp Script lato       Pagina di inizio            30 directory principale           Riga 37: la variabile
                   server       navigazione                                                   strRedirect non deve
                   (VBScript)                                                                 superare i 75 caratteri
                                                                                              Riga 271: non localizzare
                                                                                              la variabile strLang

  content.asp Script lato       Pagina                   1,830 directory principale           Riga 58: Localizzatori
                   server       contenitore                                                   spagnoli: utilizzare
                   (VBScript)                                                                 terminologia differente
                                                                                              per i mercati spagnolo e
                                                                                              messicano

  style.css        Foglio di    Gestisce la                     Style                        Riga 10: cambiare i
                   stile        visualizzazione                                               caratteri Times New
                   (CSS2)       dei contenuti                                                 Roman con SimSun per il
                                                                                              Cinese Semplificato
                                                                                              (2052), PMingLiu per il
                                                                                              Cinese Tradizionale
                                                                                              (1028), MS Mincho per il
                                                                                              Giapponese (1041) e
                                                                                              Batang per il Coreano
                                                                                              (1042)

  errmsg.inc       Testo        file include           10,000 IncludesEnMessages Stringhe di testo
                   semplice                                                         visualizzate nelle
                                                                                    finestre di messaggio per
                                                                                    segnalare un errore.


Materiale di 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
                                                                                                             Problema
       file   Percorso     Problema                         Commenti                          Altro Nome
                                                                                                              risolto

  main.rc menu             Linguistico Dopo una revisione accurata, alcuni oggetti
              principale               suonano meglio in italiano se resi al plurale:
                                       Contatto > Contatti, Fornitore > Fornitori,
                                       Preventivo > Preventivi, Cliente > Clienti,
                                       Strumento > Strumenti, Progetto > Progetti
Esempio di foglio per le domande

        Foglio per le domande: < nome del progetto > Terminologia italiano
        Urgente       Nome del                                                      Termine (lingua di
                                   Pagina Termine/Problema Contesto                                           Risposta
        (Si/No)         file                                                          destinazione)


                                              Esempio di stato di avanzamento

                                    Parole
                      Conteggio             Avanzamento                         Giorni             Data di     Data di
   Nome del file                      da                Risorse2 Produttività3
                       parole                    %1                            correnti4            inizio      fine
                                   tradurre

 rc1_en_olh.rtf           32.914      3.724           88,7%          6             333        1,9 10/3/2005 1/7/2005


   1.   100-[(parole tradotte)*100/(parole da tradurre)]
   2.   persone coinvolte
   3.   (numero di parole al giorno)/(risorse)
   4.   (parole da tradurre)/[(risorse)*(produttività)]


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

                                                Testo da      Conteggi                                           Note e
  Nome file        Tipo file     Funzione                                            Percorso
                                                tradurre      o parole                                         istruzioni

intro.bmp       BMP, 8-bit,     Immagine       Premere un             5 GraphicsFinalMain                 Usare Arial 24
                nessuna         visutalizzat   tasto per                                                     grassetto per
                compression     a all'avvio    continuare..                                                  il testo; colore
                e               del            .                                                             del testo
                                programma                                                                    #FF9900
Esempio di elenco di file grafici per una distinta dei materiali

                                            Testo da      Conteggi                                   Note e
 Nome file     Tipo file     Funzione                                            Percorso
                                            tradurre      o parole                                 istruzioni

back_off.jp JPEG,           Immagine                                 GraphicsFinalMain        Collegamento
g           compression     di sfondo                                                            in
             e 25%          per la                                                               default.asp.
                            pagina di                                                            è un'immagine
                            benvenuto                                                            molto difficile
                            del sito                                                             da riprodurre.
                            internet                                                             Se si
                            (back                                                                dimostrasse
                            office)                                                              non adatta al
                                                                                                 vostro locale,
                                                                                                 riempire il
                                                                                                 relativo spazio
                                                                                                 con
                                                                                                 un'immagine
                                                                                                 vuota.

scr01_en.gi Standard        Schermata                                GraphicsFinalScreensho   Ogni
f           GIF, 256        del menu                                 ts                          schermata
             colori         principale                                                           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 Standard        Diagramma     Vedere le             155 GraphicsFinalArtwork      Collegamento
f           GIF, 256        di flusso     etichette di                                           in
             colori         che           testo nel                                              workflow.as
                            fornisce un   file                                                   p. Il sorgente
                            quadro        sorgente                                               di questa
                            generale                                                             immagine è
                            del                                                                  workflow.xc
                            processo di                                                          f (vedi sotto),
                            produzione                                                           realizzato con
                                                                                                 GIMP (GNU
                                                                                                 Image
                                                                                                 Manipulation
                                                                                                 Program).
Esempio di elenco di file grafici per una distinta dei materiali

                                               Testo da      Conteggi                                           Note e
  Nome file       Tipo file     Funzione                                            Percorso
                                               tradurre      o parole                                         istruzioni

workflow.xc GIMP image         Diagramma                           155 GraphicsSourceArtwork             Sorgente di
f                              di flusso                                                                    workflow.gi
                               che                                                                          f (vedi sopra).
                               fornisce un                                                                  Localizzare il
                               quadro                                                                       livello di testo
                               generale                                                                     nel file con
                               del                                                                          GIMP (GNU
                               processo di                                                                  Image
                               produzione                                                                   Manipulation
                                                                                                            Program,
                                                                                                            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

                                                  Frequenza
                                        Rateo di
             Tipo                                     di                                                    Note e
Nome file               Funzione      campioname                     Piattaforma           Percorso
             file                                campioname                                               istruzioni
                                          nto
                                                     nto

welcome.     WAV                      8 bit           44 kHz         PC              MultimediaAudio   Associato al
wav          -                                                                       Main               menu
             Mono                                                                                        principale.
                                                                                                         Suono di
                                                                                                         benvenuto.

intro.wm     WMA       Presentazion 24 bit            22 kHz         Windows         MultimediaAudio   Collegament
a            -         e                                                             Web                o in
             Ster      dell'applicazi                                                                    default.as
             eo        one Web                                                                           p. file
                                                                                                         sorgente non
                                                                                                         disponibile.
                                                                                                         Dialoghi in
                                                                                                         intro_en.r
                                                                                                         tf. Usare
                                                                                                         Windows
                                                                                                         Media per
                                                                                                         ricreare il
                                                                                                         file audio.

sample.m     MPE       Video          16 bit stereo   44 kHz         Multipiattafo   MultimediaVideo   Collegament
peg          G-1       campionato                                    rma             Web                o in
                                                                                                         training.a
                                                                                                         sp. Dialoghi
                                                                                                         in
                                                                                                         intro_en.r
                                                                                                         tf. Per
                                                                                                         ragioni di
                                                                                                         supporto,
                                                                                                         per ricreare
                                                                                                         il file audio
                                                                                                         utilizzare
                                                                                                         possibilment
                                                                                                         e Adobe
                                                                                                         Premiere,
                                                                                                         Ulead Video
                                                                                                         Studio o
                                                                                                         Pinnacle
                                                                                                         Liquid
                                                                                                         Edition.
Per i file MPEG, potrebbe essere estrememente utile una versione del tutto aderente agli standard con time code 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            Milestone       Data di baseline     Data di fine          Risultati
  dall'ultimo rapporto e
  prestazioni in contrasto             Descrizione delle     gg/mm/aaaa         gg/mm/aaaa         gg/mm/aaaa
                                       milestone

  Milestone previste per il                                                     Data di fine        Data di fine
  prossimo periodo di                      Milestone       Data di baseline
                                                                                precedente           corrente
  avanzamento e loro modifiche
  in relazione al piano                Descrizione delle     gg/mm/aaaa         gg/mm/aaaa         gg/mm/aaaa
  precedente                           milestone

  Effetti del (mancato)                              Milestone                              Impatto
  raggiungimento delle
  milestone per il restante            Descrizione delle milestone            Breve descrizione delle modifiche
  periodo di progetto                  interessate                            da apportare al piano di progetto in
                                                                              conseguentza delle nuove milestone

  Informazioni generali              Aggiungere eventuali commenti di carattere generale a supporto o
                                     integrazione delle sezioni precedenti.
Modello di rapporto sullo stato del progetto

                                       <Nome progetto>
                             Rapporto sullo stato del progetto n. <X>
                                                         <Data>
  Budget                                                           Spese
                                                Data                               Spese effettive Avanzo/Disavanzo
                                                                pianificate

                                           gg/mm/aaaa

  Piano gestione rischi di                          Rischio              Probabilità Gravità      Grado      Variazione
  progetto (rispetto al rapporto
  precedente)                            Breve descrizione dei rischi        Bassa      Bassa        A       Aumento
                                         principali.                         Media      Media        B       Riduzione
                                                                              Alta       Alta        C         Novità

  Problemi                            Breve descrizione di tutte i problemi afferenti il progetto sorti dopo il
                                      precedente rapporto e che richiedono una soluzione.

  Raccomandazioni                     Brevi considerazioni da formulare o sottoscrivere.



Piano di assicurazione della qualità
Definire le attività da condurre per garantire la qualità del progetto e indicare come vadano coordinate, in 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                disponibilità dei deliverable
  cliente                          difetti dei deliverable
                                   affidabilità dei deliverable
                                   responsabilità del gruppo di progetto
                                   competenza del gruppo di progetto
                                   cortesia del gruppo di progetto
                                   comunicazione
                                   credibilità del gruppo di progetto
                                   affidabilità del gruppo di progetto rispetto agli impegni
                                   professionalità del gruppo di progetto
                                   tempi di risposta a quesiti e problemi
                                   tempi medi di risoluzione dei problemi
                                   numero di richieste di modifiche soddisfatte entro il budget e le scadenze
                                    iniziali di progetto



  Durata                         durata effettiva vs. budget (varianza)


  Lavoro                         lavoro effettivo vs. budget (varianza)
                                 ore lavorate dal responsabile di progetto vs. ore di lavoro totali


  Produttività                     ore lavorative per unità di prodotto
                                   unità di prodotto per ora di lavoro
                                   ore di lavoro in meno rispetto ai normali processi di progetto
                                   ore di lavoro risparmiate attraverso il riutilizzo di componenti preesistenti
                                   numero di idee implementate per il miglioramento dei processi
                                   numero di ore risparmiate grazie al miglioramento dei processi



  Qualità dei                      percentuale di deliverable sottoposta a controllo di qualità
  deliverable                      percentuale di controlli sui deliverable superati al primo passaggio
                                   numero di difetti riscontrati dopo 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.
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit
Guida alla realizzazione di un localization kit

Más contenido relacionado

Destacado

La diferencia entre investigar un insight y descubrir un insight
La diferencia entre  investigar un insight y  descubrir un insightLa diferencia entre  investigar un insight y  descubrir un insight
La diferencia entre investigar un insight y descubrir un insightUPN Universidad Privada del Norte
 
7 Hacks for Google AdWords to Driver More Leads & Conversion
7 Hacks for Google AdWords to Driver More Leads & Conversion7 Hacks for Google AdWords to Driver More Leads & Conversion
7 Hacks for Google AdWords to Driver More Leads & ConversionArayan Kummar Sharma
 
Trastornos hepáticos, vesiculares y pancreáticos
Trastornos hepáticos, vesiculares y pancreáticosTrastornos hepáticos, vesiculares y pancreáticos
Trastornos hepáticos, vesiculares y pancreáticosIECHS
 
The unlucky 13 - the early warning signs of potential workplace violence
The unlucky 13   - the early warning signs of potential workplace violenceThe unlucky 13   - the early warning signs of potential workplace violence
The unlucky 13 - the early warning signs of potential workplace violenceW. Barry Nixon, SPHR
 
Bringing clarity to analytics projects with decision modeling: a leading prac...
Bringing clarity to analytics projects with decision modeling: a leading prac...Bringing clarity to analytics projects with decision modeling: a leading prac...
Bringing clarity to analytics projects with decision modeling: a leading prac...Decision Management Solutions
 
Containerize, PaaS, or Go Serverless!?
Containerize, PaaS, or Go Serverless!?Containerize, PaaS, or Go Serverless!?
Containerize, PaaS, or Go Serverless!?Phil Estes
 
An Introduction To The Dick & Carey Instructional Design Model
An Introduction To The Dick & Carey Instructional Design ModelAn Introduction To The Dick & Carey Instructional Design Model
An Introduction To The Dick & Carey Instructional Design ModelLarry Weas
 
APOLO最終プレゼンスライド
APOLO最終プレゼンスライドAPOLO最終プレゼンスライド
APOLO最終プレゼンスライドKENZO OKANO
 
Congress seeks metrics for the NIST Cybersecurity Framework
Congress seeks metrics for the NIST Cybersecurity FrameworkCongress seeks metrics for the NIST Cybersecurity Framework
Congress seeks metrics for the NIST Cybersecurity FrameworkDavid Sweigert
 
EdTech×法務~教育系ベンチャー企業が知っておくべき法律問題~_GVA法律事務所
EdTech×法務~教育系ベンチャー企業が知っておくべき法律問題~_GVA法律事務所EdTech×法務~教育系ベンチャー企業が知っておくべき法律問題~_GVA法律事務所
EdTech×法務~教育系ベンチャー企業が知っておくべき法律問題~_GVA法律事務所gvalaw
 
DAR Resposta - Guia para famílias após o diagnóstico de autismo
DAR Resposta - Guia para famílias após o diagnóstico de autismoDAR Resposta - Guia para famílias após o diagnóstico de autismo
DAR Resposta - Guia para famílias após o diagnóstico de autismoSara Martins
 

Destacado (14)

La diferencia entre investigar un insight y descubrir un insight
La diferencia entre  investigar un insight y  descubrir un insightLa diferencia entre  investigar un insight y  descubrir un insight
La diferencia entre investigar un insight y descubrir un insight
 
7 Hacks for Google AdWords to Driver More Leads & Conversion
7 Hacks for Google AdWords to Driver More Leads & Conversion7 Hacks for Google AdWords to Driver More Leads & Conversion
7 Hacks for Google AdWords to Driver More Leads & Conversion
 
Trastornos hepáticos, vesiculares y pancreáticos
Trastornos hepáticos, vesiculares y pancreáticosTrastornos hepáticos, vesiculares y pancreáticos
Trastornos hepáticos, vesiculares y pancreáticos
 
The unlucky 13 - the early warning signs of potential workplace violence
The unlucky 13   - the early warning signs of potential workplace violenceThe unlucky 13   - the early warning signs of potential workplace violence
The unlucky 13 - the early warning signs of potential workplace violence
 
Bringing clarity to analytics projects with decision modeling: a leading prac...
Bringing clarity to analytics projects with decision modeling: a leading prac...Bringing clarity to analytics projects with decision modeling: a leading prac...
Bringing clarity to analytics projects with decision modeling: a leading prac...
 
Containerize, PaaS, or Go Serverless!?
Containerize, PaaS, or Go Serverless!?Containerize, PaaS, or Go Serverless!?
Containerize, PaaS, or Go Serverless!?
 
PROPOSTA SALARIAL 2017 PMPE-CBMPE
PROPOSTA SALARIAL 2017 PMPE-CBMPEPROPOSTA SALARIAL 2017 PMPE-CBMPE
PROPOSTA SALARIAL 2017 PMPE-CBMPE
 
An Introduction To The Dick & Carey Instructional Design Model
An Introduction To The Dick & Carey Instructional Design ModelAn Introduction To The Dick & Carey Instructional Design Model
An Introduction To The Dick & Carey Instructional Design Model
 
APOLO最終プレゼンスライド
APOLO最終プレゼンスライドAPOLO最終プレゼンスライド
APOLO最終プレゼンスライド
 
World Tuberculosis Day 2017 - Tuberculosis situation in the EU/EEA, 2015
World Tuberculosis Day 2017 - Tuberculosis situation in the EU/EEA, 2015 World Tuberculosis Day 2017 - Tuberculosis situation in the EU/EEA, 2015
World Tuberculosis Day 2017 - Tuberculosis situation in the EU/EEA, 2015
 
Congress seeks metrics for the NIST Cybersecurity Framework
Congress seeks metrics for the NIST Cybersecurity FrameworkCongress seeks metrics for the NIST Cybersecurity Framework
Congress seeks metrics for the NIST Cybersecurity Framework
 
GLOBAL RH 2017
GLOBAL RH 2017GLOBAL RH 2017
GLOBAL RH 2017
 
EdTech×法務~教育系ベンチャー企業が知っておくべき法律問題~_GVA法律事務所
EdTech×法務~教育系ベンチャー企業が知っておくべき法律問題~_GVA法律事務所EdTech×法務~教育系ベンチャー企業が知っておくべき法律問題~_GVA法律事務所
EdTech×法務~教育系ベンチャー企業が知っておくべき法律問題~_GVA法律事務所
 
DAR Resposta - Guia para famílias após o diagnóstico de autismo
DAR Resposta - Guia para famílias após o diagnóstico de autismoDAR Resposta - Guia para famílias após o diagnóstico de autismo
DAR Resposta - Guia para famílias após o diagnóstico de autismo
 

Similar a Guida alla realizzazione di un localization kit

La logisitca del Software OSS
La logisitca del Software OSSLa logisitca del Software OSS
La logisitca del Software OSSStefano La Gona
 
La logisitca del software oss
La logisitca del software ossLa logisitca del software oss
La logisitca del software ossStefano La Gona
 
Project Manager dalla Progettazione alla Gestione Web.pdf
Project Manager dalla Progettazione alla Gestione Web.pdfProject Manager dalla Progettazione alla Gestione Web.pdf
Project Manager dalla Progettazione alla Gestione Web.pdfNeelHope
 
UX Engineering: il ruolo dello sviluppo nel design dell'esperienza utente
UX Engineering: il ruolo dello sviluppo nel design dell'esperienza utenteUX Engineering: il ruolo dello sviluppo nel design dell'esperienza utente
UX Engineering: il ruolo dello sviluppo nel design dell'esperienza utenteMarco Pesani
 
Caso di successo: Gruppo Zucchetti e Micro Focus
Caso di successo: Gruppo Zucchetti e Micro FocusCaso di successo: Gruppo Zucchetti e Micro Focus
Caso di successo: Gruppo Zucchetti e Micro FocusMicrofocusitalia
 
Develer - Qt Embedded - Introduzione
Develer - Qt Embedded - Introduzione Develer - Qt Embedded - Introduzione
Develer - Qt Embedded - Introduzione Develer S.r.l.
 
RAMCUBE AG - software and services
RAMCUBE AG - software and servicesRAMCUBE AG - software and services
RAMCUBE AG - software and servicesluigich
 
MattiaBeltrano_azurePipelines.pptx
MattiaBeltrano_azurePipelines.pptxMattiaBeltrano_azurePipelines.pptx
MattiaBeltrano_azurePipelines.pptxAndreaCapolei1
 
EVOLUTIONBOOK: la forza di un team!
EVOLUTIONBOOK: la forza di un team!EVOLUTIONBOOK: la forza di un team!
EVOLUTIONBOOK: la forza di un team!EvolutionBook S.r.l.
 
Premio forumpa2017 chatbot_sogei_doc
Premio forumpa2017 chatbot_sogei_docPremio forumpa2017 chatbot_sogei_doc
Premio forumpa2017 chatbot_sogei_docMonica Gabrielli
 
Angular kit e Design system del Paese - Meetup ngRome 30 Gennaio 2023
Angular kit e Design system del Paese - Meetup ngRome 30 Gennaio 2023Angular kit e Design system del Paese - Meetup ngRome 30 Gennaio 2023
Angular kit e Design system del Paese - Meetup ngRome 30 Gennaio 2023AndreaStagi3
 

Similar a Guida alla realizzazione di un localization kit (20)

Produzione software
Produzione softwareProduzione software
Produzione software
 
Manuale Agile Stelnet
Manuale Agile StelnetManuale Agile Stelnet
Manuale Agile Stelnet
 
Iloveyou
IloveyouIloveyou
Iloveyou
 
La logisitca del Software OSS
La logisitca del Software OSSLa logisitca del Software OSS
La logisitca del Software OSS
 
La logisitca del software oss
La logisitca del software ossLa logisitca del software oss
La logisitca del software oss
 
Udev Presentazione
Udev PresentazioneUdev Presentazione
Udev Presentazione
 
Project Manager dalla Progettazione alla Gestione Web.pdf
Project Manager dalla Progettazione alla Gestione Web.pdfProject Manager dalla Progettazione alla Gestione Web.pdf
Project Manager dalla Progettazione alla Gestione Web.pdf
 
Brochure Soget - Italiano
Brochure Soget - ItalianoBrochure Soget - Italiano
Brochure Soget - Italiano
 
Microsoft Fast - Overview
Microsoft Fast - OverviewMicrosoft Fast - Overview
Microsoft Fast - Overview
 
UX Engineering: il ruolo dello sviluppo nel design dell'esperienza utente
UX Engineering: il ruolo dello sviluppo nel design dell'esperienza utenteUX Engineering: il ruolo dello sviluppo nel design dell'esperienza utente
UX Engineering: il ruolo dello sviluppo nel design dell'esperienza utente
 
Caso di successo: Gruppo Zucchetti e Micro Focus
Caso di successo: Gruppo Zucchetti e Micro FocusCaso di successo: Gruppo Zucchetti e Micro Focus
Caso di successo: Gruppo Zucchetti e Micro Focus
 
Vision software gestionale
Vision software gestionaleVision software gestionale
Vision software gestionale
 
Develer - Qt Embedded - Introduzione
Develer - Qt Embedded - Introduzione Develer - Qt Embedded - Introduzione
Develer - Qt Embedded - Introduzione
 
Develer - Qt Embedded - Intro
Develer - Qt Embedded - IntroDeveler - Qt Embedded - Intro
Develer - Qt Embedded - Intro
 
RAMCUBE AG - software and services
RAMCUBE AG - software and servicesRAMCUBE AG - software and services
RAMCUBE AG - software and services
 
MattiaBeltrano_azurePipelines.pptx
MattiaBeltrano_azurePipelines.pptxMattiaBeltrano_azurePipelines.pptx
MattiaBeltrano_azurePipelines.pptx
 
Sinossi
SinossiSinossi
Sinossi
 
EVOLUTIONBOOK: la forza di un team!
EVOLUTIONBOOK: la forza di un team!EVOLUTIONBOOK: la forza di un team!
EVOLUTIONBOOK: la forza di un team!
 
Premio forumpa2017 chatbot_sogei_doc
Premio forumpa2017 chatbot_sogei_docPremio forumpa2017 chatbot_sogei_doc
Premio forumpa2017 chatbot_sogei_doc
 
Angular kit e Design system del Paese - Meetup ngRome 30 Gennaio 2023
Angular kit e Design system del Paese - Meetup ngRome 30 Gennaio 2023Angular kit e Design system del Paese - Meetup ngRome 30 Gennaio 2023
Angular kit e Design system del Paese - Meetup ngRome 30 Gennaio 2023
 

Más de Luigi Muzii

Measuring for success: Goals, performances, and outcomes
Measuring for success: Goals, performances, and outcomesMeasuring for success: Goals, performances, and outcomes
Measuring for success: Goals, performances, and outcomesLuigi Muzii
 
Sharing efforts to get the most from MT+PE
Sharing efforts to get the most from MT+PESharing efforts to get the most from MT+PE
Sharing efforts to get the most from MT+PELuigi Muzii
 
Getting the Most from MT + PE
Getting the Most from MT + PEGetting the Most from MT + PE
Getting the Most from MT + PELuigi Muzii
 
Convegno Unilingue 2017
Convegno Unilingue 2017Convegno Unilingue 2017
Convegno Unilingue 2017Luigi Muzii
 
Standards, terminology and Europe
Standards, terminology and EuropeStandards, terminology and Europe
Standards, terminology and EuropeLuigi Muzii
 
TLC 2015 Warsaw - The Rumble Seat - Presentation
TLC 2015 Warsaw - The Rumble Seat - PresentationTLC 2015 Warsaw - The Rumble Seat - Presentation
TLC 2015 Warsaw - The Rumble Seat - PresentationLuigi Muzii
 
TLC 2015 Warsaw - The Rumble Seat - Companion Text
TLC 2015 Warsaw - The Rumble Seat - Companion TextTLC 2015 Warsaw - The Rumble Seat - Companion Text
TLC 2015 Warsaw - The Rumble Seat - Companion TextLuigi Muzii
 
Introduzione alla terminologia
Introduzione alla terminologiaIntroduzione alla terminologia
Introduzione alla terminologiaLuigi Muzii
 
KPIs and Capability Statements
KPIs and Capability StatementsKPIs and Capability Statements
KPIs and Capability StatementsLuigi Muzii
 
Europeo, Feb 1, 1991
Europeo, Feb 1, 1991Europeo, Feb 1, 1991
Europeo, Feb 1, 1991Luigi Muzii
 
Term Mining and Terminology Management in a Corporate Setting Perspective
Term Mining and Terminology Management in a Corporate Setting PerspectiveTerm Mining and Terminology Management in a Corporate Setting Perspective
Term Mining and Terminology Management in a Corporate Setting PerspectiveLuigi Muzii
 
Let's call the whole thing off
Let's call the whole thing offLet's call the whole thing off
Let's call the whole thing offLuigi Muzii
 
Diversità in rete: distanza che si trasforma in ricchezza
Diversità in rete: distanza che si trasforma in ricchezzaDiversità in rete: distanza che si trasforma in ricchezza
Diversità in rete: distanza che si trasforma in ricchezzaLuigi Muzii
 
Terminologia per la traduzione
Terminologia per la traduzioneTerminologia per la traduzione
Terminologia per la traduzioneLuigi Muzii
 
Is quality under pressure? Or is translation?
Is quality under pressure? Or is translation?Is quality under pressure? Or is translation?
Is quality under pressure? Or is translation?Luigi Muzii
 
Is quality under pressure? Or is translation?
Is quality under pressure? Or is translation?Is quality under pressure? Or is translation?
Is quality under pressure? Or is translation?Luigi Muzii
 
Vendor & Project Management
Vendor & Project ManagementVendor & Project Management
Vendor & Project ManagementLuigi Muzii
 

Más de Luigi Muzii (20)

Measuring for success: Goals, performances, and outcomes
Measuring for success: Goals, performances, and outcomesMeasuring for success: Goals, performances, and outcomes
Measuring for success: Goals, performances, and outcomes
 
Hic et Nunc
Hic et NuncHic et Nunc
Hic et Nunc
 
Sharing efforts to get the most from MT+PE
Sharing efforts to get the most from MT+PESharing efforts to get the most from MT+PE
Sharing efforts to get the most from MT+PE
 
Getting the Most from MT + PE
Getting the Most from MT + PEGetting the Most from MT + PE
Getting the Most from MT + PE
 
Convegno Unilingue 2017
Convegno Unilingue 2017Convegno Unilingue 2017
Convegno Unilingue 2017
 
White Noise
White NoiseWhite Noise
White Noise
 
Standards, terminology and Europe
Standards, terminology and EuropeStandards, terminology and Europe
Standards, terminology and Europe
 
ATC 2015
ATC 2015ATC 2015
ATC 2015
 
TLC 2015 Warsaw - The Rumble Seat - Presentation
TLC 2015 Warsaw - The Rumble Seat - PresentationTLC 2015 Warsaw - The Rumble Seat - Presentation
TLC 2015 Warsaw - The Rumble Seat - Presentation
 
TLC 2015 Warsaw - The Rumble Seat - Companion Text
TLC 2015 Warsaw - The Rumble Seat - Companion TextTLC 2015 Warsaw - The Rumble Seat - Companion Text
TLC 2015 Warsaw - The Rumble Seat - Companion Text
 
Introduzione alla terminologia
Introduzione alla terminologiaIntroduzione alla terminologia
Introduzione alla terminologia
 
KPIs and Capability Statements
KPIs and Capability StatementsKPIs and Capability Statements
KPIs and Capability Statements
 
Europeo, Feb 1, 1991
Europeo, Feb 1, 1991Europeo, Feb 1, 1991
Europeo, Feb 1, 1991
 
Term Mining and Terminology Management in a Corporate Setting Perspective
Term Mining and Terminology Management in a Corporate Setting PerspectiveTerm Mining and Terminology Management in a Corporate Setting Perspective
Term Mining and Terminology Management in a Corporate Setting Perspective
 
Let's call the whole thing off
Let's call the whole thing offLet's call the whole thing off
Let's call the whole thing off
 
Diversità in rete: distanza che si trasforma in ricchezza
Diversità in rete: distanza che si trasforma in ricchezzaDiversità in rete: distanza che si trasforma in ricchezza
Diversità in rete: distanza che si trasforma in ricchezza
 
Terminologia per la traduzione
Terminologia per la traduzioneTerminologia per la traduzione
Terminologia per la traduzione
 
Is quality under pressure? Or is translation?
Is quality under pressure? Or is translation?Is quality under pressure? Or is translation?
Is quality under pressure? Or is translation?
 
Is quality under pressure? Or is translation?
Is quality under pressure? Or is translation?Is quality under pressure? Or is translation?
Is quality under pressure? Or is translation?
 
Vendor & Project Management
Vendor & Project ManagementVendor & Project Management
Vendor & Project Management
 

Guida alla realizzazione di un localization kit

  • 1. Guida alla realizzazione di un localization kit Luigi Muzii
  • 2. 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.
  • 3. 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.
  • 4. 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
  • 5. dal prodotto, il kit dovrebbe comprendere una versione perfettamente funzionale del software, almeno in beta. Infine, un localization kit dovrebbe contenere tutti gli strumenti necessari per poter trattare i file. Organizzazione di un localization 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.
  • 6. 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.
  • 7. 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
  • 8. tutti i testi traducibili sono archiviati nei file di risorse, semplificando così la localizzazione. Tuttavia, in molti casi, i file che contengono i testi traducibili si trovano un po' dappertutto. È responsabilità del localization engineer individuare tutti i file traducibili e prepararli per la traduzione. 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:
  • 9.  obiettivi di progetto; o nome del prodotto; o nome o codice del progetto; o descrizione generale del prodotto e degli utenti di destinazione; o descrizione 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.
  • 10. Esempio di elenco di file localizzabili per una distinta dei materiali (BoM) Conteggio Nome file Tipo file Funzione Percorso Note e istruzioni parole default.asp Script lato Pagina di inizio 30 directory principale Riga 37: la variabile server navigazione strRedirect non deve (VBScript) superare i 75 caratteri Riga 271: non localizzare la variabile strLang content.asp Script lato Pagina 1,830 directory principale Riga 58: Localizzatori server contenitore spagnoli: utilizzare (VBScript) terminologia differente per i mercati spagnolo e messicano style.css Foglio di Gestisce la Style Riga 10: cambiare i stile visualizzazione caratteri Times New (CSS2) dei contenuti Roman con SimSun per il Cinese Semplificato (2052), PMingLiu per il Cinese Tradizionale (1028), MS Mincho per il Giapponese (1041) e Batang per il Coreano (1042) errmsg.inc Testo file include 10,000 IncludesEnMessages Stringhe di testo semplice visualizzate nelle finestre di messaggio per segnalare un errore. Materiale di 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 Problema file Percorso Problema Commenti Altro Nome risolto main.rc menu Linguistico Dopo una revisione accurata, alcuni oggetti principale suonano meglio in italiano se resi al plurale: Contatto > Contatti, Fornitore > Fornitori, Preventivo > Preventivi, Cliente > Clienti, Strumento > Strumenti, Progetto > Progetti
  • 11. Esempio di foglio per le domande Foglio per le domande: < nome del progetto > Terminologia italiano Urgente Nome del Termine (lingua di Pagina Termine/Problema Contesto Risposta (Si/No) file destinazione) Esempio di stato di avanzamento Parole Conteggio Avanzamento Giorni Data di Data di Nome del file da Risorse2 Produttività3 parole %1 correnti4 inizio fine tradurre rc1_en_olh.rtf 32.914 3.724 88,7% 6 333 1,9 10/3/2005 1/7/2005 1. 100-[(parole tradotte)*100/(parole da tradurre)] 2. persone coinvolte 3. (numero di parole al giorno)/(risorse) 4. (parole da tradurre)/[(risorse)*(produttività)] 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.
  • 12. 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.);
  • 13. file di progetto della guida (.hpj);  modelli e fogli di stile per la guida in formato HTML/XML;  file bitmap (.bmp);  file ipergrafici segmentati (.shg); Nel caso in cui sia necessaria una versione compilata, la cartella On-line help dovrà contenere anche una 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 Testo da Conteggi Note e Nome file Tipo file Funzione Percorso tradurre o parole istruzioni intro.bmp BMP, 8-bit, Immagine Premere un 5 GraphicsFinalMain Usare Arial 24 nessuna visutalizzat tasto per grassetto per compression a all'avvio continuare.. il testo; colore e del . del testo programma #FF9900
  • 14. Esempio di elenco di file grafici per una distinta dei materiali Testo da Conteggi Note e Nome file Tipo file Funzione Percorso tradurre o parole istruzioni back_off.jp JPEG, Immagine GraphicsFinalMain Collegamento g compression di sfondo in e 25% per la default.asp. pagina di è un'immagine benvenuto molto difficile del sito da riprodurre. internet Se si (back dimostrasse office) non adatta al vostro locale, riempire il relativo spazio con un'immagine vuota. scr01_en.gi Standard Schermata GraphicsFinalScreensho Ogni f GIF, 256 del menu ts schermata colori principale 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 Standard Diagramma Vedere le 155 GraphicsFinalArtwork Collegamento f GIF, 256 di flusso etichette di in colori che testo nel workflow.as fornisce un file p. Il sorgente quadro sorgente di questa generale immagine è del workflow.xc processo di f (vedi sotto), produzione realizzato con GIMP (GNU Image Manipulation Program).
  • 15. Esempio di elenco di file grafici per una distinta dei materiali Testo da Conteggi Note e Nome file Tipo file Funzione Percorso tradurre o parole istruzioni workflow.xc GIMP image Diagramma 155 GraphicsSourceArtwork Sorgente di f di flusso workflow.gi che f (vedi sopra). fornisce un Localizzare il quadro livello di testo generale nel file con del GIMP (GNU processo di Image produzione Manipulation Program, 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;
  • 16. 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 Frequenza Rateo di Tipo di Note e Nome file Funzione campioname Piattaforma Percorso file campioname istruzioni nto nto welcome. WAV 8 bit 44 kHz PC MultimediaAudio Associato al wav - Main menu Mono principale. Suono di benvenuto. intro.wm WMA Presentazion 24 bit 22 kHz Windows MultimediaAudio Collegament a - e Web o in Ster dell'applicazi default.as eo one Web p. file sorgente non disponibile. Dialoghi in intro_en.r tf. Usare Windows Media per ricreare il file audio. sample.m MPE Video 16 bit stereo 44 kHz Multipiattafo MultimediaVideo Collegament peg G-1 campionato rma Web o in training.a sp. Dialoghi in intro_en.r tf. Per ragioni di supporto, per ricreare il file audio utilizzare possibilment e Adobe Premiere, Ulead Video Studio o Pinnacle Liquid Edition. Per i file MPEG, potrebbe essere estrememente utile una versione del tutto aderente agli standard con time code 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;
  • 17.  il file grafico delle etichette per CD con la relativa versione a stampa (di solito in formato EPS);  la versione compilata (DTP) o il file grafico degli opuscoli e 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.
  • 18. 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.
  • 19. 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.
  • 20. 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 Milestone Data di baseline Data di fine Risultati dall'ultimo rapporto e prestazioni in contrasto Descrizione delle gg/mm/aaaa gg/mm/aaaa gg/mm/aaaa milestone Milestone previste per il Data di fine Data di fine prossimo periodo di Milestone Data di baseline precedente corrente avanzamento e loro modifiche in relazione al piano Descrizione delle gg/mm/aaaa gg/mm/aaaa gg/mm/aaaa precedente milestone Effetti del (mancato) Milestone Impatto raggiungimento delle milestone per il restante Descrizione delle milestone Breve descrizione delle modifiche periodo di progetto interessate da apportare al piano di progetto in conseguentza delle nuove milestone Informazioni generali Aggiungere eventuali commenti di carattere generale a supporto o integrazione delle sezioni precedenti.
  • 21. Modello di rapporto sullo stato del progetto <Nome progetto> Rapporto sullo stato del progetto n. <X> <Data> Budget Spese Data Spese effettive Avanzo/Disavanzo pianificate gg/mm/aaaa Piano gestione rischi di Rischio Probabilità Gravità Grado Variazione progetto (rispetto al rapporto precedente) Breve descrizione dei rischi Bassa Bassa A Aumento principali. Media Media B Riduzione Alta Alta C Novità Problemi Breve descrizione di tutte i problemi afferenti il progetto sorti dopo il precedente rapporto e che richiedono una soluzione. Raccomandazioni Brevi considerazioni da formulare o sottoscrivere. Piano di assicurazione della qualità Definire le attività da condurre per garantire la qualità del progetto e indicare come vadano coordinate, in 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
  • 22. Esempi di metriche Categoria Metriche Soddisfazione del  disponibilità dei deliverable cliente  difetti dei deliverable  affidabilità dei deliverable  responsabilità del gruppo di progetto  competenza del gruppo di progetto  cortesia del gruppo di progetto  comunicazione  credibilità del gruppo di progetto  affidabilità del gruppo di progetto rispetto agli impegni  professionalità del gruppo di progetto  tempi di risposta a quesiti e problemi  tempi medi di risoluzione dei problemi  numero di richieste di modifiche soddisfatte entro il budget e le scadenze iniziali di progetto Durata  durata effettiva vs. budget (varianza) Lavoro  lavoro effettivo vs. budget (varianza)  ore lavorate dal responsabile di progetto vs. ore di lavoro totali Produttività  ore lavorative per unità di prodotto  unità di prodotto per ora di lavoro  ore di lavoro in meno rispetto ai normali processi di progetto  ore di lavoro risparmiate attraverso il riutilizzo di componenti preesistenti  numero di idee implementate per il miglioramento dei processi  numero di ore risparmiate grazie al miglioramento dei processi Qualità dei  percentuale di deliverable sottoposta a controllo di qualità deliverable  percentuale di controlli sui deliverable superati al primo passaggio  numero di difetti riscontrati dopo 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.
  • 23. 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.
  • 24. 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"
  • 25. 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
  • 26. 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.