Il sito in due lingue non è un sito tradotto: guida tecnica

Dicembre 2022, gli ultimi giorni prima di Natale. Nel mio studio di Santa Maria Capua Vetere c'era il fermento tipico di quel periodo: un clima da festa che in quei giorni entra anche negli uffici.

Sullo schermo avevo Pasquale, un amico di Portici che qualche anno prima si era trasferito a Londra. Mi stava aiutando a valutare le opzioni migliori per costituire la nuova società inglese. Due sponde in una sola finestra di videochiamata.

Il 22 dicembre 2022 nasceva Insight Adv Ltd.

Fino a un attimo prima, Insight era un'agenzia italiana che parlava all'Italia. Da quel momento doveva parlare anche al Regno Unito, e a chiunque ci arrivasse dall'estero. Un sito bilingue non era più un'opzione. Era una necessità.

Un ponte non lo costruisci appendendo un cartello "Welcome" sopra l'insegna "Benvenuti". Scavi le fondamenta su tutte e due le sponde.

Non era la prima volta. Nel 2006 InsightAgency, l'agenzia creativa italiana da cui tutto è partito, aveva già un sito in quattro lingue: italiano, inglese, francese e russo. HTML, Flash e CSS. Una scelta precisa, per l'epoca. Sedici anni dopo la tecnica sotto il cofano era un'altra, e la lezione è rimasta identica: tradurre i testi è la parte facile.

Il lavoro vero si fa al buio. Tasto destro, "Ispeziona", apri l'<head> della pagina e leggi cosa c'è scritto davvero. Lì, dove il lettore non guarda mai e Google passa le notti, si decide se il tuo sito parla due lingue o balbetta in due.

Prima le parole giuste: multilingue, multiregionale, locale

Google distingue con precisione. Un sito multilingue offre contenuti in più lingue. Un sito multiregionale si rivolge esplicitamente a utenti di Paesi diversi. Il mio è entrambe le cose: italiano per l'Italia, inglese per il Regno Unito e per chi arriva dall'estero.

In codice, questa distinzione passa dai tag di lingua. Le mie pagine italiane dichiarano <html lang="it-it" dir="ltr">, quelle inglesi <html lang="en-gb" dir="ltr">. È la base giusta. I tag di lingua non distinguono tra maiuscole e minuscole: scrivo it-IT ed en-GB solo per convenzione.

Il classico errore è en-UK. Il codice del Regno Unito nella norma internazionale ISO è GB, e UK non è il valore corretto. Un dettaglio minuscolo, ma è la spia che ti dice se chi ha messo le mani sul codice sa cosa sta facendo.

Il codice, però, è solo il contenitore. Il contenuto deve riflettere il mercato.

Prendi Berto. Ha una carpenteria metallica nella zona industriale tra Santa Maria Capua Vetere e Capua, beve il caffè corto in tre sorsi e chiede un preventivo. Prendi Bobby. Ha un birrificio artigianale a Salford, ordina la pinta dopo le cinque e chiede una quote. Stessa persona, stessa esigenza. Parole diverse.

Questo non è tradurre. È scegliere.

Quattro lingue nel 2006, due nel 2022

Rimettiamo in ordine i fatti. Nel 2006 InsightAgency apre con un sito statico in HTML, Flash e CSS, in italiano, inglese, francese e russo. Era il sito principale. Al suo fianco cresceva un sito dinamico in PHP, solo in italiano: un progetto secondario, ancora in evoluzione.

Poi Flash è stato dismesso. Adobe ne ha chiuso il supporto il 31 dicembre 2020. Ho aggiornato il sito in HTML perché funzionasse senza Flash, ma l'energia è andata sul sito in PHP, che ha accelerato fino al completamento. A quel punto il multilingua non era una priorità. È rimasto indietro, e nel 2022 il conto è arrivato.

Il russo, intanto, non mi aveva mai dato problemi di caratteri. Su un sito di pagine statiche potevo scegliere la codifica pagina per pagina. Su un sito dinamico con un solo database la scelta è una per tutto, e oggi si chiama UTF-8: la codifica che rappresenta tutti gli alfabeti.

