قبل أن يقرأ العميل الإماراتي أول كلمة يكتبها روبوت المحادثة، تكون الواجهة قد أخبرته بكل شيء. اتجاه فقاعة الرسالة، موضع سهم الإرسال، تناسق الأرقام مع النص العربي، خط مبتور. هذه التفاصيل ليست جماليات، بل رسالة صامتة تقول إن الشركة صمّمت الروبوت لسوق آخر ثم أضافت العربية لاحقاً.
تصميم واجهة عربية للروبوت لا يبدأ من الألوان ولا من كتابة الردود. يبدأ من قرار معماري يتخذه فريق التطوير في اليوم الأول: هل الواجهة مبنية RTL أصلاً، أم أن dir="rtl" مجرّد لصقة فوق تصميم LTR؟ هذه المقالة تكشف الأخطاء التي تُفسد تجربة العميل الإماراتي قبل أن تبدأ المحادثة.
أهم النقاط
- دعم RTL إعادة تصميم كامل وليس خاصية CSS واحدة — يشمل عكس التخطيط بالكامل: فقاعات المحادثة، شريط الأدوات، الأسهم، والهوامش المحسوبة منطقياً لا بصرياً، إضافة إلى عرض الأرقام كما يكتبها السوق ومعالجة النصوص المختلطة. دعم اللغة العربية نصياً لا يعني تلقائياً أن بنية الواجهة أصبحت RTL.
- الأخطاء الأخطر تمر دون ملاحظة حتى من فريق عربي متحدث — الفحص البصري الداخلي لا يكفي لأن الفريق يقرأ الواجهة بعين متسامحة. المستخدم الحقيقي يحكم خلال ثوانٍ عند رؤية فقاعة أو سهم في الاتجاه الخاطئ، ولا يعود عن هذا الحكم.
- خلط العربية والإنجليزية في رسالة واحدة يحتاج unicode-bidi لا التخمين — مثال المقالة: جملة مثل حجز موعد يوم 15/09 الساعة 3 pm تنقلب فيها مواضع الأرقام والكلمات الإنجليزية داخل السياق العربي دون معالجة unicode-bidi، فتصبح مضلّلة للقارئ.
- إضافة RTL لاحقاً أصعب وأبطأ من بنائه في الهيكل منذ البداية — البناء الأصلي يعني كتابة CSS مرة واحدة باستخدام الخصائص المنطقية. الإضافة اللاحقة تعني مراجعة كل قاعدة CSS واختبار كل مكوّن مرتين وإعادة تصميم الأيقونات يدوياً، وهو فرق يُقاس بأسابيع في مشروع متوسط.
- الاختبار مع متحدثين أصليين عبر واتساب هو المقياس الحقيقي — بعض عناصر التنسيق التي تعمل على الويب لا تنقلها واتساب Business API، وبعض الأخطاء الاتجاهية تظهر فقط داخل الدردشة المدمجة على الجوال، لذا يجب اختبار الروبوت على القناتين معاً.
RTL ليس خاصية CSS واحدة، هو بنية واجهة مختلفة تماماً
الفرق بين دعم RTL السطحي والدعم الحقيقي يظهر لحظة النقر الأولى. إضافة dir="rtl" تعكس اتجاه النص فقط: الحروف تسير من اليمين إلى اليسار، لكن التخطيط يبقى كما هو.
الأزرار في مكانها، الحواف والهوامش في اتجاه LTR، الأيقونات في مواضعها الأصلية. النتيجة واجهة نصفها عربي ونصفها إنجليزي بصرياً. الدعم الحقيقي يعني عكس التخطيط (layout mirroring): فقاعات المحادثة تتبدل، شريط الأدوات ينقلب، الأسهم تعود، والهوامش تُقاس منطقياً لا بصرياً.
الالتباس الثاني بين دعم اللغة العربية النصي ودعم RTL التخطيطي. يمكن للروبوت أن يعرض النص العربي سليماً، بينما تظل بنية الواجهة LTR بالكامل. المفهومان مستقلان، والاعتقاد بأن أحدهما يجرّ الآخر تلقائياً افتراض يُكلّف الشركات الإماراتية أسابيع من إعادة العمل.
يتضاعف هذا في عناصر النموذج. حقل الإدخال يحتاج مؤشراً يبدأ من اليمين، وزر الإرسال يستقر على اليسار لأن نهاية السطر العربية هناك، وفقاعات المحادثة تعكس دور المتحدث. حين يجد المستخدم رسالته على اليسار ورسالة الروبوت على اليمين، يقرأ الواجهة بالمعنى المعكوس.
ينشر معهد الابتكار التكنولوجي في أبوظبي عائلة نماذج Falcon المفتوحة، وعدد منها مدرَّب على بيانات عربية.
الأخطاء التقنية الأكثر شيوعاً في واجهات روبوتات المحادثة العربية

