Tekst til tale med TranslatePress: Hvad der virker

11 min læsning 20 min lytning
Tekst til tale med TranslatePress: Hvad der virker

TranslatePress oversætter den renderede HTML på en side ved forespørgselstidspunktet og gemmer alle oversættelser i lokale databasetabeller. Der er ét post-ID per artikel, og sprogskift sker via trp_translate(), ikke via dublerede indlæg. Det ene faktum ændrer, hvordan tekst til tale skal fungere på en TranslatePress-side.

Dette er det femte og sidste indlæg i vores serie om flersproget TTS. Vi har allerede gennemgået WPML, Polylang, Weglot og GTranslate. TranslatePress befinder sig teknisk set midt imellem dem, og lydopsætningen afspejler det.

Sådan adskiller TranslatePress sig fra WPML, Polylang og Weglot

WPML og Polylang opretter et separat indlæg for hvert sprog. Hver oversættelse har sit eget post-ID, sit eget post_content og sit eget permalink. Lydgenerering er ligetil, fordi hvert sprog er et selvstændigt WordPress-objekt.

Weglot tager den modsatte tilgang. Oversættelser lever på Weglots servere og injiceres på siden via en proxy eller et subdomæne. Den originale WordPress-database ser aldrig den oversatte tekst, og det er grunden til, at server-side TTS på Weglot er svært uden JavaScript-hooks.

TranslatePress er midtervejen. Der er ét indlæg per artikel, så post_content indeholder kun standardsproget. Men alle oversættelser gemmes lokalt i din WordPress-database i wp_trp_-tabellerne. Du kan læse dem, forespørge dem og sende dem til en TTS-motor. Det ændrer lydtilgangen sammenlignet med de andre fire plugins.

Hvor oversættelserne faktisk gemmes

TranslatePress gemmer oversættelser i dedikerede tabeller med præfikset wp_trp_. Hvert sprogpar får sin egen ordbogstabel, navngivet som wp_trp_dictionary_<source>_<target>. Der er desuden wp_trp_original_strings til kildestrengene og gettext-tabeller til tema- og plugin-oversættelser.

Lagring er retningsbestemt. En tysk oversættelse af et engelsk site gemmes i ordbogen fra engelsk til tysk. At hente den kræver samme retning. Den offentlige funktion, du skal kende, er trp_translate(), som tager en streng med indhold og en sprogkode og returnerer den oversatte version.

if ( function_exists( 'trp_translate' ) ) {
    $translated = trp_translate( $post->post_content, 'de_DE' );
    // Brug $translated til TTS-motoren, ikke $post->post_content.
}

Til en TTS-integration er den funktion kilden til sandhed. Læser du post_content direkte, får du altid standardsproget, uanset hvilken URL besøgende er på. Se dokumentationen for TranslatePress-integrationen for at se, hvordan TTSWP håndterer dette på vores side.

Diagram over trp_translate(), der konverterer ét post_content til tre lokaliserede lydoutputs
Ét post-ID, ét post_content og mange oversatte lydoutputs via trp_translate().

Fælden med lokale koder

TranslatePress bruger fulde lokale koder, ikke slugs. Tysk er de_DE, ikke de. Fransk er fr_FR. Brasiliansk portugisisk er pt_BR. Enhver integration, der antager Polylang-style totegnskoder, fejler lydløst på TranslatePress.

TranslatePress' udviklerdokumentation er klar på dette punkt. Den sprogkode, der sendes til trp_translate(), er den lokale kode fra Indstillinger, TranslatePress, Generelt, og den er ikke nødvendigvis den samme som sprogsluget i URL'en. Et bare slug som de matcher ingen ordbog, så funktionen falder tilbage til den originale streng uden advarsel. Skriver du brugerdefineret kode, skal du normalisere dine sprogkoder, inden du kalder trp_translate(), og gemme samme lokale format sammen med dine lydfiler, så du kan matche dem bagefter.

