Sintesi vocale per siti Polylang: cosa funziona davvero

14 min di lettura 23 min di ascolto
Sintesi vocale per siti Polylang: cosa funziona davvero

La sintesi vocale su Polylang significa un file audio per ogni post tradotto, nella lingua e nella voce corrette. Polylang salva ogni traduzione come un post WordPress a sé stante con il proprio ID, quindi la generazione audio per singolo post funziona in modo nativo. Le insidie sono la selezione della voce, i redirect basati su cookie e la cache delle pagine, non l'audio in sé.

Questo è il quarto articolo della nostra serie sulla sintesi vocale multilingue. Abbiamo già trattato WPML, Weglot e il rilascio GTranslate 3.3.0. Polylang si avvicina molto a WPML nell'architettura, ma ha le sue peculiarità. Ecco cosa abbiamo testato e cosa funziona davvero su siti in produzione con Sintesi vocale - TTSWP.

Perché Polylang è importante per la sintesi vocale

Polylang gestisce più siti WordPress multilingue di qualsiasi altro plugin gratuito. Conta oltre 800.000 installazioni attive ed è il plugin multilingue gratuito con la base utenti più ampia. La prima versione è uscita nel 2011 e il plugin è ancora attivamente mantenuto. Non c'è limite al numero di lingue che puoi aggiungere e i language pack di WordPress si scaricano automaticamente. La maggior parte dei siti Polylang sono blog, piccoli editori e agenzie attente ai costi che lo hanno scelto perché il core è gratuito e l'architettura è pulita.

Questa popolarità è il problema per i plugin di sintesi vocale. Molti dichiarano il supporto a Polylang ma testano solo la lingua predefinita. Collegano un singolo file audio a un post, poi servono lo stesso file su ogni traduzione. La versione spagnola riproduce l'audio in inglese. La versione tedesca rimane silenziosa. I visitatori abbandonano.

La soluzione è strutturale. Polylang non aggiunge tabelle extra al database né shortcode. Si basa sulle tassonomie di WordPress, la stessa funzionalità core che gestisce categorie e tag. Ogni traduzione vive come un post reale. La generazione audio per singolo post, che è il modo in cui funziona TTSWP, si allinea perfettamente con il modo in cui Polylang archivia i contenuti.

Come Polylang si differenzia da Weglot e GTranslate

Polylang duplica i post. Weglot e GTranslate traducono al momento del rendering. Questa differenza determina tutto riguardo al supporto della sintesi vocale.

Su un sito Polylang, la traduzione tedesca di «Chi siamo» è un post WordPress separato con post ID 412, slug lingua «de» e il proprio contenuto nel database. WordPress lo vede, la REST API lo vede, e qualsiasi plugin di sintesi vocale che si aggancia a save_post o wp_insert_post lo vede. La generazione audio avviene una volta per traduzione, nella lingua di quella traduzione, e il file viene salvato in cache con quel post ID.

Weglot e GTranslate funzionano diversamente. Il testo tradotto esiste solo quando un utente richiede la pagina. Non c'è un secondo post a cui collegare l'audio. Abbiamo trattato le soluzioni per Weglot e GTranslate in articoli precedenti. WPML usa lo stesso modello di duplicazione di Polylang, per questo la nostra guida WPML si applica qui con piccole modifiche.

Per la sintesi vocale questa è una buona notizia. Polylang ti dà esattamente quello che ti serve: un post ID stabile per lingua, uno slug lingua noto e un permalink che non cambia al momento del rendering.

Diagramma che confronta la duplicazione dei post di Polylang con la traduzione al rendering di Weglot
Polylang crea un post reale per ogni lingua, esattamente quello di cui ha bisogno la generazione audio per singolo post.

Le quattro strutture URL di Polylang e cosa significano per la sintesi vocale

Polylang offre quattro modalità URL. Ognuna cambia come cache, CDN e codice di rilevamento lingua vedono le tue pagine. Scegli quella sbagliata e il file audio corretto finisce dietro l'URL sbagliato.

