Metadati delle immagini e gestione dei media in WordPress multilingue

Cosa cambia con la lingua e cosa dovrebbe rimanere condiviso

Un sito WordPress multilingue di solito ha due diversi tipi di dati immagine. Un tipo è il contenuto rivolto alla lingua: testo alternativo, didascalie e qualsiasi testo descrittivo che appare agli utenti o ai motori di ricerca nel contesto di una pagina. L’altro tipo è il dato media condiviso: il file immagine effettivo, il suo record tecnico di allegato e qualsiasi metadato che descrive il file anziché la lingua della pagina.

Questa distinzione è importante perché tradurre i dati tecnici condivisi crea duplicazione senza migliorare il significato, mentre non tradurre il testo rivolto alla lingua lascia l’immagine scollegata dalla lingua della pagina. Il confine corretto è di solito determinato dal fatto che il campo venga letto come contenuto o come informazione del file.

Testo alternativo: traduci il significato, non il nome del file

Il testo alternativo è il campo immagine più sensibile alla lingua in WordPress perché viene utilizzato come contenuto descrittivo. In una configurazione multilingue, il testo alternativo dovrebbe normalmente corrispondere alla lingua della pagina in cui l’immagine appare, perché le tecnologie assistive e i sistemi di ricerca lo interpretano nel contesto di quella pagina.

Questo non significa che ogni immagine debba avere una descrizione concettuale diversa in ogni lingua. Se l’immagine è puramente decorativa, il testo alternativo dovrebbe rimanere vuoto o seguire comunque l’approccio di accessibilità del sito invece di essere tradotto in una frase priva di significato. Se l’immagine trasmette informazioni, il testo alternativo tradotto dovrebbe descrivere tali informazioni nella lingua di destinazione, non conservare una formulazione nella lingua di origine che il lettore non può usare.

Un errore comune è riutilizzare il testo alternativo di una lingua per tutte le traduzioni perché l’elemento media è condiviso. Questo mantiene più semplice la libreria media, ma rompe la relazione tra l’immagine e il contenuto tradotto della pagina. Un altro errore è tradurre meccanicamente il testo alternativo lasciando invariato il testo circostante della pagina, il che può creare incongruenze nella terminologia o nei nomi dei prodotti.

Didascalie: traduci quando fanno parte della narrazione della pagina

Le didascalie si comportano più come il corpo del testo che come metadati del file. Se una didascalia è visibile ai lettori, partecipa alla lingua della pagina e di solito dovrebbe essere tradotta insieme al resto del contenuto. Questo è particolarmente vero quando la didascalia aggiunge contesto, attribuzione o interpretazione da cui dipende il testo circostante.

Poiché le didascalie vengono renderizzate nel front end, possono influire sia sulla comprensione sia sul layout. Una didascalia tradotta può espandersi o contrarsi rispetto alla lingua di origine, quindi chi implementa dovrebbe aspettarsi differenze di a capo e spaziatura invece di presumere una corrispondenza visiva uno a uno.

Se una didascalia viene usata come fonte di verità per più punti del sito, le decisioni di traduzione diventano più rilevanti. Riutilizzare una sola didascalia tra le lingue può ridurre il lavoro editoriale, ma costringe anche ogni versione linguistica a ereditare la stessa formulazione, che potrebbe non corrispondere alla terminologia locale o ai requisiti legali/di attribuzione.

Metadati degli allegati: per lo più condivisi, a volte sensibili alla lingua

I metadati degli allegati in WordPress di solito descrivono il file stesso anziché la lingua della pagina. Questo include le proprietà tecniche associate ai media caricati e il record dell’allegato che memorizza il file nella libreria media. Nella maggior parte dei flussi di lavoro multilingue, questi dati dovrebbero rimanere condivisi perché l’asset sottostante è lo stesso in tutte le lingue.

L’eccezione pratica è quando il record dell’allegato contiene testo rivolto all’utente che viene esposto nella libreria media o nel front end. In quel caso, il testo si comporta come contenuto e può richiedere una traduzione. La domanda tecnica chiave è se il campo viene usato come identificatore tecnico o come testo editoriale visibile.