تصوير: Miguel Á. Padriñán عبر Pexels
الخطأ الأول والأكثر انتشاراً: فقاعات المحادثة تظهر على الجانب الخاطئ. القارئ العربي يتوقع رسالته على اليمين ورسائل الروبوت على اليسار، لأن ذلك يعكس محاذاة الكتابة. الواجهات المنقولة عن قوالب إنجليزية تُبقي المواضع الأصلية دون فهم أن الاتجاه انعكس.
الخطأ الثاني بالأيقونات الاتجاهية. سهم الإرسال، أسهم التنقل، أيقونة الرد، سهم الرجوع، هذه العناصر تُعكس مع تغيير الاتجاه. حين تبقى في مواضعها الأصلية تظهر معكوسة منطقياً: يضغط المستخدم على سهم يتّجه يميناً ظاناً أنه يتقدّم، فيعود إلى الوراء.
الخطأ الثالث هو الأخطر تقنياً. اختلاط اتجاهات الأرقام والنصوص في جملة واحدة. حين يكتب المستخدم "أريد حجز موعد يوم 15/09 الساعة 3 pm"، دون معالجة unicode-bidi تنقلب مواضع الأرقام والكلمات الإنجليزية داخل السياق العربي، فتصبح الجملة مضلّلة.
الخطأ الرابع أقل حدةً لكنه يُشعر المستخدم بأن الواجهة ليست له. خطوط لا تدعم العربية، حروف متقاطعة، مسافات غير منتظمة، كلمات مكسورة عند التفاف السطر. الخط ليس تفصيلاً جمالياً في العربية، بل جزء من فهم النص.
تتركز أبحاث النماذج اللغوية العربية في الإمارات لدى جامعة محمد بن زايد للذكاء الاصطناعي في أبوظبي.
كيف تكسر هذه الأخطاء ثقة العميل الإماراتي في اللحظة الأولى
المستخدم الإماراتي لم يعد متسامحاً مع الواجهات العربية المتقطعة. السوق نضج، والعميل يميّز في ثوانٍ بين واجهة صُمّمت له وأخرى فُرضت عليه.
حين يرى فقاعة رسالته على الجانب الخطأ أو سهم إرسال يشير إلى الاتجاه العكسي، لا يقول "الواجهة فيها خلل". يقول "هذه الشركة لم تُصمّم روبوتها لي". هذا الحكم يستغرق ثوانٍ ولا يعود المستخدم عنه.
يتضاعف الأمر مع واقع لغوي محدد في الإمارات. العميل يكتب بالعربية والإنجليزية والعربيزي في رسالة واحدة. الروبوت الذي لا يعالج النصوص المختلطة بمعيار bidi لا يفشل في العرض فحسب، بل في الفهم حين تنعكس مواضع الأرقام وأسماء المنتجات داخل الاستعلام.
القناة الأولى للتواصل في الإمارات هي واتساب، وهذا يضاعف المشكلة. الخلل الذي يبدو محدوداً على الويب يتضخّم داخل واجهات الدردشة على الجوال. تفاصيل هذا الأثر في مقالتنا عن أتمتة خدمة العملاء بالذكاء الاصطناعي للشركات الخليجية.
الانطباع الأول لا يُصحَّح. حين يقرر المستخدم بعد ثلاث ثوانٍ أن الروبوت ليس مبنياً لسوقه، لن تستعيده بردٍّ ذكي أو بعرضٍ ترويجي. الأخطاء البصرية تُغلق المحادثة قبل أن تبدأ.
يتابع تقرير مؤشر الذكاء الاصطناعي من جامعة ستانفورد اتجاهات التبني والتكلفة والقدرات سنة بعد سنة، وهو مرجع مفيد لمراجعة ادعاءات الموردين.
الإعدادات التقنية الصحيحة: HTML وCSS وضبط اتجاه المحادثة
الحل يبدأ من العنصر الجذري لا من النص. ضعوا dir="rtl" وlang="ar" على مستوى الحاوية الأم، وليس على كل حقل أو فقاعة. هذا القرار يُخبر المتصفح بأن السياق كله عربي، فيتعامل مع كل ما بداخله بمنطق RTL افتراضياً.
الخطوة الثانية التخلي عن left وright في CSS، والانتقال إلى الخصائص المنطقية: inline-start وinline-end وpadding-inline-start وmargin-inline-end. تُعكس تلقائياً مع تغيير الاتجاه. بدلاً من كتابة كل قاعدة CSS مرتين، تكتبونها مرة واحدة وتعمل في LTR وRTL معاً.
الخطوة الثالثة معالجة النصوص المختلطة. استخدموا unicode-bidi: isolate على العناصر ذات المحتوى المختلط: اسم منتج إنجليزي داخل جملة عربية، رقم هاتف، أو عبارة عربيزي. تعزل كل مقطع في سياقه الاتجاهي، وتمنع انعكاس الأرقام والكلمات داخل السياق العربي.
الخطوة الرابعة اختيار خطوط تدعم العربية، مثل Cairo وNoto Kufi Arabic وIBM Plex Sans Arabic. الخط وحده لا يكفي: line-height لا يقل عن 1.6، وletter-spacing يبقى صفراً أو سالباً قليلاً لأن العربية لا تحتاج مباعدة اللاتينية. قبل التوقيع، اختبروا العرض على جوال بجملة تحوي كافاً وميماً وعيناً وهاءً متطرفة.
ينشر مركز بيو للأبحاث استطلاعات عن مواقف الجمهور من الذكاء الاصطناعي تستحق القراءة قبل تحديد حجم الإفصاح للعملاء.
الأيقونات والأزرار والأرقام في بيئة RTL: ما الذي يُعكس وما الذي يبقى
القاعدة بسيطة لكنها تُنسى. الأيقونات الاتجاهية تُعكس، والأيقونات الدلالية لا تُعكس.
سهم التنقل، ترتيب القوائم، مؤشر التقدم، سهم الرد، هذه اتجاهية وتُعكس مع RTL. الميكروفون، الإعجاب، القلب، علامة الصح، الكاميرا، هذه دلالية وتبقى كما هي.
الأرقام حالة خاصة في السوق الإماراتي. الوثائق التجارية والفواتير ورقم الرخصة ورقم الهاتف تُكتب بالأرقام الغربية (0123456789). الروبوت الذي يفرض الأرقام الهندية العربية (٠١٢٣٤٥٦٧٨٩) تلقائياً لأنه يعتقد أن ذلك "أصح" يخلق فجوة بين ما يعرضه وما يتعامل معه العميل يومياً.
اعرضوا الأرقام كما يكتبها السوق، لا كما تفترضون أن العربية "يجب" أن تُكتب.
ترتيب شريط الأدوات يخضع لنفس المنطق. القائمة الرئيسية من اليمين، زر الإغلاق إلى اليسار، وشريط التقدم يمتلئ من اليمين إلى اليسار مع تدفق القراءة. مؤشر الكتابة "يكتب الآن..." يظهر جانب فقاعة الروبوت الصحيحة، لا في الموضع الموروث عن التصميم الإنجليزي.
اختبروا هذا على الشاشات الصغيرة أولاً. مشاكل عكس العناصر تختبئ في العرض الواسع وتنكشف على الجوال، حيث كل عنصر في غير موضعه صادم.
وضع هذه العناصر جنباً إلى جنب يوضح الفرق بين ما يجب عكسه وما يبقى ثابتاً في واجهة RTL.
وتضع الوزارة نفسها قواعد حماية المستهلك التي تسري على التواصل البيعي الآلي كما تسري على فريق مبيعات بشري.
| العنصر | الفئة | السلوك في واجهة RTL |
|---|---|---|
| سهم التنقل وسهم الرد وسهم الإرسال | أيقونة اتجاهية | يُعكس مع تغيير الاتجاه |
| الميكروفون والكاميرا وعلامة الصح والإعجاب | أيقونة دلالية | يبقى كما هو دون عكس |
| الأرقام في الفواتير ورقم الهاتف | أرقام غربية (0123456789) | تُعرض كما يكتبها السوق دون فرض الأرقام الهندية العربية |
| القائمة الرئيسية في شريط الأدوات | عنصر تخطيط | تظهر من جهة اليمين |
| زر الإغلاق | عنصر تخطيط | يستقر إلى جهة اليسار |
| شريط التقدم | عنصر تخطيط | يمتلئ من اليمين إلى اليسار |
كيف تختبر تجربة المستخدم العربي قبل إطلاق الروبوت في السوق الإماراتي

