PolyLingo vs Polylang: hva er forskjellen og når du skal bruke hver

Hvis du har kommet hit, er du sannsynligvis i en av to situasjoner: du er fornøyd med Polylang i WordPress, men lurer på om det finnes noe tilsvarende for et prosjekt som ikke er på WordPress, eller du migrerer helt bort fra WordPress og prøver å finne ut hva som skjer med din flerspråklige oppsett.

Dette innlegget svarer på begge spørsmål direkte. Vi vil dekke hva hvert verktøy faktisk gjør, hvor hvert passer, og hvordan du velger mellom dem.

Hva Polylang er (og hva det ikke er)

Polylang er en WordPress-plugin. Det er en av de beste flerspråklige pluginene i WordPress-økosystemet. Den håndterer språkvelgere, lar deg lage oversatte versjoner av innlegg og sider, håndterer hreflang-tagger, og integreres pent med WordPress blokkredigerer. Hvis du kjører et WordPress-nettsted, er det et seriøst, godt vedlikeholdt verktøy, og det er en god grunn til at det har millioner av aktive installasjoner.

Begrensningen ligger i beskrivelsen: det er en WordPress-plugin. Den har ingen API du kan kalle fra utenfor WordPress. Den har ikke konseptet med en JSON locale-fil, en Markdown-innholdsfil eller en HTML-mal som ligger i et Next.js-prosjekt. Hele modellen antar at innholdet ligger i WordPress-databasen og rendres av WordPress.

Dette er ikke en kritikk. Det er bare verktøyets omfang.

Hva PolyLingo er

PolyLingo er en oversettelses-API. Du sender innhold til den (ren tekst, Markdown, JSON eller HTML), og den returnerer oversatte versjoner på alle språk du ber om, i én enkelt forespørsel. Den har ingen mening om ditt CMS, ditt rammeverk eller din distribusjonsoppsett. Den fungerer hvor som helst du kan gjøre en HTTP-forespørsel.

Kjernen i designmålet er formatbevaring. De fleste oversettelses-API-er er bygget rundt setninger: du sender en streng, du får en streng tilbake. Den modellen bryter raskt sammen når innholdet ditt har struktur. Lim inn en JSON locale-fil i en typisk oversettelsestjeneste, og du får oversatte nøkkelnavn, korrupte skilletegn eller prosa der det tidligere var et objekt. PolyLingo behandler struktur som utenfor grensene. Bare strengverdier endres; alt annet kommer tilbake nøyaktig som det ble sendt.

Et konkret eksempel. Du sender dette:

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

En setningsorientert oversetter kan gi deg tilbake:

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

Nøkkelen btn ble til button. Det vil ødelegge applikasjonen din. PolyLingo gir deg:

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

Nøkler uberørt. Bare verdiene oversatt.

Samme prinsipp gjelder for Markdown (overskrifter forblir overskrifter, kodeblokker forblir uendret, lenke-URL-er endres ikke) og HTML (tagger og attributter bevares, bare tekstnoder og passende attributter oversettes).

Den faktiske forskjellen: omfang

Den enkleste måten å si det på:

Polylang håndterer flerspråklig innhold inne i WordPress. Det er et CMS-lag. Det håndterer hvilket innlegg som er den spanske versjonen av hvilket engelske innlegg, genererer språkvelgere, og holder oversettelser synkronisert når du oppdaterer innhold.

PolyLingo oversetter strukturert innhold over en API. Det er et oversettelseslag. Du gir det innhold, det returnerer oversettelser. Hva du gjør med disse oversettelsene er opp til deg.

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

Når du skal bruke Polylang

Nettstedet ditt kjører på WordPress og du vil bli på WordPress
Du trenger en innholdsadministrasjonsflyt: redaktører som bytter mellom språkversjoner, sporing av oversettelsesstatus, språkvelgere i temaet
Du er ikke utvikler og ønsker en UI-drevet løsning
Du bruker WooCommerce og trenger produktoversettelse håndtert inne i WordPress

Polylang er utmerket på alt dette. Hvis WordPress er din stack, er det det riktige verktøyet.

Når du skal bruke PolyLingo

Du bygger på Next.js, Nuxt, SvelteKit, Astro eller et annet ikke-WordPress-rammeverk
Du bruker et headless CMS (Contentful, Sanity, Prismic) og trenger å oversette innhold ved publisering eller via en webhook
Innholdet ditt ligger i JSON locale-filer som må oversettes uten å ødelegge nøkkelstrukturen
Du migrerer bort fra WordPress og vil ta med deg din flerspråklige arbeidsflyt
Du har Markdown-innhold (blogginnlegg, dokumentasjon, produktbeskrivelser) og trenger oversatte versjoner som ikke ødelegger formateringen
Du vil oversette til flere språk i én enkelt API-kall i stedet for ett kall per språk

PolyLingos /translate endepunkt aksepterer en targets-array, så én forespørsel kan returnere alle 36 støttede språk på en gang. For en locale-fil som må leveres på ti språk, er det ett API-kall i stedet for ti.

Hva med migrering fra WordPress?

Hvis du flytter et WordPress-nettsted til en headless eller statisk oppsett, følger ikke Polylang-innholdet ditt automatisk med. Oversettelsene lagres som WordPress post metadata og eksporteres ikke rent til Markdown-filer eller JSON-strukturer.

Den praktiske veien de fleste team tar:

Eksporter WordPress-innholdet ditt til Markdown eller JSON (verktøy som wordpress-export-to-markdown håndterer den mekaniske delen)
Bruk PolyLingo til å oversette det eksporterte innholdet til målspråkene dine
Lagre de resulterende filene i din nye innholdsstruktur sammen med kildespråket

PolyLingos batch-endepunkt (POST /translate/batch) er laget for akkurat dette. Du kan sende opptil 100 innholdsobjekter i én forespørsel, hver med sitt eget format, alle med samme sett av målspråk. For en nettstedsmigrasjon med hundrevis av sider er det det riktige verktøyet for jobben.

Side-ved-side oppsummering

	PolyLingo	Polylang
Fungerer uten WordPress	Ja	Nei
Formatbevaring (JSON, Markdown, HTML)	Ja	Kun WordPress-innhold
Én forespørsel, alle språk	Ja	Nei
REST API-tilgang	Ja	Nei
Innholdsadministrasjons-UI	Oversetter-UI (ingen kode)	Full WordPress admin
Automatisk gjenkjenning av innholdsformat	Ja	Ikke aktuelt
RTL språkstøtte	Ja	Ja
Bruksbasert fakturering	Ja	Gratis plugin / Polylang Pro fast pris

Den korte versjonen

Hvis du er på WordPress og blir på WordPress: bruk Polylang. Det er bygget for det miljøet og det er bra på det.

Hvis du er utenfor WordPress, går bort fra WordPress, eller bygger noe som ikke er WordPress: PolyLingo gir deg samme strukturerte flerspråklige arbeidsflyt gjennom en API som fungerer med hva enn du bygger med.

De to verktøyene kan også eksistere side om side. Noen team kjører Polylang på deres hovedmarkedsføringsside (som forblir på WordPress) og bruker PolyLingo for deres dokumentasjonsnettsted, deres webapp UI-strenger eller deres e-postmaler. Arbeidsflyten er den samme; stakken trenger ikke å være det.

Prøv det

PolyLingos gratisnivå inkluderer 100 000 tokens per måned. Det er nok for flere blogginnlegg på ti språk, eller en middels stor locale-fil på 36 språk. Ingen kredittkort kreves.

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 å oversette gratis

PolyLingo vs Polylang: hva er forskjellen og når bør man bruke hver av dem