1. Lingua dal contenuto (nessun codice lingua nell'URL)

È il caso più complesso. L'URL example.com/about serve l'inglese a un visitatore e il tedesco a un altro, in base al cookie o al rilevamento del browser. Le cache delle pagine vedono un solo URL e memorizzano una sola variante. Vince la lingua che la cache ha acquisito per prima.

Per la sintesi vocale il file audio in sé va bene perché è legato al post ID, non all'URL. Il problema è la pagina che incorpora il player. Se la pagina inglese in cache carica l'embed audio tedesco, il player riproduce comunque il tedesco, ma i visitatori si aspettavano il testo inglese. Non consigliamo questa modalità URL su nessun sito con cache attiva.

2. URL con directory (/en/, /de/)

È l'impostazione predefinita e quella che consigliamo. Ogni lingua vive nel proprio percorso. Le cache trattano /en/about e /de/about come chiavi distinte. La pagina giusta si carica con il player giusto e il file audio giusto. Nessun trucco con i cookie.

Attenzione all'opzione «nascondi le informazioni sulla lingua nell'URL per la lingua predefinita». Quando è attiva, la lingua predefinita non ha il prefisso. /about diventa inglese e /de/about rimane tedesco. Il rilevamento della lingua basato su URL nel codice di terze parti fallisce sui percorsi della lingua predefinita perché non vede nessuno slug. Se usi questa opzione, affidati a pll_current_language() invece di analizzare l'URL.

3. Sottodominio (en.example.com, de.example.com)

I sottodomini assegnano a ogni lingua il proprio host e il proprio namespace di cache. I player di sintesi vocale si caricano correttamente per lingua. Il costo è la gestione DNS, i certificati SSL per ogni sottodominio e un'analisi leggermente più complessa. Funziona bene su larga scala.

4. Domini separati per lingua

Separazione completa. example.com per l'inglese, example.de per il tedesco. La sintesi vocale continua a collegare l'audio al post ID all'interno di ogni installazione WordPress e il player funziona allo stesso modo. Questa modalità è comune per i brand che già possiedono ccTLD.

Il problema dei redirect basati su cookie

Polylang può rilevare la lingua del browser di un visitatore alla prima visita alla homepage. Imposta quindi il cookie pll_language e reindirizza il visitatore alla versione nella lingua corrispondente. Combinato con la cache delle pagine, è qui che compare l'audio nella lingua sbagliata.

Ecco la sequenza di errore che abbiamo riprodotto. Un visitatore francese arriva alla homepage. Polylang rileva il francese, imposta il cookie pll_language e reindirizza a /fr/. La cache memorizza quella risposta di redirect sotto l'URL della homepage. Il visitatore successivo, un anglofono, richiede la homepage e riceve il redirect in cache verso /fr/. Atterra sulla pagina francese, sente l'audio in francese e abbandona.

Con gli URL a directory il danno rimane sulla homepage, perché ogni altra pagina ha una chiave di cache distinta per lingua. Con la modalità «lingua dal contenuto» lo stesso problema si diffonde a tutti gli URL del sito.

Ci sono tre soluzioni. La più semplice è disattivare il rilevamento della lingua del browser su qualsiasi sito con cache e lasciare che i visitatori scelgano tramite il selettore di lingua. La seconda è configurare il plugin di cache per variare o bypassare il cookie pll_language. La terza è escludere la homepage dalla cache delle pagine, in modo che il redirect di rilevamento venga sempre eseguito dal vivo.

Se usi WP Rocket, W3 Total Cache o LiteSpeed, consulta la nostra documentazione sull'integrazione con la cache per la configurazione dei cookie. Polylang funziona con questi plugin di cache, ma coesistere non significa essere compatibili con la gestione delle lingue. La cache va configurata manualmente.

Comportamento AJAX nel frontend

Polylang rileva automaticamente la lingua corrente nelle richieste AJAX dal frontend e carica le stringhe per quella lingua. Puoi anche passare una variabile lang esplicita nella richiesta per forzare una lingua specifica. Per la sintesi vocale questo è rilevante quando il player audio o il widget dei post correlati invia una richiesta AJAX per recuperare un post diverso.

Nei nostri test, Polylang gestisce questo correttamente. Non abbiamo riscontrato le regressioni AJAX-lingua che abbiamo documentato nel post su WPML. Se un'integrazione personalizzata deve recuperare un post in una lingua non corrente, passa lang esplicitamente e verifica che function_exists('pll_current_language') prima di leggere il risultato.

Configurare Sintesi vocale - TTSWP su un sito Polylang

Questi passaggi presuppongono che Polylang sia già installato e che esista almeno una traduzione.

  1. Installa Sintesi vocale - TTSWP dalla pagina del plugin su WordPress.org. Attivalo. Consulta la documentazione di installazione se riscontri un errore di permessi.
  2. Collega il plugin a TTSWP seguendo la guida alla connessione. Il piano gratuito include crediti di benvenuto per testare prima di scegliere un piano a pagamento.
  3. Apri il post nella lingua originale e genera l'audio. Verifica che il player compaia nel frontend.
  4. Passa alla versione tradotta dal selettore di lingua di Polylang nell'editor del post. Genera l'audio di nuovo. Polylang ha caricato un post ID diverso, quindi TTSWP lo tratta come una nuova generazione e salva un file separato.
  5. Scegli la voce per ogni traduzione. La selezione della voce avviene a livello di post. Consulta la documentazione sulla selezione delle voci per l'override per singolo post.
  6. Verifica nel frontend. Apri /en/post-slug e /de/post-slug in schede diverse. Riproduci entrambi. Voci e lingue devono corrispondere.

Al momento, la mappatura predefinita delle voci per lingua in TTSWP copre prima WPML e Weglot. Su Polylang, la selezione della voce vive a livello di post e il valore predefinito per lingua funziona tramite il rilevamento della lingua del post descritto di seguito. Per la maggior parte dei siti Polylang questo è sufficiente, perché ogni traduzione è un post reale e la voce viene impostata una volta per post. Consulta la documentazione sull'integrazione con Polylang per il comportamento attuale.

Editor post di WordPress con il selettore di lingua di Polylang e il pannello audio TTSWP affiancati
Ogni traduzione Polylang è un post separato, quindi la generazione audio e la selezione della voce avvengono per traduzione.

Come leggere la lingua del post per la selezione della voce

L'API corretta per leggere la lingua di un post in Polylang è pll_get_post_language(). Verifica sempre che la funzione esista prima di chiamarla, come raccomanda la documentazione per sviluppatori di Polylang. Il pattern è questo:

if ( function_exists( 'pll_get_post_language' ) ) {
    $lang = pll_get_post_language( $post_id, 'slug' );
    // $lang è ora 'en', 'de', 'fr', ecc.
}

Per il contesto frontend, pll_current_language() restituisce la lingua della richiesta corrente. Entrambe le funzioni sono stabili e fanno parte dell'API pubblica di Polylang da anni. La logica di mappatura delle voci deve sempre leggere dalla lingua del post, mai dal valore predefinito del sito, altrimenti le traduzioni ereditano la voce sbagliata.

Polylang gratuito vs Polylang Pro per la sintesi vocale

Niente in Polylang Pro è necessario per l'audio. La versione gratuita di Polylang fornisce tutto ciò di cui TTSWP ha bisogno: duplicazione per post, slug lingua e le funzioni API pubbliche sopra indicate.

Polylang Pro aggiunge la traduzione automatica con DeepL, il supporto REST API, gli slug URL tradotti e l'esportazione XLIFF per lavori di traduzione esternalizzati. Nessuna di queste funzionalità cambia il quadro della sintesi vocale per post e pagine. Polylang per WooCommerce è un'estensione a pagamento separata che gestisce le pagine del negozio, le categorie di prodotti, gli attributi e le email transazionali. Se vuoi la narrazione sulle descrizioni dei prodotti, consulta la nostra guida alla sintesi vocale per WooCommerce.

SEO e AEO con un file audio per lingua

Polylang gestisce automaticamente gli hreflang, che rappresentano la maggior parte del lavoro SEO per i siti multilingue. Aggiungi lo schema AudioObject per ogni versione linguistica, puntando ciascuno al file di quella specifica traduzione, e dai ai motori di ricerca un segnale chiaro.

Nei nostri test, gli articoli con audio e schema AudioObject vengono citati più spesso dai motori di ricerca basati su AI. Abbiamo documentato il metodo e i risultati nel nostro articolo su AEO e audio. In breve: un file audio per traduzione, schema per traduzione, e il beneficio AEO arriva di conseguenza.

Problemi comuni e soluzioni

SintomoCausa probabileSoluzione
La traduzione viene riprodotta con la voce sbagliataVoce impostata globalmente, non per singolo postApri il post tradotto, imposta la voce su quel post, rigenera
Una lingua non ha audioAudio mai generato su quella traduzioneApri il post tradotto nell'editor, clicca su genera
La pagina in cache mostra il player nella lingua sbagliataCache che memorizza il redirect di rilevamento o una sola variante della paginaDisattiva il rilevamento della lingua del browser, oppure configura la cache per variare sul cookie pll_language
Il layout del player per arabo o ebraico non è correttoCSS RTL non applicato al playerAggiungi override RTL tramite CSS personalizzato
Le stringhe dell'interfaccia del player rimangono nella lingua predefinitaStringhe del plugin non registrate per la traduzioneRegistra le stringhe del player con pll_register_string in modo che Polylang le esponga nella schermata di traduzione delle stringhe
L'audio viene generato nella lingua predefinita per tutti i postMappatura voci che legge il locale del sito invece della lingua del postVerifica la lingua del post con pll_get_post_language($post_id, 'slug')
Illustrazione di tre percorsi lingua ciascuno con una chiave di cache e un file audio distinti, incluso il layout RTL per l'arabo
Gli URL con directory assegnano a ogni traduzione la propria chiave di cache, evitando che l'audio sbagliato finisca sulla pagina sbagliata.

Accessibilità

Aggiungere la narrazione per ogni lingua è anche un vantaggio per l'accessibilità. I visitatori che leggono meglio nella propria lingua ma preferiscono ascoltare ottengono entrambe le opzioni. Se il tuo sito rientra nell'ambito di WCAG 2.2 o dell'European Accessibility Act, consulta la nostra guida alla conformità audio WCAG per i criteri applicabili. Per una panoramica completa su come aggiungere la sintesi vocale a WordPress nel 2026, il tutorial principale copre le basi.

Domande frequenti

Polylang funziona con la sintesi vocale?

Sì. Polylang salva ogni traduzione come un post WordPress separato con il proprio ID, la stessa architettura che TTSWP usa per l'audio per singolo post. Genera l'audio su ogni traduzione e otterrai un file per lingua con la voce che hai scelto. La versione gratuita di Polylang è sufficiente. Non è necessaria alcuna configurazione speciale oltre alla configurazione standard di TTSWP.

Ho bisogno di Polylang Pro per l'audio?

No. La versione gratuita di Polylang espone tutto ciò di cui TTSWP ha bisogno: duplicazione dei post per lingua, slug lingua e le funzioni API pubbliche pll_get_post_language() e pll_current_language(). Polylang Pro aggiunge la traduzione automatica con DeepL, il supporto REST API e gli slug URL tradotti. Nessuna di queste funzionalità cambia il funzionamento della generazione o della riproduzione audio.

Ogni lingua può avere la propria voce?

Sì. Poiché ogni traduzione è un post separato, la selezione della voce avviene a livello di post. Scegli una voce tedesca sulla traduzione tedesca, una voce spagnola sulla traduzione spagnola, e così via. TTSWP salva la scelta per post e la usa ogni volta che rigeneri. Consulta la documentazione sulla mappatura lingua e voce per il comportamento attuale.

Perché il mio audio viene riprodotto nella lingua sbagliata?

La causa più comune è la cache delle pagine combinata con il rilevamento della lingua del browser di Polylang. La cache memorizza il redirect della homepage o una sola variante linguistica e la serve a tutti. Il file audio in sé è corretto per il post ID. Non lo è la pagina che lo carica. Disattiva il rilevamento del browser sui siti con cache, oppure configura il plugin di cache per variare sul cookie pll_language. Gli URL con directory (/en/, /de/) limitano il danno alla homepage perché ogni altra pagina ha una chiave di cache distinta.

In cosa si differenzia Polylang da WPML per la sintesi vocale?

Entrambi duplicano i post per lingua, quindi l'audio per singolo post funziona allo stesso modo su entrambi. Le differenze riguardano la gestione AJAX, il comportamento dei cookie e i nomi delle funzioni nell'API per sviluppatori. Polylang usa funzioni con prefisso pll_ ed è generalmente più leggero. WPML ha più funzionalità WooCommerce integrate ma un footprint del plugin più grande. Il nostro post su WPML tratta questo aspetto nel dettaglio.

Posso tradurre le etichette del player audio?

Sì, con un passaggio aggiuntivo. Polylang espone una schermata di traduzione delle stringhe per i plugin che registrano le proprie stringhe di interfaccia usando pll_register_string(). Se vuoi che il pulsante play, l'etichetta del timer di avanzamento o qualsiasi altro testo del player cambino con la lingua, registra quelle stringhe nel tema figlio o in un piccolo plugin specifico per il sito. Appariranno poi in Lingue, Traduzione stringhe.

Cosa fare adesso

Apri uno dei tuoi post tradotti nell'editor di WordPress e guarda il pannello audio. Se mostra già la lingua corretta, la configurazione è completa. In caso contrario, imposta la voce su quella traduzione, rigenera e controlla il frontend. Una volta che una traduzione funziona, le altre seguono lo stesso schema.

Se non hai ancora installato Sintesi vocale - TTSWP, scaricalo da WordPress.org e collegalo al tuo account TTSWP gratuito. Testa su una traduzione, ascolta e decidi se estenderlo alle altre.