تصميم قالب Odoo عربي احترافي: دليل RTL والقوالب المخصصة

ياسر نجيب
•
•
آخر مراجعة:
•
7 دقائق قراءة

القالب العربي الجيد في Odoo ليس نسخة إنجليزية عُكست في نهاية المشروع. هو نظام واجهة يبدأ من بنية المحتوى العربي، ويحافظ في الوقت نفسه على إمكانات Website Builder والتجارة الإلكترونية والترجمة والترقية.

يمكن كتابة CSS كثير يجعل الصفحة الرئيسية جميلة في لقطة واحدة. الأصعب هو أن يظل الموقع قابلاً للتحرير من فريق المحتوى، وأن تعمل صفحة المنتج والسلة والبحث والنماذج في العربية والإنجليزية، وألا يتحول كل تحديث Odoo إلى مشروع إنقاذ.

سأشرح هنا طريقة بناء قالب مخصص على Odoo 19، مع التركيز على القرارات التي تجعل القالب منتجاً قابلاً للصيانة لا مجرد واجهة ثابتة.

متى تحتاج قالباً مخصصاً؟

ابدأ بما يقدمه محرر Odoo القياسي. يمكن ضبط الألوان والخطوط وأنماط العناوين والأزرار واستخدام building blocks دون تطوير قالب كامل. هذا مناسب عندما تكون هوية العلامة قابلة للتمثيل بخيارات القالب الحالية.

يصبح القالب المخصص منطقياً عندما تحتاج واحداً أو أكثر من الآتي:

  • نظام ألوان ومسافات ومكونات يختلف فعلياً عن الخيارات المتاحة.
  • مقتطفات قابلة للتحرير تعكس نوع المحتوى أو المنتج الخاص بالشركة.
  • تجربة متجر عربية تتطلب بطاقات وفلاتر وتفاصيل منتج مصممة للسوق المستهدف.
  • عدة مواقع أو presets تشترك في قاعدة تصميم مع اختلافات محسوبة.
  • سلوك تفاعلي مخصص يجب تحميله ضمن أصول Odoo لا عبر سكربتات متناثرة.
  • تسليم يمكن تثبيته واختباره وترقيته كوحدة مستقلة.

أما إذا كان المطلوب تغيير خط ولون وزر، فإعدادات Website Builder أقل تكلفة وأكثر أماناً من قالب جديد.

القالب في Odoo هو Module

توضح وثائق Odoo أن قالب الموقع وحدة لها manifest وبيانات وعروض وأصول. بنية عملية قد تبدو هكذا:

theme_arabic_brand/
├── __init__.py
├── __manifest__.py
├── data/
│   ├── presets.xml
│   └── pages.xml
├── views/
│   ├── layout.xml
│   └── snippets/
├── static/src/
│   ├── scss/
│   ├── js/
│   └── img/
└── i18n/

هذه البنية تفصل مسؤوليات واضحة:

  • data/ يهيئ الخيارات والصفحات أو القيم الافتراضية.
  • views/ يحتوي امتدادات QWeb والمقتطفات.
  • static/src/ يحتوي SCSS و JavaScript والصور.
  • i18n/ يحتفظ بالترجمات الناتجة والمراجعة.

لا تعدّل ملفات website أو web الأساسية. استخدم الوراثة و XPath والأصول المعلنة في الوحدة. تعديل core قد يبدو أسرع اليوم، لكنه يجعل المقارنة والترقية وإعادة التثبيت أكثر صعوبة.

ابدأ بنظام تصميم صغير

قبل كتابة صفحة، حدد tokens التي ستتكرر:

  • ألوان العلامة والأسطح والنصوص والحالات.
  • خط عربي وخط لاتيني مع أوزان فعلية متاحة.
  • مقياس للمسافات بدلاً من قيم عشوائية لكل عنصر.
  • نصف قطر الحدود والظلال.
  • أحجام العناوين والنصوص وأسطر القراءة.
  • سلوك التركيز ولوحة المفاتيح والحركة المخفضة.

في Odoo يمكن ربط كثير من هذه القرارات بمتغيرات القالب و Bootstrap، ثم إضافة SCSS الخاص بالعلامة. مثال مبسط داخل manifest:

