Tekst til tale for Polylang-nettsteder: Det som faktisk fungerer

Ekte Polylang-støtte for tekst til tale betyr én lydfil per oversatt innlegg, med riktig språk og stemme. Fordi Polylang lagrer hver oversettelse som sitt eget WordPress-innlegg med sin egen ID, fungerer per-innlegg lydgenerering uten ekstra konfigurasjon. Fallgruvene er stemmevalg, informasjonskapsel-omdirigeringer og side-caching, ikke selve lyden.

Dette er det fjerde innlegget i vår serie om flerspråklig TTS. Vi har tidligere dekket WPML, Weglot og GTranslate 3.3.0. Polylang ligner mest på WPML i arkitektur, men har sine egne særtrekk. Her er hva vi testet og hva som faktisk fungerer på produksjonssider med Tekst til Tale - TTSWP.

Hvorfor Polylang er viktig for tekst til tale

Polylang driver flere flerspråklige WordPress-nettsteder enn noe annet gratis programtillegg. Det har over 800 000 aktive installasjoner og den største gratis installasjonsmassen av alle flerspråklige programtillegg. Den første versjonen kom i 2011, og programtillegget vedlikeholdes fortsatt aktivt. Det er ingen grense for antall språk du kan legge til, og WordPress-språkpakker lastes ned automatisk. De fleste Polylang-nettsteder er blogger, mindre utgivere og budsjettbevisste byråer som valgte det fordi kjernen er gratis og arkitekturen er ryddig.

Den populariteten er problemet for TTS-programtillegg. Mange hevder å støtte Polylang, men tester bare standardspråket. De knytter én lydfil til et innlegg og serverer samme fil på alle oversettelser. Den spanske versjonen spiller engelsk lyd. Den tyske versjonen er stille. Besøkende forlater siden.

Løsningen er strukturell. Polylang legger til ingen ekstra databasetabeller og ingen kortkodet. Det bygger på WordPress-taksonomier, den samme kjernefunksjonen som driver kategorier og etiketter. Hver oversettelse lever som et ekte innlegg. Dermed passer per-innlegg lydgenerering, som er slik TTSWP fungerer, perfekt med hvordan Polylang lagrer innhold.

Hvordan Polylang skiller seg fra Weglot og GTranslate

Polylang dupliserer innlegg. Weglot og GTranslate oversetter ved visning. Den ene forskjellen avgjør alt om TTS-støtte.

På et Polylang-nettsted er den tyske oversettelsen av «Om oss» et eget WordPress-innlegg med post-ID 412, språkslug «de» og sitt eget innhold i databasen. WordPress ser det, REST API ser det, og ethvert TTS-programtillegg som kobler seg til save_post eller wp_insert_post ser det. Lydgenerering kjøres én gang per oversettelse, på det språket, og filen bufres mot den post-ID-en.

Weglot og GTranslate fungerer annerledes. Den oversatte teksten finnes bare når en bruker ber om siden. Det er ingen ekstra innlegg å knytte lyd til. Vi dekket løsningene for Weglot og GTranslate i tidligere innlegg. WPML bruker samme duplikeringsmodell som Polylang, og derfor gjelder vår WPML-guide her med små justeringer.

For TTS er dette gode nyheter. Polylang gir deg nøyaktig det du trenger: en stabil post-ID per språk, en kjent språkslug og en permalink som ikke endres ved visning.

De fire Polylang URL-strukturene og hva de betyr for TTS

Polylang tilbyr fire URL-moduser. Hver endrer hvordan buffere, CDN-er og språkdeteksjonskode ser sidene dine. Velger du feil, ender riktig lydfil bak feil URL.

1. Språk kun fra innhold (ingen språkkode i URL)

Dette er det vanskeligste tilfellet. URL-en example.com/about serverer engelsk til én besøkende og tysk til en annen, basert på informasjonskapsel eller nettleserdeteksjon. Side-buffere ser én URL og lagrer én variant. Det språket bufferen fanget opp først, vinner.