URL-struktur og caching

TranslatePress bruger som standard en undermappe per sprog. Din engelske side ligger på site.com/blog/post og den tyske version på site.com/de/blog/post. Der er også en mulighed for at bruge en undermappe til standardsproget, så alle sprog behandles symmetrisk.

Det er den gode situation for caching. Forskellige URL'er giver forskellige cachenøgler per sprog. WP Rocket, LiteSpeed og CDN-edge-caches behandler alle /de/blog/post som en separat ressource fra /blog/post, så din tyske lydfil serveres med den tyske side og din engelske lyd med den engelske side. Vores caching-dokumentation dækker eksklusionsreglerne, hvis du har brug for dem.

Den eneste risiko er det betalte tilvalg Automatic User Language Detection. Det omdirigerer besøgende baseret på browsersprog, hvilket kan kollidere med sidecaches og sende den forkerte omdirigering til den forkerte bruger. Vi gennemgik det samme mønster i Polylang-indlægget. Færre TranslatePress-sider bruger sprogdetektering, fordi det er et betalt tilvalg, men bruger du det, skal du ekskludere omdirigeringslogikken fra cachen.

Problemet med oversættelse af afspillerens brugergrænseflade

Dette er unikt for TranslatePress. Pluginnet registrerer og oversætter strenge indsat af JavaScript, hvilket er usædvanligt. De fleste oversættelsesværktøjer ignorerer JS-renderet indhold. TranslatePress fanger det i DOM'en efter rendering og tilbyder at oversætte det.

Bivirkningen er, at lydafspillerens labels som «Afspil», «Pause» og «Lyt til denne artikel» dukker op i TranslatePress-editoren som oversættelige strenge. Hvis de strenge maskinoversættes uden gennemgang, kan afspilleren ende med akavet eller forkert knaptekst, og endnu værre, fejloversatte tilgængelighedslabels, der forvirrer skærmlæsere.

Der er to løsninger i TranslatePress. Tilføj attributten data-no-translation til et element, du vil ekskludere. Eller brug eksklusionsselectorerne under Avancerede indstillinger til at springe hele containere over med en CSS-selektor. Begge er dokumenteret i TranslatePress' egne indstillinger. For TTSWP-afspilleren specifikt skal du ekskludere afspiller-wrapperens klasse og lade vores oversatte afspillerlabels komme via pluginnets egne sprogfiler.

Hvad du skal ekskludere

  • Lydafspillerens containerelement
  • ARIA-labels på afspil-, pause- og fremdriftskontroller
  • Tidsvisninger og vartighedstællere
  • Eventuelle stemme- eller sprognavn-labels renderet af TTSWP

Vil du ændre afspillerens udseende efter ekskludering, dækker vores dokumentation om brugerdefineret CSS selectorerne.

Problemet med desynkronisering ved indholdsopdatering

TranslatePress knytter hver oversættelse til den præcise kildestreng. Redigerer du originalen, opretter TranslatePress en ny kildestreng og frakobler den eksisterende oversættelse. Translation Memory foreslår den gamle oversættelse tilbage, men indtil en person bekræfter det, falder målsproget tilbage til kilden.

For tekst til tale betyder det, at lyd kan komme ud af sync med oversat tekst efter en redigering. Et komma tilføjet på engelsk frakobler oversættelsen for den pågældende streng i alle sprog. Din tyske lyd siger stadig den gamle sætning, mens den synlige tyske tekst nu viser den nye.

Praktisk tjekliste efter redigering af indhold:

  1. Bekræft den nye kildestreng i TranslatePress-editoren for hvert aktivt sprog.
  2. Generer lyd på standardsprogindlægget først.
  3. Generer lyd for hvert sprog, og afspil lyden på hver lokaliseret URL for at bekræfte, at den nye fil matcher den synlige tekst.
  4. Ryd din sidecache for alle lokaliserede URL'er, ikke kun standardsproget.