"assets": {
    "web.assets_frontend": [
        "theme_arabic_brand/static/src/scss/theme.scss",
        "theme_arabic_brand/static/src/js/theme.js",
    ],
}

لا تضع كل ملف في web.assets_frontend تلقائياً. يحتاج Website Builder إلى أصول خاصة بوضع التحرير، وقد تحتاج المقتطفات إلى ملفات منفصلة. تحميل JavaScript غير مستخدم في كل صفحة يبطئ الموقع بلا فائدة.

RTL قرار بنيوي

العربية لا تعني direction: rtl فقط. اختبر هذه الطبقات من البداية:

  1. تسلسل المحتوى: ما الذي يراه القارئ أولاً؟ ترتيب النص والصورة قد يحتاج قراراً مختلفاً عن الإنجليزية.
  2. المحاذاة: استخدم text-align: start عندما يكون المقصود بداية السطر، لا right في كل مكان.
  3. المسافات: استخدم الخصائص المنطقية مثل margin-inline-start وpadding-inline-end.
  4. الأيقونات: أسهم الرجوع والتقدم والـ breadcrumb تحتاج اتجاه معنى، لا قلباً آلياً لكل SVG.
  5. النص المختلط: أسماء المنتجات والرموز والأسعار والهواتف تحتاج dir="auto" أو <bdi> في المواضع المناسبة.
  6. النماذج: موضع label ورسالة الخطأ وأيقونة الحقل وتسلسل التركيز يجب أن يعمل بلوحة المفاتيح.
  7. المتجر: السعر والعملة والكمية والخصم والتوفر تحتاج اختباراً مستقلاً، خصوصاً عند خلط العربية والأرقام اللاتينية.

نسخ CSS كامل تحت محدد [dir="rtl"] علامة تحذير. الأفضل أن تكون القاعدة الأساسية مرنة، ثم تضيف استثناءات RTL فقط عندما يختلف المعنى أو التكوين فعلاً.

صمم مقتطفات قابلة للتحرير

Building blocks أو snippets هي ما يسمح لفريق المحتوى ببناء الصفحات. القالب الاحترافي لا يحول كل تعديل نصي إلى طلب للمطور.

كل مقتطف يحتاج إجابات واضحة:

  • ما الحقول التي يستطيع المحرر تغييرها؟
  • ماذا يحدث عند عنوان طويل؟
  • هل الصورة إلزامية؟ وما نسبة أبعادها؟
  • هل يمكن إخفاء الزر؟
  • كيف تظهر الحالة دون محتوى؟
  • هل يعمل المقتطف داخل أكثر من موقع؟
  • ماذا يرى الزائر في العربية والإنجليزية؟

توضح وثائق Odoo أن ملفات المقتطفات تعيش عادةً تحت views/snippets/، بينما توضع أصولها تحت static/src/snippets/. وجود المقتطف في المحرر ليس نهاية الاختبار؛ يجب سحبه إلى صفحة، تعديل خياراته، حفظ الصفحة، ثم فتحها كزائر مجهول.

لا تجعل الصفحة الرئيسية كل القالب

تظهر جودة قالب التجارة الإلكترونية في المسارات التي يتجاهلها العرض الأول:

  • قائمة المنتجات والفلاتر والفرز.
  • صفحة منتج باسم طويل وصور متعددة وخيارات variants.
  • حالة منتج غير متوفر.
  • السلة والقسائم والضرائب والشحن.
  • تسجيل الدخول وحساب العميل والطلبات السابقة.
  • نتائج البحث الفارغة.
  • رسائل الخطأ والتحقق في النماذج.

قد تبدو hero جميلة بينما زر الشراء غير واضح على الهاتف أو يختفي اسم variant في RTL. لذلك أبني مصفوفة شاشات قبل التصميم، لا بعده.

الأداء: افهم حزم الأصول

يعالج Odoo ملفات JavaScript و CSS أو SCSS ويجمعها ويصغرها، ويعطي الأصول checksum يسمح بالتخزين المؤقت الطويل. هذه ميزة، لكنها لا تعني أن الحجم غير مهم.

