Text till tal för TranslatePress: Så fungerar det

TranslatePress översätter den renderade HTML-koden för en sida vid förfrågningstid och lagrar alla översättningar i lokala databastabeller. Det finns ett post-ID per artikel och språkbyten sker via trp_translate(), inte via dubblettposter. Det ändrar hur text till tal måste fungera på en TranslatePress-sajt.

Det här är det femte och sista inlägget i vår serie om flerspråkig TTS. Vi har redan gått igenom WPML, Polylang, Weglot och GTranslate. TranslatePress befinner sig tekniskt sett mitt emellan dem, och ljuduppsättningen speglar det.

Hur TranslatePress skiljer sig från WPML, Polylang och Weglot

WPML och Polylang skapar en separat post för varje språk. Varje översättning har sitt eget post-ID, sitt eget post_content och sin egen permalänk. Ljudgenerering är enkelt eftersom varje språk är ett eget WordPress-objekt.

Weglot tar motsatt approach. Översättningarna lagras på Weglots servrar och injiceras på sidan via en proxy eller subdomän. Den ursprungliga WordPress-databasen ser aldrig den översatta texten, vilket är anledningen till att server-side TTS på Weglot är svårt utan JavaScript-hooks.

TranslatePress är mittenalternativet. Det finns en post per artikel, så post_content innehåller bara standardspråket. Men alla översättningar lagras lokalt i din WordPress-databas, i wp_trp_-tabellerna. Du kan läsa dem, du kan fråga dem och du kan skicka dem till en TTS-motor. Det förändrar ljudstrategin jämfört med de andra fyra pluginsen.

Var översättningarna faktiskt lagras

TranslatePress lagrar översättningar i dedikerade tabeller med prefixet wp_trp_. Varje språkpar får sin egen ordlistetabell, namngiven som wp_trp_dictionary_<source>_<target>. Det finns också wp_trp_original_strings för källsträngarna och gettext-tabeller för tema- och pluginöversättningar.

Lagringen är riktad. En tysk översättning av en engelsk sajt lagras i ordboken från engelska till tyska. Att läsa tillbaka den kräver samma riktning. Den publika funktion du behöver är trp_translate(), som tar en textsträng och en språkkod och returnerar den översatta versionen.

if ( function_exists( 'trp_translate' ) ) {
    $translated = trp_translate( $post->post_content, 'de_DE' );
    // Pass $translated to the TTS engine, not $post->post_content.
}

För en TTS-integration är den funktionen sanningskällan. Läser du post_content direkt får du standardspråket varje gång, oavsett vilken URL besökaren är på. Se integrationsdokumentationen för TranslatePress för hur TTSWP hanterar detta på vår sida.

Fällan med locale-koder

TranslatePress använder fullständiga locale-koder, inte slugs. Tyska är de_DE, inte de. Franska är fr_FR. Brasiliansk portugisiska är pt_BR. En integration som antar Polylang-liknande tvåbokstavsslugs misslyckas tyst i TranslatePress.

TranslatePress utvecklardokumentation är tydlig om detta. Språkkoden som skickas till trp_translate() är locale-koden från Inställningar, TranslatePress, Allmänt, och den är inte nödvändigtvis densamma som språkslugen i URL:en. En enkel slug som de matchar ingen ordlista, så funktionen faller tillbaka på originalsträngen utan varning. Skriver du egen kod ska du normalisera dina språkkoder innan du anropar trp_translate(), och lagra samma locale-format tillsammans med dina ljudfiler så att du kan matcha dem senare.

URL-struktur och cachelagring

TranslatePress använder som standard en underkatalog per språk. Din engelska sida ligger på site.com/blog/post och den tyska versionen på site.com/de/blog/post. Det finns också ett alternativ att använda en underkatalog för standardspråket, vilket gör alla språk symmetriska.

Det är det bra fallet för cachelagring. Olika URL:er innebär olika cache-nycklar per språk. WP Rocket, LiteSpeed och CDN-kantcacher behandlar alla /de/blog/post som en separat resurs från /blog/post, så din tyska ljudfil levereras med den tyska sidan och din engelska med den engelska. Vår dokumentation om cache-integration beskriver undantagsreglerna om du behöver dem.

En risk är tillägget Automatic User Language Detection, som är betalt. Det omdirigerar besökare baserat på webbläsarspråk, vilket kan krocka med sidcacher och servera fel omdirigering till fel användare. Vi tog upp samma mönster i Polylang-inlägget. Färre TranslatePress-sajter använder det eftersom det är ett betaltillägg, men om du använder det ska du undanta omdirigeringslogiken från cachen.

