Tekst til tale med Polylang: Hvad der faktisk virker

Rigtig tekst til tale med Polylang betyder én lydfil pr. oversat indlæg, på det korrekte sprog og med den rigtige stemme. Polylang gemmer hver oversættelse som sit eget WordPress-indlæg med sit eget ID, så lydgenerering pr. indlæg fungerer direkte. Udfordringerne ligger i stemmevalg, cookie-omdirigeringer og side-caching, ikke i selve lyden.

Dette er det fjerde indlæg i vores flersprogede TTS-serie. Vi har gennemgået WPML, Weglot og GTranslate 3.3.0-udgivelsen. Polylang ligner WPML mest i arkitektur, men har sine egne særtræk. Her er, hvad vi testede, og hvad der faktisk virker på produktionssites med Tekst til tale - TTSWP.

Derfor er Polylang vigtig for tekst til tale

Polylang driver flere flersprogede WordPress-sites end noget andet gratis plugin. Det har over 800.000 aktive installationer og den største gratis brugerbase af alle generelle flersprogede plugins. Den første version udkom i 2011, og pluginnet vedligeholdes stadig aktivt. Der er ingen grænse for antallet af sprog, du kan tilføje, og WordPress-sprogpakker hentes automatisk. De fleste Polylang-sites er blogs, mindre udgivere og budgetbevidste bureauer, der valgte det, fordi kernen er gratis og arkitekturen er overskuelig.

Den popularitet er problemet for TTS-plugins. Mange hævder at understøtte Polylang, men tester kun standardsproget. De knytter én lydfil til et indlæg og serverer derefter den samme fil for alle oversættelser. Den spanske version afspiller engelsk lyd. Den tyske version er tavs. Besøgende forlader siden.

Løsningen er strukturel. Polylang tilføjer ingen ekstra databasetabeller og ingen shortcodes. Det bygger på WordPress-taksonomier, den samme kernefunktion der driver kategorier og tags. Hver oversættelse lever som et rigtigt indlæg. Derfor passer lydgenerering pr. indlæg, som er sådan TTSWP fungerer, direkte med, hvordan Polylang gemmer indhold.

Sådan adskiller Polylang sig fra Weglot og GTranslate

Polylang duplikerer indlæg. Weglot og GTranslate oversætter ved rendering. Den ene forskel afgør alt om TTS-understøttelse.

På et Polylang-site er den tyske oversættelse af «Om os» et separat WordPress-indlæg med indlægs-ID 412, sprogslug «de» og sit eget indhold i databasen. WordPress ser det, REST API'et ser det, og ethvert TTS-plugin, der hager sig ind i save_post eller wp_insert_post, ser det. Lydgenerering kører én gang pr. oversættelse, på det pågældende sprogs sprog, og filen caches mod det indlægs-ID.

Weglot og GTranslate fungerer anderledes. Den oversatte tekst eksisterer kun, når en bruger anmoder om siden. Der er intet andet indlæg at knytte lyd til. Vi gennemgik løsningerne for Weglot og GTranslate i tidligere indlæg. WPML bruger samme duplikeringsmodel som Polylang, og derfor gælder vores WPML-guide her med små justeringer.

For TTS er det gode nyheder. Polylang giver dig præcis, hvad du har brug for: et stabilt indlægs-ID pr. sprog, et kendt sprogslug og et permalink, der ikke ændrer sig ved rendering.

De fire Polylang URL-strukturer og hvad hver betyder for TTS

Polylang tilbyder fire URL-tilstande. Hver ændrer, hvordan caches, CDN'er og sprogdetektionskode ser dine sider. Vælger du den forkerte, ender den rigtige lydfil bag den forkerte URL.

1. Sprog fra indhold alene (ingen sprogkode i URL)

Dette er det sværeste tilfælde. URL'en example.com/about serverer engelsk til én besøgende og tysk til en anden, baseret på cookie eller browserdetektering. Side-caches ser én URL og gemmer én variant. Det sprog, cachen hentede først, vinder.

