PolyLingo vs Polylang: vad är skillnaden och när ska man använda varje

Om du har hamnat här är du förmodligen i en av två situationer: du är nöjd med Polylang i WordPress men undrar om det finns något motsvarande för ett projekt som inte är på WordPress, eller så migrerar du helt bort från WordPress och försöker lista ut vad som händer med din flerspråkiga setup.

Det här inlägget svarar direkt på båda frågorna. Vi går igenom vad varje verktyg faktiskt gör, var varje passar in och hur man väljer mellan dem.

Vad Polylang är (och vad det inte är)

Polylang är ett WordPress-plugin. Det är ett av de bästa flerspråkiga pluginen i WordPress-ekosystemet. Det hanterar språkväxlare, låter dig skapa översatta versioner av inlägg och sidor, hanterar hreflang-taggar och integreras snyggt med WordPress blockredigerare. Om du driver en WordPress-sajt är det ett seriöst, väl underhållet verktyg och det finns en god anledning till att det har miljontals aktiva installationer.

Begränsningen finns i beskrivningen: det är ett WordPress-plugin. Det har inget API som du kan anropa utanför WordPress. Det har inget koncept av en JSON-lokalfil, en Markdown-innehållsfil eller en HTML-mall i ett Next.js-projekt. Hela dess modell antar att innehållet finns i WordPress-databasen och renderas av WordPress.

Det är inte en kritik. Det är bara verktygets omfattning.

Vad PolyLingo är

PolyLingo är ett översättnings-API. Du skickar innehåll (ren text, Markdown, JSON eller HTML) och det returnerar översatta versioner på alla språk du ber om, i en enda förfrågan. Det har ingen åsikt om ditt CMS, ditt ramverk eller din distributionssetup. Det fungerar var som helst där du kan göra en HTTP-förfrågan.

Kärndesignmålet är formatbevarande. De flesta översättnings-API:er är byggda kring meningar: du skickar en sträng, du får en sträng tillbaka. Den modellen fallerar snabbt när ditt innehåll har struktur. Klistra in en JSON-lokalfil i en typisk översättningstjänst och du får översatta nyckelnamn, korrupta avgränsare eller prosa där ett objekt brukade vara. PolyLingo behandlar struktur som otillgänglig. Endast strängvärden ändras; allt annat kommer tillbaka exakt som det skickades.

Ett konkret exempel. Du skickar detta:

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

En mening-orienterad översättare kan ge dig tillbaka:

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

Nyckeln btn blev button. Det kommer att bryta din applikation. PolyLingo ger dig:

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

Nycklar orörda. Endast värdena översatta.

Samma princip gäller för Markdown (rubriker förblir rubriker, kodblock lämnas verbatim, länk-URL:er ändras inte) och HTML (taggar och attribut bevaras, endast textnoder och lämpliga attribut översätts).

Den faktiska skillnaden: omfattning

Det enklaste sättet att säga det:

Polylang hanterar flerspråkigt innehåll inom WordPress. Det är ett CMS-lager. Det hanterar vilken post som är den spanska versionen av vilken engelsk post, genererar språkväxlare och håller översättningar synkroniserade när du uppdaterar innehåll.

PolyLingo översätter strukturerat innehåll via ett API. Det är ett översättningslager. Du matar in innehåll, det returnerar översättningar. Vad du gör med dessa översättningar är upp till dig.

De löser närliggande problem, inte samma problem. Därför är jämförelsen inte riktigt "vilket är bättre" utan "vilket problem har jag."

När man ska använda Polylang

Din sajt körs på WordPress och du vill stanna på WordPress
Du behöver ett innehållshanteringsflöde: redaktörer som växlar mellan språkversioner, spårning av översättningsstatus, språkväxlare i temat
Du är inte utvecklare och vill ha en UI-driven lösning
Du använder WooCommerce och behöver produktöversättning hanterad inom WordPress

Polylang är utmärkt på allt detta. Om WordPress är din stack är det rätt verktyg.

När man ska använda PolyLingo

Du bygger på Next.js, Nuxt, SvelteKit, Astro eller något annat icke-WordPress-ramverk
Du använder ett headless CMS (Contentful, Sanity, Prismic) och behöver översätta innehåll vid publicering eller via en webhook
Ditt innehåll finns i JSON-lokaliseringsfiler som behöver översättas utan att förstöra nyckelstrukturen
Du migrerar bort från WordPress och vill ta med ditt flerspråkiga arbetsflöde
Du har Markdown-innehåll (blogginlägg, dokumentation, produktbeskrivningar) och behöver översatta versioner som inte bryter formateringen
Du vill översätta till flera språk i ett enda API-anrop istället för att göra ett anrop per språk

PolyLingos /translate-endpoint accepterar en targets-array, så en förfrågan kan returnera alla 36 stödda språk på en gång. För en lokalfil som behöver levereras på tio språk är det ett API-anrop istället för tio.

Vad händer vid migrering från WordPress?

Om du flyttar en WordPress-sajt till en headless eller statisk setup följer inte ditt Polylang-innehåll automatiskt med. Översättningarna lagras som WordPress-postmetadata och exporteras inte rent till Markdown-filer eller JSON-strukturer.

Den praktiska vägen som de flesta team tar:

Exportera ditt WordPress-innehåll till Markdown eller JSON (verktyg som wordpress-export-to-markdown hanterar den mekaniska delen)
Använd PolyLingo för att översätta det exporterade innehållet till dina målspråk
Spara de resulterande filerna i din nya innehållsstruktur tillsammans med källspråket

PolyLingos batch-endpoint (POST /translate/batch) är byggd för just detta. Du kan skicka upp till 100 innehållsobjekt i en enda förfrågan, var och en med sitt eget format, alla med samma uppsättning målspråk. För en sajt-migrering med hundratals sidor är det rätt verktyg för jobbet.

Sammanfattning sida vid sida

	PolyLingo	Polylang
Fungerar utan WordPress	Ja	Nej
Formatbevarande (JSON, Markdown, HTML)	Ja	Endast WordPress-innehåll
En förfrågan, alla språk	Ja	Nej
REST API-åtkomst	Ja	Nej
UI för innehållshantering	Översättar-UI (ingen kod)	Full WordPress-admin
Autoidentifierar innehållsformat	Ja	N/A
Stöd för RTL-språk	Ja	Ja
Betalning baserad på användning	Ja	Gratisplugin / Polylang Pro fast avgift

Den korta versionen

Om du är på WordPress och stannar på WordPress: använd Polylang. Det är byggt för den miljön och är bra på det.

Om du är utanför WordPress, lämnar WordPress eller bygger något som inte är WordPress: PolyLingo ger dig samma strukturerade flerspråkiga arbetsflöde via ett API som fungerar med vad du än bygger med.

De två verktygen kan också samexistera. Vissa team kör Polylang på sin huvudsakliga marknadsföringssajt (som stannar på WordPress) och använder PolyLingo för sin dokumentationssajt, sina webbapp-UI-strängar eller sina e-postmallar. Arbetsflödet är detsamma; stacken behöver inte vara det.

Prova det

PolyLingos gratisnivå inkluderar 100 000 tokens per månad. Det räcker för flera blogginlägg på tio språk, eller en medelstor lokalfil på 36 språk. Ingen kreditkort krävs.

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"]
  }'

Börja översätta gratis

PolyLingo vs Polylang: vad är skillnaden och när ska man använda vilken