Problemet med översättning av spelargränssnittet

Det här är unikt för TranslatePress. Pluginet identifierar och översätter strängar som injiceras av JavaScript, vilket är ovanligt. De flesta översättningsverktyg ignorerar JS-renderat innehåll. TranslatePress fångar det i DOM:en efter rendering och erbjuder att översätta det.

Bieffekten är att ljudspelarmärken som «Spela», «Pausa» och «Lyssna på den här artikeln» dyker upp i TranslatePress-redigeraren som översättningsbara strängar. Om de strängarna maskinöversätts utan granskning kan spelaren sluta med korrumperad eller felaktig knaptext, och ännu värre, felöversatta tillgänglighetsetiketter som förvirrar skärmläsare.

Det finns två lösningar i TranslatePress. Lägg till attributet data-no-translation på det element du vill undanta. Eller använd undantagsväljarna under Avancerade inställningar för att hoppa över hela behållare med CSS-väljare. Båda är dokumenterade i TranslatePress egna inställningar. För TTSWP-spelaren specifikt undantar du spelarbehållaren med klass, och låter sedan våra översatta spelarmärken komma via pluginets egna språkfiler.

Vad du ska undanta

• Ljudspelarens behållarelement
• ARIA-etiketter på uppspelnings-, paus- och förloppskontroller
• Tidsvisningar och varaktighetsindikatorer
• Röst- och språknamnetiketter som renderas av TTSWP

Om du vill styla om spelaren efter att ha undantagit den, beskriver vår dokumentation om anpassad CSS vilka väljare du behöver.

Problemet med innehållssynkronisering vid redigering

TranslatePress kopplar varje översättning till den exakta källsträngen. Redigerar du originalet skapar TranslatePress en ny källsträng och kopplar bort den befintliga översättningen. Översättningsminnet föreslår den gamla översättningen, men tills en person bekräftar den faller målspråket tillbaka på källan.

För text till tal innebär det att ljud kan glida ur synk med översatt text efter en redigering. Ett komma tillagt på engelska kopplar bort alla språks översättning av den strängen. Din tyska ljudfil säger fortfarande den gamla meningen, men den synliga tyska texten säger nu den nya.

Praktisk checklista efter redigering av innehåll:

1. Bekräfta den nya källsträngen i TranslatePress-redigeraren för varje aktivt språk.
2. Generera om ljud på standardspråkets post först.
3. Generera om ljud för varje språk, spela sedan upp ljudet på varje lokaliserad URL för att bekräfta att den nya filen matchar den synliga texten.
4. Rensa sidcachen för varje lokaliserad URL, inte bara standardspråkets.

Konfigurera TTSWP på en TranslatePress-sajt

Här är det nuvarande flödet. Integrationsdokumentationen beskriver alltid det senaste beteendet.

1. Installera TTSWP från WordPress.org plugin-katalogen. Installationsguiden går igenom det steg för steg.
2. Anslut pluginet till TTSWP-backend. Gratisplaner inkluderar välkomstpoäng så att du kan testa hela flödet innan du betalar. Se Anslut din sajt.
3. Kontrollera att TranslatePress är aktivt och att minst ett målspråk är konfigurerat med en fullständig locale-kod.
4. Tilldela en röst per språk med hjälp av språk-till-röst-mappningen. Tilldela en tysk röst till de_DE, en fransk röst till fr_FR och så vidare. Se röstval för röstlistan.
5. Publicera eller uppdatera ett inlägg. Ljud genereras för standardspråket först.
6. Spela upp ljudet på varje översatt URL. Generering sker on-demand. Första gången en besökare spelar upp ljud på ett sekundärt språk meddelar TranslatePress TTSWP vilket språk som är aktivt, och TTSWP genererar och cachelagrar filen för det språket. Alla efterföljande uppspelningar använder den cachelagrade filen.
7. Undanta spelaren från TranslatePress med data-no-translation eller en väljare i Avancerade inställningar så att spelarmärken styrs av TTSWP:s egna översättningar.

TTSWP lagrar en ljudfil per post och språk, och spelaren följer språket på den URL besökaren befinner sig på. På /de/blog/post laddar spelaren den tyska filen, på standard-URL:en laddar den filen för standardspråket. Med automatisk översättning aktiv läser TTSWP den översatta texten direkt från TranslatePress innan den skickas till ElevenLabs, så ljudet matchar det besökaren ser på sidan.

