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.