PolyLingo vs Polylang: apa bezanya dan bila hendak guna setiap satu

Jika anda sampai di sini, mungkin anda berada dalam salah satu daripada dua situasi: anda berpuas hati dengan Polylang dalam WordPress tetapi tertanya-tanya jika ada sesuatu yang setara untuk projek yang bukan di WordPress, atau anda sedang berhijrah sepenuhnya dari WordPress dan cuba memahami apa yang berlaku dengan tetapan berbilang bahasa anda.

Pos ini menjawab kedua-dua soalan tersebut secara langsung. Kami akan membincangkan apa yang setiap alat lakukan, di mana setiap satu sesuai, dan bagaimana memilih antara mereka.

Apa itu Polylang (dan apa yang bukan)

Polylang adalah plugin WordPress. Ia adalah salah satu plugin berbilang bahasa terbaik dalam ekosistem WordPress. Ia mengurus penukar bahasa, membolehkan anda membuat versi terjemahan pos dan halaman, mengendalikan tag hreflang, dan berintegrasi dengan editor blok WordPress dengan kemas. Jika anda menjalankan laman WordPress, ia adalah alat yang serius dan dijaga dengan baik dan ada sebab kukuh ia mempunyai berjuta-juta pemasangan aktif.

Hadnya terletak pada deskripsi itu: ia adalah plugin WordPress. Ia tidak mempunyai API yang boleh dipanggil dari luar WordPress. Ia tidak mempunyai konsep fail locale JSON, fail kandungan Markdown, atau templat HTML dalam projek Next.js. Modelnya sepenuhnya menganggap kandungan berada dalam pangkalan data WordPress dan dirender oleh WordPress.

Ini bukan kritikan. Ia hanya skop alat itu.

Apa itu PolyLingo

PolyLingo adalah API terjemahan. Anda menghantar kandungan (teks biasa, Markdown, JSON, atau HTML) dan ia mengembalikan versi terjemahan dalam setiap bahasa yang anda minta, dalam satu permintaan. Ia tidak mempunyai pendapat tentang CMS anda, rangka kerja anda, atau tetapan penyebaran anda. Ia berfungsi di mana sahaja anda boleh membuat permintaan HTTP.

Matlamat reka bentuk teras adalah pemeliharaan format. Kebanyakan API terjemahan dibina berdasarkan ayat: anda menghantar satu rentetan, anda mendapat rentetan kembali. Model itu cepat rosak apabila kandungan anda mempunyai struktur. Tampal fail locale JSON ke dalam perkhidmatan terjemahan biasa dan anda akan mendapat nama kunci yang diterjemah, pemisah yang rosak, atau prosa di mana objek sepatutnya. PolyLingo menganggap struktur sebagai kawasan larangan. Hanya nilai rentetan yang berubah; segala-galanya yang lain kembali tepat seperti yang dihantar.

Contoh konkrit. Anda menghantar ini:

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

Penterjemah berorientasikan ayat mungkin memberi anda kembali:

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

Kunci btn menjadi button. Itu akan merosakkan aplikasi anda. PolyLingo memberi anda:

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

Kunci tidak disentuh. Hanya nilai diterjemah.

Prinsip yang sama terpakai kepada Markdown (tajuk kekal tajuk, blok kod dibiarkan seperti asal, URL pautan tidak berubah) dan HTML (tag dan atribut dipelihara, hanya nod teks dan atribut yang sesuai diterjemah).

Perbezaan sebenar: skop

Cara paling mudah untuk katakan:

Polylang mengurus kandungan berbilang bahasa dalam WordPress. Ia adalah lapisan CMS. Ia mengendalikan pos mana yang versi Sepanyol bagi pos Inggeris mana, ia menjana penukar bahasa, dan ia menyelaraskan terjemahan apabila anda mengemas kini kandungan.

PolyLingo menterjemah kandungan berstruktur melalui API. Ia adalah lapisan terjemahan. Anda beri ia kandungan, ia pulangkan terjemahan. Apa yang anda lakukan dengan terjemahan itu terpulang kepada anda.

Mereka menyelesaikan masalah bersebelahan, bukan masalah yang sama. Sebab itu perbandingan bukan "mana lebih baik" tetapi "masalah mana yang saya ada."

Bila hendak guna Polylang

