:: Pretesti ::

:: Appunti su tecnologie, società, comunicazione creativa :: home :: perche' pretesti :: archivio :: contattaci ::
[::..feed site..::]
atom
[::..categorie..::]
:: disservizi [>]
:: meditazione [>]
:: usability [>]
[::..link amici..::]
:: inform-arch [>]
:: trovabile [>]
:: idearium [>]
:: megachip [>]
:: indymedia [>]
:: ied com [>]
:: articolo 21 [>]
:: rekombinant [>]
:: blog mds [>]
:: resmini.net [>]
:: diodati.org [>]

:: 30.10.02 ::

Tradurre un sito in più lingue: now panic

"Those French, they have a different word for everything”
Steve Martin


E' veramente sorprendente la quantità di problemi da affrontare nel momento in cui si decide di mettere online un certo numero di versioni tradotte in lingua straniera di un sito. Un'esperienza in cui è necessario prendere tante piccole decisioni, ognuna delle quali avrà effetti a cascata - sulla navigabilità del sito, sulla quantità del lavoro di manutenzione, sull'efficacia del risultato finale - spesso difficili da prevedere.

1. Traduciamo tutto o...
In molti casi le "versioni in lingua" non sono in realtà traduzioni del sito ma soltanto le versioni tradotte di poche pagine statiche. Se si prende questa via (per carità, del tutto rispettabile) molti dei problemi che seguono non si pongono. Diverso è se invece si intende pubblicare interamente, o nella sua massima parte, un sito complesso, riproducendo le modalità di navigazione e di interazione. Nel caso dei siti dinamici, in cui le pagine sono generate automaticamente a partire da un database, la decisione su cosa tradurre e cosa non tradurre va anticipata al momento dell'analisi e della progettazione del database. Infatti bisognerà definire, per ogni record, quali campi duplicare per le lingue straniere e inserirli nel DB. Dopodché, al momento dell'inserimento dei dati, ovviamente, il lavoro si moltiplica.
Nella nostra esperienza, si trattava di un sito complesso articolato in: parti statiche (aggiornate con un editor HTML senza periodicità), parti dinamiche (aggiornate automaticamente con i dati inseriti in un database, più che quotidianamente) e sottositi. Abbiamo tradotto integralmente le parti statiche, non i sottositi (per la natura del loro contenuto) e non le parti dinamiche (per l'impraticabilità della traduzione nelle varie lingue di tutti i contenuti inseriti quotidianamente). Al posto delle sezioni dinamiche sono state create sezioni ad hoc, differenti da quelle in lingua originale.
Come gestire però il passaggio tra contenuti tradotti e non tradotti, quando le versioni non collimano? Ecco il secondo problema.

2. Come gestire i passaggi dalla versione in lingua a quella originale e viceversa?
Può sembrare una sottigliezza ma spesso nei siti tradotti in più lingue è facile (lo dico da utente) smarrirsi nel passaggio dalla versione in lingua originale a quella tradotta. Si stava leggendo tutto in italiano, ed ecco improvvisamente il menu di navigazione è di nuovo in tedesco... Cos'è successo? Il fatto è che se si lasciano alcune parti non tradotte, ma non le si tolgono dai menu di navigazione, chi visita il sito può passare senza accorgersene dalla versione tradotta a quella originale.
Quando i siti in lingua straniera non sono completi, ci sono due alternative: o si eliminano i riferimenti alle sezioni non tradotte oppure, per rendere comunque fruibili tutti i contenuti, quando non siano presenti nella versione in lingua si rimanda alla versione originale. La distinzione dipende ovviamente da una valutazione dell'importanza dei contenuti in questione e delle motivazioni della loro mancata traduzione. Nel caso si scelga la seconda strada, però, (il link alla versione originale) può essere opportuno aprire il sito in lingua originale in una nuova finestra e/o inserire dei segnali di avvertimento che indichino al visitatore che sta uscendo dalla versione tradotta.

3. Una lingua per volta o tutte insieme?
A mio avviso è preferibile realizzare le versioni in lingua in parallelo, in modo da gestire nel modo più omogeneo possibile le varie decisioni e velocizzare le procedure impaginando simultaneamente la stessa pagina in tutte le lingue. E' anche vero, secondo alcuni, che procedere con una lingua per volta permette di affrontare tutti i dubbi all'inizio e proseguire più speditamente con le lingue successive. Probabilmente dipende anche da sito a sito, e dal numero di lingue in ballo (la traduzione simultanea è praticabile soltanto se si ha a che fare con due-tre versioni tradotte, altrimenti diventa ingestibile).
Un altro stratagemma consigliabile è non avviare il lavoro di traduzione appena lanciato un nuovo sito. E' meglio concedersi circa due-tre settimane di tempo (a seconda della tipologia di sito, della sua dimensione e del ritmo degli aggiornamenti) per collaudare i nuovi servizi, verificare le problematiche legate all'aggiornamento e effettuare il "fine-tuning" nella versione originale.

4. Chi traduce?
Di norma si ha un traduttore o un'agenzia di traduzioni cui si recapitano i testi da tradurre, e che li restituisce tradotti. Già questa circostanza presenta però il primo problema. Il traduttore ha idea di dove si collocano i testi? Che si faccia un giro nel sito è più che consigliato. Infatti è indispensabile che chi traduce si renda conto di quali sono i termini chiave (per esempio le voci del menu di navigazione - da tradurre sempre allo stesso modo), quale il tono generale del sito (per capire che registro linguistico adottare), quale lo scopo e il target a cui si rivolge. Meglio ancora sarebbe se il traduttore potesse prelevare i testi, invece che da un documento consegnatogli ad hoc, direttamente dal sito... o addirittura, contrattualizzare un traduttore/web editor che si occupi anche della stessa realizzazione pratica delle pagine. Questa soluzione - purtroppo nella maggior parte dei casi del tutto impraticabile - permetterebbe di coinvolgere il traduttore più pesantemente nei problemi generali di comunicazione dell'azienda (per esempio, verificare se e come altri settori dell'azienda traducono materiali promozionali. E potrebbe aiutare, tra l'altro, a risolvere il quarto problema.

5. E il microcontent?
Pensare che per tradurre un sito sia sufficiente inviare i testi al traduttore, per poi copiarli e incollarli nel template originale, significa quantomeno peccare di eccessivo ottismismo. Bisognerà infatti aver cura di far tradurre anche tutto il cosiddetto "microcontent": didascalie, testi alternativi per le immagini, testi presenti nelle icone e nelle foto, link e pulsanti di navigazione (con gli eventuali link title). Senza dimenticare gli eventuali banner autopromozionali e/o pubblicitari, i messaggi di errore e di conferma e via dicendo. Tutto ciò può ben presto trasformarsi in un incubo.
Tra le mille cose cui far attenzione c'è per esempio il fatto che le scritte brevi per "statuto" - i nomi delle sezioni che devono comparire nel menu di navigazione, le scritte incluse nelle icone, nei banner, nelle foto, nelle didascalie - potrebbero cambiare drammaticamente lunghezza una volta tradotte. Sarà quindi il caso di sensibilizzare il traduttore a compiere uno sforzo lessicale... oppure di far trovare al grafico nuove soluzioni visive per inglobare nei template le nuove scritte.
E a questo proposito, chi avrà realizzato un sito più "usabile", limitando i testi inclusi nella grafica, a questo punto troverà la giusta gratificazione per il suo sforzo. Considerate infatti che per inserire i testi tradotti nella grafica non solo è necessario realizzare nuovamente tutte le GIF o JPG, ma se si ha a che fare con lingue che utilizzano altri alfabeti anche avere le giuste estensioni di carattere in Photoshop o nell'editor visivo che si usa...

6. Aiuto: i caratteri
Detto per inciso, se lo spagnolo, con i suoi accenti, può costituire un fastidio, non parliamo dell'arabo, del russo e del cinese. O meglio di tutte le lingue che usano altri alfabeti. Lì infatti bisognerà verificare la codifica dei caratteri... Senza entrare nel vespaio di Unicode, mi limito a dire che andrà verificato che su tutti i browser, tutte le piattaforme sia possibile leggere correttamente i caratteri arabi, ciricillici e via dicendo.

7. Date, giorni, orari
Un microcontent tipico a cui fare attenzione è la data: quando si dà il caso, sarà necessario modificare lo script usato per generarla, in modo che nella versione in lingua sia visualizzata con il formato richiesto e usando i termini giusti per i giorni della settimana e i mesi. Se il sito include calendari, bisogna fare attenzione anche alle lettere che indicano i giorni della settimana.
Per non parlare degli orari, che ovviamente non possono mai essere indicati in modo neutrale (tranne nella lingua originale, dove in genere possiamo dare per scontato che il fuso di riferimento è quello del paese originario). La soluzione migliore è identificare un fuso di riferimento (GMT o UTC è spesso lo standard per l'Europa, ma a seconda del contenuto del sito può essere preferibile usare come riferimento l'ora locale originale, quindi, nel caso di un sito italiano, l'ora italiana. Attenzione però che i rapporti tra GMT e altri fusi cambiano con l'adozione dell'ora legale, complicando ulteriormente la cosa).
In alcuni casi si può usare una soluzione che dà molta soddisfazione: uno script che rileva il fuso impostato sul computer dell'utente e in base a quello ricalcola gli orari indicati.

8. Che fare con i nomi delle cartelle e dei file?
La domanda che si pone molto presto nella lavorazione è: traduciamo anche i nomi delle cartelle e dei file, o lasciamo l'architettura delle directory in italiano (assumendo che la lingua originale sia l'italiano)? Nella nostra esperienza, abbiamo optato per la prima ipotesi: puntando ad una traduzione "completa", non potevamo esimerci dal fornire anche nelle URL percorsi intellegibili e coerenti. Ecco però un altro elemento da far tradurre per tempo, forse addirittura prima di tutto il resto.
Quando si ha a che fare con molte lingue, di cui alcune del tutto sconosciute al team di lavoro, può essere preferibile lasciare i nomi dei file e delle directory nella lingua originale (in modo da essere sempre in grado di verificare su quale file in quale lingua si sta lavorando), anteponendo però una sigla per identificare la lingua: p.es. jp_chisiamo.html.

9. Come si arriva alle versioni in lingua?
La bandierina - questo lo sanno tutti - va evitata. Il motivo è abbastanza evidente: lo spagnolo non è parlato solo in Spagna, la lingua inglese va ben al di là del territorio della Gran Bretagna ecc. Il metodo migliore per realizzare il cosiddetto "language gateway" è utilizzare il nome della lingua, espresso nella lingua stessa: English, Francais ecc. Se le lingue sono diverse da quelle "classiche", assicuratevi che il traduttore vi mandi anche il nome della lingua in cui sta traducendo, nella lingua in cui sta traducendo (perdonate lo scioglilingua). Ovviamente è altamente preferibile inserire questi "gateway" in tutte le pagine, nella barra di navigazione, nel pie' di pagina o in un apposito menu a tendina, perché non tutti i visitatori entrano nel sito dalla home page. Trovo molto fastidiose le cover realizzate appositamente per indirizzare, ancora prima dell'ingresso nel sito, alle varie versioni in lingua. Ognuno dovrebbe poter entrare e navigare nel sito in versione originale o tradotta e poi passare con un clic, da qualsiasi pagina, ad un'altra versione. Normalmente però il link, dovunque si trovi, rimanderà sempre alla home page della versione tradotta.

10. Questioni di cultura: tradurre, "localizzare" o "globalizzare"?
Una cosa è tradurre, altro è localizzare (cioè adattare il contenuto allo specifico target geografico) e altro ancora globalizzare (cioè rendere il contenuto del sito adatto a tutte le audiences internazionali). Alcuni consigli per la globalizzazione vanno tenuti presenti nella redazione dei contenuti già nella lingua originale, in previsione delle traduzioni. Per esempio, nei testi e nelle icone è necessario non usare metafore legate al calcio, al baseball, ecc. o a elementi culturali tipicamente locali che possano non essere compresi nei paesi di destinazione; a seconda dei paesi cui ci si rivolge, poi, è bene anche fare attenzione ad alcune norme di cortesia adottare in paesi non occidentale (non usare icone che puntano l'indice, o il piede, contro il visitatore del sito). Se poi si intende localizzare il contenuto, ciò comporta trasformare tutti i riferimenti alla valuta, alle misure, alle date, ma anche modificare il contenuto in base al rapporto che si ha con quel target, inserendo riferimenti specifici all'area linguistica e all'attività condotta dall'azienda in quell'area.

Qualche link per approfondire (in inglese):
- interessante guida alla "web globalization" nel sito di una società di traduzioni statunitense
- l'Alertbox di Jakob Nielsen dedicato al problema delle versioni internazionali di un sito web (del 1996)
- qualche altro consiglio su Web Developers Virtual Library


:: sandra 10/30/2002 03:50:00 PM :: permalink
...

Pretesti 2002-2008. Tutti i testi di questo blog sono rilasciati sotto Creative Commons License
Registrazione Tribunale Civile di Roma n. 398 del 12/07/2002
This page is powered by Blogger. Isn't yours?