شرح Polylang 2026: إعداد موقع WordPress متعدد اللغات خطوة بخطوة

Polylang من أشهر الطرق لبناء موقع WordPress متعدد اللغات مع الاحتفاظ بمحتوى مستقل لكل لغة داخل WordPress. الفكرة ليست أن الإضافة «تترجم كل شيء تلقائيًا»، بل أنها تضيف طبقة Language Management: تحدد لغة كل محتوى، تربط النسخ المترجمة ببعضها، وتعرض Language Switcher للمستخدم.

الخلاصة التنفيذية: استخدم Polylang عندما تريد إدارة نسخ عربية وإنجليزية أوأكثر داخل WordPress بطريقة واضحة. اضبط اللغات وURL structure أولًا، ثم اربط المقالات والصفحات والتصنيفات، وبعدها أضف Language Switcher واختبر hreflang وCanonical وSitemap. لمتاجر WooCommerce، قيّم Polylang for WooCommerce بدل افتراض أن النسخة الأساسية وحدها تكفي.

إذا كنت ما زلت في مرحلة اختيار Architecture، ابدأ من دليل ترجمة WordPress متعدد اللغات وSEO. وإذا كنت تقارن Polylang مع WPML وTranslatePress وGTranslate وWeglot، راجع مقارنة إضافات ترجمة WordPress 2026.

ما هي Polylang وكيف تعمل؟

Polylang تضيف مفهوم اللغة إلى المحتوى داخل WordPress. بدل أن تكون الصفحة «صفحة واحدة تتغير لغتها آليًا»، يكون لديك محتوى مستقل لكل لغة مع علاقة Translation تربط النسخ ببعضها.

وفق الصفحة الرسمية الحالية، الإضافة توفر Setup Wizard عند التفعيل، وتدعم Language Switcher، وتدير لغات Posts وPages وCategories وTags وCustom taxonomies بحسب الإعداد.

قبل تثبيت Polylang: حدد هذه القرارات

• ما اللغات التي ستدعمها فعلًا؟
• ما اللغة الافتراضية؟
• هل ستستخدم Subdirectories مثل /ar/ و/en/؟
• هل تريد إظهار Language code للغة الافتراضية؟
• هل المحتوى سيترجم يدويًا أمبمساعدة AI/خدمة خارجية؟
• هل لديك WooCommerce؟
• هل تستخدم Custom Post Types أوACF أوPage Builder؟

هذه القرارات أهم من شكل زر تبديل اللغة.

تثبيت Polylang

1. من WordPress افتح Plugins → Add New.
2. ابحث عن Polylang.
3. ثبّت الإضافة وفعّلها.
4. سيظهر Setup Wizard لمساعدتك في الإعداد الأولي.

لا تعتمد على Screenshots قديمة لأن واجهة WordPress وPolylang تتغير مع الإصدارات. اتبع أسماء الأقسام الحالية داخل لوحة التحكم ووثائق الإضافة الرسمية.

الخطوة 1: إضافة اللغات

من Languages → Languages أضف اللغة المطلوبة. عند اختيار لغة معروفة، تضبط Polylang بياناتها الأساسية مثل:

• Name.
• Locale مثل ar أوen_US بحسب اللغة.
• Language code.
• Text direction RTL/LTR.
• ترتيب ظهورها في Language Switcher.

الوثائق الحالية تشير إلى وجود عدد كبير من اللغات المعرفة مسبقًا، مع إمكانية إضافة لغة مخصصة إذا احتجت.

الخطوة 2: اختيار اللغة الافتراضية

حدد اللغة الأساسية للمحتوى الحالي. هذه الخطوة مهمة جدًا لموقع قائم؛ اختيار لغة خاطئة ثم محاولة إعادة توزيع مئات الصفحات لاحقًا يخلق عملًا إضافيًا ومخاطر روابط.

قبل تنفيذ Polylang على موقع كبير:

• خذ Backup.
• جرّب على Staging.
• احصر المحتوى الحالي.
• حدد اللغة الفعلية لكل نوع محتوى.

الخطوة 3: URL structure

في إعدادات URL modifications حدد كيف تظهر اللغة في الروابط. بنية شائعة:

• example.com/ar/page/
• example.com/en/page/

تجنب تغيير URL structure عدة مرات بعد الفهرسة. أي تغيير URL منشور يحتاج Redirects واختبار روابط داخلية وSitemap.

هل أخفي اللغة الافتراضية من URL؟

يمكن أن تختار بنية تظهر Code لكل اللغات أولا. المهم هو الثبات والوضوح. لا يوجد مكسب SEO سحري من إخفاء أوإظهار Code وحده.

الخطوة 4: ترجمة المقالات والصفحات

بعد إضافة اللغات، تظهر Controls تربط المحتوى بالنسخ المترجمة. Workflow الأساسي:

1. افتح المقال أوالصفحة الأصلية.
2. حدد لغتها الصحيحة.
3. أنشئ النسخة للغة الثانية.
4. اكتب الترجمة الفعلية.
5. تأكد أن النسختين مرتبطتان كTranslations.
6. راجع Title وMeta وInternal links لكل لغة.

لا تنسخ النص الأصلي إلى صفحة لغة ثانية وتتركه بلا ترجمة. وجود URL باللغة الثانية لا يجعل المحتوى متعدد اللغات إذا ظل النص بلغة أخرى.

الخطوة 5: ترجمة Categories وTags وTaxonomies

الموقع متعدد اللغات يحتاج Taxonomy مقابلة لكل لغة. مثال:

• العربية: «أخبار ووردبريس».
• الإنجليزية: «WordPress News».

اربط النسختين كترجمة لنفس المفهوم، ثم تأكد أن المقال الإنجليزي مرتبط بالتصنيف الإنجليزي وليس العربي.

Custom Taxonomies

إذا Theme أوPlugin تضيف Brands أوPortfolio Categories أوTaxonomies خاصة، تحقق أنها مفعلة للترجمة قبل بدء المحتوى.

الخطوة 6: ترجمة Strings

منطقة String translations تستخدم للنصوص المسجلة التي لا تُدار كمقال أوصفحة، مثل بعض إعدادات الموقع أوالنصوص التي تسجلها القوالب والإضافات.

لكن لا تخلط بين Polylang وبين أداة Localization مثل Loco Translate. إذا كان النص داخل ملفات Theme/Plugin ولم يُسجّل ضمن Polylang، قد تحتاج Workflow ترجمة Gettext منفصل.

للتعريب التقني للقوالب راجع دليل Loco Translate وRTL.

الخطوة 7: Language Switcher

Polylang توفر مبدل لغة بعدة طرق. الوثائق الحالية تذكر إمكانية إضافته إلى Navigation، واستخدام Blocks في البيئات المدعومة، كما يوجد Template function للمطورين.

سلوك مهم يجب فهمه

وفق وثائق Polylang الحالية، إذا الصفحة الحالية لا تملك ترجمة للغة معينة، قد يتجه Language Switcher إلى الصفحة الرئيسية في تلك اللغة بحسب الإعداد والسياق. لذلك اختبر الصفحات المهمة واحدة واحدة.

أفضل ممارسة

• إذا هناك نسخة مترجمة للصفحة الحالية، اربط إليها مباشرة.
• لا ترسل المستخدم إلى Home بدون سبب.
• أخفِ اللغة التي لا يوجد لها محتوى إذا كان ذلك أوضح.
• اختبر Desktop وMobile.

الخطوة 8: القوائم Menus

في المواقع التي تستخدم Classic Menus، قد تحتاج Menu مستقلة لكل لغة حسب Theme والConfiguration. في Block Themes/Navigation Blocks قد تختلف طريقة الإدارة.

لا تنس ترجمة:

• Menu labels.
• Custom links.
• CTA.
• Footer navigation.

الخطوة 9: الصور والMedia

قرار ترجمة Media metadata يعتمد على المشروع. لا تحتاج Duplicate لكل صورة لمجرد وجود لغة ثانية إذا الصورة نفسها مناسبة للجميع.

قد تحتاج ترجمة:

• Alt text عندما يحمل معنى لغويًا.
• Caption.
• Title/description عند استخدامهما فعليًا.

أما Logo أوProduct image نفسها فقد تبقى مشتركة ما لم تحتوي نصًا داخل الصورة.

Polylang وRTL

اللغة العربية تستخدم RTL. Polylang تعرف اتجاه اللغة، لكن نجاح Layout يعتمد على Theme وPlugins أيضًا.

اختبر:

• Header.
• Navigation.
• Forms.
• Tables.
• Breadcrumbs.
• Page Builder sections.
• WooCommerce إذا كان موجودًا.

SEO مع Polylang

نجاح SEO متعدد اللغات لا يأتي من تثبيت Plugin فقط. راجع لكل لغة:

• URL مستقلة.
• Self-canonical.
• hreflang صحيح ومتبادل.
• Title وMeta مناسبين للغة.
• H1 ومحتوى فعلي باللغة المستهدفة.
• Internal links للنسخ المناسبة.
• Sitemap.
• عدم وجود noindex غير مقصود.

لا تترجم Keyword حرفيًا

نفّذ Search Intent لكل لغة. مثال: المصطلح الأكثر استخدامًا بالعربية قد لا يكون الترجمة الحرفية للعبارة الإنجليزية.

Canonical وhreflang

لا تجعل الصفحة الإنجليزية Canonical إلى العربية لمجرد أنهما نفس الموضوع. إذا كل نسخة مترجمة ومفيدة، المعتاد أن تكون Self-canonical مع hreflang يربط النسخ.