Il punto non è la nostalgia. È la differenza tra un sito che si pubblica e uno che si mantiene. Su un sito statico le lingue sono pagine che restano ferme. Su un sito che vive di articoli, ogni lingua in più è un impegno che si rinnova a ogni aggiornamento.

Di come un brand impara a parlare due lingue ho scritto in Dalla serra di Caserta a Londra. Qui parlo di tecnica, ed è un altro mestiere.

L'architettura: dove abitano le due lingue

Le tre strade (e una da evitare)

Dove vivono, fisicamente, la versione italiana e quella inglese? La documentazione di Google Search Central mette davanti tre strade.

La quarta strada, i parametri nell'URL come ?lang=en, la cito solo per scartarla: Google non la raccomanda.

La mia scelta

Il sito vive su un solo dominio, .it, con le sottocartelle /it/ e /en/. Possiedo anche .uk, .ltd.uk ed .eu, che servono lo stesso sito, ciascuno sul proprio indirizzo, e .co.uk, che inoltra al .uk. Per i motori di ricerca sono copie: la canonical dovrebbe tenerle a bada, e il rimedio pulito sarebbe un redirect 301 verso il dominio principale.

Il limite della scelta è evidente: .it è un segnale geografico forte per l'Italia, e il pubblico inglese sta nel Regno Unito. Ho dei numeri per misurarlo. Da gennaio il Regno Unito è l'undicesimo Paese per utenti: 470, l'1,74% del totale. Il tasso di interazione è del 9,38%, il tempo medio di interazione di 2 secondi, nessuna conversione registrata. Sono numeri da avviso, non da mercato. La spiegazione è più semplice del dominio: il sito cresce solo in modo organico, e l'unica promozione passa dai canali social, dove i follower sono soprattutto italiani, soprattutto sui miei profili. Il Regno Unito non lo sto ancora raggiungendo.

La mia posizione è questa: la struttura giusta è quella che riesci a tenere in ordine per anni. Un dominio nazionale trascurato fa più danni di una sottocartella ben curata.

La radice del sito e l'inganno dell'indirizzo IP

Per anni è stata di moda una pratica: leggi l'indirizzo IP di chi arriva e lo mandi in automatico alla sua lingua. Google la sconsiglia. Il motivo è tecnico: il suo crawler scansiona soprattutto da indirizzi statunitensi e non imposta la lingua preferita del browser. Se rediriggi in base alla posizione, Googlebot può non vedere mai una delle due versioni.

La regola è semplice: lascia che sia l'utente a scegliere, oppure presenta una pagina selettore.

Se chiedo insightadv.it/ senza dichiarare nessuna lingua, finisco su /it: per chi non dichiara preferenze, il sito parte dall'italiano.

Nei prossimi giorni lavorerò a un sistema che orienti il visitatore in base alla sua lingua, ed è il momento giusto per scrivere le regole prima di scrivere il codice:

1. Suggerire, non forzare. Un avviso discreto ("Vuoi leggere questa pagina in inglese?") che chi legge può chiudere, non un salto automatico.
2. Agire solo sulla radice. Chi apre un indirizzo esplicito, /it/ o /en/, ci resta: se ha cliccato o ha incollato quel link, voleva quella pagina.
3. Guardare la lingua del browser, non l'indirizzo IP. Un italiano a Londra legge in italiano. La lingua dichiarata dal browser racconta meglio di chi legge che il Paese da cui si connette.
4. Ricordare la scelta. Se qualcuno sceglie una lingua, il sito non gliela richiede a ogni visita. Come si conserva quella scelta, e se richieda o meno il consenso, lo verifico con un consulente privacy.
5. Lasciare ai motori di ricerca tutte e due le strade. Gli indirizzi di entrambe le lingue restano raggiungibili da semplici link, senza dipendere da nessuna intestazione del browser.

Quando sarà in produzione, lo racconterò qui.

Una URL, una lingua