For TTS er lydfilen i seg selv uproblematisk fordi den er knyttet til post-ID, ikke URL-en. Problemet er siden som bygger inn spilleren. Hvis den bufrede engelske siden lastes med den tyske lydinnbyggingen, spiller spilleren fortsatt tysk, men besøkende forventet engelsk tekst. Vi anbefaler ikke denne URL-modusen på noe bufret nettsted.

2. Katalog-URL-er (/en/, /de/)

Dette er standardoppsettet vi anbefaler. Hvert språk bor på sin egen sti. Buffere behandler /en/about og /de/about som distinkte nøkler. Riktig side lastes med riktig spiller og riktig lydfil. Ingen informasjonskapsel-triks nødvendig.

Pass på alternativet «skjul URL-språkinformasjon for standardspråk». Når det er aktivert, mister standardspråket prefikset. /about blir engelsk og /de/about forblir tysk. URL-basert språkdeteksjon i tredjeparts kode feiler da på standardspråk-stiene fordi den ikke ser noen slug. Bruker du dette alternativet, bruk pll_current_language() i stedet for URL-parsing.

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

Subdomener gir hvert språk sin egen vert og sitt eget buffer-navnerom. TTS-spillere lastes rent per språk. Kostnaden er DNS, SSL-sertifikater per subdomene og litt mer kompleks analyse. Fungerer bra i stor skala.

4. Separate domener per språk

Full separasjon. example.com for engelsk, example.de for tysk. TTS knytter fortsatt lyd til post-ID-en inne i hver WordPress-installasjon, og spilleren fungerer på samme måte. Denne modusen er vanlig for merkevarer som allerede eier ccTLD-er.

Problemet med informasjonskapsel-omdirigeringer

Polylang kan oppdage en besøkendes nettleserspråk ved det første besøket på hjemmesiden. Da setter den pll_language-informasjonskapselen og omdirigerer den besøkende til riktig språkversjon. Kombinert med side-caching er dette der feil-språk-lyd dukker opp.

Her er feilsekvensen vi har reprodusert. En fransk besøkende lander på hjemmesiden. Polylang oppdager fransk, setter pll_language-informasjonskapselen og omdirigerer til /fr/. Bufferen lagrer dette omdirigeringssvaret under hjemmesidens URL. Neste besøkende, en engelsktalende, ber om hjemmesiden og får den bufrede omdirigeringen til /fr/. De lander på den franske siden, hører fransk lyd og forlater.

Med katalog-URL-er begrenses skaden til hjemmesiden, fordi alle andre sider har en distinkt buffer-nøkkel per språk. Med «språk kun fra innhold»-modusen sprer samme problem seg til alle URL-er på nettstedet.

Tre løsninger fungerer. Den enkleste er å slå av nettleserbasert språkdeteksjon på alle bufrede nettsteder og la besøkende velge via språkbytteren. Den andre er å si til buffer-programtillegget at det skal variere på eller omgå pll_language-informasjonskapselen. Den tredje er å utelukke hjemmesiden fra side-bufferen slik at deteksjons-omdirigeringen alltid kjøres live.

Bruker du WP Rocket, W3 Total Cache eller LiteSpeed, se vår dokumentasjon for caching-integrasjon for informasjonskapsel-konfigurasjonen. Polylang fungerer ved siden av disse buffer-programtilleggene, men det å sameksistere er ikke det samme som å være språkbevisst. Du konfigurerer bufferen selv.

AJAX-atferd på grensesnittet

Polylang oppdager automatisk gjeldende språk på AJAX-forespørsler fra grensesnittet og laster strenger for det språket. Du kan også sende en eksplisitt lang-variabel i forespørselen for å tvinge et bestemt språk. For TTS er dette viktig når lydspilleren eller relaterte-innlegg-widgeten sender en AJAX-forespørsel for å hente et annet innlegg.

I vår testing håndterer Polylang dette uten problemer. Vi så ikke AJAX-språk-regresjonene vi dokumenterte i WPML-innlegget. Hvis en tilpasset integrasjon trenger å hente et innlegg på et annet enn gjeldende språk, send lang eksplisitt og sjekk at function_exists('pll_current_language') før du leser resultatet.