Opsætning af TTSWP på en TranslatePress-side

Her er det nuværende flow. Integrationsdokumentationen beskriver altid den seneste adfærd.

  1. Installér TTSWP fra WordPress.org's plugin-katalog. Installationsvejledningen guider dig igennem det.
  2. Forbind pluginnet til TTSWP-backend. Gratis planer inkluderer velkomstcredits, så du kan afprøve det fulde flow, inden du betaler. Se tilslut dit site.
  3. Bekræft, at TranslatePress er aktivt, og at mindst ét målsprog er konfigureret med en fuld lokal kode.
  4. Tildel en stemme per sprog via sprog-til-stemme-mapping. Tilknyt en tysk stemme til de_DE, en fransk stemme til fr_FR og så videre. Se stemmevalg for stemmekataloget.
  5. Udgiv eller opdater et indlæg. Lyd genereres for standardsproget først.
  6. Afspil lyden på hver oversat URL. Generering sker on demand. Første gang en besøgende afspiller lyd på et sekundært sprog, fortæller TranslatePress TTSWP, hvilket sprog der er aktivt, og TTSWP genererer og cacher filen for det pågældende sprog. Alle efterfølgende afspilninger bruger den cachede fil.
  7. Ekskludér afspilleren fra TranslatePress med data-no-translation eller en selektor under Avancerede indstillinger, så afspillerens labels styres af TTSWP's egne oversættelser.

TTSWP gemmer én lydfil per indlæg og sprog, og afspilleren følger sproget på den URL, den besøgende er på. På /de/blog/post indlæser afspilleren den tyske fil, og på standard-URL'en indlæser den filen på standardsproget. Med automatisk oversættelse aktiv læser TTSWP den oversatte tekst direkte fra TranslatePress, inden den sendes til ElevenLabs, så lyden matcher det, den besøgende ser på siden.

Gratis vs. betalt TranslatePress til TTS

Gratis TranslatePress understøtter ét ekstra sprog, inkluderer 2.000 AI-oversatte ord via TranslatePress AI og lader dig bruge Google Translate med din egen API-nøgle. Det er nok til at drive en tosproget blog med matchende lyd på to sprog.

Betalt TranslatePress tilføjer ubegrænsede ekstra sprog, SEO Pack med oversatte slugs, meta og hreflang-kontrol, DeepL-understøttelse, oversætterkonti, tilvalget Automatic User Language Detection og mulighed for forskelligt domæne per sprog. Har du brug for mere end to sprog, hreflang-tags til søgemaskiner eller DeepL-kvalitetsoversættelser inden TTS-generering, er den betalte version det praktiske valg. Lydkvaliteten afhænger ikke af, hvilken plan du er på.

SEO og AEO med lyd per sprog

SEO Pack lader dig konfigurere hreflang-tags per sprog med muligheder for landsspecifik lokal kode, regionsuafhængigt sprog eller begge dele. For søgemaskiner og AI-besvarelsesmotorer er det det, der signalerer, hvilken lyd der matcher hvilken region.

Tilknyt en AudioObject-schemapost per sprog-URL med den korrekte inLanguage-værdi, der matcher hreflang-koden. Google og Bing registrerer sprogparringen, og i vores egne tests citerer AI-motorer som Perplexity og ChatGPT Search artikler med lydforbedringer oftere, når skemaet er rent og lyd-URL'en kan løses. Vi har skrevet mere om dette i indlægget om AEO og lyd.

Almindelige problemer og løsninger