Ogni versione ha un suo indirizzo stabile. Niente pagine miste, e gli slug (la parte finale dell'indirizzo) vanno tradotti: /it/blog/sito-bilingue e /en/blog/bilingual-website, non due pagine con lo stesso slug italiano. Come vedrai nell'autopsia, il mio sito non lo fa dappertutto.

hreflang: il patto di reciprocità

Facciamo una prova. Due telefoni. Berto, seduto a un tavolino di Piazza Adriano a Santa Maria Capua Vetere, cerca un'agenzia creativa. Bobby, fuori da un pub di Salford, cerca una creative agency. Senza nessuna dichiarazione, Google deve indovinare quale pagina mostrare a chi. A volte indovina. L'hreflang smette di farglielo fare a caso.

L'hreflang è un'annotazione, invisibile a chi legge, che dice ai motori di ricerca: questo indirizzo italiano e questo indirizzo inglese sono la stessa pagina in lingue o regioni diverse.

Le regole, dalla documentazione di Google, sono poche e non negoziabili:

• ogni versione elenca se stessa e tutte le altre;
• l'insieme dei link è identico su ogni versione;
• i link stanno nell'<head>, oppure negli header HTTP, oppure nella sitemap: scegline uno solo e non mescolarli.

Un esempio illustrativo, con slug fittizi:

<link rel="alternate" hreflang="it-IT" href="https://insightadv.it/it/blog/slug-italiano" />
<link rel="alternate" hreflang="en-GB" href="https://insightadv.it/en/blog/slug-inglese" />
<link rel="alternate" hreflang="x-default" href="https://insightadv.it/it/blog/slug-italiano" />

È un incastro a coda di rondine. Se una delle due parti non tiene, non regge nessuna delle due.

Cos'è davvero x-default

x-default è il valore per tutte le lingue che non hai elencato, o per la pagina selettore. Non decide in base al Paese: decide in base a ciò che manca. È un segnale, non un ordine, ed è raccomandato più che obbligatorio.

Il mio x-default punta alla pagina italiana, la stessa URL dell'it. Il sito è nato in italiano e l'inglese è stato aggiunto dopo: è una scelta di storia, non di strategia, e la cambio a breve.

La regola che applicherei: il fallback deve parlare la lingua del pubblico che vuoi raggiungere fuori dai due mercati principali. Per un sito che si rivolge anche a Polonia, Bulgaria, Romania e Ucraina, il fallback naturale è l'inglese, oppure un selettore.

Gli errori classici

1. Il link non reciproco. La pagina italiana punta all'inglese e l'inglese non risponde: Google ignora la coppia.
2. en-UK al posto di en-GB.
3. Hreflang su pagine escluse dalla canonical. La canonical è il tag che dice quale URL è quello "ufficiale".
4. Metodi mescolati. Un po' nell'head e un po' nella sitemap.
5. Il solo auto-riferimento mancante. Ogni versione deve elencare anche se stessa.

Sulla canonical, una regola secca: ogni versione linguistica ha la propria canonical che punta a se stessa. La pagina inglese non deve mai puntare all'italiana.

lang non è hreflang

L'attributo lang che hai visto nell'<html> non serve a Google per decidere a chi mostrare la pagina: la documentazione è chiara su questo. Serve a chi legge con un lettore di schermo, alla sillabazione automatica, ai correttori. È un pezzo dell'accessibilità, e ne ho scritto in Accessibilità web 2026.

Come si verifica

Tasto destro, "Visualizza sorgente". Oppure, da terminale:

curl -s https://tuosito.it/it/pagina | grep -i hreflang

Non fidarti mai di un plugin che ti dice "tutto ok". Leggi il codice.

Joomla e Falang: cosa fa il CMS e cosa no

Il CMS (il sistema che gestisce i contenuti) di insightadv.it è Joomla, con EasyBlog per il blog. Joomla ha un sistema multilingua nativo, fatto di plugin e di associazioni tra contenuti, ma molti siti si affidano a un componente di terze parti. Io uso Falang: lo dice il sorgente, dove il selettore di lingua è il modulo mod_falang. Falang traduce i contenuti nel database e gestisce il cambio di lingua.

Chi usa il sistema nativo trova nel tracker pubblico di Joomla due insidie note: la canonical che sparisce con gli alternate meta tags attivi (issue 42128) e l'hreflang assente se l'elemento associato è nel cestino (issue 13359). Con Falang il comportamento può essere diverso, e non l'ho verificato.

Ho verificato invece il mio. Ho aperto il sorgente di una pagina italiana, la categoria Corso di fotografia, e poi la sua gemella inglese.

Quello che funziona:

• tre tag hreflang (it, x-default, en) e la pagina che dichiara se stessa;
• una canonical che punta alla pagina stessa, sia nella versione italiana sia in quella inglese;
• gli indirizzi dei post tradotti, come /en/blog/the-different-typologies-of-digital-cameras-and-not-only.

Il bug della canonical che sparisce, qui, non c'è.

Quello che non torna:

1. L'hreflang inglese è en, non en-GB. È valido e vale per chiunque legga inglese, e per un sito che parla anche a Polonia, Bulgaria, Romania e Ucraina è perfino coerente. Ma il sito dichiara en-gb nell'html e en nell'hreflang: due livelli di precisione, e una scelta che dovrei spiegare.
2. Gli slug inglesi di categorie e pagine sono rimasti italiani. La gemella della categoria è /en/blog/categories/corso-di-fotografia, e nel menu ci sono /en/servizi/advertising e /en/l-agenzia/the-our-method. I post sono tradotti, le categorie no: in questo articolo dico che gli slug vanno tradotti, e per metà del sito non l'ho fatto.
3. Stringhe nella lingua sbagliata. Nella pagina italiana, l'anteprima per i social (og:description) dice "There is no description for this category.". Nella pagina inglese, la meta description e il suffisso del titolo ("Il blog della Insight Adv Ltd") sono in italiano, e nei moduli restano "Nome utente", "Password", "Ricordami" e "voti".
4. Il selettore usa le bandiere. Due bandierine con le sigle IT ed EN accanto: l'opposto di ciò che sostengo nella sezione sul selettore.
5. Il logo e il "Home" del percorso di navigazione puntano alla radice, non a /en/: da una pagina inglese, un clic sul logo passa da insightadv.it/, che senza preferenze porta all'italiano.

Sono carenze di cui sono consapevole, e mi sto preparando a superarle. Le scrivo qui perché un articolo che predica il rigore non può nascondere i propri difetti.

I sei controlli che faccio:

1. il sorgente della home;
2. il sorgente di un post del blog;
3. il selettore di lingua: genera URL puliti?
4. la canonical: punta a se stessa?
5. l'attributo lang nell'<html>;
6. il comportamento del sito se una traduzione manca.

Il selettore di lingua

Il selettore non è un abbellimento. È l'interruttore della luce.

Prendo una posizione editoriale, non una regola di legge: niente bandiere. Le bandiere rappresentano Paesi, non lingue. L'inglese che leggi non appartiene a un solo Paese, e uno svizzero del Canton Ticino parla italiano senza parlare il tricolore. Il mio selettore, come hai visto nell'autopsia, usa ancora le bandiere: è un debito che dichiaro.

Il modello è il design system di GOV.UK. Il componente Language navigation scrive il nome della lingua nella lingua stessa ("Cymraeg", non "Welsh"), con gli attributi lang e hreflang, e precisa che non traduce nulla: i contenuti vanno creati e mantenuti per ogni lingua. Il pattern per passare al gallese, nei design system di DWP, aggiunge un'altra regola: chi cambia lingua resta sulla stessa pagina del servizio, non ricomincia dall'inizio.

E se la pagina non ha una gemella? Il selettore porta alla home dell'altra lingua. Mai a un 404. Con un sito tradotto al 100% il caso è raro, ma esiste, per esempio quando una traduzione è in bozza.

Trascreare, non tradurre

Il mio sito non è tradotto alla lettera. Ogni contenuto, blog compreso, esiste in italiano e in inglese, con testi in un inglese britannico naturale. Fanno eccezione i video.

Il metodo è questo. Scrivo l'articolo in italiano, perché è la lingua in cui mi viene naturale. L'articolo viene poi tradotto con l'IA, e la traduzione la verifico io. Se ho un dubbio, passo il testo ai collaboratori a Londra e ad altri strumenti linguistici per controllare che sia tutto corretto. In ciascuna lingua cerco la naturalezza del linguaggio.

Tre coppie dal blog, con quello che cambia:

Non è sempre andata così. Nel titolo inglese dell'articolo sull'influencer di quartiere, del 22 settembre 2026, c'è scritto neighborhood, all'americana. In un sito che dichiara en-gb dovrebbe essere neighbourhood. E nel menu c'è "Write us", un calco di "Scrivici": un britannico scriverebbe "Contact us" o "Get in touch". I testi recenti del blog sono riscritti. Le stringhe d'interfaccia più vecchie, no.

C'è una cautela. Lo slang londinese rende naturale il tono su un pubblico di Shoreditch o di Hackney. Un cliente di Manchester o di Salford può sentirlo come una parodia. Va deciso apposta, non per riflesso.

È come la parmigiana a Londra. Non porti la ricetta in valigia e la ripeti uguale. La rifai con gli ingredienti che trovi a Borough Market, e deve restare parmigiana.

Numeri e valute

In Italia si scrive 1.234,56, nel Regno Unito 1,234.56. L'euro spesso va dopo la cifra (100 €), la sterlina sta sempre prima (£100).

Nella tabella dei prezzi di Quanto costa davvero un sito web l'italiano scrive £3.000, con il punto, e la versione inglese £3,000, con la virgola. La cella cambia insieme alla lingua. Nessuno se ne accorge finché è giusto, e chiunque se ne accorge quando è sbagliato.

Date, ortografia, moduli

Italia e Regno Unito condividono il giorno prima del mese, a differenza degli Stati Uniti. La differenza sta nei nomi dei mesi e nel rischio di scivolare nell'inglese americano (colour e color, organisation e organization): lo hai visto, nel caso di neighborhood. Un modulo italiano chiede provincia e CAP, uno inglese county e postcode. Il prefisso passa da +39 a +44. Se clono un modulo senza trascrearlo, il cliente si ferma al momento di compilarlo.

Tipografia

I font devono avere tutti i glifi: à, è, é, ì, ò, ù per l'italiano, il simbolo £ per l'inglese britannico. Nel mio <head> i font che carico oggi (Bricolage Grotesque e Merriweather) sono dichiarati per sottoinsiemi di caratteri: accenti italiani, £ ed € stanno nel sottoinsieme latin, quindi il controllo è passato. Sui font ho scritto in Tipografia Web e in variable fonts. Le virgolette cambiano: «caporali» in italiano, “doppi apici” in inglese. La sillabazione automatica del CSS (hyphens: auto) funziona in base alla lingua dichiarata, quindi senza un lang corretto non sillaba.

Poi ci sono gli spazi. I titoli in italiano tendono a essere più lunghi dell'equivalente inglese. Una hero section che regge con tre parole in inglese può sbordare su due righe in italiano. Della struttura della prima schermata ho scritto in Il primo schermo mente sempre.

Immagini e social

I testi dentro le immagini vanno duplicati, gli attributi alt tradotti e pensati per la ricerca di ciascuna lingua. Per i social, la dichiarazione Open Graph og:locale deve passare da it_IT a en_GB.

Il video non è bilingue: come dichiararlo

I contenuti video sono l'unica parte del sito che non esiste in entrambe le lingue, quindi qui il lavoro è dichiarare e rendere accessibile. Del metodo per riusare un video in più contenuti ho scritto in Un video, dieci contenuti.

Sul piano tecnico servono i sottotitoli nel player HTML5, con l'elemento <track kind="subtitles" srclang="en">. Sul piano dei dati strutturati, schema.org prevede la proprietà inLanguage per dichiarare la lingua dell'audio.

Sul piano dell'accessibilità, i sottotitoli per i video preregistrati sono un requisito di livello A delle WCAG (Web Content Accessibility Guidelines, le linee guida internazionali sull'accessibilità), criterio 1.2.2. E se incorpori un video in italiano in una pagina inglese, la lingua di quella parte va dichiarata con lang (criterio 3.1.2).

