Polylang vs. WPML vs. TranslatePress: Sammenligning i 2026

Du er ved at bygge et flersproget WordPress-websted. Du åbner Google, skriver "bedste WordPress oversættelses-plugin," og inden for ti minutter drukner du i affiliate-anmeldelser, sammenligningstabeller, der ser kopieret ud, og modstridende råd om Polylang, WPML og TranslatePress. Hver anmeldelse konkluderer bekvemt med "Plugin X er vinderen," og du har ingen måde at vide, hvilket der faktisk vil fungere for dit projekt.

Her er det ærlige svar: disse tre plugins løser det samme overfladiske problem - at vise dit websted på flere sprog - men de bruger fundamentalt forskellige tilgange. WPML gemmer oversættelser i duplikerede indlæg. Polylang gør det samme, men holder sin kerne gratis. TranslatePress oversætter gengivet HTML i realtid. Hver arkitektur har reelle afvejninger for ydeevne, SEO, indholds-workflow og langsigtet vedligeholdelse.

Denne sammenligning skærer igennem affiliate-støjen med de detaljer, der faktisk påvirker dit websted i 2026: priser gældende fra i år, hvordan hvert plugin påvirker dine Core Web Vitals, hvad der går i stykker, når du skifter plugins, og hvorfor et stigende antal teams springer alle tre over og oversætter .po-filer direkte.

Hvad disse plugins faktisk gør (De er ikke det samme)

Før du sammenligner funktioner, skal du forstå, at disse plugins bruger tre forskellige arkitekturer. Vælg den forkerte arkitektur, og ingen mængde af plugin-konfiguration vil redde dig.

WPML: Duplikat-indlæg model

WPML opretter en separat kopi af hvert indlæg, side, taksonomibegreb og menupunkt for hvert sprog. Din posts-tabel vokser lineært med antallet af sprog. Et websted med 500 indlæg og 5 sprog ender med 2.500 rækker i wp_posts, plus matchende postmeta, term relationships og revisioner.

Dette giver dig rene URL-strukturer (/es/producto/, /fr/produit/), fuld kompatibilitet med de fleste plugins og uafhængig redigering pr. sprog. Omkostningen er databasestørrelse og forespørgselskompleksitet - hver arkivforespørgsel skal filtrere efter sprog, og komplekse websteder begynder at sænke hastigheden omkring 10.000+ oversatte indlæg.

Polylang: Også Duplikat-indlæg (Med gratis kerne)

Polylang bruger den samme duplikat-indlægs-tilgang som WPML, men leveres med et gratis kerne-plugin og et betalt Pro-tilføjelsesprogram til avancerede funktioner som strengoversættelse til plugins og WooCommerce-understøttelse. Under motorhjelmen er arkitekturen næsten identisk med WPML - samme ydeevnekarakteristika, samme skaleringsadfærd.

TranslatePress: Front-end HTML omskrivning

TranslatePress bruger en helt anden tilgang. I stedet for at duplikere indlæg, oversætter det den gengivne HTML i farten. Du besøger dit websted på fransk, og TranslatePress opfanger outputtet, slår oversættelser op i sin egen tabel og erstatter strenge, før responsen sendes til browseren.

Dette betyder, at du ikke duplikerer indlæg. Men det betyder også, at hver enkelt sidegengivelse kører ekstra forespørgsler for at slå oversatte strenge op. For websteder med høj trafik skaber dette et ydelsesloft, som de andre plugins ikke har.

Pris- og licensoversigt (2026)

Prissætning er det nemmeste at faktatjekke og det sværeste sted for affiliate-anmeldelser at forblive ærlige. Her er 2026-tallene som offentliggjort på hver leverandørs websted.

Få ting som sammenligningstabellerne normalt skjuler:

• Automatisk oversættelse koster ekstra. WPML's Advanced Translation Editor bruger DeepL eller Google, målt pr. ord. Polylang integrerer med Lingotek eller DeepL, også målt. TranslatePress opkræver for "automatiske oversættelseskreditter" ud over licensen.
• WooCommerce-understøttelse er begrænset. Polylang kræver Business-tier for WooCommerce. WPML kræver Multilingual CMS-tier. TranslatePress Personal inkluderer ikke WooCommerce-strengoversættelse.
• Fornyelsespriser stiger. Nogle anmeldelser angiver rabatten for første år. Flerårige omkostninger er det, der betyder noget.

For en fuld oversigt over, hvordan disse omkostninger akkumuleres i forhold til freelancerpriser og skyoversættelse, se vores sammenligning af WordPress-oversættelsesomkostninger.

Ydeevne og indvirkning på webstedets hastighed

Dette er her, de arkitektoniske forskelle betyder mest. Core Web Vitals påvirker din SEO direkte, og oversættelses-plugins er en af de mest almindelige skjulte årsager til dårlige LCP- og INP-scores.

WPML og Polylang: Databasestørrelse

Begge plugins tilføjer joins til de fleste front-end forespørgsler. WP_Query skal filtrere efter sprog, hvilket betyder ekstra term_taxonomy- og term_relationships-joins på hver arkivside. På et lille websted vil du ikke mærke det. På et websted med 5.000+ indlæg fordelt på 5 sprog vil du se TTFB stige med 200-500ms uden aggressiv caching.

TranslatePress: Omskrivning pr. anmodning

TranslatePress udfører strengopslag på hver gengivet side. Selv med objektcaching introducerer plugin'et et loft for, hvor hurtigt dit websted kan reagere, fordi det skal opfange, parse, omskrive og genudsende HTML. Vi målte dette i detaljer i vores benchmark af statiske .mo-filer vs oversættelses-plugins - front-end omskrivning rangerede konsekvent som den langsomste tilgang på tværs af alle testscenarier.