ProblemÅrsagLøsning
Lyd afspilles på det forkerte sprogTekst hentes fra post_content i stedet for trp_translate()Send tekst gennem trp_translate( $content, $locale ) med den fulde lokale kode
Afspillerknapper maskinoversatTranslatePress fangede de JS-renderede afspillerlabelsTilføj data-no-translation til afspiller-wrapperen, eller ekskludér den med en selektor under Avancerede indstillinger
Lyd mangler efter indholdsopdateringRedigering af kilden frakobler oversættelser og dermed lyd per sprogBekræft oversættelser i TranslatePress-editoren, og generer derefter lyd per sprog
Lokal kode matcher ikkeIntegrationen sender de i stedet for de_DENormaliser til fuld lokal kode inden kald af trp_translate()
RTL-layout brudt for arabisk eller hebraiskAfspiller-CSS er ikke RTL-kompatibelBrug brugerdefineret CSS til at spejlvende afspillerkontrollerne for RTL-sprog
Cache sender besøgende til det forkerte sprogTilvalget Automatic User Language Detection i konflikt med sidecachenEkskludér omdirigeringen fra cachen, eller slå sprogdetektering fra

Om tilgængelighed

Lydfortælling understøtter flere WCAG-succeskriterieer, når afspilleren kan betjenes med tastatur og er korrekt mærket. Ekskluderer du afspilleren fra TranslatePress, skal du beholde ARIA-labels intakte i TTSWP's egne oversættelser. Vores WCAG-lydguide gennemgår kriterierne i detaljer, og den overordnede opsætningsvejledning er et godt udgangspunkt.

Ofte stillede spørgsmål

Virker TranslatePress med tekst til tale?

Ja. TranslatePress gemmer oversættelser lokalt i wp_trp_-databasetabeller, og funktionen trp_translate() returnerer oversat indhold på server-siden. En TTS-integration kan læse den oversatte tekst og generere lyd per sprog, så længe den nøgler lyd på post-ID plus lokal kode og bruger fulde lokale koder som de_DE i stedet for slugs.

Skal jeg have den betalte version af TranslatePress for at få lyd?

Nej. Gratis TranslatePress understøtter ét ekstra sprog og inkluderer oversættelse via TranslatePress AI, Google Translate med din egen nøgle eller manuel redigering. Det er tilstrækkeligt til et tosproget site med matchende lyd. Betalt versionen tilføjer ubegrænsede sprog, SEO Pack, DeepL og detekterings-tilvalg, som er nyttige, hvis du har brug for mere end to sprog eller hreflang-kontrol.

Hvorfor er mine afspillerknapper oversat forkert?

TranslatePress registrerer JS-indsatte strenge, så lydafspillerens labels dukker op i editoren og kan maskinoversættes. Løs det ved at tilføje data-no-translation til afspiller-wrapperen, eller ekskludér afspillerbeholderen under Avancerede indstillinger med en CSS-selektor. Afspillerens labels hentes derefter fra TTSWP's egne sprogfiler.

Hvorfor stemmer min lyd ikke længere overens med oversættelsen?

Redigering af den originale streng i TranslatePress opretter en ny kildestreng og frakobler den eksisterende oversættelse. Translation Memory foreslår den tilbage, men indtil du bekræfter den, falder målsproget tilbage til kilden. Generer lyd på standardindlægget og hvert sprog efter enhver indholdsopdatering, og ryd derefter cachen for alle lokaliserede URL'er.

Hvad er forskellen på TranslatePress og Weglot til TTS?

Weglot gemmer oversættelser på sine egne servere og injicerer dem på siden, så WordPress aldrig ser den oversatte tekst på server-siden. TranslatePress gemmer alle oversættelser i din lokale database og giver adgang til trp_translate() på server-siden. Det gør lydgenerering per sprog mere direkte på TranslatePress end på Weglot.

Hvad gør du nu

Installér Tekst til tale - TTSWP fra WordPress.org's plugin-katalog, forbind det til din konto, og tildel én stemme per sprog, du allerede bruger i TranslatePress. Udgiv et indlæg, afspil lyden på hver oversat URL, og bekræft, at lyden matcher den synlige tekst. Opstår der problemer, er dokumentationen for TranslatePress-integrationen det første sted at kigge.