Un video in italiano non rompe la coppia hreflang: le pagine sono equivalenti. Ma serve una riga chiara che avvisi chi legge in inglese: Video in italiano, con sottotitoli in inglese. La lingua di un video è un fatto. Il difetto è non dichiararla.

Cookie e privacy: due leggi, un sito

Qui il codice finisce e comincia il diritto. Premessa: non sono un avvocato, e questa sezione va verificata con un consulente privacy.

Il titolare del trattamento è Insight Adv Ltd, una società britannica registrata presso l'ICO, l'autorità britannica per la protezione dei dati, come dichiara il piè di pagina. Due regimi sullo stesso sito.

In Italia conta il Garante per la protezione dei dati personali. Le sue linee guida sui cookie (provvedimento n. 231 del 10 giugno 2021, Gazzetta Ufficiale del 9 luglio 2021, operative da gennaio 2022) fissano quattro punti. Lo scroll della pagina non è consenso. Il cookie wall, cioè "accetta o non entri", non è ammesso. La "X" di chiusura del banner vale come rifiuto. Dopo un rifiuto il banner non va riproposto prima di sei mesi, salvo eccezioni. Per gli analytics, le stesse linee guida ammettono, a condizioni precise, i cookie statistici senza consenso: le condizioni esatte vanno lette nel testo.

