Un sito web in decine di lingue: i18n pratica per l’e-commerce
Internazionalizzare un sito e-commerce oltre una manciata di lingue fa emergere tutte le ipotesi implicite in una base di codice progettata per un’unica lingua e area geografica. Il lavoro per renderla adeguata — estrazione delle stringhe, formattazione localizzata, adattamenti del layout RTL — è ben compreso in teoria ed estremamente laborioso nella pratica. Meno compresa è la sequenza di decisioni che determina se il risultato sarà un’esperienza davvero localizzata o una facciata evidentemente tradotta da una macchina, seppure visualizzata nel sistema di scrittura corretto.
Dopo aver affrontato questo processo per siti destinati a decine di lingue e aree geografiche, la conclusione più rilevante è che l’implementazione tecnica rappresenta la parte minore del problema. La pipeline di traduzione, l’architettura degli URL e la configurazione hreflang sono problemi ingegneristici risolvibili. L’adattamento culturale — capire cosa rende credibile una scheda prodotto in Giappone, in Germania o in Brasile — è il punto in cui la maggior parte dei progetti di localizzazione fallisce, perché non può essere completamente automatizzato e richiede conoscenze costose da acquisire.
Struttura degli URL: la decisione più difficile da cambiare in seguito
La struttura degli URL di un sito multilingue è la prima decisione da prendere e la più difficile da ribaltare. Tre approcci sono realmente diffusi: domini separati per lingua e area geografica (example.de, example.fr), sottodomini (de.example.com, fr.example.com) e sottodirectory (example.com/de/, example.com/fr/). Le conseguenze per l’autorevolezza SEO, la complessità della distribuzione e l’onere operativo non sono equivalenti.
I domini separati offrono l’esperienza utente più chiara e consentono un hosting completamente indipendente per ciascun mercato, ma frammentano l’autorevolezza del dominio: il beneficio di anni di link in entrata verso example.com non si trasferisce direttamente a example.de. Per siti con traffico organico consolidato, è un costo significativo. Per nuovi siti destinati a mercati in cui i domini di primo livello locali trasmettono fiducia, la valutazione cambia.
Le sottodirectory per lingua e area geografica sono l’approccio più comunemente consigliato per consolidare l’autorevolezza SEO e, in genere, la scelta giusta per siti e-commerce senza valide ragioni per separare i mercati a livello di dominio. Il compromesso è che tutte le versioni condividono l’infrastruttura: una distribuzione che interessa una versione può influire su tutte. Per la maggior parte dei team è un vincolo operativo accettabile.
La cosa più importante è decidere consapevolmente, fin dall’inizio e con piena comprensione delle implicazioni SEO e operative. Cambiare la struttura degli URL dopo che un sito ha accumulato link in entrata e indicizzazione costa così tanto che la scelta iniziale tende a persistere anche molto dopo che ne sono emersi i limiti.
La pipeline di traduzione
Una pipeline di traduzione per decine di lingue comprende tre attività distinte, spesso confuse fra loro: traduzione automatica iniziale per creare una base, revisione umana per correggere errori e adattare il tono, manutenzione continua al variare dei contenuti di origine. Ciascuna ha costi diversi e un diverso limite qualitativo.
La traduzione automatica è migliorata al punto da costituire una base credibile per la maggior parte delle lingue dell’Europa occidentale e una base utilizzabile, ma più limitata, per giapponese, cinese e lingue con sistemi onorifici complessi. Il risultato va comunque revisionato, indipendentemente dalla qualità: non perché la traduzione automatica sbagli sistematicamente, ma perché produce regolarmente testi tecnicamente corretti e inadeguati nel tono. Un testo legale tradotto da una macchina suona come tale e indebolisce la credibilità che i contenuti localizzati dovrebbero creare.
Mantenere aggiornate le traduzioni quando cambiano i contenuti è la sfida operativa che i piani di espansione sottovalutano regolarmente. Aggiornare il contenuto di origine in una lingua genera un arretrato di traduzione per tutte le altre versioni. Senza un tracciamento esplicito delle traduzioni aggiornate, i contenuti obsoleti si accumulano senza essere notati, finché un utente di un mercato non anglofono non trova una scheda prodotto con i prezzi dell’anno precedente o una funzionalità dismessa presentata come disponibile.
La scelta degli strumenti — un sistema di gestione delle traduzioni, file semplici o un livello di gestione dei contenuti basato su database — dovrebbe dipendere da questo flusso di manutenzione, non dal volume iniziale di traduzioni. Un approccio basato su file, rapido da avviare, diventa un problema su larga scala se non dispone di strumenti per individuare e dare priorità all’arretrato di traduzione.
hreflang: implementazione ed errori comuni
I tag hreflang indicano ai motori di ricerca quale versione linguistica e regionale di una pagina mostrare ai diversi utenti. La documentazione fa sembrare semplice l’implementazione: aggiungere a ogni pagina un insieme di tag <link rel="alternate">, uno per ciascuna lingua e area geografica, con i codici linguistici corretti (un codice lingua ISO 639-1, seguito facoltativamente da un codice regione ISO 3166-1 alpha-2, come de o de-AT). Nella pratica, le possibilità di errore sono tali che un’implementazione scorretta di hreflang è la norma, più che l’eccezione.
L’errore più comune è un insieme di riferimenti hreflang incompleto. Ogni versione deve rimandare a tutte le altre, inclusa sé stessa, nei propri tag hreflang. Se una pagina elenca sette versioni su otto, la coppia mancante non è più reciproca e Google ignora le annotazioni hreflang tra pagine che non rimandano entrambe l’una all’altra. Generare questi tag programmaticamente da un unico elenco delle lingue e aree geografiche supportate evita il problema, ma solo se l’elenco viene aggiornato correttamente quando si aggiungono o rimuovono versioni.
Il secondo errore comune è la mancata corrispondenza dei valori hreflang: il tag della pagina inglese punta a /de/product-name, ma l’URL canonico della pagina tedesca è in realtà /de/produktname. Succede quando si traducono gli slug, come è opportuno per la SEO nei mercati in cui contano le parole chiave locali, senza aggiornare i riferimenti hreflang. Un controllo automatizzato, che esplori il sito e verifichi che ogni tag hreflang rimandi a un URL canonico esistente, è l’unico modo affidabile per rilevare queste discrepanze su larga scala.
Il valore hreflang x-default viene spesso frainteso. Non significa «lingua predefinita», ma «per gli utenti che non corrispondono ad alcuno dei tag linguistici e regionali specifici». Per la maggior parte dei siti dovrebbe puntare alla versione nella lingua principale, ma nei siti con pagine di selezione della lingua o reindirizzamenti basati sulla geolocalizzazione può correttamente puntare altrove.
RTL: non basta invertire il layout
Il supporto delle lingue scritte da destra a sinistra — arabo, ebraico, persiano (farsi), urdu e altri sistemi di scrittura da destra a sinistra — è trattato nella maggior parte dei progetti come un problema CSS: aggiungere dir="rtl" all’elemento radice, invertire le direzioni flex, specchiare padding e margini e considerare il lavoro concluso. In realtà, il supporto RTL fa emergere ipotesi sul layout che restano invisibili finché non cambia la direzione di lettura.
La direzionalità delle icone è la dimenticanza più comune. Frecce di navigazione, indicatori di avanzamento e icone che puntano a sinistra o a destra hanno un significato semantico che va specchiato nei contesti RTL: una freccia «indietro» che punta a sinistra in LTR dovrebbe puntare a destra in RTL. La proprietà CSS transform: scaleX(-1) esegue l’operazione meccanicamente, ma richiede di controllare ogni icona direzionale dell’interfaccia per assicurarsi di specchiarla solo dove appropriato.
Le cifre, i numeri di telefono e i codici postali si leggono da sinistra a destra anche nel testo RTL e non vanno specchiati. Poiché l’algoritmo bidirezionale Unicode tratta le cifre e i loro separatori come caratteri deboli o neutri, la loro posizione dipende dal testo circostante. Questi valori devono quindi spesso essere isolati, per esempio con <bdi> o dir="ltr". Mescolare contenuti LTR e RTL in un unico blocco di testo, per esempio una descrizione prodotto con un numero di modello, richiede controlli bidirezionali Unicode espliciti o un uso accurato degli attributi HTML dir, per evitare che l’algoritmo bidirezionale del browser produca un risultato confuso.
Adattamento culturale oltre la traduzione
Localizzazione e traduzione non sono la stessa attività. La traduzione converte le parole. La localizzazione converte il significato e richiede di capire il contesto culturale che determina cosa comunica un messaggio a un pubblico specifico.
Le differenze commercialmente più significative riguardano i segnali di fiducia. Ciò che rende credibile una scheda prodotto varia molto da un mercato all’altro: i clienti tedeschi danno peso a marchi di certificazione e specifiche tecniche; quelli giapponesi alla reputazione del marchio e alla qualità dell’imballaggio; quelli americani alla riprova sociale e alla visibilità della politica di reso. Una scheda che converte bene in un mercato può convertire male in un altro a parità di qualità della traduzione, perché layout e priorità valorizzano i segnali di fiducia sbagliati.
I metodi di pagamento sono un’altra dimensione culturale, spesso trattata come un’integrazione tecnica anziché come un aspetto della localizzazione. In Germania, bonifico bancario (Überweisung) e addebito diretto SEPA restano modalità d’acquisto importanti. In Giappone, il pagamento nei convenience store è ancora molto utilizzato. Offrire soltanto carte di credito e PayPal in questi mercati non è un errore di traduzione, ma un fallimento pratico della localizzazione: non si risponde alle abitudini dei clienti.
Una valutazione onesta è che la maggior parte dei siti e-commerce multilingue è tradotta, non localizzata. Il testo è nella lingua giusta, ma l’esperienza non è stata adattata al mercato. Per le aziende che competono con operatori locali, il divario fra traduzione e localizzazione è all’origine delle differenze nei tassi di conversione del traffico organico.
Approfondimenti correlati
- Interventi SEO che fanno davvero la differenza: URL canonici, sitemap e barre finali — gli interventi SEO tecnici specifici associati a una migliore indicizzazione e a un miglior posizionamento dei siti multilingue.
- Astro i18n: creare un sito statico in nove lingue senza CMS — i dettagli di implementazione dell’instradamento i18n e del sistema di traduzione usati su questo sito.
- La nostra strategia per lasciare Shopify: valutare alternative e-commerce headless — come i requisiti i18n hanno influenzato la decisione di valutare piattaforme headless come alternative a Shopify.