تصوير: Christina Morillo عبر Pexels
الفحص البصري من فريق التطوير لا يكفي. حتى الفريق العربي المتحدث سيمرّ على أخطاء لأنه يقرأ الواجهة بعينٍ متسامحة. الاختبار الحقيقي مع مستخدمين خارج الفريق، متحدثين أصليين، لا يعرفون الروبوت مسبقاً.
اجعلوا قائمة تحقق ثابتة قبل كل إطلاق:
- اتجاه فقاعات المحادثة (المستخدم يميناً، الروبوت يساراً).
- انعكاس الأيقونات الاتجاهية دون الدلالية.
- سلوك الإدخال المختلط: جملة عربية تحوي رقماً وكلمة إنجليزية واسم منتج.
- عرض الأرقام بالصيغة الغربية في السياقات التجارية.
- موضع مؤشر النص وسلوك المسح للخلف.
- التفاف الأسطر مع الكلمات الطويلة كالمصطلحات التقنية.
اختبروا الروبوت عبر واتساب Business API إلى جانب الويب. العميل الإماراتي يبدأ محادثته على واتساب غالباً، والفروق حقيقية: بعض عناصر التنسيق التي تعمل على الويب لا تنقلها واتساب، وبعض الأخطاء الاتجاهية تظهر فقط داخل الدردشة المدمجة.
جزء أساسي من الاختبار هو التبديل بين اللغات في المحادثة الواحدة. المستخدم يبدأ بالعربية، يسأل عن سعر بالإنجليزية، يكتب اسم منتج بالعربيزي، ثم يعود إلى العربية. الروبوت الذي ينهار عند هذا التبديل يفشل في نصف السوق، وتفاصيل ذلك في مقالتنا عن الروبوت متعدد اللغات: العربية والإنجليزية والأردية والهندية في محادثة واحدة.
ما الذي تطلبونه من مزوّد الروبوت لضمان تصميم واجهة عربية صحيحة منذ اليوم الأول
قبل التوقيع، اطرحوا هذه الأسئلة على المزوّد. هل الواجهة مصمّمة RTL منذ البداية، أم تُضيفون طبقة RTL على تصميم LTR؟ الإجابة الأولى تعني أسابيع تطوير أقل ومخاطر أقل، والثانية تعني تكلفة الترجمة المعمارية طوال عمر المنتج.
كيف تعالجون النصوص المختلطة؟ إذا لم يذكر المزوّد unicode-bidi و CSS Logical Properties، فدعم RTL لديه سطحي. اطلبوا عرضاً حياً لجملة تحوي عربية وإنجليزية وأرقاماً في سياق واحد.
هل دعم RTL موثّق كمعيار قبول (acceptance criterion) في مرحلة الاستلام، أم أنه سيُعالج "بعد الإطلاق"؟ الإجابة الثانية تعني أن الروبوت سيُطلق بواجهة مكسورة، وأن الإصلاحات ستُدفع كتخصيصات إضافية.
الفرق في الجهد بين البنائين ملموس. بناء RTL أصلاً يعني كتابة CSS مرة واحدة، اختيار مكتبة تدعم الاتجاهين، وتصميم الأيقونات بمنطق الانعكاس. الإضافة اللاحقة تعني مراجعة كل قاعدة CSS، اختبار كل مكوّن مرتين، وإعادة تصميم الأيقونات يدوياً.
للمعايير الكاملة لاختيار روبوت محادثة عربي، راجعوا الدليل الكامل لاختيار روبوت المحادثة العربي وبنائه وتشغيله. وإن كنتم تدرسون حلاً مخصصاً يعالج متطلبات RTL من الأساس، فخدمة تطوير ذكاء اصطناعي مخصص توضّح مسار العمل.
هل واجهة روبوتكم جاهزة للسوق الإماراتي فعلاً؟
إن كنتم غير متأكدين من جودة دعم RTL، أو تخطّطون لبناء روبوت جديد وتريدون تجنّب أخطاء الأشهر الأولى، احجزوا استشارة مع فريق Lenoo AI. نُقيّم الواجهة الحالية، ونُحدد ما يحتاج إصلاحاً قبل أن يراه العميل الإماراتي. المكالمة بلا عرض مبيعات: نستمع، نُشخّص، ونُخبركم بصراحة إن كان الإصلاح يستحق.
الأسئلة الشائعة
ما الفرق بين إضافة dir="rtl" للصفحة وبين تصميم واجهة RTL كاملة لروبوت المحادثة؟
إضافة dir="rtl" تعكس النص فقط دون التخطيط. الواجهة RTL الكاملة تعكس فقاعات المحادثة، والأيقونات الاتجاهية، والهوامش، وشريط الأدوات باستخدام CSS Logical Properties. الفرق هو بين واجهة عربية شكلاً وأخرى مصمّمة للقارئ العربي فعلاً.
هل تدعم منصات روبوتات المحادثة الجاهزة تصميم واجهة عربية بشكل كامل أم تحتاج تخصيصاً إضافياً؟
معظم المنصات الجاهزة توفّر دعماً سطحياً لـ RTL يعكس النص دون التخطيط. المكوّنات والأيقونات ومعالجة النصوص المختلطة تحتاج تخصيصاً يدوياً. اطلبوا عرضاً حياً بجملة تخلط العربية والإنجليزية والأرقام قبل الالتزام.
ما العناصر البصرية التي يجب عكسها في بيئة RTL وما التي تبقى في اتجاهها الأصلي؟
الأيقونات الاتجاهية تُعكس: أسهم التنقل، سهم الإرسال، سهم الرد، شريط التقدم، ترتيب القوائم. الأيقونات الدلالية تبقى: الميكروفون، الكاميرا، الإعجاب، القلب، علامة الصح، الإرفاق. القاعدة: أي أيقونة يحمل شكلها معنى اتجاهياً تُعكس، وأي أيقونة تُمثّل شيئاً محدداً تبقى.
كيف يتعامل روبوت المحادثة مع مستخدم يكتب بالعربية والإنجليزية في رسالة واحدة دون خلط اتجاهي؟
بخاصية unicode-bidi: isolate على العناصر ذات المحتوى المختلط. تعزل كل مقطع في سياقه الاتجاهي، فيبقى النص العربي RTL والإنجليزي والأرقام LTR داخل الجملة نفسها دون انعكاس.
ما قائمة التحقق التي يجب إجراؤها للتأكد من أن واجهة الروبوت العربية سليمة قبل الإطلاق؟
اتجاه فقاعات المحادثة، انعكاس الأيقونات الاتجاهية دون الدلالية، سلوك الإدخال المختلط، عرض الأرقام بالصيغة الغربية في السياقات التجارية، موضع مؤشر النص، التفاف الأسطر، واختبار الأداء على واتساب Business API إلى جانب واجهة الويب. الاختبار يتم مع مستخدمين خارج فريق التطوير، متحدثين أصليين بالعربية.
هل بناء RTL في روبوت المحادثة أصعب تقنياً وأكثر تكلفةً من إضافته لاحقاً على تصميم جاهز؟
العكس هو الصحيح. بناء RTL منذ البداية يعني كتابة CSS مرة واحدة بالخصائص المنطقية واختيار مكوّنات تدعم الاتجاهين.
الإضافة لاحقاً تعني مراجعة كل قاعدة CSS، واختبار كل مكوّن مرتين، وإعادة تصميم الأيقونات يدوياً. الفرق يقاس بأسابيع في مشروع متوسط.