بهترین افزونه ترجمه وردپرس: مقایسه

در پروژه‌ای که سایت شرکتی‌اش قرار بود به سه زبان ارائه شود، مشتری تصمیم گرفت «یک افزونه‌ی چندزبانه‌ی معروف» بخرد و بعد از سه ماه، با یک سایت کند، ترجمه‌ی نیمه‌کاره و لینک‌های شکسته به من زنگ زد. مشکل، خودِ افزونه نبود؛ مشکل این بود که انتخاب افزونه، بدون فهمیدن معماریِ چندزبانگی انجام شده بود. سه نوع معماری برای سایت چندزبانه وجود دارد و هر افزونه، یکی از این سه را پیاده می‌کند.

این مقاله، یک مقایسه‌ی فنی و صادقانه است: پنج افزونه‌ی اصلی را روی محورهای واقعی می‌سنجم و در پایان هر بخش، یک تصمیم‌نامه می‌دهم. اگر تازه با این حوزه آشنا می‌شوید، پیشنهاد می‌کنم اول چگونه از وردپرس چندزبانه استفاده کنیم را بخوانید.

سه معماری چندزبانگی: قبل از هر مقایسه‌ای

قبل از این‌که سراغ مقایسه‌ی افزونه‌ها برویم، باید بدانید هر افزونه یکی از سه معماری زیر را پیاده می‌کند. انتخاب معماری، مهم‌تر از انتخاب برند است:

هر معماری، پیامدهای مشخصی دارد. معماری اول، بهترین کنترل را می‌دهد ولی سنگین‌تر است. معماری دوم، سریع‌ترین راه‌اندازی را دارد ولی در تغییر قالب، ممکن است ترجمه‌ها از دست برود. معماری سوم، راحت‌ترین است ولی وابستگی به سرویس بیرونی دارد و هزینه‌ی ماهانه‌اش با ترافیک رشد می‌کند.

قبل از انتخاب افزونه، معماری را انتخاب کنید. افزونه، فقط پیاده‌سازیِ معماری است؛ اگر معماری اشتباه باشد، بهترین افزونه هم نتیجه‌ی درستی نمی‌دهد.

شش محور واقعی سنجش

در مقایسه‌های اینترنتی معمولاً روی «امکانات» تمرکز می‌شود. ولی در پروژه‌های واقعی، شش محور دیگری هستند که تفاوت‌ساز می‌شوند:

1. سازگاری با قالب و افزونه: آیا با فروشگاه ووکامرس کار می‌کند؟ با فرم‌ساز؟ با المنتور؟
2. سئوی چندزبانه: آیا برای هر زبان، URL جداگانه و sitemap مستقل تولید می‌کند؟
3. کارایی (Performance): آیا در هر درخواست، overhead اضافه می‌کند؟
4. مدل قیمت‌گذاری: سالانه، ماهانه، بر اساس تعداد کلمات، بر اساس ترافیک؟
5. تجربه‌ی مدیریت ترجمه: تیم محتوا چقدر راحت می‌تواند ترجمه اضافه کند؟
6. سازگاری با RTL و فارسی: برای سایت‌های ایرانی، این محور حیاتی است.

با این شش محور، سراغ پنج افزونه‌ی اصلی می‌رویم. برای هر افزونه، سه چیز را می‌گویم: قوت اصلی، ضعف اصلی، و تصمیم‌نامه‌ی چه کسی.

WPML: پرقدرت‌ترین، سنگین‌ترین

WPML (WordPress Multilingual) قدیمی‌ترین و پرقدرت‌ترین افزونه‌ی چندزبانه است. معماری‌اش بر پایه‌ی «محتوای جداگانه برای هر زبان» است.

قوت اصلی: سازگاری با تقریباً هر قالب و افزونه‌ی مهمی، از جمله ووکامرس. برای پروژه‌های پیچیده‌ای که چند نوع محتوای سفارشی، محصولات متغیر، و فیلدهای سفارشی دارند، WPML جامع‌ترین گزینه است. مدل قیمت‌گذاری‌اش — بر اساس سطح (Multilingual Blog, CMS, Agency) — به شما اجازه می‌دهد مطابق نیاز واقعی‌تان هزینه کنید.

