Come pianificare un sito multilingue in Svizzera

Partite dai mercati e dalle attività dei clienti, non dal numero di lingue

La Svizzera è multilingue, ma questo non significa che ogni azienda svizzera debba offrire ogni pagina in tedesco, francese, italiano e inglese. La domanda utile è quali clienti intendete servire, che cosa devono riuscire a fare e se il vostro team può rispondere nella lingua pubblicata.

Partite da dati concreti: conversazioni commerciali, richieste ricevute, assistenza clienti, ricerche e piani di espansione. Distinguete una lingua che genera già ricavi da una che rappresenta un esperimento. Un percorso di acquisto completo in tedesco e francese può risultare più credibile di quattro selettori linguistici che conducono a contenuti parziali o obsoleti.

Per ogni pubblico definite l’attività principale. Un responsabile degli acquisti può aver bisogno di specifiche e di un preventivo; un cliente locale, di conoscere la disponibilità e telefonare; un partner internazionale, di verificare le credenziali aziendali. Queste attività determinano quali pagine, prove e moduli vanno localizzati insieme.

• Elencate mercati attuali e previsti, decisori e copertura dei servizi.
• Annotate la lingua usata nelle vendite, nell’erogazione e nell’assistenza successiva.
• Contrassegnate le pagine che incidono su acquisto, richiesta, contratto o assistenza.
• Non promettete una gestione delle richieste in una lingua che l’azienda non è in grado di garantire.

Scegliete consapevolmente tra versioni linguistiche e regionali

Un codice di lingua descrive la lingua. Un codice regionale facoltativo restringe la regione prevista. Per contenuti in tedesco destinati in generale ai lettori potete usare de; per contenuti tedeschi adattati specificamente alla Svizzera, de-CH. Lo stesso criterio vale per fr e fr-CH, it e it-CH, en e en-CH.

Un codice paese da solo non è una lingua. ch non è quindi un valore hreflang valido. Aggiungere una regione a ogni URL aumenta inoltre il lavoro di manutenzione: fatelo soltanto quando prezzi, terminologia, informazioni legali, disponibilità o offerta differiscono davvero.

Mantenete un solo URL canonico per ciascuna versione prevista della pagina. Non create varianti svizzere, tedesche e austriache con lo stesso testo soltanto per occupare più risultati di ricerca. Se il contenuto è realmente identico tra regioni, una versione linguistica più ampia può essere la scelta più chiara.

• Usate versioni per sola lingua quando i contenuti sono ampiamente condivisi.
• Usate versioni lingua-regione per un pubblico o un’offerta significativamente regionali.
• Mantenete coerenti URL, canonical e intento hreflang.
• Documentate il motivo di ogni variante regionale.

Create una matrice delle versioni locali prima di progettare i modelli

Una matrice delle versioni locali trasforma un piano di traduzione astratto in un inventario. Assegnate una riga a ogni intento di pagina e uno stato a ogni versione locale. Registrate URL, canonical, responsabile, versione di origine, stato di approvazione e varianti corrispondenti. In questo modo emergeranno le lacune prima che diventino menu non funzionanti o annotazioni fuorvianti.

Considerate una società di consulenza svizzera fittizia. Offre pagine di consulenza in quattro lingue, ma un servizio normativo specialistico esiste soltanto in tedesco perché per ora viene erogato solo in quella lingua. La matrice corretta non inventa tre equivalenti vuoti: pubblica la pagina tedesca e la esclude dal gruppo multilingue finché non esistono servizi localizzati reali.

Identificatori stabili aiutano i team ad associare le pagine equivalenti anche quando le parole negli URL localizzati cambiano. Il percorso visibile può essere tradotto, mentre il sistema editoriale conserva un unico ID condiviso per la pagina.

Create gruppi hreflang completi e reciproci

Hreflang associa equivalenti localizzati. Non traduce il contenuto e non ne determina da solo la lingua. Google supporta le annotazioni nell’head HTML, nelle intestazioni HTTP o in una sitemap XML e precisa che applicare tutti e tre i metodi non offre vantaggi per la ricerca. Scegliete il metodo che il team può generare e verificare con regolarità.

Ogni elemento di un gruppo deve indicare se stesso e tutti gli altri. Se la pagina A indica la pagina B ma B non restituisce il riferimento, Google può ignorare l’associazione. Gli URL devono essere assoluti e condurre alla pagina canonica prevista.

Un URL x-default può offrire una soluzione di riserva agli utenti che non corrispondono alle versioni disponibili, spesso un selettore linguistico o una versione adatta a un pubblico ampio. È una soluzione di riserva, non sostituisce un piano linguistico completo.