Questa distinzione influisce anche sulla manutenzione. I dati condivisi degli allegati riducono la duplicazione e mantengono sincronizzati gli aggiornamenti, ma possono rendere più difficile il controllo editoriale specifico per lingua se il flusso di lavoro non separa il testo descrittivo dall’identità del file. I record degli allegati sensibili alla lingua offrono agli editor maggiore controllo, ma aumentano anche il rischio di divergenze tra le versioni se la stessa immagine viene aggiornata in una lingua e non nelle altre.

Nomi dei file e SEO delle immagini: utili per la scoperta, ma non un target di traduzione per impostazione predefinita

I nomi dei file immagine fanno parte del livello file, quindi di solito sono condivisi anziché tradotti per lingua. Cambiare i nomi dei file dopo il caricamento può creare complessità operative perché il percorso del file, i riferimenti nel contenuto e qualsiasi URL derivato potrebbero dover rimanere allineati. Per questo motivo, i nomi dei file sono meglio considerati identificatori tecnici che contenuti specifici per lingua.

Dal punto di vista della SEO delle immagini, i nomi dei file possono comunque contare perché contribuiscono a come l’asset viene denominato e organizzato. Ma in WordPress multilingue, il segnale linguistico più forte di solito proviene dal contenuto circostante della pagina, dal testo alternativo tradotto, dalle didascalie e dalla struttura di routing e canonical della pagina stessa. Un nome file tradotto da solo non rende un’immagine realmente localizzata se il testo visibile attorno ad essa rimane in un’altra lingua.

Il compromesso è semplice: tradurre i nomi dei file può migliorare la leggibilità umana nella libreria media, ma può anche complicare il riutilizzo, la memorizzazione nella cache e i riferimenti tra le versioni linguistiche. Mantenere condivisi i nomi dei file preserva la stabilità e rende l’asset più facile da gestire come un singolo file usato da più traduzioni.

Media riutilizzabili: un file, molti contesti linguistici

I media riutilizzabili sono il punto in cui WordPress multilingue diventa operativamente interessante. Una singola immagine può apparire in più traduzioni, ma ogni versione linguistica può aver bisogno di testo descrittivo diverso, di un testo circostante diverso o persino di un ritaglio diverso se il layout cambia. Il file condiviso rimane lo stesso, mentre la presentazione specifica per lingua cambia attorno ad esso.

Questa separazione è utile perché evita di duplicare inutilmente gli asset binari. Significa anche che la libreria media e il livello dei contenuti non devono seguire lo stesso modello di traduzione. L’immagine può essere condivisa globalmente mentre i metadati a livello di pagina che la descrivono vengono localizzati per lingua.

Il principale errore è presumere che media condivisi implichino significato condiviso. Un’immagine che funziona in una versione linguistica potrebbe aver bisogno di una didascalia diversa, di un testo alternativo diverso o persino di un’immagine sostitutiva diversa in un’altra lingua se il contesto culturale o editoriale cambia. Il riutilizzo è efficiente, ma non dovrebbe prevalere sull’adeguatezza linguistica.

Come decidere cosa tradurre

Una regola pratica è tradurre tutto ciò che un lettore interpretarebbe come parte del messaggio della pagina e mantenere condiviso tutto ciò che identifica o memorizza il file stesso. Questo significa che il testo alternativo e le didascalie di solito vengono tradotti, mentre il file immagine sottostante e la maggior parte dei metadati degli allegati rimangono condivisi.

Quando un campo si trova nel mezzo, fai due domande: il campo appare agli utenti e il suo significato dipende dalla lingua della pagina? Se la risposta a una delle due è sì, la traduzione può essere appropriata. Se il campo serve solo a supportare la gestione del file o il rendering, di solito dovrebbe rimanere globale.

Questa decisione influisce anche sul flusso di lavoro editoriale. I team che localizzano il testo delle immagini hanno bisogno di un processo per mantenere allineate le descrizioni tradotte con gli aggiornamenti della pagina. I team che mantengono condivisi i media hanno bisogno di una regola chiara per stabilire quando una nuova versione linguistica debba riutilizzare l’asset esistente e quando invece debba avere un’immagine o una didascalia separata.