For TTS er lydfilen i sig selv fin, fordi den er knyttet til indlægs-ID'et, ikke URL'en. Problemet er siden, der indlejrer afspilleren. Hvis den cachede engelske side indlæses med den tyske lydindlejring, afspiller afspilleren stadig tysk, men besøgende forventede engelsk tekst. Vi anbefaler ikke denne URL-tilstand på nogen cachet site.

2. Mappe-URL'er (/en/, /de/)

Dette er standardindstillingen og den opsætning, vi anbefaler. Hvert sprog har sin egen sti. Caches behandler /en/about og /de/about som separate nøgler. Den rigtige side indlæses med den rigtige afspiller og den rigtige lydfil. Ingen cookie-tricks nødvendig.

Hold øje med indstillingen «skjul URL-sprogoplysninger for standardsprog». Når den er aktiveret, mister standardsproget sit præfiks. /about bliver engelsk, og /de/about forbliver tysk. URL-baseret sprogdetektering i tredjepartskode fejler derefter på standardsprogsstierne, fordi den ikke ser noget slug. Bruger du denne indstilling, bør du bruge pll_current_language() frem for URL-parsing.

3. Subdomæne (en.example.com, de.example.com)

Subdomæner giver hvert sprog sit eget host og sit eget cache-navnerum. TTS-afspillere indlæses korrekt pr. sprog. Prisen er DNS, SSL-certifikater pr. subdomæne og lidt mere kompleks analyse. Fungerer godt i større skala.

4. Separate domæner pr. sprog

Fuld adskillelse. example.com til engelsk, example.de til tysk. TTS knytter stadig lyd til indlægs-ID'et inden for hver WordPress-installation, og afspilleren fungerer på samme måde. Denne tilstand er almindelig for brands, der allerede ejer ccTLD'er.

Problemet med cookie-omdirigeringer

Polylang kan registrere en besøgendes browsersprog ved første besøg på forsiden. Derefter sætter den pll_language-cookien og omdirigerer den besøgende til den tilsvarende sprogversion. Kombineret med side-caching er det her, forkert-sprog-lyd opstår.

Her er den fejlsekvens, vi har reproduceret. En fransk besøgende lander på forsiden. Polylang registrerer fransk, sætter pll_language-cookien og omdirigerer til /fr/. Cachen gemmer den omdirigeringsrespons under forsidernes URL. Den næste besøgende, en engelsk taler, anmoder om forsiden og modtager den cachede omdirigering til /fr/. De lander på den franske side, hører fransk lyd og forlader siden.

Med mappe-URL'er begrænses skaden til forsiden, fordi alle andre sider har en separat cachenøgle pr. sprog. Med «sprog fra indhold»-tilstanden spreder det samme problem sig til alle URL'er på sitet.

Tre løsninger virker. Den enkleste er at slå browsersprogs-detektering fra på alle cachede sites og lade besøgende vælge via sprogskifteren. Den anden er at fortælle dit cache-plugin om at variere på eller omgå pll_language-cookien. Den tredje er at ekskludere forsiden fra side-cachen, så detekteringsomdirigeringen altid kører live.

Bruger du WP Rocket, W3 Total Cache eller LiteSpeed, se vores caching-integrationsdokumentation for cookie-konfigurationen. Polylang fungerer sammen med disse cache-plugins, men at sameksistere er ikke det samme som at være sprogs-bevidst. Du skal stadig konfigurere cachen selv.

AJAX-adfærd på frontend

Polylang registrerer automatisk det aktuelle sprog ved frontend-AJAX-anmodninger og indlæser strenge for det pågældende sprog. Du kan også sende en eksplicit lang-variabel i anmodningen for at tvinge et bestemt sprog. For TTS betyder det noget, når lydafspilleren eller widgets til relaterede indlæg sender en AJAX-forespørgsel for at hente et andet indlæg.