Nel Regno Unito i cookie sono regolati dal PECR (Privacy and Electronic Communications Regulations) e dalla versione britannica del GDPR, il regolamento sulla protezione dei dati. Il Data (Use and Access) Act 2025 ha cambiato il PECR, e secondo le fonti che ho consultato le modifiche sono in vigore dal 5 febbraio 2026. La novità è un'eccezione per le statistiche, ma è stretta: i dati devono essere aggregati e usati solo per migliorare il servizio, il fornitore deve agire per tuo conto senza usarli per scopi propri, serve un'informazione chiara e un modo semplice per opporsi. Pubblicità, profilazione e tracciamento tra siti richiedono ancora il consenso. Le analisi che ho letto indicano che strumenti come Google Analytics difficilmente rientrano nell'eccezione. L'ICO ha pubblicato la sua guida definitiva a maggio 2026: la fonte da leggere è ico.org.uk.

Il confronto è questo. Italia e Regno Unito ammettono entrambe i cookie statistici senza consenso, a condizioni diverse e restrittive. Nessuna delle due è un lasciapassare per gli analytics di terze parti.

Il banner deve parlare la lingua della pagina. Quanto al comportamento, hai due strade: uno standard unico, il più severo, per tutti, oppure comportamenti diversi per Paese. Attenzione alla distinzione: variare il banner in base al Paese è un conto, rediriggere in base all'IP è un altro. Il primo non toglie a Google la vista su nessuna delle due versioni. Il secondo sì.

