PolyLingo vs Polylang: wat is het verschil en wanneer gebruik je welke

Als je hier bent beland, zit je waarschijnlijk in een van twee situaties: je bent tevreden met Polylang binnen WordPress maar vraagt je af of er iets vergelijkbaars is voor een project dat niet op WordPress draait, of je migreert helemaal weg van WordPress en probeert te begrijpen wat er gebeurt met je meertalige setup.

Deze post beantwoordt beide vragen direct. We behandelen wat elk hulpmiddel eigenlijk doet, waar elk past, en hoe je tussen hen kiest.

Wat Polylang is (en wat het niet is)

Polylang is een WordPress-plugin. Het is een van de beste meertalige plugins in het WordPress-ecosysteem. Het beheert taalwisselaars, laat je vertaalde versies van berichten en pagina's maken, behandelt hreflang-tags en integreert netjes met de WordPress blokeditor. Als je een WordPress-site runt, is het een serieus, goed onderhouden hulpmiddel en er is een goede reden dat het miljoenen actieve installaties heeft.

De beperking zit al in de beschrijving: het is een WordPress-plugin. Het heeft geen API die je van buiten WordPress kunt aanroepen. Het kent geen JSON locale-bestand, Markdown-inhoudsbestand of HTML-sjabloon in een Next.js-project. Het hele model gaat ervan uit dat inhoud in de WordPress-database leeft en door WordPress wordt gerenderd.

Dat is geen kritiek. Het is gewoon de scope van het hulpmiddel.

Wat PolyLingo is

PolyLingo is een vertaal-API. Je stuurt er inhoud naartoe (platte tekst, Markdown, JSON of HTML) en het geeft vertaalde versies terug in elke taal die je vraagt, in één verzoek. Het heeft geen mening over je CMS, je framework of je deployment setup. Het werkt overal waar je een HTTP-verzoek kunt doen.

Het kernontwerpdoel is behoud van formaat. De meeste vertaal-API's zijn gebouwd rond zinnen: je stuurt een string, je krijgt een string terug. Dat model faalt snel als je inhoud structuur heeft. Plak een JSON locale-bestand in een typische vertaaldienst en je krijgt vertaalde sleutelnamen, corrupte scheidingstekens of proza waar een object stond. PolyLingo behandelt structuur als verboden terrein. Alleen stringwaarden veranderen; alles anders komt precies terug zoals het werd verzonden.

Een concreet voorbeeld. Je stuurt dit:

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

Een zin-georiënteerde vertaler zou je terug kunnen geven:

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

De sleutel btn werd button. Dat breekt je applicatie. PolyLingo geeft je:

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

Sleutels onaangeroerd. Alleen de waarden vertaald.

