L’adattamento di un’applicazione ad un contesto multilingue è un compito complesso. I principali punti di intervento, in funzione della lingua della sessione, sono i seguenti:
- Modifica delle proprietà degli elementi visuali e delle liste valori.
- Modifica delle stringhe contenute nel codice.
- Modifica dei formati di input e output dei numeri e delle date.
- Modifica delle descrizioni di entità estratte dal database.
Ovviamente non tutte le proprietà, le liste valori, le stringhe, i formati e le descrizioni devono risultare tradotte, solo quelle che si riferiscono ad un contesto multilingue.
Per ottenere questo risultato occorre un sistema in grado di localizzare tutte le istanze di stringhe da tradurre, permettere ai traduttori di effettuare la traduzione conoscendo il contesto, infine un sistema che adatti l’output dell’applicazione verso il browser selezionando i dati di traduzione relativi alla lingua di ogni diversa sessione di lavoro.
L’approccio tradizionale #
L’approccio tradizionale, possibile anche con Instant Developer Cloud, è piuttosto semplice: utilizzare una mappa, cioè un insieme di elementi chiave-valore, per valorizzare ogni elemento visuale che contiene informazioni dipendenti dalla lingua. È quindi sufficiente un oggetto javascript definito a livello di applicazione che rappresenta le traduzioni di tutti gli oggetti traducibili, in tutte le lingue disponibili. Poi, tramite codice, si carica la traduzione corretta.
Immaginiamo di avere quindi un oggetto così costituito:
App.traduzioni = {
ITEM_LABEL: {
“it”: “Articolo”,
“en”: “Item”,
“ru”: “пункт”,
…
},
…
};In tutti i punti in cui ci si riferisce all’etichetta di un articolo è sufficiente scrivere la seguente riga di codice nell’evento onLoad oppure onRowComposition.
$itemLabel.innerText = App.traduzioni.ITEM_LABEL[app.langCode];Dove app.langCode è la proprietà della sessione che rappresenta il codice della lingua (“it”, “en”, eccetera).
Si potrebbe considerare anche un approccio più generale, creando un metodo che scorre la struttura degli elementi visuali di una videata e applica tutte le traduzioni in base al nome dell’elemento, ma come vedremo in seguito, questa non è un’opzione percorribile.
Problemi dell’approccio tradizionale #
I problemi che l’approccio tradizionale pone sono molti. Vediamo i principali:
- Durante lo sviluppo è necessario decidere da subito quali sono le informazioni che devono essere localizzate. Questa informazione, invece, non è così scontata ed è facile dimenticarsene, considerato che anche in un’applicazione costituita da dieci videate si può facilmente arrivare ad avere centinaia di stringhe localizzabili.
- Non è facile decidere se la medesima informazione deve avere lo stesso codice di traduzione o meno: dovendo rendere localizzabile la label Articolo in diverse videate, è vero che in tutte queste si deve usare sempre la stessa costante ITEM_LABEL? Oppure devono essere tutte diverse? Questa decisione spetterebbe ad un esperto linguista, non ad un programmatore che sta scrivendo il codice di traduzione.
- Se si hanno migliaia di proprietà traducibili, la modifica dell’oggetto di traduzione e la ricerca di proprietà già esistenti diventa impossibile o comunque molto costosa.
- Il caso precedente fa diventare ancora più inaffidabile l’utilizzo di un metodo di traduzione generico in base ai nomi degli elementi. Essi vengono scelti con altri criteri dai programmatori, basta che siano univoci, non certo con criteri linguistici.
- L’estrazione, la programmazione e l’implementazione dell’oggetto contenente le traduzioni è quindi un compito complesso che richiede tempo e quindi denaro.
- Se poi l’applicazione deve diventare localizzabile dopo che essa è già stata sviluppata in modo non localizzabile, ad esempio perché cambiano le specifiche in una versione successiva, si tratta di una vera e propria riprogrammazione di almeno tutto il front-end.
- Anche il compito dei traduttori non è facile: ricevendo un oggetto JSON come quello precedente, non hanno minimamente idea del contesto in cui le informazioni devono apparire. Quindi la precisione della traduzione sarà minima, sotto allo stato dell’arte di una traduzione professionale, tanto vale usare Google Translate.
- Quando una stringa deve essere modificata nella lingua madre, ad esempio perché cambiano le funzioni dell’interfaccia utente, non è facile tenere traccia delle differenze fra una versione e la successiva. I traduttori dovrebbero utilizzare un software CAT (Computer-Assisted Translation) in grado di tracciare le differenze, ma questo non è sempre vero. Inoltre, l’affidabilità del tracciamento delle differenze dipende dalla struttura dei file che vengono dati in input a tali strumenti: se i file non sono strutturati in modo compatibile con i software CAT, il tracciamento in molti casi non è possibile. Comunque non è facile essere certi di non pubblicare un’applicazione parzialmente tradotta o con traduzioni non aggiornate, magari solo in alcune lingue.
- Anche la lingua madre di un’applicazione dovrebbe essere considerata come una traduzione, infatti se il contenuto testuale dell’interfaccia viene deciso dagli sviluppatori, occorre anche qui un esperto linguista per rendere più comprensibile l’applicazione all’utente finale.
L’approccio Instant Developer Cloud #
Solitamente il problema delle traduzioni viene considerato come “poco importante” dai reparti tecnici che si occupano di sviluppo. Dal punto di vista dell’utente finale, invece, avere una applicazione non tradotta o non comprensibile è un difetto di pari gravità ad un comportamento errato, forse in alcuni casi ancora peggiore.
Per convincersene è sufficiente provare ad installare un’applicazione non localizzata in una lingua non familiare, come ad esempio russo o cinese. Non sarà possibile nemmeno iniziare ad usarla.
Anche un sito molto famoso può essere inutilizzabile se non correttamente localizzato
Visti i problemi che l’approccio tradizionale pone sia a livello di tempi e costi di sviluppo, sia, soprattutto, di precisione del risultato e vista l’importanza che l’utente finale pone su questo argomento, Instant Developer Cloud include un framework specifico e una serie di strumenti IDE ad esso dedicati.
L’obiettivo di questi strumenti è di ottimizzare il processo di localizzazione degli elementi visuali, delle liste valori e delle stringhe inserite a livello di codice, sia nell’applicazione principale che in eventuali componenti importati, risolvendo tutti i problemi indicati sopra.
I paragrafi seguenti illustrano il processo di preparazione e di traduzione. Al termine di questo libro verrà indicata una strategia per la traduzione delle descrizioni provenienti dal database.