Det sammensatte problem: Plugin-stakke

Du kører sjældent et oversættelses-plugin isoleret. Tilføj WooCommerce, en sidebygger, et SEO-plugin og et caching-lag, og hvert oversættelses-plugin har sine egne kompatibilitets-shims. WPML leverer adaptere til snesevis af plugins. Polylang er lidt lettere. TranslatePress har det mindste kompatibilitetsfodaftryk, men omskriver HTML, efter at alle andre plugins er færdige, hvilket kan fortryde caching-optimeringer fra resten af din stak.

Oversættelseskvalitet og workflow

Kvaliteten af automatisk oversættelse afhænger af, hvilken motor hvert plugin kalder, ikke selve plugin'et. WPML bruger DeepL, Google eller Microsoft. Polylang bruger DeepL, Google eller Lingotek. TranslatePress bruger DeepL eller Google.

Vigtigere er, hvordan oversættelsen leveres og lagres:

• WPML og Polylang gemmer oversættelser i deres egne tabeller og serverer dem fra PHP. Redigering kræver login, åbning af den avancerede editor og lagring pr. streng.
• TranslatePress bruger en visuel front-end editor. Du klikker på en streng på siden og redigerer inline. Ikke-tekniske brugere kan lide dette, men det skalerer ikke til hundredvis af sider.

Ingen af disse tre plugins beskytter pladsholdere eller kode-tokens som standard. Hvis du kører automatisk oversættelse på tværs af dine strenge, får du stadig den samme %s-korruption, HTML-tag-brud og flertalsformfejl, der plager rå AI-oversættelse. Vores guide om manuel vs. AI-oversættelse til WordPress går i dybden med sikkerheds-afvejningerne.

Det skjulte alternativ: Statiske .mo-filer (Ingen plugin)

Hvert WordPress-tema og plugin leveres med .pot-skabelonfiler. En korrekt oversat .po-fil, kompileret til .mo og placeret i wp-content/languages/, læses én gang pr. sideindlæsning af WordPress-kernen - med nul ekstra databaseforespørgsler, nul plugin-overhead og fuld CDN-kompatibilitet.

Det er sådan, WordPress-kernefællesskabet har lokaliseret WordPress selv til 70+ sprog i 20 år. Det er hurtigt, stabilt og binder dig ikke til nogen leverandørs økosystem.

Den eneste grund til, at de fleste webstedsejere bruger plugins i stedet, er, at oversættelse af .po-filer manuelt er kedeligt - du åbner Poedit, oversætter 2.000 strenge i hånden og håber, at du ikke har ødelagt en pladsholder. Skybaserede oversættelsesværktøjer fjerner den barriere fuldstændigt. Upload .po, download oversat .po + .mo, læg det i wp-content/languages/themes/your-theme-es_ES.mo, færdig.

Ingen plugin-licens. Ingen ydelsesstraf. Ingen leverandørbinding. Hvis temaet opdateres og tilføjer nye strenge, oversæt den nye .pot og genudgiv den opdaterede .mo-fil.

Denne tilgang fungerer smukt til indhold, der ligger i kode (tema-UI, plugin-strenge, fejlmeddelelser, knaptekster). For indhold, der ligger i databasen (indlæg, sider, produktbeskrivelser), har du stadig brug for et plugin eller et manuelt duplikat-indlægs-workflow. Mange teams kombinerer begge: statiske .mo-filer til UI, WPML eller Polylang til indhold. Resultatet er hurtigere, billigere og lettere at vedligeholde end at stole på et enkelt plugin alene.

Hvornår skal du vælge hvilken tilgang

Hurtig beslutningsguide baseret på projekttype:

• Lille blog, 2-3 sprog, mest UI-indhold: Statiske .mo-filer. Spring plugin'et over.
• Indholdstungt websted, redaktionelt team, mange indlæg: Polylang eller WPML. Vælg Polylang, hvis du har brug for et gratis udgangspunkt og senere Business-funktioner; vælg WPML, hvis du har brug for flersprogede custom post types og taksonomier i stor skala.
• Visuelt redigerings-workflow for ikke-tekniske brugere: TranslatePress, men accepter ydelses-afvejningen og undgå det på WooCommerce-butikker med høj trafik.
• WooCommerce-butik med stort katalog: WPML Multilingual CMS plus .mo-filer til tema-UI. Polylang Business fungerer også.
• Bureau, der administrerer 20+ klientwebsteder: Flyt så meget oversættelse som muligt til .mo-filer. Se vores ideelle lokaliserings-workflow for bureauer for den fulde arkitektur.

Sammenfatning

Polylang, WPML og TranslatePress er alle legitime værktøjer. Hver især har reelle brugere, der succesfuldt udgiver flersprogede websteder. Fejlen er at behandle dem som udskiftelige alternativer og vælge et ud fra en sammenligningstabel. De er fundamentalt forskellige arkitekturer med forskellige ydelseslofter og indholds-workflows.

Det dybere spørgsmål, de fleste webstedsejere aldrig stiller, er, om de overhovedet har brug for et oversættelses-plugin. En stor del af det, disse plugins oversætter - knaptekster, fejlmeddelelser, tema-UI, kasse-strenge - ligger i .po-filer, som WordPress-kernen kan læse indbygget. At oversætte disse filer én gang og placere den kompilerede .mo i wp-content/languages/ eliminerer en hel klasse af plugin-overhead, licensfornyelser og ydeevneproblemer.

Klar til at oversætte dine WordPress .po-filer uden at tilføje endnu et plugin til din stak? Prøv SimplePoTranslate gratis - intet kreditkort påkrævet. Upload .po, download oversat .po + .mo, implementer.