Hetzelfde principe geldt voor Markdown (koppen blijven koppen, codeblokken blijven letterlijk, link-URL's veranderen niet) en HTML (tags en attributen blijven behouden, alleen tekstnodes en passende attributen worden vertaald).

Het daadwerkelijke verschil: scope

De eenvoudigste manier om het te zeggen:

Polylang beheert meertalige inhoud binnen WordPress. Het is een CMS-laag. Het regelt welke post de Spaanse versie is van welke Engelse post, genereert taalwisselaars en houdt vertalingen synchroon als je inhoud bijwerkt.

PolyLingo vertaalt gestructureerde inhoud via een API. Het is een vertaallaag. Je voedt het met inhoud, het geeft vertalingen terug. Wat je met die vertalingen doet, is aan jou.

Ze lossen aanverwante problemen op, niet hetzelfde probleem. Daarom is de vergelijking niet echt "wat is beter" maar "welk probleem heb ik."

Wanneer Polylang te gebruiken

Je site draait op WordPress en je wilt op WordPress blijven
Je hebt een content management workflow nodig: redacteuren die wisselen tussen taalversies, vertaalstatus bijhouden, taalwisselaars in het thema
Je bent geen ontwikkelaar en wilt een UI-gedreven oplossing
Je gebruikt WooCommerce en hebt productvertaling nodig die binnen WordPress wordt beheerd

Polylang is uitstekend in dit alles. Als WordPress jouw stack is, is het het juiste hulpmiddel.

Wanneer PolyLingo te gebruiken

Je bouwt op Next.js, Nuxt, SvelteKit, Astro of een ander niet-WordPress framework
Je gebruikt een headless CMS (Contentful, Sanity, Prismic) en moet inhoud vertalen bij publicatie of via een webhook
Je inhoud staat in JSON locale-bestanden die vertaald moeten worden zonder de sleutelstructuur te beschadigen
Je migreert van WordPress en wilt je meertalige workflow meenemen
Je hebt Markdown-inhoud (blogposts, documentatie, productbeschrijvingen) en hebt vertaalde versies nodig die de opmaak niet breken
Je wilt in één API-aanroep naar meerdere talen vertalen in plaats van één oproep per taal

PolyLingo's /translate endpoint accepteert een targets array, dus één verzoek kan alle 36 ondersteunde talen tegelijk teruggeven. Voor een locale-bestand dat in tien talen moet worden geleverd, is dat één API-aanroep in plaats van tien.

Hoe zit het met migreren van WordPress?

Als je een WordPress-site verhuist naar een headless of statische setup, komt je Polylang-inhoud niet automatisch mee. De vertalingen worden opgeslagen als WordPress post metadata en exporteren niet netjes naar Markdown-bestanden of JSON-structuren.

Het praktische pad dat de meeste teams nemen:

Exporteer je WordPress-inhoud naar Markdown of JSON (tools zoals wordpress-export-to-markdown regelen het mechanische deel)
Gebruik PolyLingo om de geëxporteerde inhoud te vertalen naar je doeltalen
Sla de resulterende bestanden op in je nieuwe contentstructuur naast de brontaal

PolyLingo's batch endpoint (POST /translate/batch) is precies hiervoor gebouwd. Je kunt tot 100 contentitems in één verzoek sturen, elk met zijn eigen formaat, allemaal met dezelfde set doeltalen. Voor een site-migratie met honderden pagina's is dat het juiste hulpmiddel voor de klus.

Samenvatting naast elkaar

	PolyLingo	Polylang
Werkt zonder WordPress	Ja	Nee
Formaatbehoud (JSON, Markdown, HTML)	Ja	Alleen WordPress-inhoud
Eén verzoek, alle talen	Ja	Nee
REST API-toegang	Ja	Nee
Content management UI	Vertaler UI (no-code)	Volledige WordPress admin
Detecteert contentformaat automatisch	Ja	N.v.t.
RTL taalondersteuning	Ja	Ja
Gebruik-gebaseerde facturering	Ja	Gratis plugin / Polylang Pro vaste prijs

De korte versie

Als je op WordPress zit en op WordPress blijft: gebruik Polylang. Het is gebouwd voor die omgeving en het is er goed in.

Als je niet op WordPress zit, van WordPress afgaat, of iets bouwt dat geen WordPress is: PolyLingo geeft je dezelfde gestructureerde meertalige workflow via een API die werkt met wat je ook bouwt.

De twee tools kunnen ook naast elkaar bestaan. Sommige teams draaien Polylang op hun hoofdmarketingsite (die op WordPress blijft) en gebruiken PolyLingo voor hun documentatiesite, hun webapp UI-strings of hun e-mailsjablonen. De workflow is hetzelfde; de stack hoeft dat niet te zijn.

Probeer het

PolyLingo's gratis laag bevat 100.000 tokens per maand. Dat is genoeg voor meerdere blogposts in tien talen, of een middelgroot locale-bestand in 36 talen. Geen creditcard vereist.

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

Begin gratis vertalen

PolyLingo versus Polylang: wat is het verschil en wanneer gebruik je welke