Text till tal för Polylang-sajter: vad som faktiskt fungerar

Verkligt stöd för text till tal i Polylang innebär en ljudfil per översatt inlägg, på rätt språk och med rätt röst. Eftersom Polylang lagrar varje översättning som ett eget WordPress-inlägg med ett eget ID fungerar per-inlägg-ljudgenerering direkt. Fallgroparna är röstval, cookie-omdirigeringar och sidcachning, inte själva ljudet.

Det här är det fjärde inlägget i vår serie om flerspråkig TTS. Vi har tidigare gått igenom WPML, Weglot och GTranslate 3.3.0-releasen. Polylang liknar WPML i arkitekturen men har sina egna egenheter. Här är vad vi testade och vad som faktiskt fungerar på produktionssajter med Text till tal - TTSWP.

Varför Polylang spelar roll för text till tal

Polylang driver fler flerspråkiga WordPress-sajter än något annat gratis-plugin. Det har mer än 800 000 aktiva installationer och den största gratisbasen av alla allmänna flerspråkiga plugin. Den första versionen kom 2011 och plugin-programmet underhålls fortfarande aktivt. Det finns ingen gräns för hur många språk du kan lägga till, och WordPress språkpaket laddas ned automatiskt. De flesta Polylang-sajter drivs av bloggar, mindre utgivare och budgetmedvetna byråer som valde det för att kärnan är gratis och arkitekturen ren.

Den populariteten är problemet för TTS-plugin. Många påstår sig stödja Polylang men testar bara standardspråket. De kopplar en enda ljudfil till ett inlägg och serverar sedan samma fil på varje översättning. Den spanska versionen spelar engelsk audio. Den tyska versionen är tyst. Besökarna lämnar.

Lösningen är strukturell. Polylang lägger inte till några extra databastabeller eller shortcodes. Det bygger på WordPress-taxonomier, samma kärnfunktion som driver kategorier och taggar. Varje översättning lever som ett riktigt inlägg. Per-inlägg-ljudgenerering, vilket är hur TTSWP fungerar, passar därför perfekt med hur Polylang lagrar innehåll.

Hur Polylang skiljer sig från Weglot och GTranslate

Polylang duplicerar inlägg. Weglot och GTranslate översätter vid renderingstillfället. Den enda skillnaden avgör allt om TTS-stödet.

På en Polylang-sajt är den tyska översättningen av "Om oss" ett separat WordPress-inlägg med inläggs-ID 412, språk-slug "de" och sitt eget innehåll i databasen. WordPress ser det, REST API ser det, och alla TTS-plugin som kopplar sig till save_post eller wp_insert_post ser det. Ljudgenerering körs en gång per översättning, på det språket, och filen cachas mot det inläggs-ID:t.

Weglot och GTranslate fungerar annorlunda. Den översatta texten finns bara när en användare begär sidan. Det finns inget andra inlägg att koppla ljud till. Vi gick igenom lösningarna för Weglot och GTranslate i tidigare inlägg. WPML använder samma dupliceringsmodell som Polylang, vilket är varför vår WPML-guide gäller här med små justeringar.

För TTS är det goda nyheter. Polylang ger dig exakt vad du behöver: ett stabilt inläggs-ID per språk, en känd språk-slug och en permalänk som inte förändras vid renderingstillfället.

Polylangs fyra URL-strukturer och vad de innebär för TTS

Polylang erbjuder fyra URL-lägen. Vart och ett förändrar hur cacher, CDN:er och språkdetekteringskod ser dina sidor. Välj fel och rätt ljudfil hamnar bakom fel URL.

1. Språk enbart från innehåll (ingen språkkod i URL)

Det här är det svåraste fallet. URL:en example.com/about serverar engelska till en besökare och tyska till en annan, baserat på cookie eller webbläsardetektering. Sidcacher ser en URL och lagrar en variant. Vilket språk cachen fångade först vinner.

För TTS är själva ljudfilen okej eftersom den är knuten till inläggs-ID:t, inte URL:en. Problemet är sidan som bäddar in spelaren. Om den cachade engelska sidan läses in med den tyska ljudinbäddningen spelar spelaren fortfarande tyska, men besökarna förväntade sig engelsk text. Vi rekommenderar inte det här URL-läget på någon cachad sajt.

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

Det här är standardinställningen och den vi rekommenderar. Varje språk lever på sin egen sökväg. Cacher behandlar /en/about och /de/about som distinkta nycklar. Rätt sida laddas med rätt spelare och rätt ljudfil. Inga cookie-trick behövs.

Håll koll på alternativet "dölj URL-språkinformation för standardspråket". När det är aktiverat tappar standardspråket prefixet. /about blir engelska och /de/about förblir tyska. URL-baserad språkdetektering i tredjepartskod misslyckas då på standardspråkets sökvägar eftersom den inte ser någon slug. Om du använder det här alternativet, förlita dig på pll_current_language() snarare än URL-parsning.

3. Subdomän (en.example.com, de.example.com)