ضعف اصلی: سنگینی. WPML با معماری «هر زبان، یک نسخه‌ی جداگانه»، در پروژه‌های بزرگ با هزاران مقاله، دیتابیس را به‌طور محسوس سنگین می‌کند. سرعت پیشخوان، سرعت جستجو، و گاهی سرعت front-end افت می‌کند. علاوه بر این، رابط کاربری‌اش در نسخه‌های اخیر بهتر شده ولی هنوز پیچیده است.

تصمیم‌نامه: برای سایت‌های فروشگاهی چندزبانه‌ی جدی، WPML انتخاب اول است — به‌شرط پذیرش سنگینی. اگر سایت‌تان زیر ۲۰۰ مقاله است، به‌سراغش نروید.

Polylang: سبک، ماژولار، سئو-محور

Polylang رقیب اصلی WPML است و فلسفه‌ی متفاوتی دارد: به‌جای یک بسته‌ی بزرگ، یک هسته‌ی سبک با ماژول‌های جداگانه. نسخه‌ی رایگان آن در مخزن رسمی وردپرس موجود است.

قوت اصلی: سبکی. Polylang در پروژه‌های محتوایی، overhead محسوسی روی دیتابیس اضافه نمی‌کند. رابط کاربری ساده و بصری آن، کار با ترجمه‌ی مقالات را راحت‌تر می‌کند. برای سایت‌های وبلاگی، خبری و آموزشی، انتخاب اول من است. نسخه‌ی Pro اخیراً با قابلیت‌های پیشرفته‌تر برای ووکامرس و ACF ارائه شده است.

ضعف اصلی: سازگاری کمتر با افزونه‌های ثالث نسبت به WPML. اگر پروژه‌ی شما از افزونه‌ی خاص و پیچیده‌ای استفاده می‌کند، احتمالاً به کاستوم‌سازی نیاز دارید. هم‌چنین، پشتیبانی نسخه‌ی رایگان، محدود به انجمن است.

تصمیم‌نامه: برای سایت‌های محتوایی، خبری، آموزشی و شرکتی غیر‌فروشگاهی، Polylang در نسخه‌ی رایگان خود، بهترین نسبت هزینه به کارایی را دارد.

یک نکته‌ی جانبی که در پروژه‌های فارسی مهم است: هم Polylang و هم WPML، هر دو RTL را درست پشتیبانی می‌کنند. برای اطمینان، بعد از نصب حتماً در یک قالب فارسی تست کنید. راهنمای آماده‌سازی فارسی قالب در چگونه قالب وردپرس را برای زبان فارسی آماده کنیم آمده است.

TranslatePress: ترجمه‌ی بصری زنده

TranslatePress یک رویکرد متفاوت دارد: به‌جای جدا کردن محتوا به زبان‌های مختلف در دیتابیس، یک نسخه‌ی محتوا نگه می‌دارد و ترجمه را در لایه‌ی نمایش اعمال می‌کند. محبوب‌ترین ویژگی‌اش، ترجمه‌ی بصری زنده است: قالب را باز می‌کنید و همان‌طور که در front-end می‌بینید، ترجمه می‌کنید.

قوت اصلی: تجربه‌ی کاربری. برای کسب‌وکارهای کوچک و سایت‌های شخصی، TranslatePress سریع‌ترین راه به نتیجه است. تیم محتوا بدون نیاز به دانش فنی، در همان صفحه‌ی سایت، ترجمه‌ها را وارد می‌کند. نسخه‌ی رایگان برای یک زبان اضافی کافی است.

ضعف اصلی: یکی از مهم‌ترین ضعف‌ها که معمولاً در بازاریابی ذکر نمی‌شود: ترجمه‌ی نمایش‌محور، در روز تغییر قالب با مشکل مواجه می‌شود. اگر ترجمه‌ها به ساختار قالب گره خورده باشند، تعویض قالب می‌تواند بخش بزرگی از آن‌ها را از دست بدهد. همچنین، برای پروژه‌های چندزبانگی پیچیده — چند نوع محتوا، فیلدهای سفارشی، فروشگاه — انعطاف کمتری از WPML و Polylang دارد.

تصمیم‌نامه: برای سایت‌های کوچک و متوسط که سریع‌ترین راه‌اندازی را می‌خواهند و تعداد زبان‌ها کمتر از سه است، TranslatePress گزینه‌ی درخشانی است. اگر پروژه‌ی شما قرار است چند سال بماند و قالب عوض شود، با احتیاط.