Sette opp Tekst til Tale - TTSWP på et Polylang-nettsted

Disse trinnene forutsetter at Polylang allerede er installert og at minst én oversettelse finnes.

1. Installer Tekst til Tale - TTSWP fra WordPress.org-siden for programtillegget. Aktiver det. Se installasjonsdokumentasjonen hvis du får en tillatelsesfeile.
2. Koble programtillegget til TTSWP ved å følge tilkoblingsveiledningen. Den gratis planen inkluderer velkomstkreditter slik at du kan teste før du bestemmer deg for et betalt nivå.
3. Åpne innlegget på originalspråket og generer lyd. Bekreft at spilleren vises på grensesnittet.
4. Bytt til den oversatte versjonen fra Polylangs språkbytter i innleggsredigereren. Generer lyd igjen. Polylang har lastet en annen post-ID, så TTSWP behandler dette som en ny generering og lagrer en separat fil.
5. Velg stemme for hver oversettelse. Stemmevalg skjer på innleggsnivå. Se dokumentasjonen for stemmevalg for overstyring per innlegg.
6. Kontroller på grensesnittet. Åpne /en/innlegg-slug og /de/innlegg-slug i forskjellige faner. Spill begge. Stemmene og språkene bør stemme overens.

Per i dag dekker per-språk standard stemmetilordning i TTSWP WPML og Weglot først. På Polylang skjer stemmevalg på innleggsnivå, og per-språk-standarden fungerer via innleggsspråk-hentingen vi beskriver nedenfor. For de fleste Polylang-nettsteder er dette nok, fordi hver oversettelse er et ekte innlegg og stemmen settes én gang per innlegg. Se Polylang-integrasjonsdokumentasjonen for gjeldende atferd.

Slik henter stemmevalget innleggets språk

Det riktige API-kallet for å lese et innleggs språk i Polylang er pll_get_post_language(). Sjekk alltid at funksjonen finnes før du kaller den, slik Polylangs egen utviklerveiledning anbefaler. Mønsteret ser slik ut:

if ( function_exists( 'pll_get_post_language' ) ) {
    $lang = pll_get_post_language( $post_id, 'slug' );
    // $lang er nå 'en', 'de', 'fr', osv.
}

For grensesnitt-kontekst returnerer pll_current_language() gjeldende forespørselsspråk. Begge funksjonene er stabile og har vært del av Polylangs offentlige API i mange år. Logikk for stemmetilordning bør alltid lese fra innleggets språk, aldri fra nettstedets standard, ellers arver oversettelser feil stemme.

Polylang gratis versus Polylang Pro for TTS

Ingenting i Polylang Pro er nødvendig for lyd. Den gratis versjonen av Polylang gir deg alt TTSWP trenger: per-innlegg duplisering, språkslugs og de offentlige API-funksjonene ovenfor.

Polylang Pro legger til DeepL maskinoversettelse, REST API-støtte, oversatte URL-slugs og XLIFF-eksport for utkontraktert oversettelsearbeid. Ingen av disse endrer TTS-bildet for blogginnlegg og sider. Polylang for WooCommerce er et separat betalt tillegg som håndterer butikksider, produktkategorier, attributter og transaksjons-e-poster. Vil du ha lyttefunksjon på produktbeskrivelser, se vår WooCommerce TTS-guide.

SEO og AEO med lyd per språk

Polylang håndterer hreflang automatisk, noe som er det meste av SEO-arbeidet for flerspråklige nettsteder. Legg til AudioObject-schema per språkversjon, pek hver enkelt mot filen for den aktuelle oversettelsen, og du gir søkemotorer et tydelig signal.

I vår egen testing siteres artikler med lyd og AudioObject-schema oftere av AI-søkemotorer. Vi dokumenterte metoden og resultatene i vårt AEO- og lyd-innlegg. Kortversjonen: én lydfil per oversettelse, schema per oversettelse, og AEO-fordelen følger.

Vanlige problemer og løsninger