Laman anda berjalan di WordPress dan anda mahu kekal di WordPress
Anda perlukan aliran kerja pengurusan kandungan: editor bertukar antara versi bahasa, penjejakan status terjemahan, penukar bahasa dalam tema
Anda bukan pembangun dan mahu penyelesaian berasaskan UI
Anda menggunakan WooCommerce dan perlukan terjemahan produk diurus dalam WordPress

Polylang sangat baik dalam semua ini. Jika WordPress adalah tumpuan anda, ia alat yang tepat.

Bila hendak guna PolyLingo

Anda membina di Next.js, Nuxt, SvelteKit, Astro, atau mana-mana rangka kerja bukan WordPress
Anda menggunakan CMS tanpa kepala (Contentful, Sanity, Prismic) dan perlu menterjemah kandungan semasa penerbitan atau melalui webhook
Kandungan anda berada dalam fail locale JSON yang perlu diterjemah tanpa merosakkan struktur kunci
Anda berhijrah dari WordPress dan mahu membawa aliran kerja berbilang bahasa bersama anda
Anda ada kandungan Markdown (pos blog, dokumentasi, penerangan produk) dan perlukan versi terjemahan yang tidak merosakkan format
Anda mahu menterjemah ke pelbagai bahasa dalam satu panggilan API dan bukannya satu panggilan setiap bahasa

Titik akhir /translate PolyLingo menerima array targets, jadi satu permintaan boleh mengembalikan semua 36 bahasa yang disokong sekaligus. Untuk fail locale yang perlu dihantar dalam sepuluh bahasa, itu satu panggilan API dan bukannya sepuluh.

Bagaimana dengan berhijrah dari WordPress?

Jika anda memindahkan laman WordPress ke tetapan tanpa kepala atau statik, kandungan Polylang anda tidak dibawa secara automatik. Terjemahan disimpan sebagai metadata pos WordPress dan tidak dieksport dengan bersih ke fail Markdown atau struktur JSON.

Jalan praktikal yang diambil kebanyakan pasukan:

Eksport kandungan WordPress anda ke Markdown atau JSON (alat seperti wordpress-export-to-markdown mengendalikan bahagian mekanikal)
Gunakan PolyLingo untuk menterjemah kandungan yang dieksport ke bahasa sasaran anda
Simpan fail yang terhasil dalam struktur kandungan baru anda bersama bahasa sumber

Titik akhir batch PolyLingo (POST /translate/batch) dibina untuk ini. Anda boleh hantar sehingga 100 item kandungan dalam satu permintaan, setiap satu dengan format sendiri, semua berkongsi set bahasa sasaran yang sama. Untuk migrasi laman dengan ratusan halaman, itu alat yang tepat untuk kerja itu.

Ringkasan sebelah-menyebelah

	PolyLingo	Polylang
Berfungsi tanpa WordPress	Ya	Tidak
Pemeliharaan format (JSON, Markdown, HTML)	Ya	Kandungan WordPress sahaja
Satu permintaan, semua bahasa	Ya	Tidak
Akses REST API	Ya	Tidak
UI pengurusan kandungan	UI Penterjemah (tanpa kod)	Admin WordPress penuh
Mengesan format kandungan secara automatik	Ya	N/A
Sokongan bahasa RTL	Ya	Ya
Penagihan berdasarkan penggunaan	Ya	Plugin percuma / bayaran tetap Polylang Pro

Versi ringkas

Jika anda di WordPress dan kekal di WordPress: guna Polylang. Ia dibina untuk persekitaran itu dan ia bagus untuk itu.

Jika anda bukan di WordPress, keluar dari WordPress, atau membina apa-apa yang bukan WordPress: PolyLingo memberi anda aliran kerja berbilang bahasa berstruktur yang sama melalui API yang berfungsi dengan apa sahaja yang anda bina.

Kedua-dua alat juga boleh wujud bersama. Sesetengah pasukan menjalankan Polylang di laman pemasaran utama mereka (yang kekal di WordPress) dan menggunakan PolyLingo untuk laman dokumentasi mereka, rentetan UI aplikasi web mereka, atau templat emel mereka. Aliran kerja sama; tumpukan tidak perlu sama.

Cuba ia

Tahap percuma PolyLingo termasuk 100,000 token sebulan. Itu cukup untuk beberapa pos blog dalam sepuluh bahasa, atau fail locale bersaiz sederhana dalam 36 bahasa. Tiada kad kredit diperlukan.

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

Mulakan terjemahan percuma

PolyLingo vs Polylang: apakah perbezaannya dan bila perlu menggunakan setiap satu