PolyLingo vs Polylang: qual è la differenza e quando usare ciascuno

Se sei arrivato qui, probabilmente ti trovi in una di due situazioni: sei soddisfatto di Polylang all'interno di WordPress ma ti chiedi se esiste qualcosa di equivalente per un progetto che non è su WordPress, oppure stai migrando completamente da WordPress e stai cercando di capire cosa succede alla tua configurazione multilingue.

Questo post risponde direttamente a entrambe le domande. Copriremo cosa fa effettivamente ogni strumento, dove si inserisce ciascuno e come scegliere tra loro.

Cos'è Polylang (e cosa non è)

Polylang è un plugin per WordPress. È uno dei migliori plugin multilingua nell'ecosistema WordPress. Gestisce i selettori di lingua, ti permette di creare versioni tradotte di post e pagine, gestisce i tag hreflang e si integra perfettamente con l'editor a blocchi di WordPress. Se gestisci un sito WordPress, è uno strumento serio, ben mantenuto e c'è un buon motivo se ha milioni di installazioni attive.

La limitazione è proprio nella descrizione: è un plugin per WordPress. Non ha un'API che puoi chiamare dall'esterno di WordPress. Non ha il concetto di un file locale JSON, un file di contenuto Markdown o un template HTML in un progetto Next.js. Il suo intero modello presume che il contenuto risieda nel database di WordPress e venga renderizzato da WordPress.

Non è una critica. È solo l'ambito dello strumento.

Cos'è PolyLingo

PolyLingo è un'API di traduzione. Gli invii contenuti (testo semplice, Markdown, JSON o HTML) e restituisce versioni tradotte in tutte le lingue che richiedi, in una singola richiesta. Non ha opinioni sul tuo CMS, sul tuo framework o sulla tua configurazione di deployment. Funziona ovunque tu possa fare una richiesta HTTP.

L'obiettivo principale di progettazione è la preservazione del formato. La maggior parte delle API di traduzione è costruita attorno alle frasi: invii una stringa, ricevi una stringa indietro. Quel modello si rompe rapidamente quando il tuo contenuto ha una struttura. Incolla un file locale JSON in un servizio di traduzione tipico e otterrai nomi di chiavi tradotti, delimitatori corrotti o prosa dove prima c'era un oggetto. PolyLingo considera la struttura off-limits. Solo i valori stringa cambiano; tutto il resto torna esattamente com'era inviato.

Un esempio concreto. Invi questo:

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

Un traduttore orientato alle frasi potrebbe restituirti:

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

La chiave btn è diventata button. Questo romperà la tua applicazione. PolyLingo ti dà:

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

Chiavi intatte. Solo i valori tradotti.

Lo stesso principio si applica a Markdown (le intestazioni rimangono intestazioni, i blocchi di codice sono lasciati verbatim, gli URL dei link non cambiano) e HTML (tag e attributi sono preservati, solo i nodi di testo e gli attributi appropriati sono tradotti).

La vera differenza: ambito

Il modo più semplice per dirlo:

Polylang gestisce contenuti multilingua all'interno di WordPress. È uno strato CMS. Gestisce quale post è la versione spagnola di quale post inglese, genera selettori di lingua e mantiene le traduzioni sincronizzate quando aggiorni il contenuto.

PolyLingo traduce contenuti strutturati tramite un'API. È uno strato di traduzione. Gli fornisci contenuti, restituisce traduzioni. Cosa fai con quelle traduzioni dipende da te.

Risolvono problemi adiacenti, non lo stesso problema. Ecco perché il confronto non è davvero "qual è migliore" ma "quale problema ho."

Quando usare Polylang

Il tuo sito gira su WordPress e vuoi rimanere su WordPress
Hai bisogno di un flusso di lavoro di gestione dei contenuti: editor che passano tra versioni linguistiche, tracciamento dello stato della traduzione, selettori di lingua nel tema
Non sei uno sviluppatore e vuoi una soluzione guidata dall'interfaccia utente
Usi WooCommerce e hai bisogno che la traduzione dei prodotti sia gestita all'interno di WordPress

Polylang è eccellente in tutto questo. Se WordPress è il tuo stack, è lo strumento giusto.

Quando usare PolyLingo

Stai costruendo su Next.js, Nuxt, SvelteKit, Astro o qualsiasi altro framework non WordPress
Usi un CMS headless (Contentful, Sanity, Prismic) e devi tradurre contenuti al momento della pubblicazione o tramite webhook
I tuoi contenuti risiedono in file locale JSON che devono essere tradotti senza corrompere la struttura delle chiavi
Stai migrando da WordPress e vuoi portare con te il tuo flusso di lavoro multilingua
Hai contenuti Markdown (post del blog, documentazione, descrizioni di prodotti) e hai bisogno di versioni tradotte che non rompano la formattazione
Vuoi tradurre in più lingue in una singola chiamata API invece di fare una chiamata per ogni lingua

L'endpoint /translate di PolyLingo accetta un array targets, quindi una richiesta può restituire tutte e 36 le lingue supportate in una volta. Per un file locale che deve essere distribuito in dieci lingue, è una chiamata API invece di dieci.

E la migrazione da WordPress?

Se stai spostando un sito WordPress a una configurazione headless o statica, i tuoi contenuti Polylang non ti seguono automaticamente. Le traduzioni sono memorizzate come metadata dei post di WordPress e non si esportano pulitamente in file Markdown o strutture JSON.

Il percorso pratico che la maggior parte dei team segue:

Esporta i tuoi contenuti WordPress in Markdown o JSON (strumenti come wordpress-export-to-markdown gestiscono la parte meccanica)
Usa PolyLingo per tradurre i contenuti esportati nelle lingue target
Conserva i file risultanti nella tua nuova struttura di contenuti accanto alla lingua sorgente

L'endpoint batch di PolyLingo (POST /translate/batch) è costruito proprio per questo. Puoi inviare fino a 100 elementi di contenuto in una singola richiesta, ciascuno con il proprio formato, tutti condividendo lo stesso set di lingue target. Per una migrazione di sito con centinaia di pagine, è lo strumento giusto per il lavoro.

Riepilogo affiancato

	PolyLingo	Polylang
Funziona senza WordPress	Sì	No
Preservazione del formato (JSON, Markdown, HTML)	Sì	Solo contenuti WordPress
Una richiesta, tutte le lingue	Sì	No
Accesso REST API	Sì	No
UI di gestione contenuti	UI traduttore (no-code)	Admin WordPress completo
Rileva automaticamente il formato del contenuto	Sì	N/A
Supporto lingue RTL	Sì	Sì
Fatturazione basata sull'uso	Sì	Plugin gratuito / tariffa fissa Polylang Pro

Versione breve

Se sei su WordPress e rimani su WordPress: usa Polylang. È costruito per quell'ambiente ed è bravo in questo.

Se sei fuori WordPress, stai lasciando WordPress o stai costruendo qualcosa che non è WordPress: PolyLingo ti offre lo stesso flusso di lavoro multilingue strutturato tramite un'API che funziona con qualunque cosa tu stia costruendo.

I due strumenti possono anche coesistere. Alcuni team usano Polylang sul loro sito marketing principale (che rimane su WordPress) e usano PolyLingo per il sito della documentazione, le stringhe UI della loro app web o i template email. Il flusso di lavoro è lo stesso; lo stack non deve esserlo.

Provalo

Il piano gratuito di PolyLingo include 100.000 token al mese. È sufficiente per diversi post di blog in dieci lingue, o un file locale di medie dimensioni in 36 lingue. Non serve carta di credito.

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

Inizia a tradurre gratis