Per la newsletter, modulo e informativa vanno nella lingua di chi si iscrive. Il modulo della mia newsletter è gestito da SendFox, un servizio esterno: la lingua e la forma del consenso dipendono da quello che il servizio mi permette di scrivere. Il doppio consenso è una buona pratica, non un obbligo di legge. Sui banner e sulle trappole di design, ho scritto in Il trucco che ora è reato, in Il cookie è morto e, sulle regole del 2021, in Nuove linee guida sui cookies.

Come si tiene in piedi un sito tradotto al 100%

Tradurre tutto ha un vantaggio. Per Google le versioni localizzate sono duplicate solo se il contenuto principale resta nella lingua originale, quindi se traduci tutto non corri quel rischio. E la documentazione consiglia di bloccare con robots.txt le pagine tradotte automaticamente e non curate: la traduzione fatta male è un debito.

Il costo è un altro. Ogni articolo ha due versioni da scrivere, collegare e pubblicare. La pubblicazione, da me, è quasi immediata: finito l'articolo in italiano e la traduzione, li carico sul sito. Il caso difficile è un altro: la correzione di un articolo già uscito. Se non ci stai attento, è lì che una delle due versioni resta indietro.

Nemmeno chi lo fa meglio traduce tutto. Il Government Digital Service di GOV.UK dà priorità alle traduzioni in gallese in base ai bisogni degli utenti. Io scelgo di tradurre ogni cosa, e so che significa pagare ogni aggiornamento due volte.