I vores test håndterer Polylang dette korrekt. Vi så ikke de AJAX-sprogregressioner, vi dokumenterede i WPML-indlægget. Hvis en tilpasset integration skal hente et indlæg på et ikke-aktuelt sprog, send lang eksplicit og tjek, at function_exists('pll_current_language') er sand, før du læser resultatet.

Sådan opsætter du Tekst til tale - TTSWP på et Polylang-site

Disse trin forudsætter, at Polylang allerede er installeret, og at der findes mindst én oversættelse.

1. Installer Tekst til tale - TTSWP fra WordPress.org-plugin-siden. Aktiver det. Se installationsdokumentationen, hvis du støder på en tilladselsesfejl.
2. Forbind pluginnet til TTSWP ved at følge forbindelsesguiden. Den gratis plan inkluderer velkomst-kreditter, så du kan teste, inden du beslutter dig for et betalt niveau.
3. Åbn indlægget på originalsprog og generer lyd. Bekræft, at afspilleren vises på frontend.
4. Skift til den oversatte version via Polylangs sprogskifter i indlægseditoren. Generer lyd igen. Polylang har indlæst et andet indlægs-ID, så TTSWP behandler dette som en ny generering og gemmer en separat fil.
5. Vælg stemme for hver oversættelse. Stemmevalg sker på indlægsniveau. Se dokumentationen for stemmevalg for pr.-indlæg-tilsidesættelsen.
6. Verificer på frontend. Åbn /en/indlæg-slug og /de/indlæg-slug i forskellige faner. Afspil begge. Stemmerne og sprogene bør stemme overens.

I dag dækker pr.-sprog standard stemme-mapping i TTSWP primært WPML og Weglot. På Polylang foregår stemmevalg på indlægsniveau, og pr.-sprog-standarden fungerer via den indlægssprog-hentning, vi beskriver nedenfor. For de fleste Polylang-sites er det nok, fordi hver oversættelse er et rigtigt indlæg, og stemmen sættes én gang pr. indlæg. Se Polylang-integrationsdokumentationen for den aktuelle adfærd.

Sådan henter stemmevalget indlægssproget

Den korrekte API til at læse et indlægs sprog i Polylang er pll_get_post_language(). Tjek altid, at funktionen eksisterer, inden du kalder den, som Polylangs egne udviklervejledninger anbefaler. Mønsteret ser sådan ud:

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

Til frontend-kontekst returnerer pll_current_language() det aktuelle anmodningssprog. Begge funktioner er stabile og har været en del af Polylangs offentlige API i mange år. Stemme-mapping-logik bør altid læse fra indlægssproget, aldrig fra sitestandarden, ellers arver oversættelser den forkerte stemme.

Polylang gratis versus Polylang Pro til TTS

Intet i Polylang Pro er nødvendigt for lyd. Den gratis version af Polylang giver dig alt, TTSWP har brug for: pr.-indlæg-duplikering, sprogslug og de offentlige API-funktioner ovenfor.

Polylang Pro tilføjer DeepL-maskinoversættelse, REST API-understøttelse, oversatte URL-slug og XLIFF-eksport til outsourcet oversættelsesarbejde. Ingen af disse ændrer TTS-billedet for blogindlæg og sider. Polylang til WooCommerce er et separat betalt tilføjelsesprogram, der håndterer butikssider, produktkategorier, attributter og transaktionsmails. Ønsker du oplæsning af produktbeskrivelser, se vores WooCommerce TTS-guide.

SEO og AEO med lyd pr. sprog

Polylang håndterer hreflang automatisk, hvilket udgør det meste af SEO-arbejdet for flersprogede sites. Tilføj AudioObject-schema pr. sprogversion, peg hver enkelt på filen for den specifikke oversættelse, og du giver søgemaskiner et klart signal.

I vores egne tests bliver artikler med lyd og AudioObject-schema citeret hyppigere af AI-søgemaskiner. Vi dokumenterede metoden og resultaterne i vores AEO og lyd-indlæg. Den korte version: én lydfil pr. oversættelse, schema pr. oversættelse, og AEO-fordelen følger med.