En merknad om tilgjengelighet

Å legge til lyttefunksjon per språk er også en tilgjengelighetsgevinst. Besøkende som leser best på morsmålet sitt, men foretrekker å lytte, får nå begge deler. Faller nettstedet ditt inn under WCAG 2.2 eller EUs tilgjengelighetsdirektiv, se vår WCAG-lydoppfyllelsesveiledning for kriteriene som gjelder. For en bredere gjennomgang av å legge til TTS i WordPress i 2026, dekker hovedveiledningen det grunnleggende.

Ofte stilte spørsmål

Fungerer Polylang med tekst til tale?

Ja. Polylang lagrer hver oversettelse som et eget WordPress-innlegg med sin egen ID, noe som er den samme arkitekturen TTSWP bruker for per-innlegg lyd. Generer lyd på hver oversettelse og du får én fil per språk med stemmen du valgte. Den gratis versjonen av Polylang er nok. Ingen spesiell konfigurasjon er nødvendig utover standard TTSWP-oppsett.

Trenger jeg Polylang Pro for lyd?

Nei. Den gratis versjonen av Polylang eksponerer alt TTSWP trenger: per-språk innleggsduplisering, språkslugs og de offentlige API-funksjonene pll_get_post_language() og pll_current_language(). Polylang Pro legger til DeepL maskinoversettelse, REST API-støtte og oversatte URL-slugs. Ingen av disse endrer hvordan lydgenerering eller avspilling fungerer.

Kan hvert språk ha sin egen stemme?

Ja. Fordi hver oversettelse er et eget innlegg, skjer stemmevalg på innleggsnivå. Velg en tysk stemme på den tyske oversettelsen, en spansk stemme på den spanske, og så videre. TTSWP lagrer valget per innlegg og bruker det hver gang du genererer på nytt. Se dokumentasjonen for språk- og stemmetilordning for gjeldende atferd.

Hvorfor spilles lyden på feil språk?

Den vanligste årsaken er side-caching kombinert med Polylangs nettleserbaserte språkdeteksjon. Bufferen lagrer hjemmesidens omdirigering eller én språkvariant og serverer den til alle. Lydfilen i seg selv er riktig for post-ID-en. Siden som laster den, er ikke det. Slå av nettleserdeteksjon på bufrede nettsteder, eller si til buffer-programtillegget at det skal variere på pll_language-informasjonskapselen. Katalog-URL-er (/en/, /de/) begrenser skaden til hjemmesiden fordi alle andre sider har en distinkt buffer-nøkkel.

Hvordan skiller Polylang seg fra WPML for TTS?

Begge dupliserer innlegg per språk, så per-innlegg lyd fungerer på samme måte på begge. Forskjellene ligger i AJAX-håndtering, informasjonskapsel-atferd og navn på utvikler-API. Polylang bruker funksjoner med pll_-prefiks og er generelt lettere. WPML har flere innebygde WooCommerce-funksjoner, men et større programtillegg-fotavtrykk. Vår WPML-guide dekker den siden.

Kan jeg oversette spillerens etiketter?

Ja, med ett ekstra trinn. Polylang har en skjerm for strengoversettelse for programtillegg som registrerer sine UI-strenger med pll_register_string(). Vil du at avspillingsknappen, tidsetiketten eller annen spillertekst skal bytte med språket, registrer disse strengene i barnetemaet ditt eller et lite nettstedsspesifikt programtillegg. De vises da under Språk, Strengoversettelser.

Hva gjør du videre

Åpne ett av de oversatte innleggene dine i WordPress-redigereren og se på lydpanelet. Viser det riktig språk som standard, er oppsettet ferdig. Hvis ikke, sett stemmen på den oversettelsen, generer på nytt og sjekk grensesnittet. Når én oversettelse fungerer, følger resten samme mønster.

Har du ikke installert Tekst til Tale - TTSWP ennå, hent det fra WordPress.org og koble det til din gratis TTSWP-konto. Test på én oversettelse, lytt, og bestem deg for om du vil rulle det ut på resten.