قواعد عملية:

  • لا تحمل مكتبة كبيرة لتأثير واحد يمكن تنفيذه بواجهة المتصفح.
  • استخدم صوراً بالأبعاد الفعلية وصيغ مناسبة، ولا تضع صورة أصلية ضخمة في بطاقة صغيرة.
  • اجعل الحركة تعتمد على transform وopacity قدر الإمكان.
  • اختبر prefers-reduced-motion للحركات غير الضرورية.
  • لا تكرر ملفات الخط أو الأيقونات التي يوفرها النظام بالفعل.
  • افتح debug=assets عند تشخيص الترتيب، ثم اختبر النسخة المجمعة أيضاً.
  • افحص Network و Coverage، لا تعتمد على الإحساس بأن الصفحة «خفيفة».

الترجمة ليست استبدال نص فقط

يجب أن تكون بنية QWeb قابلة للاستخراج والترجمة، وأن لا تُلصق الكلمات داخل JavaScript أو صور لا يمكن تعديلها. راجع النصوص العربية يدوياً بعد التصدير، لأن السياق يغير الترجمة.

لكل لغة افحص:

  • عنوان الصفحة ووصفها القانوني canonical.
  • الروابط الداخلية ومبدل اللغة.
  • القوائم والفئات والمنتجات.
  • رسائل التحقق والخطأ.
  • البريد الناتج من النماذج والطلبات.
  • البيانات المنظمة عند استخدامها.

لا تفترض أن ترجمة الصفحة الرئيسية تعني أن checkout مترجم.

الوصول قبل الزينة

القالب جزء من واجهة عمل، لذلك يجب أن يحافظ على HTML الدلالي:

  • عنوان رئيسي واحد واضح لكل صفحة.
  • أزرار للإجراءات وروابط للتنقل.
  • أسماء قابلة للوصول للأيقونات التفاعلية.
  • تباين مقروء للنص والحالات.
  • focus مرئي.
  • ترتيب منطقي بلوحة المفاتيح.
  • نص بديل مناسب للصور التي تحمل معنى.
  • عدم وضع معلومات مهمة في اللون وحده.

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

مصفوفة الاختبار التي أستخدمها

قبل التسليم أراجع القالب في حالات ممثلة:

البعدالحالات
اللغةالعربية، الإنجليزية، ونص مختلط
العرضهاتف ضيق، هاتف شائع، جهاز متوسط، سطح مكتب
المستخدمزائر، عميل مسجل، محرر Website
المحتوىقصير، طويل، فارغ، صورة مفقودة
المتجرمتوفر، غير متوفر، variants، سلة، checkout
الحالةتحميل، نجاح، خطأ، disabled، validation

أضيف إلى ذلك تثبيتاً نظيفاً للقالب، ثم upgrade للوحدة على قاعدة اختبار. صفحة تعمل في قاعدة المطور القديمة قد تعتمد على record أو asset بقي من تجربة سابقة.

ما يجب أن يتسلمه صاحب الموقع

التسليم الجيد لا يقتصر على ZIP:

  • كود الوحدة بإصدار واضح.
  • قائمة إصدارات Odoo المدعومة.
  • خطوات التثبيت والترقية والإزالة الآمنة.
  • قائمة المقتطفات وخياراتها.
  • دليل مختصر للمحرر.
  • خريطة الخطوط والألوان والصور.
  • نتائج الاختبار وأي قيود معروفة.
  • توضيح ما إذا كان القالب يعتمد على Enterprise أو وحدات أخرى.
  • سياسة دعم عند تغير نسخة Odoo.

ما الذي يجب تسليمه؟

قالب Odoo العربي الاحترافي يجمع ثلاثة أشياء: هوية بصرية مميزة، أدوات تحرير يفهمها فريق المحتوى، وبنية تقنية تحترم Odoo بدلاً من الالتفاف حوله.

ابدأ من RTL والمحتوى الحقيقي ومسارات المتجر، ثم ابن tokens ومقتطفات قابلة للتحرير، وحمّل أقل قدر ضروري من الأصول. النتيجة ليست صفحة أجمل فقط؛ هي موقع يستطيع الفريق تشغيله وتطويره دون أن يفقد قابليته للترقية.

المراجع الرسمية

اقرأ أيضاً