Il mio criterio è questo: un sito bilingue non si misura da quante pagine ha il giorno del lancio, ma da quante restano allineate dopo un anno.

Due esempi dal mondo

Il modello: GOV.UK. L'ho già citato per il selettore, ma il punto è un altro. Il Government Digital Service non ha costruito un sito tradotto: ha costruito un sito pensato per tutti i suoi utenti, e il gallese ne fa parte. La guida richiama i criteri WCAG 3.1.1 e 3.1.2 sull'attributo di lingua e dà priorità alle traduzioni in base ai bisogni reali di chi legge. È la differenza tra tradurre e localizzare.

L'avvertimento: Italia.it, 2007. Il portale che doveva presentare l'Italia al mondo fu presentato a febbraio 2007. Erano stati stanziati 45 milioni di euro, e la spesa effettiva è contestata nelle fonti, tra circa uno e circa sette milioni. Fu chiuso a gennaio 2008. Secondo le cronache dell'epoca non rispettava la Legge Stanca, la norma italiana sull'accessibilità dei siti pubblici. L'AIAP, l'associazione dei grafici italiani, promosse una petizione contro il marchio e fece notare che lo slogan "L'Italia lascia il segno" ricalcava quello di campagne spagnole e portoghesi. Parlare al mondo non vuol dire copiare il modo in cui il mondo si presenta. E un sito pubblico che non si legge con un lettore di schermo non parla a tutti.

Conclusione

Torno a quel dicembre: lo studio di Santa Maria Capua Vetere, la videochiamata con Pasquale, il 22 dicembre in cui nasceva Insight Adv Ltd. Un sito bilingue era diventato una necessità, e un ponte non si costruisce con un cartello, ma con fondamenta su due sponde. Oggi so anche altro: le fondamenta non si scavano una volta, si controllano ogni settimana. E si controllano dal sorgente, non dal browser.

Le carenze che ho elencato sono queste, in ordine: l'hreflang inglese senza regione e l'x-default sull'italiano; gli slug italiani nelle categorie e nel menu inglese; le stringhe nella lingua sbagliata; il selettore con le bandiere; gli alias che duplicano il sito; il logo che punta alla radice; l'og:locale che manca; un titolo all'americana e un calco nel menu. Sono carenze di cui sono consapevole, e mi preparo a superarle. Quando l'avrò fatto, lo scriverò qui.

Un sito tradotto parla due lingue con una voce sola. Un sito localizzato parla a due persone diverse. Il primo costa meno, e perde in entrambi i mercati.

Costruisco siti web per mestiere, ed è per questo che so quanto costa un errore che nessuno vede. Se hai un sito in due lingue, apri il sorgente stasera. Se qualcosa non torna, scrivimi.

Fonti

• Google Search Central, Tell Google about localized versions of your page
• Google Search Central, Managing multi-regional and multilingual sites
• GOV.UK Design System, Language navigation
• DWP Design System, Toggle to Welsh
• GOV.UK, Welsh language on GOV.UK
• W3C, WCAG 2.2
• Adobe, annuncio di fine supporto di Flash Player (31 dicembre 2020)
• Garante per la protezione dei dati personali, Linee guida cookie e altri strumenti di tracciamento, provvedimento n. 231 del 10 giugno 2021 (GU n. 163 del 9 luglio 2021)
• Information Commissioner's Office (ICO), guida sulle tecnologie di archiviazione e accesso, 2026, ico.org.uk
• PMI.it, Rinasce il portale Italia.it
• 01net, Il grande flop di Italia.it