راجع تفاصيل Architecture في دليل SEO متعدد اللغات.

ماذا عن اكتشاف لغة المتصفح؟

بعض الإعدادات أوExtensions قد تسمح باكتشاف لغة المتصفح. استخدم ذلك بحذر.

لا تجعل المستخدم غير قادر على الوصول إلى لغة أخرى، ولا تعتمد على Redirect مغلق يمنع Search Engine من اكتشاف النسخ. الأفضل Language Switcher واضح مع اقتراح اختياري للغة.

Polylang وWooCommerce

إذا لديك متجر، لا تفترض أن Polylang الأساسية وحدها هي التكامل التجاري الكامل. هناك منتج مخصص باسم Polylang for WooCommerce للتعامل مع عناصر المتجر ومزامنة البيانات المرتبطة.

لمتجر فعلي، راجع دليل WooCommerce متعدد اللغات واختبر المنتجات والتصنيفات والVariations وCart وCheckout وEmails.

Polylang وPage Builders

إذا تستخدم Elementor أويشبهه، عادة ستدير نسخة Content مستقلة لكل لغة. اختبر:

• Templates.
• Global widgets.
• Dynamic fields.
• Forms.
• Popups.
• Header/Footer templates.

التوافق النظري لا يغني عن اختبار Staging على نفس Stack.

Polylang المجانية vs Pro

لا أنشر جدول أسعار ثابتًا لأن الباقات والخصائص تتغير. الأفضل مراجعة الموقع الرسمي قبل الشراء.

عمليًا اسأل:

• هل تحتاج ترجمة Slugs؟
• هل تحتاج Workflow متقدم؟
• هل تحتاج WooCommerce integration؟
• هل تحتاج DeepL/Automatic Translation عبر إضافات أوتكاملات؟
• هل تحتاج دعمًا تجاريًا؟

أخطاء شائعة عند استخدام Polylang

• تثبيت الإضافة على Production بدون Backup.
• اختيار اللغة الافتراضية خطأ.
• إنشاء URL للغة الثانية بدون ترجمة المحتوى.
• نسيان Categories وTags.
• ترك Internal links تعيد المستخدم للغة الأصلية.
• عدم ترجمة SEO metadata.
• تغيير URL structure بعد الفهرسة بدون Redirects.
• استخدام Browser redirect بطريقة تمنع الوصول للنسخ الأخرى.
• افتراض أن WooCommerce يعمل بالكامل بنفس إعداد Blog عادي.

Checklist بعد الإعداد

• كل صفحة لها Language صحيحة.
• النسخ المترجمة مرتبطة ببعضها.
• Language Switcher يصل إلى الصفحة المقابلة.
• Categories وTaxonomies مترجمة.
• Menus تعمل بكل لغة.
• RTL سليم.
• Canonical وhreflang صحيحان.
• Sitemap تشمل النسخ المناسبة.
• لا يوجد noindex غير مقصود.
• Mobile UX سليمة.

أسئلة شائعة

هل Polylang تترجم المحتوى تلقائيًا؟

وظيفتها الأساسية إدارة اللغات وربط النسخ. Automatic Translation قد يتم عبر حلول أوتكاملات إضافية حسب Workflow الذي تختاره.

هل يمكن استخدام Polylang مجانًا؟

نعم توجد نسخة مجانية على WordPress.org، مع خصائص إضافية ومنتجات تجارية منفصلة حسب الحاجة.

هل Polylang مناسبة للعربية؟

نعم تدعم لغات RTL، لكن يجب أن يكون Theme وPlugins نفسها متوافقة مع RTL.

هل Polylang مناسبة لـWooCommerce؟

يوجد تكامل مخصص باسم Polylang for WooCommerce. لا تعامل النسخة الأساسية كأنها تكفي تلقائيًا لكل منطق المتجر.

ماذا يحدث إذا الصفحة غير مترجمة؟

سلوك Language Switcher يعتمد على الإعداد. الوثائق الحالية تذكر أنه قد يربط إلى Home للغة الأخرى إذا لا توجد ترجمة للصفحة، ويمكن ضبط إخفاء اللغات التي لا توجد لها Translation في بعض السيناريوهات.

الخلاصة

Polylang خيار قوي عندما تريد إدارة موقع WordPress متعدد اللغات بمحتوى مستقل لكل لغة. نجاح التنفيذ يعتمد على التخطيط: لغة افتراضية صحيحة، URL ثابتة، ترجمة Taxonomies وMenus، وربط النسخ وSEO بصورة سليمة.

لا تبدأ من زر Language Switcher؛ ابدأ من Architecture، ثم طبّق Polylang كأداة إدارة لهذا الـArchitecture.