Gratis eller betalt TranslatePress för TTS

Gratis TranslatePress stöder ett ytterligare språk, inkluderar 2 000 AI-översatta ord via TranslatePress AI och låter dig använda Google Translate med din egen API-nyckel. Det räcker för att driva en tvåspråkig blogg med matchande ljud på båda språken.

Betald TranslatePress lägger till obegränsade extra språk, SEO Pack för översatta slugs, meta och hreflang-kontroll, DeepL-stöd, översättarkonton, tillägget Automatic User Language Detection och olika domän per språk. För en sajt som behöver fler än två språk, hreflang-taggar för sökmotorer eller DeepL-kvalitetsöversättningar innan TTS-generering är betalversionen det praktiska valet. Ljudkvaliteten påverkas inte av vilken nivå du använder.

SEO och AEO med språkspecifikt ljud

SEO Pack låter dig konfigurera hreflang-taggar per språk, med alternativ för landsspecifik locale, regionsoberoende språk eller båda. För sökmotorer och AI-svarsmotorer är det det som signalerar vilket ljud som matchar vilken region.

Lägg till en AudioObject-schemapost per språk-URL med rätt inLanguage-värde som matchar hreflang. Google och Bing plockar upp språkparet, och i våra egna tester citerar AI-motorer som Perplexity och ChatGPT Search artiklar med ljud oftare när schemat är välstrukturerat och ljud-URL:en svarar. Vi skrev mer om detta i inlägget om AEO och ljud.

Vanliga problem och lösningar

Tillgänglighetsnotering

Ljuduppläsning stöder flera WCAG-framgångskriterier när spelaren är tangentbordsmanövrerad och korrekt märkt. Om du undantar spelaren från TranslatePress, behåll ARIA-etiketterna intakta i TTSWP:s egna översättningar. Vår WCAG-guide för ljud går igenom kriterierna i detalj, och den huvudsakliga installationsguiden är ett bra ställe att börja.

Vanliga frågor

Fungerar TranslatePress med text till tal?

Ja. TranslatePress lagrar översättningar lokalt i wp_trp_-databastabeller, och funktionen trp_translate() returnerar översatt innehåll på serversidan. En TTS-integration kan läsa den översatta texten och generera språkspecifikt ljud, så länge den kopplar ljud till post-ID plus locale och använder fullständiga locale-koder som de_DE istället för slugs.

Behöver jag betald TranslatePress för ljud?

Nej. Gratis TranslatePress stöder ett ytterligare språk och inkluderar översättning via TranslatePress AI, Google Translate med din egen nyckel eller manuell redigering. Det räcker för en tvåspråkig sajt med matchande ljud. Betalversionen lägger till obegränsade språk, SEO Pack, DeepL och identifieringstillägg, vilket hjälper om du behöver fler än två språk eller hreflang-kontroll.

Varför är mina spelarknappar felaktigt översatta?

TranslatePress identifierar JS-injicerade strängar, så ljudspelarmärken syns i redigeraren och kan maskinöversättas. Åtgärda det genom att lägga till data-no-translation på spelarbehållaren, eller undanta spelarbehållaren i Avancerade inställningar med en CSS-väljare. Spelarmärkena hämtas då från TTSWP:s egna språkfiler istället.

Varför slutade mitt ljud matcha översättningen?

Redigering av originalsträngen i TranslatePress skapar en ny källsträng och kopplar bort den befintliga översättningen. Översättningsminnet föreslår den gamla, men tills du bekräftar den faller målspråket tillbaka på källan. Generera om ljud på standardinlägget och varje språk efter innehållsredigering, och rensa sedan cachen för varje lokaliserad URL.

Hur skiljer sig TranslatePress från Weglot för TTS?

Weglot lagrar översättningar på sina egna servrar och injicerar dem på sidan, så WordPress ser aldrig den översatta texten på serversidan. TranslatePress lagrar alla översättningar i din lokala databas och exponerar trp_translate() för åtkomst på serversidan. Det gör språkspecifik ljudgenerering mer direkt på TranslatePress än på Weglot.

Nästa steg

Installera Text till tal - TTSWP från WordPress.org plugin-katalogen, anslut det till ditt konto och tilldela en röst per språk du redan kör i TranslatePress. Publicera ett inlägg, spela upp ljudet på varje översatt URL och kontrollera att ljudet matchar den synliga texten. Om något går fel är integrationsdokumentationen för TranslatePress det första stället att kolla.