Domenica 11 settembre 2011
Volete espandervi a livello mondiale e avete bisogno di un sito web all'altezza? Si tratta solo di far tradurre del testo e siete a posto, giusto? Probabilmente no. Il team di Google per i webmaster realizza spesso siti che sono localizzati in oltre 40 lingue: ecco alcuni aspetti che prendiamo in considerazione quando lanciamo le nostre pagine in altre lingue e aree geografiche.
Anche se ritenete di essere immuni a questi problemi perché offrite solo contenuti in inglese, è possibile che i visitatori non anglofoni utilizzino strumenti come Google Traduttore per visualizzare i vostri contenuti nella propria lingua. Dovreste vedere questo traffico nella dashboard di analisi, in modo da farvi un'idea di quanti visitatori non visualizzano il sito come previsto.
Più lingue non significa più modelli HTML
Non ci stancheremo mai di ripeterlo: riutilizzate lo stesso modello per le versioni in tutte le lingue e cercate sempre di mantenere semplice l'HTML del modello.
Utilizzare lo stesso codice HTML per tutte le lingue ha i suoi vantaggi in termini di manutenzione; rimaneggiare il codice HTML per ogni lingua per correggere i bug non consente un approccio scalabile: il codice della pagina deve essere il più ordinato possibile per risolvere eventuali problemi di stile nel CSS. Citiamo solo uno dei vantaggi di un codice scritto bene: la maggior parte degli strumenti di traduzione analizza le stringhe di contenuti traducibili nel documento HTML e questa operazione è molto più semplice quando l'HTML è ben strutturato e valido.
La lunghezza delle stringhe
Se il vostro design è basato su del testo che si inserisce in elementi a dimensione fissa, la traduzione del testo potrebbe provocare disastri. Ad esempio, è probabile che il testo della barra di navigazione a sinistra venga tradotto in stringhe di testo molto più lunghe in diverse lingue; date un'occhiata alla differenza di lunghezza delle stringhe tra inglese e olandese per gli stessi contenuti nel pannello di navigazione. Preparatevi a possibili titoli di navigazione che potrebbero occupare più di una riga cercando di capire l'altezza della riga che ospita questo testo (potrebbe valere la pena fare queste considerazioni nelle fasi iniziali, quando create il testo di navigazione in inglese).
La lunghezza variabile delle parole causa problemi particolari nelle etichette e nei controlli dei moduli. Se, ad esempio, il layout del modulo mostra le etichette a sinistra e i campi a destra, le stringhe di testo più lunghe possono occupare due righe, mentre quelle più brevi non sembrano essere associate ai relativi campi di immissione del modulo; entrambi gli scenari compromettono il design e la leggibilità del modulo. Valutate inoltre lo stile aggiuntivo che vi servirà per i layout da destra verso sinistra (RTL), su cui trovate maggiori informazioni più avanti nell'articolo. Per questi motivi, progettiamo moduli con etichette sopra i campi per favorire una migliore leggibilità e uno stile che possa adattarsi bene a tutte le lingue.
Evitate anche colonne ad altezza fissa: se state cercando di migliorare il layout con sfondi delle caselle che corrispondono all'altezza, è probabile che il testo, dopo che è stato tradotto, eccederà il limite di altezza di aree progettate per includere solo contenuti in inglese. Cercate di capire se gli elementi dell'interfaccia utente che prevedete di utilizzare nel vostro design funzioneranno in presenza di una quantità di testo maggiore o minore, ad esempio schede orizzontali o verticali.
La modifica bidirezionale
La modifica del testo di partenza per codice HTML bidirezionale può essere problematica perché molti editor non sono stati creati per supportare l'algoritmo bidirezionale Unicode (ulteriori ricerche su problemi e soluzioni). In breve, il markup potrebbe essere mostrato in modo incomprensibile:
<p>
ابةتث
<img src="foo.jpg" alt=" جحخد" />
< ذرزسش!
</p>
Dal nostro utilizzo quotidiano è emerso che i seguenti editor al momento forniscono soluzioni accettabili per la modifica bidirezionale: Coda, Dreamweaver, IntelliJ IDEA e JEditX.
Se progettate per lingue da destra a sinistra, potete sviluppare la maggior parte del supporto necessario nel CSS principale e utilizzare l'attributo direzionale dell'elemento html (per la compatibilità con le versioni precedenti) in combinazione con una classe nell'elemento body. Come sempre, tenere tutti gli stili in un singolo foglio di stile principale migliora la manutenibilità.
Ecco alcuni problemi di stile importanti a cui prestare attenzione: eventuali elementi spostati a destra devono essere trasferiti a sinistra e viceversa; le larghezze extra di spaziatura interna o margini applicate a un solo lato di un elemento dovranno essere sostituite e modificate ed eventuali attributi text-align devono essere invertiti.
In genere, applichiamo il seguente approccio, incluso l'utilizzo di una classe nel tag body anziché un selettore CSS html[dir=rtl], perché é compatibile con i browser meno recenti:
Elementi:
<body class="rtl">
<h1>
<a href="https://www.blogger.com/">
<img alt="Google" src="https://www.google.com/images/logos/google_logo.png" />
</a> Heading
</h1>
Stile da sinistra a destra (predefinito):
h1 {
height: 55px;
line-height: 2.05;
margin: 0 0 25px;
overflow: hidden;
}
h1 img {
float: left;
margin: 0 43px 0 0;
position: relative;
}
Stile da destra a sinistra:
body.rtl {
direction: rtl;
}
body.rtl h1 img {
float: right;
margin: 0 0 0 43px;
}
(Potete vedere un'applicazione pratica in inglese e arabo).
Un'ultima nota su questo argomento: nella maggior parte dei casi i vostri contenuti destinati a pagine in lingue con direzione da destra a sinistra sono bidirezionali anziché prettamente RTL; questo perché è probabile che alcune stringhe debbano mantenere la propria direzione da sinistra a destra, come i nomi delle aziende in alfabeto latino o i numeri di telefono. Per assicurarvi che il browser gestisca correttamente questo aspetto in un documento principalmente RTL, dovete mandare a capo le stringhe di testo incorporate con un elemento incorporato utilizzando un attributo per impostare la direzione, come descritto di seguito:
<h2>עוד ב- <span dir="ltr">Google</span></h2>
Se non avete un contenitore HTML in cui agganciare l'attributo dir, come gli elementi title o il codice sorgente generato da JavaScript per i messaggi di avviso, potete utilizzare questo equivalente per impostare la direzione, dove ‫ e ‬ sono caratteri di controllo Unicode per l'incorporamento da destra a sinistra:
<title>‫הפוך את Google לדף הבית שלך‬</title>
Esempio di utilizzo nel codice JavaScript:
var ffError = '\u202B' +'כדי להגדיר את Google כדף הבית שלך ב\x2DFirefox, לחץ על הקישור \x22הפוך את Google לדף הבית שלי\x22, וגרור אותו אל סמל ה\x22בית\x22 בדפדפן שלך.'+ '\u202C';
Per ulteriori dettagli, consultate gli articoli di W3C sulla creazione di HTML per arabo, ebraico e altri sistemi di scrittura da destra a sinistra e sulla creazione di sistemi di scrittura da destra a sinistra.
Per me è arabo…
Se non avete mai lavorato con set di caratteri non latini (cirillico, greco e una miriade di contenuti asiatici e indoari), potreste notare che sia l'editor che il browser non mostrano i contenuti come previsto.
Verificate che le codifiche dell'editor e del browser siano impostate su UTF-8 (opzione consigliata) e valutate la possibilità di aggiungere un elemento <span> e l'attributo lang dell'elemento html al modello HTML, in modo che i browser sappiano cosa aspettarsi dal rendering della pagina: ciò comporta l'ulteriore vantaggio di garantire che tutti i caratteri Unicode vengano visualizzati correttamente, pertanto non è necessario utilizzare entità HTML come é (é), risparmiando byte preziosi. Se avete difficoltà, consultate il tutorial di W3C sulla codifica dei caratteri, che contiene spiegazioni approfondite dei problemi.
Qualche parola sulla denominazione
Infine, un suggerimento pratico sulle convenzioni di denominazione quando create versioni in tante lingue. L'utilizzo di uno standard come i codici lingua ISO 639-1 per la denominazione è di aiuto quando iniziate a gestire versioni dello stesso documento in molte lingue.
L'impiego di uno standard convenzionale aiuterà gli utenti a comprendere la struttura del vostro sito, oltre a renderlo più gestibile per tutti i webmaster che potrebbero svilupparlo; utilizzare i codici lingua per altri asset del sito (immagini di loghi, documenti PDF) è utile per poter identificare rapidamente i file.
Consultate i precedenti post del Centro webmaster per consigli sulle strutture degli URL e su altri problemi sull'utilizzo di siti web multiregionali e di siti web multilingue.
Questo è un riepilogo delle principali sfide che dobbiamo affrontare ogni giorno; tuttavia, possiamo garantire che la pianificazione e il lavoro preliminare per scrivere codice HTML ben strutturato e un CSS efficace ripagheranno poi in fase di localizzazione.