PolyLingo vs Polylang: hvad er forskellen, og hvornår skal man bruge hver

Hvis du er landet her, er du sandsynligvis i en af to situationer: du er tilfreds med Polylang inden for WordPress, men spekulerer på, om der findes noget tilsvarende til et projekt, der ikke er på WordPress, eller du migrerer helt væk fra WordPress og prøver at finde ud af, hvad der sker med din flersprogede opsætning.

Dette indlæg besvarer begge spørgsmål direkte. Vi vil dække, hvad hvert værktøj faktisk gør, hvor hvert passer ind, og hvordan man vælger mellem dem.

Hvad Polylang er (og hvad det ikke er)

Polylang er et WordPress-plugin. Det er et af de bedste flersprogede plugins i WordPress-økosystemet. Det håndterer sprogskiftere, lader dig oprette oversatte versioner af indlæg og sider, håndterer hreflang-tags og integreres pænt med WordPress blokeditor. Hvis du kører et WordPress-site, er det et seriøst, velvedligeholdt værktøj, og der er en god grund til, at det har millioner af aktive installationer.

Begrænsningen ligger lige i beskrivelsen: det er et WordPress-plugin. Det har ikke et API, du kan kalde uden for WordPress. Det har ikke begrebet en JSON locale-fil, en Markdown-indholdsfil eller en HTML-skabelon, der ligger i et Next.js-projekt. Hele dets model antager, at indholdet lever i WordPress-databasen og gengives af WordPress.

Det er ikke en kritik. Det er bare værktøjets omfang.

Hvad PolyLingo er

PolyLingo er et oversættelses-API. Du sender det indhold (ren tekst, Markdown, JSON eller HTML), og det returnerer oversatte versioner på alle de sprog, du beder om, i en enkelt anmodning. Det har ingen holdning til dit CMS, dit framework eller din deploymentsopsætning. Det virker, hvor du kan lave en HTTP-anmodning.

Kernedesignmålet er formatbevarelse. De fleste oversættelses-API'er er bygget omkring sætninger: du sender en streng, du får en streng tilbage. Den model bryder hurtigt sammen, når dit indhold har struktur. Indsæt en JSON locale-fil i en typisk oversættelsestjeneste, og du får oversatte nøgle-navne, korrupte afgrænsere eller prosa, hvor der plejede at være et objekt. PolyLingo behandler struktur som off-limits. Kun strengværdier ændres; alt andet kommer tilbage præcis som det blev sendt.

Et konkret eksempel. Du sender dette:

{"btn": {"save": "Save", "cancel": "Cancel"}}

En sætning-orienteret oversætter kunne give dig tilbage:

{"button": {"save": "Guardar", "cancel": "Cancelar"}}

Nøglen btn blev til button. Det vil bryde din applikation. PolyLingo giver dig:

{"btn": {"save": "Guardar", "cancel": "Cancelar"}}

Nøgler uberørte. Kun værdierne oversat.