Weglot: ابری و بی‌دردسر

Weglot یک سرویس ابری است. افزونه‌ی سبکی روی سایت نصب می‌کنید و تمام ترجمه در سرور Weglot انجام می‌شود. ترجمه‌ی اولیه، ماشینی است و بعد می‌توانید دستی ویرایش کنید.

قوت اصلی: سادگی مطلق. در کمتر از ده دقیقه، سایت شما به چند زبان ارائه می‌شود. برای کسب‌وکارهایی که نمی‌خواهند به زیرساخت ترجمه درگیر شوند، این سادگی طلاست. Weglot نسخه‌های مختلف بر اساس تعداد کلمات ارائه می‌دهد و برای سایت‌های کوچک، هزینه‌ی قابل‌توجیهی دارد.

ضعف اصلی: مدل هزینه. Weglot بر اساس تعداد کلمات قیمت‌گذاری می‌کند. سایت‌های محتوایی با هزاران مقاله، در سال دوم با هزینه‌ی سنگینی مواجه می‌شوند. علاوه بر این، وابستگی به سرویس ابری، نگرانی‌های حریم‌خصوصی و انطباق GDPR را به‌وجود می‌آورد.

تصمیم‌نامه: برای کسب‌وکارهای کوچک، سایت‌های خدماتی، و پروژه‌هایی که ترجمه‌ی ماشینی + ویرایش سبک کافی است، Weglot بهترین گزینه است. برای سایت‌های محتوایی بزرگ، هزینه‌ی سالانه‌اش ممکن است غیرقابل‌توجیه شود.

GTranslate: ترجمه‌ی ماشینی خودکار

GTranslate روی ترجمه‌ی ماشینی Google تمرکز دارد. نسخه‌ی رایگان آن، ترجمه‌ی خودکار را بر اساس Google Translate ارائه می‌دهد، و نسخه‌های پولی، کنترل بیشتر و حذف برند GTranslate از URL را اضافه می‌کنند.

قوت اصلی: ارزان‌ترین راه برای چندزبانه کردن سایت. نسخه‌ی رایگان آن، حتی برای پروژه‌های کوچک با ترافیک بالا کافی است. سادگی نصب و راه‌اندازی از هر گزینه‌ی دیگری بیشتر است.

ضعف اصلی: کیفیت ترجمه. ترجمه‌ی ماشینی خودکار برای محتوای تخصصی، غیرقابل‌قبول است. حتی با ترجمه‌ی Google، تفاوت‌های فرهنگی و اصطلاحات تخصصی، کیفیت را پایین می‌آورد. از منظر سئو، URLهای ترجمه‌شده به‌صورت زیر‌دامنه یا با پیشوند خاص، گاهی توسط گوگل به‌عنوان محتوای تکراری در نظر گرفته می‌شوند.

تصمیم‌نامه: برای وبلاگ‌های شخصی، سایت‌های توریستی، یا پروژه‌هایی که هدف فقط «دیده شدن در چند زبان» است بدون انتظار کیفیت، GTranslate کافی است. برای هر پروژه‌ی جدی، پیشنهاد نمی‌کنم.

جدول مقایسه‌ی نهایی

حالا پنج افزونه را در یک جدول جمع می‌کنم. امتیازها بر اساس تجربه‌ی پروژه‌های واقعی و بر پایه‌ی شش محوری است که در ابتدا آمد:

یک نکته در خواندن این جدول: ستون «کارایی» مهم‌تر از آن است که فکر می‌کنید. در سایت‌هایی که ترافیک بالایی دارند، هر میلی‌ثانیه‌ای که افزونه‌ی چندزبانه به زمان بارگذاری اضافه می‌کند، در نرخ پرش منعکس می‌شود. اگر سایت شما ترافیک بالایی دارد، Polylang یا Weglot انتخاب‌های بهتری هستند. برای بهینه‌سازی کلی سرعت، چگونه سرعت سایت وردپرسی را افزایش دهیم را بخوانید.

سئوی چندزبانه: لایه‌ای که اکثر انتخاب‌ها را لو می‌دهد

سئوی چندزبانه، یک لایه‌ی فنی جداگانه است که در انتخاب افزونه، حیاتی است. سه نکته‌ی کلیدی:

