WooCommerce multilingue: cosa deve rimanere sincronizzato tra le lingue

Il modello di base: tradurre i contenuti, sincronizzare lo stato commerciale

In un negozio WooCommerce multilingue, non tutti i campi prodotto hanno la stessa funzione. Alcuni campi servono a comunicare con gli acquirenti in una lingua specifica, mentre altri definiscono l’articolo effettivamente acquistabile e devono restare coerenti ovunque quel prodotto compaia.

Questa distinzione conta perché le versioni linguistiche non sono solo copie di testo. Di solito sono rappresentazioni separate della stessa relazione di prodotto sottostante. Se la versione tradotta diverge per stock, SKU, struttura delle varianti o mappatura della tassonomia, il negozio può presentare un prodotto che sembra locale ma si comporta come un articolo diverso al checkout.

Categoria di dati	Trattamento tipico	Perché
Titolo prodotto, descrizione, descrizione breve	Tradurre	Si tratta di campi di contenuto rivolti al cliente.
Prezzo	Sincronizzare	Prezzi diversi tra le lingue creano comportamenti di acquisto incoerenti, a meno che l’azienda non supporti intenzionalmente prezzi localizzati.
Quantità di stock e stato dello stock	Sincronizzare	L’inventario rappresenta lo stesso articolo fisico o vendibile in tutte le versioni linguistiche.
SKU	Sincronizzare	Lo SKU è un identificatore del prodotto o della variante e non dovrebbe divergere tra le traduzioni.
Relazioni di tassonomia	Sincronizzare o mappare con attenzione	Categorie, tag e termini degli attributi influenzano la navigazione, i filtri e il raggruppamento dei prodotti tra le lingue.
Varianti	Sincronizzare struttura e identificatori	I set di varianti devono rimanere equivalenti, così ogni versione linguistica offre le stesse opzioni acquistabili.
Comportamento di checkout	Sincronizzare	La logica di carrello, checkout e ordine deve risolvere le stesse regole di prodotto indipendentemente dalla lingua.
Permalink e routing	Consapevole della lingua ma coerente	Ogni lingua ha bisogno del proprio percorso URL o schema di routing, ma la relazione del prodotto deve comunque risolversi in modo pulito.
Canonical e relazioni linguistiche	Sincronizzare a livello di relazione	I motori di ricerca e la navigazione interna hanno bisogno di una mappatura stabile tra le versioni linguistiche.

I contenuti prodotto traducibili sono il livello che i clienti leggono

I campi multilingue più evidenti sono quelli che descrivono il prodotto in linguaggio naturale: titolo, descrizione estesa, descrizione breve e qualsiasi altro testo rivolto al cliente associato alla pagina prodotto.

Questi campi possono differire da una lingua all’altra senza cambiare l’identità del prodotto sottostante. Questo è il senso della traduzione: l’acquirente dovrebbe capire la stessa offerta nella propria lingua, ma il negozio dovrebbe comunque vendere lo stesso record di prodotto o la stessa famiglia di prodotti collegati.

I dati commerciali devono rimanere sincronizzati perché guidano la logica di acquisto

Prezzo, stock, SKU e struttura delle varianti non sono solo campi di visualizzazione. Determinano se il prodotto può essere acquistato, come viene identificato negli ordini e quali opzioni sono disponibili al momento dell’aggiunta al carrello.

Se una versione linguistica mostra uno stato dello stock o un set di varianti diverso, il negozio può diventare internamente incoerente. Un acquirente può arrivare su una pagina tradotta che sembra disponibile, per poi fallire al checkout perché lo stato acquistabile sottostante appartiene a una versione diversa. Può accadere anche il contrario: un prodotto può risultare esaurito in una vista linguistica ma apparire ancora disponibile in un’altra se la sincronizzazione è interrotta.

Tassonomie e attributi richiedono una mappatura deliberata, non una duplicazione casuale

Categorie, tag e attributi del prodotto si collocano tra contenuto e commercio. Aiutano gli acquirenti a navigare, filtrare e confrontare i prodotti, ma influenzano anche il modo in cui i prodotti vengono raggruppati e come vengono definite le varianti.

In configurazioni multilingue, queste relazioni richiedono una gestione attenta. L’etichetta tradotta di una categoria non è la stessa cosa di una relazione di categoria diversa. Se la mappatura è errata, il prodotto può scomparire dalle pagine archivio previste, i filtri possono smettere di corrispondere oppure le pagine tradotte possono puntare a termini di tassonomia che non corrispondono tra le lingue.

Le varianti sono la parte più fragile del modello di prodotto multilingue

I prodotti variabili dipendono da una struttura coerente: lo stesso set di varianti, la stessa logica degli attributi e la stessa relazione tra prodotto padre e varianti figlie.

Questa struttura deve sopravvivere alla traduzione. Le etichette visibili degli attributi possono cambiare da una lingua all’altra, ma il modello delle varianti non può frammentarsi. Se una versione linguistica ha un set di varianti diverso, gli acquirenti possono vedere opzioni che non esistono altrove, oppure il prodotto tradotto può non riuscire a risolvere la variante acquistabile corretta quando viene aggiunto al carrello.

Il comportamento di checkout deve rimanere neutrale rispetto alla lingua a livello logico

Il checkout è il punto in cui la presentazione multilingue termina e subentra la logica commerciale. Il flusso di carrello e checkout deve risolvere la stessa identità del prodotto, le stesse regole di prezzo, gli stessi controlli di stock e le stesse selezioni delle varianti, indipendentemente dalla lingua usata per arrivarci.

Ecco perché il comportamento di checkout appartiene al livello sincronizzato. L’acquirente può leggere l’interfaccia in una lingua e completare l’acquisto in un’altra, ma i dati dell’ordine sottostanti devono comunque rimandare agli stessi record di prodotto e di variante. Se questa mappatura si rompe, gli articoli dell’ordine possono diventare ambigui o incoerenti tra i contesti linguistici.

Permalink, routing e segnali canonical supportano la separazione linguistica senza deriva del prodotto

Ogni versione linguistica ha bisogno del proprio percorso, così motori di ricerca e utenti possono raggiungere la pagina localizzata corretta. Ma URL separati non significano prodotti separati.

Il livello di routing dovrebbe distinguere le versioni linguistiche preservando però la relazione tra di esse. È questa relazione che mantiene allineati i collegamenti interni, i segnali canonical e la navigazione consapevole della lingua. Se gli URL sono isolati ma il collegamento del prodotto è debole, i motori di ricerca possono trattare le pagine come duplicati non correlati oppure gli acquirenti possono arrivare alla versione linguistica sbagliata tramite i link interni.

Dal punto di vista operativo, la domanda è quali campi sono campi fonte di verità

Una decisione di implementazione utile è classificare ogni campo prodotto in base alla proprietà. I campi di proprietà della traduzione possono variare per lingua. I campi di proprietà del commercio dovrebbero avere un’unica fonte di verità ed essere propagati a ogni versione linguistica.

Questa classificazione riduce l’ambiguità durante gli aggiornamenti. Per esempio, se lo stock cambia dopo una vendita, l’aggiornamento dovrebbe propagarsi a tutte le versioni linguistiche. Se un addetto marketing riscrive la descrizione del prodotto, quella modifica dovrebbe restare nel livello di contenuto tradotto. Il negozio diventa più facile da mantenere quando gli editor sanno quali campi sono localizzabili e quali sono sincronizzati per progettazione.