Samme princip gælder for Markdown (overskrifter forbliver overskrifter, kodeblokke efterlades ordret, link-URL'er ændres ikke) og HTML (tags og attributter bevares, kun tekstnoder og passende attributter oversættes).

Den faktiske forskel: omfang

Den nemmeste måde at sige det på:

Polylang håndterer flersproget indhold inden for WordPress. Det er et CMS-lag. Det håndterer, hvilket indlæg der er den spanske version af hvilket engelske indlæg, det genererer sprogskiftere, og det holder oversættelser synkroniserede, når du opdaterer indhold.

PolyLingo oversætter struktureret indhold via et API. Det er et oversættelseslag. Du fodrer det med indhold, det returnerer oversættelser. Hvad du gør med de oversættelser, er op til dig.

De løser tilstødende problemer, ikke det samme problem. Derfor er sammenligningen ikke rigtig "hvilken er bedre", men "hvilket problem har jeg."

Hvornår skal man bruge Polylang

Dit site kører på WordPress, og du vil blive på WordPress
Du har brug for en content management workflow: redaktører, der skifter mellem sprogversioner, sporing af oversættelsesstatus, sprogskiftere i temaet
Du er ikke udvikler og ønsker en UI-drevet løsning
Du bruger WooCommerce og har brug for produktoversættelse håndteret inden for WordPress

Polylang er fremragende til alt dette. Hvis WordPress er din stack, er det det rigtige værktøj.

Hvornår skal man bruge PolyLingo

Du bygger på Next.js, Nuxt, SvelteKit, Astro eller et andet ikke-WordPress framework
Du bruger et headless CMS (Contentful, Sanity, Prismic) og har brug for at oversætte indhold ved udgivelsestidspunktet eller via en webhook
Dit indhold lever i JSON locale-filer, der skal oversættes uden at ødelægge nøglestrukturen
Du migrerer væk fra WordPress og vil tage din flersprogede workflow med dig
Du har Markdown-indhold (blogindlæg, dokumentation, produktbeskrivelser) og har brug for oversatte versioner, der ikke ødelægger formateringen
Du vil oversætte til flere sprog i et enkelt API-kald i stedet for at lave et kald pr. sprog

PolyLingos /translate endpoint accepterer et targets array, så en enkelt anmodning kan returnere alle 36 understøttede sprog på én gang. For en locale-fil, der skal leveres på ti sprog, er det ét API-kald i stedet for ti.

Hvad med migrering fra WordPress?

Hvis du flytter et WordPress-site til en headless eller statisk opsætning, følger dit Polylang-indhold ikke automatisk med. Oversættelserne gemmes som WordPress post metadata og eksporteres ikke rent til Markdown-filer eller JSON-strukturer.

Den praktiske vej, som de fleste teams tager:

Eksporter dit WordPress-indhold til Markdown eller JSON (værktøjer som wordpress-export-to-markdown håndterer den mekaniske del)
Brug PolyLingo til at oversætte det eksporterede indhold til dine målsprog
Gem de resulterende filer i din nye indholdsstruktur ved siden af kildesproget

PolyLingos batch endpoint (POST /translate/batch) er bygget til netop dette. Du kan sende op til 100 indholdselementer i en enkelt anmodning, hver med sit eget format, alle med samme sæt af målsprog. For en site-migrering med hundredvis af sider er det det rigtige værktøj til jobbet.

Side-om-side oversigt

	PolyLingo	Polylang
Virker uden WordPress	Ja	Nej
Formatbevarelse (JSON, Markdown, HTML)	Ja	Kun WordPress-indhold
Én anmodning, alle sprog	Ja	Nej
REST API adgang	Ja	Nej
Content management UI	Oversætter UI (ingen kode)	Fuld WordPress admin
Automatisk detektering af indholdsformat	Ja	Ikke relevant
RTL sprogunderstøttelse	Ja	Ja
Brug-baseret fakturering	Ja	Gratis plugin / Polylang Pro fast pris

Den korte version

Hvis du er på WordPress og bliver på WordPress: brug Polylang. Det er bygget til det miljø og er godt til det.

Hvis du er uden for WordPress, forlader WordPress, eller bygger noget, der ikke er WordPress: PolyLingo giver dig den samme strukturerede flersprogede workflow via et API, der virker med hvad som helst, du bygger med.

De to værktøjer kan også sameksistere. Nogle teams kører Polylang på deres hovedmarkedsføringssite (som bliver på WordPress) og bruger PolyLingo til deres dokumentationssite, deres webapp UI-strenge eller deres e-mail-skabeloner. Workflowet er det samme; stacken behøver ikke være det.

Prøv det

PolyLingos gratis niveau inkluderer 100.000 tokens pr. måned. Det er nok til flere blogindlæg på ti sprog eller en mellemstor locale-fil på 36 sprog. Intet kreditkort kræves.

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "# Welcome\n\nTranslate **any format** without breaking the structure.",
    "format": "markdown",
    "targets": ["es", "fr", "de", "ja"]
  }'

Start med at oversætte gratis

PolyLingo vs Polylang: hvad er forskellen, og hvornår skal man bruge hver af dem