1. ساختار URL: آیا افزونه برای هر زبان، یک URL جداگانه می‌سازد؟ مثلاً example.com/fa/ و example.com/en/. اگر این‌طور نباشد و از پارامتر استفاده شود، گوگل ممکن است محتوا را تکراری ببیند.
2. hreflang: این تگ به گوگل می‌گوید «این صفحه، نسخه‌ی فارسی از همان محتوایی است که در URL انگلیسی هست». بدون hreflang، گوگل نمی‌داند کدام نسخه را به کاربر فارسی‌زبان نشان بدهد.
3. sitemap مستقل برای هر زبان: Search Console باید بتواند ترجمه‌های شما را جداگانه ایندکس کند.

در پنج افزونه‌ی بالا:

• WPML و Polylang: hreflang و sitemap مستقل را به‌طور استاندارد تولید می‌کنند.
• TranslatePress: هر دو را دارد ولی در پیاده‌سازی hreflang، گاهی نیاز به بررسی دستی دارد.
• Weglot: hreflang را تولید می‌کند ولی sitemap را از سرویس ابری ارائه می‌دهد.
• GTranslate: hreflang ندارد یا ناقص است. این یکی از مهم‌ترین ضعف‌های سئویی‌اش است.

نقش hreflang در سئوی بین‌المللی، در سئو تکنیکال از خزش تا ایندکس به‌طور کامل آمده. اگر سایت چندزبانه‌ای دارید و رشد ارگانیک می‌خواهید، این لایه غیرقابل‌مذاکره است. راهنمای کامل سئوی چندزبانه هم در سئو تکنیکال چیست و چرا مهم است آمده است.

سایت چندزبانه‌ای که hreflang ندارد، مثل کتابخانه‌ای است که کتاب‌هایش را در قفسه‌های اشتباه گذاشته: کاربر پیدا نمی‌کند، گوگل هم.

تصمیم‌نامه: کدام افزونه برای کدام سایت؟

در پایان همه‌ی این مقایسه‌ها، تصمیم‌نامه‌ی من بر اساس سناریوهای واقعی پروژه‌ها:

یک تذکر مهم: هیچ‌کدام از این انتخاب‌ها دائمی نیستند. اگر در نیمه‌ی راه متوجه شدید که انتخاب اشتباه بوده، مهاجرت بین افزونه‌های چندزبانه سخت ولی ممکن است. بهترین کار، انتخاب درست از ابتدا با توجه به رشد سه‌ساله‌ی سایت است.

اشتباهات رایج در پروژه‌های چندزبانه

در تجربه‌ی خودم، این اشتباهات بیشتر از همه دیده می‌شوند:

1. انتخاب افزونه بدون تعریف «سطح چندزبانگی»: آیا محتوا کاملاً ترجمه می‌شود؟ آیا فقط منو و رابط ترجمه می‌شود؟ این تصمیم، قبل از انتخاب افزونه گرفته می‌شود.
2. بی‌توجهی به hreflang و sitemap: بدون این دو، ترجمه‌های شما در گوگل رتبه نمی‌گیرند.
3. نصب دو افزونه‌ی چندزبانه روی هم: این کار، همان‌قدر خطرناک است که نصب دو افزونه‌ی سئو. تضاد بین آن‌ها، سایت را از کار می‌اندازد.
4. بی‌توجهی به ترجمه‌ی محتوای پویا: تاریخ‌ها، فرم‌ها، دکمه‌ها — گاهی از ترجمه جا می‌مانند.
5. تست نکردن ترجمه در RTL: سایت فارسی، یک تست جداگانه می‌خواهد. مسیر تست کامل در بهترین روش تست قالب وردپرس آمده است.

اگر پروژه‌ی شما فروشگاهی است، اشتباهات حوزه‌ی چندزبانگی، مستقیماً به سفارش‌های از دست رفته تبدیل می‌شوند. راهنمای تخصصی در تنظیم روش‌های پرداخت در ووکامرس و خطای عدم نمایش محصولات در ووکامرس آمده است.

نگاه معمارانه: چندزبانگی به‌عنوان تصمیم معماری

برای کسی که سال‌ها روی معماری سیستم‌های وب کار کرده، افزونه‌ی چندزبانه در نگاه اول یک انتخاب نرم‌افزاری است. اما اگر عمیق‌تر نگاه کنید، چندزبانگی یک تصمیم معماری با سه لایه است:

