مقارنة Polylang وWPML وTranslatePress لعام 2026
أنت على وشك بناء موقع WordPress متعدد اللغات. تفتح Google، وتكتب "أفضل إضافة ترجمة لـ WordPress،" وفي غضون عشر دقائق، ستجد نفسك غارقًا في مراجعات الشركاء التابعين، وجداول مقارنة تبدو وكأنها منسوخة ولصق، ونصائح متضاربة حول Polylang وWPML وTranslatePress. كل مراجعة تختتم بشكل ملائم بـ "الإضافة X هي الفائزة،" وليس لديك طريقة لمعرفة أي واحدة ستعمل بالفعل لمشروعك.
إليك الإجابة الصادقة: تحل هذه الإضافات الثلاث المشكلة السطحية نفسها - عرض موقعك بلغات متعددة - لكنها تتبع مقاربات مختلفة جوهريًا. يقوم WPML بتخزين الترجمات في منشورات مكررة. يقوم Polylang بنفس الشيء لكنه يحافظ على نسخته الأساسية مجانية. يقوم TranslatePress بترجمة HTML المعروض في الوقت الفعلي. كل بنية لديها مفاضلات حقيقية تؤثر على الأداء، وتحسين محركات البحث (SEO)، وسير عمل المحتوى، والصيانة طويلة الأجل.
هذه المقارنة تتجاوز ضجيج التسويق بالعمولة وتقدم التفاصيل التي تؤثر فعليًا على موقعك في عام 2026: التسعير اعتبارًا من هذا العام، وكيف تؤثر كل إضافة على Core Web Vitals لموقعك، وما الذي يتعطل عند تبديل الإضافات، ولماذا يتجاهل عدد متزايد من الفرق هذه الإضافات الثلاثة ويقومون بترجمة ملفات .po مباشرةً.
ما تفعله هذه الإضافات بالفعل (إنها ليست متماثلة)
قبل مقارنة الميزات، تحتاج إلى فهم أن هذه الإضافات تستخدم ثلاث بنيات مختلفة. اختر البنية الخاطئة ولن تتمكن أي كمية من إعدادات الإضافات من إنقاذك.
WPML: نموذج تكرار المنشورات
ينشئ WPML نسخة منفصلة من كل منشور، صفحة، مصطلح تصنيفي، وعنصر قائمة لكل لغة. ينمو جدول posts الخاص بك بشكل خطي مع عدد اللغات. موقع يحتوي على 500 منشور و 5 لغات ينتهي به المطاف بـ 2500 صف في wp_posts، بالإضافة إلى بيانات وصفية للمنشورات المطابقة، وعلاقات المصطلحات، والمراجعات.
يمنحك هذا هياكل عناوين URL نظيفة (/es/producto/, /fr/produit/)، وتوافقًا كاملاً مع معظم الإضافات، وتحريرًا مستقلاً لكل لغة. التكلفة هي حجم قاعدة البيانات وتعقيد الاستعلامات - يجب على كل استعلام أرشيف تصفية حسب اللغة، وتبدأ المواقع المعقدة في التباطؤ عند حوالي 10,000+ منشور مترجم.
Polylang: أيضًا نموذج تكرار المنشورات (مع نواة مجانية)
يستخدم Polylang نفس نهج تكرار المنشورات مثل WPML ولكنه يأتي مع إضافة أساسية مجانية وإضافة Pro مدفوعة للميزات المتقدمة مثل ترجمة السلاسل للإضافات ودعم WooCommerce. تحت الغطاء، البنية متطابقة تقريبًا مع WPML - نفس خصائص الأداء، نفس سلوك التوسع.
TranslatePress: إعادة كتابة HTML للواجهة الأمامية
يتخذ TranslatePress نهجًا مختلفًا تمامًا. بدلاً من تكرار المنشورات، يقوم بترجمة HTML المعروض أثناء التنقل. تزور موقعك بالفرنسية، ويقوم TranslatePress باعتراض المخرجات، والبحث عن الترجمات في جدوله الخاص، واستبدال السلاسل قبل إرسال الاستجابة إلى المتصفح.
هذا يعني أنك لا تكرر المنشورات. لكنه يعني أيضًا أن كل عرض صفحة واحدة يقوم بتشغيل استعلامات إضافية للبحث عن السلاسل المترجمة. بالنسبة للمواقع ذات الزيارات العالية، يخلق هذا سقفًا للأداء لا تملكه الإضافات الأخرى.
تفصيل التسعير والترخيص (2026)
التسعير هو أسهل شيء للتحقق من الحقائق، وأصعب مكان لمراجعات الشركاء التابعين للبقاء صادقة. فيما يلي أرقام 2026 كما نُشرت على موقع كل بائع.
| الإضافة | الطبقة المجانية | المدفوعة الأولية | الطبقة الاحترافية | المواقع | التجديد |
|---|---|---|---|---|---|
| WPML | لا | 39 دولارًا/سنة (Multilingual Blog) | 99 دولارًا/سنة (Multilingual CMS) | 1-غير محدود | نعم، خصم ~50% للسنة الأولى |
| Polylang | نعم (أساسية) | 99 دولارًا/سنة (Pro) | 139 دولارًا/سنة (Business) | 1-5 | نعم، خصم 50% |
| TranslatePress | نعم (محدودة) | 7.99 دولار/شهر (Personal) | 14.99 دولار/شهر (Business) | 1-5 | تجديد تلقائي |
أشياء قليلة تخفيها جداول المقارنة عادةً:
- تكلفة الترجمة التلقائية إضافية. يستخدم محرر WPML المتقدم للترجمة DeepL أو Google، ويتم احتساب التكلفة بالكلمات. يتكامل Polylang مع Lingotek أو DeepL، ويتم احتساب التكلفة أيضًا. يفرض TranslatePress رسومًا على "أرصدة الترجمة التلقائية" بالإضافة إلى الترخيص.
- دعم WooCommerce مقيد. يتطلب Polylang الطبقة Business لدعم WooCommerce. يتطلب WPML الطبقة Multilingual CMS. لا يشمل TranslatePress Personal ترجمة سلاسل WooCommerce.
- أسعار التجديد تقفز. تذكر بعض المراجعات خصم السنة الأولى. التكلفة لعدة سنوات هي ما يهم.
للحصول على تفصيل كامل لكيفية تراكم هذه التكاليف مقابل أسعار المستقلين والترجمة السحابية، راجع مقارنة تكلفة ترجمة WordPress الخاصة بنا.
الأداء وتأثير سرعة الموقع
هنا تبرز أهمية الفروقات المعمارية بشكل أكبر. تؤثر Core Web Vitals على تحسين محركات البحث (SEO) لديك مباشرةً، وتعتبر إضافات الترجمة أحد الأسباب الخفية الأكثر شيوعًا لضعف درجات LCP وINP.
WPML وPolylang: ثقل قاعدة البيانات
تضيف كلتا الإضافتين روابط (joins) لمعظم استعلامات الواجهة الأمامية. يجب على WP_Query التصفية حسب اللغة، مما يعني روابط إضافية لـ term_taxonomy وterm_relationships في كل صفحة أرشيف. في موقع صغير لن تلاحظ ذلك. في موقع يضم أكثر من 5000 منشور عبر 5 لغات، سترى زيادة في TTFB بمقدار 200-500 مللي ثانية بدون تخزين مؤقت قوي.
TranslatePress: إعادة الكتابة لكل طلب
يقوم TranslatePress بإجراء بحث عن السلاسل في كل صفحة معروضة. حتى مع التخزين المؤقت للكائنات، تفرض الإضافة حدًا أدنى لسرعة استجابة موقعك لأنه يجب عليها اعتراض HTML، وتحليله، وإعادة كتابته، وإعادة إصداره. لقد قسنا هذا بالتفصيل في اختبار الأداء لملفات .mo الثابتة مقابل إضافات الترجمة الخاص بنا - حيث احتلت إعادة كتابة الواجهة الأمامية باستمرار المرتبة الأبطأ بين جميع سيناريوهات الاختبار.
المشكلة المتفاقمة: حزم الإضافات
نادرًا ما تقوم بتشغيل إضافة ترجمة واحدة بمعزل عن غيرها. أضف WooCommerce، ومنشئ الصفحات، وإضافة SEO، وطبقة تخزين مؤقت، وستجد أن كل إضافة ترجمة لها حلول توافق خاصة بها. يقدم WPML محولات (adapters) لعشرات الإضافات. Polylang أخف قليلاً. يتمتع TranslatePress بأصغر بصمة توافق ولكنه يعيد كتابة HTML بعد انتهاء كل إضافة أخرى، مما قد يلغي تحسينات التخزين المؤقت من باقي حزمة أدواتك.
جودة الترجمة وسير العمل
تعتمد جودة الترجمة التلقائية على المحرك الذي تستدعيه كل إضافة، وليس على الإضافة نفسها. يستخدم WPML DeepL أو Google أو Microsoft. يستخدم Polylang DeepL أو Google أو Lingotek. يستخدم TranslatePress DeepL أو Google.
الأهم هو كيفية تسليم الترجمة وتخزينها:
- يقوم WPML وPolylang بتخزين الترجمات في جداول خاصة بهما وتقديمها من PHP. يتطلب التحرير تسجيل الدخول، وفتح المحرر المتقدم، والحفظ لكل سلسلة.
- يستخدم TranslatePress محررًا مرئيًا للواجهة الأمامية. تنقر على سلسلة في الصفحة وتعدلها مباشرةً. يحب المستخدمون غير التقنيين هذا، لكنه لا يتوسع لمئات الصفحات.
لا تحمي أي من هذه الإضافات الثلاثة العناصر النائبة (placeholders) أو رموز الكود (code tokens) افتراضيًا. إذا قمت بتشغيل الترجمة التلقائية عبر سلاسلك، فستظل تحصل على نفس تلف %s، وتكسر علامات HTML، وأخطاء صيغ الجمع التي تعاني منها الترجمة الآلية الخام. يتعمق دليلنا حول الترجمة اليدوية مقابل الترجمة بالذكاء الاصطناعي لـ WordPress في مفاضلات السلامة.
البديل الخفي: ملفات .mo الثابتة (بدون إضافة)
يأتي كل قالب وإضافة WordPress مع ملفات قالب .pot . يتم قراءة ملف .po مترجم بشكل صحيح، ومحول إلى .mo ووضعه في wp-content/languages/، مرة واحدة لكل تحميل صفحة بواسطة نواة WordPress - بدون أي استعلامات إضافية لقاعدة البيانات، وبدون أي عبء إضافي للإضافة، ومع توافق كامل مع شبكة CDN.
هذه هي الطريقة التي استخدمها مجتمع نواة WordPress لترجمة WordPress نفسه إلى أكثر من 70 لغة على مدار 20 عامًا. إنها سريعة ومستقرة، ولا تربطك بأي نظام بيئي لمورد معين.
السبب الوحيد الذي يجعل معظم أصحاب المواقع يستخدمون الإضافات بدلاً من ذلك هو أن ترجمة ملفات .po يدويًا مرهقة - تفتح Poedit، تترجم 2000 سلسلة يدويًا، وتأمل ألا تكون قد كسرت عنصرًا نائبًا. تزيل أدوات الترجمة السحابية هذا الحاجز تمامًا. حمّل .po، نزّل ملفات .po + .mo المترجمة، ضعها في wp-content/languages/themes/your-theme-es_ES.mo، وتم الأمر.
لا يوجد ترخيص إضافة. لا عقوبة على الأداء. لا يوجد حصر على بائع معين. إذا تم تحديث القالب وأضيفت سلاسل جديدة، فقم بترجمة ملف .pot الجديد وإعادة نشر ملف .mo المحدث.
يعمل هذا النهج بشكل رائع للمحتوى الموجود في الكود (واجهة مستخدم القالب، سلاسل الإضافات، رسائل الخطأ، تسميات الأزرار). بالنسبة للمحتوى الموجود في قاعدة البيانات (المنشورات، الصفحات، أوصاف المنتجات)، لا تزال بحاجة إلى إضافة أو سير عمل يدوي لتكرار المنشورات. تجمع العديد من الفرق بين الاثنين: ملفات .mo الثابتة لواجهة المستخدم، وWPML أو Polylang للمحتوى. النتيجة أسرع وأرخص وأكثر قابلية للصيانة من الاعتماد على إضافة واحدة فقط.
متى تختار أي نهج
دليل قرار سريع بناءً على نوع المشروع:
- مدونة صغيرة، 2-3 لغات، محتوى واجهة مستخدم في الغالب: ملفات
.moثابتة. تخطى الإضافة. - موقع غني بالمحتوى، فريق تحرير، العديد من المنشورات: Polylang أو WPML. اختر Polylang إذا كنت تحتاج إلى نقطة انطلاق مجانية وميزات Business لاحقًا؛ اختر WPML إذا كنت تحتاج إلى أنواع منشورات مخصصة وتصنيفات متعددة اللغات على نطاق واسع.
- سير عمل التحرير المرئي للمستخدمين غير التقنيين: TranslatePress، ولكن اقبل التنازل عن الأداء وتجنبه في متاجر WooCommerce ذات الزيارات العالية.
- متجر WooCommerce بكتالوج كبير: WPML Multilingual CMS بالإضافة إلى ملفات
.moلواجهة مستخدم القالب. Polylang Business يعمل أيضًا. - وكالة تدير أكثر من 20 موقعًا لعملائها: انقل أكبر قدر ممكن من الترجمة إلى ملفات
.mo. راجع سير عمل التوطين المثالي للوكالات الخاص بنا للحصول على البنية الكاملة.
تجميع كل ذلك معًا
تعد Polylang وWPML وTranslatePress جميعها أدوات مشروعة. كل منها لديه مستخدمون حقيقيون يقومون بنشر مواقع متعددة اللغات بنجاح. الخطأ هو معاملتها كبدائل قابلة للتبديل واختيار واحدة بناءً على جدول مقارنة. إنها بنيات مختلفة جوهريًا بسقوف أداء مختلفة وسير عمل للمحتوى.
السؤال الأعمق الذي لا يطرحه معظم أصحاب المواقع أبدًا هو ما إذا كانوا بحاجة إلى إضافة ترجمة على الإطلاق. يعيش جزء كبير مما تترجمه هذه الإضافات - تسميات الأزرار، رسائل الخطأ، واجهة مستخدم القالب، سلاسل الدفع - في ملفات .po التي يمكن لنواة WordPress قراءتها أصلاً. ترجمة تلك الملفات مرة واحدة ووضع ملف .mo المترجم في wp-content/languages/ يلغي فئة كاملة من الأعباء الإضافية للإضافات، وتجديد التراخيص، ومشكلات الأداء.
هل أنت مستعد لترجمة ملفات
.poالخاصة بـ WordPress دون إضافة إضافة أخرى إلى حزمتك؟ جرب SimplePoTranslate مجانًا - لا يلزم وجود بطاقة ائتمان. حمّل.po، نزّل ملفات.po+.moالمترجمة، ثم انشرها.