Almindelige problemer og løsninger

En note om tilgængelighed

Oplæsning pr. sprog er også en gevinst for tilgængelighed. Besøgende, der læser bedre på deres modersmål, men foretrækker at lytte, får nu begge dele. Falder dit site under WCAG 2.2 eller den europæiske tilgængelighedslov, se vores WCAG-lydoverholdelsesguide for de relevante kriterier. For en bredere gennemgang af, hvordan du tilføjer TTS til WordPress i 2026, dækker hovedtutorialen grundprincipperne.

Ofte stillede spørgsmål

Virker Polylang med tekst til tale?

Ja. Polylang gemmer hver oversættelse som et separat WordPress-indlæg med sit eget ID, hvilket er den samme arkitektur, TTSWP bruger til pr.-indlæg-lyd. Generer lyd på hver oversættelse, og du får én fil pr. sprog med den stemme, du valgte. Den gratis version af Polylang er nok. Der kræves ingen særlig konfiguration ud over den standard TTSWP-opsætning.

Har jeg brug for Polylang Pro til lyd?

Nej. Den gratis version af Polylang eksponerer alt, TTSWP har brug for: pr.-sprog-indlægsduplikering, sprogslug og de offentlige API-funktioner pll_get_post_language() og pll_current_language(). Polylang Pro tilføjer DeepL-maskinoversættelse, REST API-understøttelse og oversatte URL-slug. Ingen af disse ændrer, hvordan lydgenerering eller afspilning fungerer.

Kan hvert sprog have sin egen stemme?

Ja. Fordi hver oversættelse er et separat indlæg, sker stemmevalg på indlægsniveau. Vælg en tysk stemme på den tyske oversættelse, en spansk stemme på den spanske oversættelse og så videre. TTSWP gemmer valget pr. indlæg og bruger det, hver gang du regenererer. Se dokumentationen for sprog og stemme-mapping for den aktuelle adfærd.

Hvorfor afspilles min lyd på det forkerte sprog?

Den typiske årsag er side-caching kombineret med Polylangs browsersprogs-detektering. Cachen gemmer forside-omdirigeringen eller én sprogvariant og serverer den til alle. Lydfilen i sig selv er korrekt for indlægs-ID'et. Det er siden, der indlæser den, der ikke er. Slå browserdetektering fra på cachede sites, eller fortæl dit cache-plugin om at variere på pll_language-cookien. Mappe-URL'er (/en/, /de/) begrænser skaden til forsiden, fordi alle andre sider har en separat cachenøgle.

Hvordan adskiller Polylang sig fra WPML til TTS?

Begge duplikerer indlæg pr. sprog, så pr.-indlæg-lyd fungerer på samme måde på begge. Forskellene ligger i AJAX-håndtering, cookie-adfærd og navnene på udvikler-API'et. Polylang bruger pll_-præfikserede funktioner og er generelt lettere. WPML har flere indbyggede WooCommerce-funktioner, men et større plugin-fodaftryk. Vores WPML-indlæg dækker den side.

Kan jeg oversætte afspillerens etiketter?

Ja, med et ekstra trin. Polylang eksponerer en strengoversættelsesskærm for plugins, der registrerer deres UI-strenge med pll_register_string(). Ønsker du, at afspilningsknappen, tidslinjeetiketten eller anden afspillertekst skifter med sproget, registrer de strenge i dit child-tema eller et lille site-specifikt plugin. De vises derefter under Sprog, Strengoversættelser.

Næste skridt

Åbn et af dine oversatte indlæg i WordPress-editoren og se på lydpanelet. Viser det det rigtige sprog som standard, er opsætningen færdig. Hvis ikke, sæt stemmen på den oversættelse, generer igen og tjek frontend. Når én oversættelse virker, følger resten det samme mønster.

Har du endnu ikke installeret Tekst til tale - TTSWP, hent det fra WordPress.org og forbind det til din gratis TTSWP-konto. Test på én oversættelse, lyt, og beslut derefter, om du vil rulle det ud på resten.