• لایه‌ی داده: آیا محتوا به‌ازای هر زبان جداگانه ذخیره می‌شود یا یک نسخه با لایه‌ی نمایش؟ این تصمیم، در سطح دیتابیس اثر می‌گذارد: حجم، پرس‌وجو، و بکاپ.
• لایه‌ی ارائه: آیا URLها به‌ازای هر زبان جداگانه‌اند؟ آیا کوکی‌ها و sessionها زبان را درست مدیریت می‌کنند؟ این لایه، مستقیماً روی سئو و کش تأثیر دارد.
• لایه‌ی تجربه: آیا کاربر می‌تواند بدون دوباره‌کاری، زبان را جابه‌جا کند؟ آیا متون ترجمه‌نشده به‌درستی نمایش داده می‌شوند؟ این لایه، روی نرخ تبدیل اثر می‌گذارد.

معماری چندزبانگی در پروژه‌های جدی، معمولاً با مفهوم «Localization Architecture» شناخته می‌شود: طراحی سیستم برای پشتیبانی از چند زبان و چند فرهنگ، به‌عنوان یک تصمیم بنیادی — نه یک افزونه‌ی بعد از انتشار. تفاوت بین سایت‌هایی که «چندزبانه‌اند» و سایت‌هایی که «چندزبانه‌ی حرفه‌ای» هستند، در همین تصمیم بنیادی است. اگر چندزبانگی از روز اول در معماری نبود، اضافه‌کردنش در سال سوم، همان‌قدر هزینه دارد که بازسازی نیمی از پروژه. برای درک عمیق‌تر این نگاه، چگونه یک پروژه توسعه وردپرس را ساختاربندی کنیم و چگونه معماری وب مقیاس‌پذیر طراحی کنیم را در کنار این بحث بخوانید. یک نکته‌ی مهم دیگر که در پروژه‌های بین‌المللی یاد گرفته‌ام: تفاوت بین ترجمه و بومی‌سازی را جدی بگیرید. ترجمه یعنی تبدیل کلمات؛ بومی‌سازی یعنی تبدیل تاریخ، واحد اندازه‌گیری، فرمت پول، و حتی رنگ‌ها به فرهنگ مقصد. اگر سایت شما قرار است مخاطب بین‌المللی داشته باشد، این تفاوت را از روز اول در تصمیم معماری لحاظ کنید. و اگر سایت شما در ایران است، چندزبانگی معمولاً یک انتخاب استراتژیک برای رشد بازار است — نه یک هزینه‌ی اضافی. این انتخاب، در فروشگاه‌های اینترنتی می‌تواند تفاوت بین ماندن در بازار داخلی و ورود به بازارهای منطقه باشد.

خط آخر: زبان، بخشی از تجربه‌ی کاربر است

خلاصه‌ی این مقایسه در یک جمله: بهترین افزونه‌ی ترجمه، افزونه‌ای نیست که بیشترین امکانات را داشته باشد؛ افزونه‌ای است که با معماری پروژه‌ی شما همخوانی داشته باشد. WPML برای پروژه‌های پیچیده، Polylang برای سایت‌های محتوایی، TranslatePress برای شروع سریع، Weglot برای پروژه‌های بین‌المللی، و GTranslate برای پروژه‌های سبک — هر کدام در جای خود بهترین هستند.

قدم عملی امشب‌تان: قبل از انتخاب هر افزونه‌ای، سه سؤال را جواب بدهید: چند زبان؟ چند نوع محتوا؟ قرار است سایت چند سال بماند؟ پاسخ این سه، شما را به یکی از پنج گزینه می‌رساند.

اگر تجربه‌ای از پروژه‌ی چندزبانه دارید — چه با موفقیت، چه با شکست — برای من جذاب است بدانم کدام افزونه و چه رویکردی در پروژه‌ی شما جواب داد. تجربه‌تان را در دیدگاه‌ها بنویسید؛ مخصوصاً اگر افزونه‌ای هست که در این فهرست نبوده ولی در پروژه‌ی شما کلیدی بوده، آن هم داده‌ای است که برای نفر بعدی، ماه‌ها وقت ذخیره می‌کند. 🌍