• Usate codici ISO validi per la lingua e, facoltativamente, per la regione.
• Includete riferimenti a se stessi e riferimenti reciproci.
• Fate puntare le alternative agli URL canonici definitivi e indicizzabili.
• Evitate di mescolare host di staging e produzione.

Traducete le decisioni, non soltanto le frasi

Una traduzione letterale può rispettare la grammatica e perdere il significato commerciale. Nomi dei prodotti, prove, obiezioni e inviti all’azione devono essere esaminati da chi comprende il pubblico e l’offerta. Una struttura di navigazione tradotta attorno a contenuti principali in inglese non costituisce un’esperienza localizzata utile.

Fornite ai traduttori il contesto: lettore, scopo della pagina, passo successivo desiderato, terminologia approvata e limiti di caratteri. Affidate a un revisore del mercato il controllo di affermazioni, esempi e tono. Quando un concetto originale non ha un equivalente naturale, riscrivetelo con chiarezza invece di copiarne la struttura della frase.

Mantenete corrette le prove in ogni lingua. Se un caso di studio riguarda un solo mercato, dichiaratelo invece di presentarlo come prova locale. Se la disponibilità del servizio varia, modificate anche l’offerta e l’instradamento del modulo, non soltanto le parole.

• Mantenete un registro condiviso della terminologia e delle affermazioni.
• Traducete metadati, testi alternativi delle immagini, errori e conferme.
• Controllate link, documenti scaricabili e dati strutturati in ogni lingua.
• Registrate le differenze intenzionali, affinché i redattori successivi non le cancellino.

Progettate un unico processo affidabile per i contatti multilingue

Una pagina localizzata non raggiunge il suo obiettivo commerciale se il passaggio successivo torna a un’altra lingua o arriva a un team che non può rispondere. Seguite il percorso dalla pagina del servizio agli errori di convalida, alla conferma, alla notifica via email e alla risposta personale.

Mantenete i moduli abbastanza brevi da poter essere compilati, ma raccogliete il contesto necessario per instradare la richiesta. La lingua può derivare dal percorso della pagina, senza aggiungere un’altra domanda. Confermate nella stessa lingua che cosa succederà e non promettete tempi di risposta che il team non ha concordato.

Per una società di ingegneria fittizia, le richieste in francese potrebbero arrivare a una coda commerciale francofona con un responsabile designato, mentre gli allegati tecnici vengono inoltrati a un team di progetto condiviso. Si tratta di una scelta operativa, non soltanto di un modulo tradotto.

Assegnate un responsabile a ogni pagina e lingua

La qualità multilingue diminuisce quando nessuno risponde delle modifiche dopo la pubblicazione. Nominate un redattore per la lingua di origine, un revisore per ciascun mercato e un decisore per le affermazioni. Definite un livello di servizio per gli aggiornamenti sostanziali, come prezzi, disponibilità, personale, politiche e recapiti.

Un flusso di lavoro utile distingue le modifiche strutturali da quelle minori. Una nuova sezione dedicata a un servizio può richiedere l’aggiornamento simultaneo di tutte le versioni locali; un evento regionale può riguardarne una sola. La matrice deve mostrare quali differenze sono intenzionali.

Programmate revisioni periodiche in base al rischio aziendale, non a un calendario editoriale arbitrario. Le pagine ad alta conversione o soggette a norme meritano maggiore attenzione rispetto a un vecchio annuncio.

• Nominate un responsabile e un revisore per ogni versione locale.
• Definite quali modifiche bloccano la pubblicazione finché tutte le versioni non sono pronte.
• Conservate date di revisione e materiali di origine insieme ai contenuti.
• Ritirate in modo ordinato le pagine linguistiche che non potete più gestire.

Verificate il gruppo come sistema prima della pubblicazione

Non controllate soltanto il selettore linguistico. Eseguite la scansione di ogni versione locale, confrontate annotazioni canonical e alternative, seguite i reindirizzamenti, esaminate le pagine su dispositivi mobili e inviate vere richieste di prova. La mancanza di un riferimento reciproco in una sola pagina può indebolire il gruppo previsto.

Google consiglia di rendere disponibili su mobile contenuti principali equivalenti, titoli, metadati e dati strutturati. Questo conta quando i modelli mobili localizzati o i livelli di consenso differiscono dalla versione desktop.

Concludete con un elenco firmato delle eccezioni. Una traduzione decorativa mancante può entrare nella coda delle attività successive. Un canonical errato, un modulo non funzionante o una lingua promessa ma non disponibile devono bloccare la pubblicazione.

• Controllate stato, indicizzabilità, canonical e hreflang per ogni riga della matrice.
• Verificate che il cambio di lingua mantenga la pagina equivalente.
• Esaminate i contenuti mobili e l’intero percorso della richiesta.
• Verificate nuovamente ogni gruppo corretto prima dell’approvazione.