Subdomäner ger varje språk sin egen host och sitt eget cache-namnområde. TTS-spelare läses in rent per språk. Kostnaden är DNS, SSL-certifikat per subdomän och lite mer komplex analys. Fungerar bra i stor skala.

4. Separata domäner per språk

Fullständig separation. example.com för engelska, example.de för tyska. TTS kopplar fortfarande ljud till inläggs-ID:t inuti varje WordPress-installation och spelaren fungerar på samma sätt. Det här läget är vanligt för varumärken som redan äger ccTLD:er.

Problemet med cookie-omdirigeringar

Polylang kan detektera en besökares webbläsarspråk vid det första besöket på din startsida. Det sätter då cookien pll_language och omdirigerar besökaren till rätt språkversion. Kombinerat med sidcachning är det här var fel-språks-ljud dyker upp.

Här är felscenariot vi har reproducerat. En fransk besökare landar på startsidan. Polylang detekterar franska, sätter cookien pll_language och omdirigerar till /fr/. Cachen lagrar det omdirigeringssvaret under startsidans URL. Nästa besökare, en engelsktalande, begär startsidan och får den cachade omdirigeringen till /fr/. De hamnar på den franska sidan, hör franskt ljud och lämnar.

Med katalog-URL:er stannar skadan på startsidan, eftersom varje annan sida har en distinkt cachenyckel per språk. Med läget "språk från innehåll" sprids samma problem till alla URL:er på sajten.

Tre lösningar fungerar. Den enklaste är att stänga av webbläsarspråksdetektering på alla cachade sajter och låta besökarna välja via språkväljaren. Den andra är att instruera ditt cache-plugin att variera på eller hoppa över cookien pll_language. Den tredje är att utesluta startsidan från sidcachen så att detekteringsomdirigeringen alltid körs live.

Kör du WP Rocket, W3 Total Cache eller LiteSpeed, se vår dokumentation om cachningsintegrationer för cookie-konfigurationen. Polylang fungerar sida vid sida med dessa cache-plugin, men att samexistera är inte samma sak som att vara språkmedveten. Du konfigurerar fortfarande cachen själv.

AJAX-beteende i frontend

Polylang detekterar automatiskt det aktuella språket vid frontend-AJAX-förfrågningar och laddar strängar för det språket. Du kan också skicka en explicit lang-variabel i förfrågan för att tvinga fram ett specifikt språk. För TTS spelar det roll när ljudspelaren eller widgeten för relaterade inlägg skickar ett AJAX-anrop för att hämta ett annat inlägg.

I våra tester hanterar Polylang det här rent. Vi såg inte de AJAX-språkregressioner vi dokumenterade i WPML-inlägget. Om en anpassad integration behöver hämta ett inlägg på ett icke-aktuellt språk, skicka lang explicit och kontrollera att function_exists('pll_current_language') innan du läser resultatet.

Sätta upp Text till tal - TTSWP på en Polylang-sajt

Dessa steg förutsätter att Polylang redan är installerat och att minst en översättning finns.

1. Installera Text till tal - TTSWP från plugin-sidan på WordPress.org. Aktivera det. Se installationsdokumentationen om du får ett behörighetsfel.
2. Anslut plugin-programmet till TTSWP genom att följa anslutningsguiden. Gratisplanen inkluderar välkomstpoäng så att du kan testa innan du bestämmer dig för en betalnivå.
3. Öppna inlägget på originalspråket och generera ljud. Bekräfta att spelaren visas i frontend.
4. Byt till den översatta versionen via Polylangs språkväljare i inläggsredigeraren. Generera ljud igen. Polylang har laddat ett annat inläggs-ID, så TTSWP behandlar det som en ny generering och lagrar en separat fil.
5. Välj röst för varje översättning. Röstval sker på inläggsnivå. Se dokumentationen för röstval för per-inlägg-överstyrning.
6. Verifiera i frontend. Öppna /en/inlagg-slug och /de/inlagg-slug i olika flikar. Spela varje. Rösterna och språken ska stämma.

I nuläget täcker per-språk standardröstmappning i TTSWP WPML och Weglot i första hand. På Polylang sker röstval på inläggsnivå och per-språk-standarden fungerar via inläggets språkhämtning som vi beskriver nedan. För de flesta Polylang-sajter räcker det, eftersom varje översättning är ett riktigt inlägg och rösten ställs in en gång per inlägg. Se Polylang-integrationsdokumentationen för det aktuella beteendet.

Hur röstvalet ska hämta inläggets språk

Det korrekta API:et för att läsa ett inläggs språk i Polylang är pll_get_post_language(). Kontrollera alltid att funktionen finns innan du anropar den, vilket även Polylangs egna riktlinjer för utvecklare rekommenderar. Mönstret ser ut så här:

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

I frontend-kontext returnerar pll_current_language() det aktuella förfrågningsspråket. Båda funktionerna är stabila och har ingått i Polylangs publika API i många år. Röstmappningslogiken bör alltid läsa från inläggets språk, aldrig från sajtstandardinställningen, annars ärver översättningar fel röst.

Polylang gratis jämfört med Polylang Pro för TTS

Inget i Polylang Pro krävs för ljud. Gratisversionen av Polylang ger dig allt TTSWP behöver: per-inlägg-duplicering, språk-slugs och de publika API-funktionerna ovan.

Polylang Pro lägger till DeepL-maskinöversättning, REST API-stöd, översatta URL-slugs och XLIFF-export för outsourcad översättningsarbete. Inget av detta förändrar TTS-situationen för blogginlägg och sidor. Polylang för WooCommerce är ett separat betalt tillägg som hanterar butikssidor, produktkategorier, attribut och transaktionsmail. Vill du ha uppläsning på produktbeskrivningar, se vår WooCommerce TTS-guide.

SEO och AEO med ljud per språk

Polylang hanterar hreflang automatiskt, vilket är det mesta av SEO-arbetet för flerspråkiga sajter. Lägg till AudioObject-schema per språkversion, peka varje på filen för den specifika översättningen och du ger sökmotorer en tydlig signal.

I våra egna tester citeras artiklar med ljud och AudioObject-schema oftare av AI-sökmotorer. Vi dokumenterade metoden och resultaten i vårt inlägg om AEO och ljud. Kortversionen: en ljudfil per översättning, schema per översättning, och AEO-fördelen följer.

Vanliga problem och lösningar

En not om tillgänglighet

Att lägga till uppläsning per språk är också en tillgänglighetsvinst. Besökare som läser bättre på sitt modersmål men föredrar att lyssna får nu båda alternativen. Om din sajt omfattas av WCAG 2.2 eller EU:s tillgänglighetsdirektiv, se vår guide om WCAG-ljudkrav för de kriterier som gäller. För en bredare genomgång av hur du lägger till TTS i WordPress 2026 tar huvudhandledningen upp grunderna.

Vanliga frågor

Fungerar Polylang med text till tal?

Ja. Polylang lagrar varje översättning som ett separat WordPress-inlägg med ett eget ID, vilket är samma arkitektur som TTSWP använder för per-inlägg-ljud. Generera ljud på varje översättning och du får en fil per språk med den röst du valde. Gratisversionen av Polylang räcker. Ingen särskild konfiguration krävs utöver standardinställningen för TTSWP.

Behöver jag Polylang Pro för ljud?

Nej. Gratisversionen av Polylang exponerar allt TTSWP behöver: per-språk-inläggsduplikering, språk-slugs och de publika API-funktionerna pll_get_post_language() och pll_current_language(). Polylang Pro lägger till DeepL-maskinöversättning, REST API-stöd och översatta URL-slugs. Inget av det påverkar hur ljudgenerering eller uppspelning fungerar.

Kan varje språk ha sin egen röst?

Ja. Eftersom varje översättning är ett separat inlägg sker röstvalet på inläggsnivå. Välj en tysk röst på den tyska översättningen, en spansk röst på den spanska översättningen, och så vidare. TTSWP sparar valet per inlägg och använder det varje gång du genererar om. Se dokumentationen för språk- och röstmappning för det aktuella beteendet.

Varför spelas mitt ljud på fel språk?

Den vanligaste orsaken är sidcachning kombinerat med Polylangs webbläsarspråksdetektering. Cachen lagrar startsideomdirigeringen eller en enda språkvariant och serverar den till alla. Själva ljudfilen är korrekt för inläggs-ID:t. Det är sidan som laddar den som inte stämmer. Stäng av webbläsardetektering på cachade sajter, eller instruera ditt cache-plugin att variera på cookien pll_language. Katalog-URL:er (/en/, /de/) begränsar skadan till startsidan eftersom alla andra sidor har en distinkt cachenyckel.

Hur skiljer sig Polylang från WPML för TTS?

Båda duplicerar inlägg per språk, så per-inlägg-ljud fungerar likadant på båda. Skillnaderna finns i AJAX-hanteringen, cookie-beteendet och API-namngivningen. Polylang använder funktioner med prefixet pll_ och är generellt sett lättare. WPML har fler inbyggda WooCommerce-funktioner men ett större plugin-fotavtryck. Vårt WPML-inlägg tar upp den sidan.

Kan jag översätta spelarens etiketter?

Ja, med ett extra steg. Polylang erbjuder en strängöversättningsskärm för plugin som registrerar sina UI-strängar med pll_register_string(). Vill du att uppspelningsknappen, tidräkningsetiketten eller annan spelartext ska byta med språket, registrera de strängarna i ditt child-tema eller ett litet sajt-specifikt plugin. De visas sedan under Språk, Strängöversättningar.

Nästa steg

Öppna ett av dina översatta inlägg i WordPress-redigeraren och titta på ljudpanelen. Om den visar rätt språk som standard är uppsättningen klar. Annars ställer du in rösten på den översättningen, genererar om och kontrollerar frontend. När en översättning fungerar följer resten samma mönster.

Har du inte installerat Text till tal - TTSWP än, hämta det från WordPress.org och anslut det till ditt gratis TTSWP-konto. Testa på en översättning, lyssna och bestäm om du vill rulla ut det på resten.