إطلاق SaaS عربي أولًا ويدعم RTL باستخدام Lovable (دليل مؤسسي الشركات الناشئة في الخليج)

دليل GCC خطوة بخطوة لاستخدام Lovable في تصميم وإطلاق منتجات SaaS عربية أولًا وباتجاه RTL باستخدام Lovable: من الهيكلية، إلى إعداد الـ prompts، وReact الداعمة لـ RTL، وقرارات الترجمة والتوطين.

Faisal Karkoh · 10 مايو 2026 · 12 دقائق قراءة

إطلاق SaaS عربي أولًا ويدعم الاتجاه من اليمين إلى اليسار باستخدام Lovable (دليل RTL لمؤسسي الشركات في الخليج)

اعتماد العربية أولًا هو قرار منتجي، وليس مهمة ترجمة متأخرة. يمكن لـ Lovable أن يوفّر SaaS عاملًا في غضون ساعات، لكنه يفترض الإنجليزية والاتجاه من اليسار إلى اليمين افتراضيًا ما لم يُوجَّه صراحةً بعكس ذلك. يقدّم هذا المقال دليلًا عمليًا لاستخدام Lovable لبناء منتجات عربية أولًا تبدو طبيعية لمستخدمي الخليج، ويوضّح أين يمكن دمجه مع مسارات عمل أخرى مثل سباقات نهاية الأسبوع باستخدام Lovable وعمليات الإطلاق بدون وكالات كما في لماذا يجب على مؤسسي الشركات في الخليج التوقف عن انتظار الوكالات.

خلاصة سريعة للمؤسسين

مناسب لـ: المؤسسين غير التقنيين أو ذوي الخلفية التقنية الخفيفة الذين يريدون SaaS عاملًا مبنيًا على React/Supabase بسرعة، ومستعدون لاحقًا لاستثمار جهد إضافي في دعم RTL وتجربة مستخدم عربية وتهيئة الترجمة.

يُفضّل تجنّبه إذا: كانت هناك حاجة من اليوم الأول لتحكّم هندسي عميق وطويل الأجل، أو وُجدت قيود تنظيمية صارمة تجعل الاعتماد على منصات بناء قائمة على الذكاء الاصطناعي المستضاف محفوفًا بالمخاطر.

نقطة القوة الأساسية: يقوم Lovable بتوليد تطبيقات ويب متكاملة انطلاقًا من أوامر بلغة طبيعية (غالبًا باستخدام React مع Supabase في الخلفية)، ويسمح لك بالتعديل والتكرار داخل المتصفح نفسه، ما يجعله مثاليًا لتجارب SaaS قطاعية سريعة في أسواق الخليج. إذا كنت لا تزال تقارن بين الأدوات، راجع مراجعة Lovable لعام 2026 قبل الالتزام.

القيّد الرئيسي: لا يوجد وضع عربي أولًا أو دعم RTL أصيل. كل شيء منحاز افتراضيًا للإنجليزية والاتجاه من اليسار إلى اليمين؛ بنية RTL وبنية التوطين يجب أن يعرّفها الفريق ويطبّقها بصرامة.

لماذا العربية أولًا؟ ولماذا الآن؟

أدوات بناء التطبيقات بالذكاء الاصطناعي مثل Lovable وBolt.new وv0.dev خفّضت بشكل كبير تكلفة الوصول إلى تطبيق عامل. يمكنك وصف المنتج باللغة الطبيعية، ثم تتولى الأداة توليد تطبيق ويب متكامل الطبقات، غالبًا React في الواجهة الأمامية وقاعدة بيانات مُدارة مثل Supabase في الخلفية. بالنسبة لمؤسسي الشركات في الخليج، هذا يعني أن SaaS قطاعي يمكن أن ينتقل من مواصفات على Notion إلى نموذج قابل للاستخدام خلال عطلة نهاية أسبوع، دون الاستعانة بوكالة – وهو ما يتوافق مع الحجّة في لماذا يجب على مؤسسي الخليج التوقف عن انتظار الوكالات ومع نمط “من الفكرة إلى الإطلاق” في From idea to launch in a weekend with Lovable.

المشكلة: هذه الأدوات عمليًا إنجليزية وتعمل باتجاه من اليسار إلى اليمين افتراضيًا. الأمثلة والقوالب والنصوص المولّدة تفترض أنماطًا غربية. في المقابل، كثير من أسواق الخليج والمنطقة الأوسع (MENA) هي عربية أولًا في التشغيل اليومي، خصوصًا خارج أدوات المطورين والشرائح الضيقة في B2B.

ما الذي يعنيه “عربي أولًا” فعليًا؟

بالنسبة للمؤسسين، العربي أولًا ليس مجرّد زر لغة مضاف فوق منتج مبني بالإنجليزية. غالبًا ما يعني:

اللغة: أن تكون النصوص الأساسية لواجهة المستخدم بالعربية، مع سياسة واضحة للنصوص الإنجليزية المضمّنة (أسماء المنتجات، الأكواد، المعرّفات).
الاتجاه: استخدام dir="rtl" على مستوى الإطار العام للتطبيق، مع قرارات مدروسة حول المكوّنات التي تبقى باتجاه LTR.
الطباعة: حزمة خطوط تركّز على العربية أولًا، وأطوال سطور مريحة، وتنسيق بصري مميز للنصوص اللاتينية.
تنسيقات البيانات: التواريخ والمبالغ وأرقام الهواتف وأرقام IBAN والعملات بتنسيقات متوقعة محليًا.
مسارات العمل: شاشات مصمّمة ومحسّنة لمستخدمي التشغيل اليومي الناطقين بالعربية، وليس فقط للإداريين أو التنفيذيين المتمكّنين من الإنجليزية.

تُظهر الأبحاث حول المواقع العربية تكرار مشكلات واضحة عندما تُعامل العربية كتفكير لاحق للترجمة: تخريب في التخطيطات، ارتباك في المزج بين الاتجاهين، وتباينات مزعجة في الطباعة.

هل تحتاج فعلًا إلى “عربي أولًا” في الإصدار الأول (v1)؟

هناك مقايضة حقيقية هنا. نقاشات المجتمعات بين مؤسسي SaaS تُظهر فرقًا استثمرت بقوة في التوطين قبل وجود مستخدمين، ثم خلصت لاحقًا إلى أنها سبقت بالأولوية العمل الخاطئ.

صياغة براغماتية:

غالبًا آمن البدء بالإنجليزية فقط: أدوات المطورين العميقة، تحليلات تقنية، ومسارات عمل B2B ضيقة يكون المستخدمون اليوميون فيها متمكّنين من الإنجليزية ويتوقعون استخدامها.
مخاطرة في تجاهل العربية: التطبيقات الموجهة للمستهلك النهائي، أدوات إدارة الأعمال الصغيرة والمتوسطة، أنظمة المكاتب الخلفية المستخدمة من موظفين ناطقين بالعربية، أو الخدمات القريبة من القطاع الحكومي. هذه غالبًا تصطدم بسقف في التبنّي إذا لم يكن هناك حد أدنى من العربية من اليوم الأول.
مسار وسط: إطلاق “شريحة” عربية رفيعة حول أعلى مسارات العمل استخدامًا (مثل شاشة قائمة الطلبات وتفاصيل الطلب في نظام تجارة خلفي)، مع إبقاء شاشات الإعدادات والإدارة الأقل استخدامًا بالإنجليزية في المرحلة الأولى.

ما الذي يُجيده Lovable – وأين يصعّب عليك دعم العربية

ما يقدّمه Lovable: انطلاقًا من وصف بلغة طبيعية، يولّد Lovable عادةً تطبيق React متكاملًا مع واجهة خلفية تعتمد على Supabase، بما في ذلك نظام الدخول، وشاشات CRUD، والتوجيه، وبعض التنسيقات الأساسية. يقع في نفس فئة “ابنِ تطبيقًا” مثل Bolt.new وReplit Agent وv0.dev.

عدة مقارنات في 2025–2026 تصف Lovable بأنه أسهل اقترابًا للمؤسسين غير التقنيين مقارنةً بأدوات تعتمد على IDE مثل Cursor، وأنه قوي في النمذجة السريعة وضعيف نسبيًا في التعامل مع قواعد شيفرة معقّدة وطويلة العمر. إذا كان هدفك الانتقال من الفكرة إلى منتج حي خلال أيام، يمكن دمج Lovable مع النهج الموضّح في هذا الدليل من Lovable إلى الإنتاج.

نقاط القوة لمؤسسي الشركات في الخليج والمنطقة

السرعة: واجهة الإدارة، ونظام التوثيق، وقاعدة البيانات، والتدفقات الأساسية يمكن إعدادها في ساعات بدلًا من أسابيع، وهو ما يهم كثيرًا عند اختبار شرائح SaaS رأسية.
خفض العتبة التقنية: يمكن للمؤسسين البقاء في نطاق اللغة الطبيعية لوصف الوحدات، ثم تحسينها عبر التعليمات بدلًا من توصيل كل شيء يدويًا.
منصة تقنية مشتركة: مزيج React + Supabase شائع؛ ما يجعل التوظيف أو الانتقال إلى أدوات أخرى لاحقًا أمرًا مباشرًا نسبيًا.

حيث يتعارض Lovable مع استراتيجية "Arabic-first"

انحياز لغوي: التسميات والنصوص المساعدة والرسائل المولَّدة تأتي افتراضيًا بالإنجليزية.
افتراضات في التخطيط: المكوّنات مبنية على أساس اتجاه LTR، مع استخدام CSS لـleft/right غالبًا بدل الخصائص المنطقية.
الأمثلة والقوالب: النموذج العقلي المرجعي هو لوحة تحكم SaaS غربية، وليس مكتبًا خلفيًا في الخليج مصمَّمًا بالعربية أولًا.

حتى أغسطس 2026، لا تسلط مواد التسويق العامة والمقارنات الخاصة بـ Lovable الضوء على أي قدرات Arabic-first أو دعم مخصص لـ RTL؛ فالأمثلة والوثائق المتاحة بسهولة عمليًا إنجليزية أولًا وLTR بشكل افتراضي. يمكن طلب تسميات عربية وdir="rtl" عبر التعليمات، لكن هذا يضيف RTL والتعريب فوق مُولِّد منحاز أصلًا لـ LTR.

خيارات معمارية تجعل دعم RTL أسهل لاحقًا

في كل الأحوال، سيولّد Lovable تطبيق React. السؤال الحاسم هو: هل نُصمِّم لدعم RTL من اليوم الأول، أم نضيفه لاحقًا بتكلفة أعلى؟ تُظهِر الأبحاث حول الواجهات ثنائية الاتجاه أن الأُطر تدعم RTL تقنيًا، لكن العديد من التطبيقات الفعلية تُسيء استخدامه، ما يسبب ارتباكًا. قرارات صغيرة مبكرة تساعد على تجنّب هذه النتيجة.

1. التمسك بمنصة Lovable وإضافة طبقة خفيفة لنظام تصميم

الالتزام بافتراضات Lovable (React + Supabase) يجنبك مقاومة الأداة. فوق ذلك، يمكن إدخال نظام تصميم مصغَّر مبكرًا:

عناصر تخطيط أساسية: <Stack>، <Row>، <Column>، <Page> لاحتواء المسافات والمحاذاة.
مكونات جوهرية: Button، وInput، وSelect، وCard، وTable، وNavbar، وSidebar.
الثيم: مصدر وحيد للحقيقة للطباعة والألوان والمسافات، مع رموز تدرك اتجاه الواجهة.

الهدف العملي هو أن تعتمد تعديلات Lovable على هذه المكونات بدل نشر شيفرات CSS وتخطيطات مخصَّصة في كل مكان.

2. توحيد التحكم في الاتجاه

توصي أبحاث واجهات المستخدم ثنائية الاتجاه بالتحكم المركزي الواضح في الاتجاه بدلًا من استعمال سمات dir عشوائيًا. في تطبيق مولَّد عبر Lovable:

ضبط <html lang="ar" dir="rtl"> على مستوى المستند عندما تكون العربية هي اللغة الأساسية.
استخدام مكوّن تخطيط على المستوى الأعلى (<AppLayout dir={direction}>) يمرّر الاتجاه للأبناء.
توفير قيمة direction داخل الثيم أو السياق (مثلًا "rtl" | "ltr").

هذا يجعل عكس اتجاه مكونات بعينها إلى LTR عند الحاجة أسهل بكثير، بدل محاولة "فرض RTL" على كل شيء.

3. فرض استخدام الخصائص المنطقية في CSS

توصيات خبراء تجربة المستخدم بالعربية تؤكد بقوة على استخدام الخصائص المنطقية مثل margin-inline وpadding-inline بدل margin-left/margin-right. هذا أساسي عندما يكون وكيل البرمجة الرئيسي نموذجًا لغويًا يميل افتراضيًا إلى left/right.

أنماط يُفضّل توحيدها مبكرًا:

المسافات: margin-inline-start، margin-inline-end، padding-inline، وgap في تخطيطات flex وgrid.
التموضع: inset-inline-start، inset-inline-end بدل left/right.
محاذاة النص: استخدام text-align: start/end; قدر الإمكان.

يمكن توثيق هذه الاتفاقيات في ملف CONTRIBUTING.md أو rtl-guidelines.md داخل المستودع، بحيث يمكن لـ Lovable قراءتها واتباعها (جزئيًا) عند إجراء تعديلات.

4. فصل النصوص عن الشيفرة منذ اليوم الأول

توضح دراسات لمواقع عربية مشكلات متكررة حين تتوزع التسميات والنصوص عبر القوالب. في مشروع مبني على Lovable، يمكن أن يتفاقم هذا الأمر: كل إضافة لميزة جديدة قد تدخل المزيد من النصوص المضمّنة في الشيفرة.

لتفادي ذلك:

إضافة طبقة i18n مثل react-i18next أو قاموس بسيط مخصّص حتى إن بدأ التطبيق بلغة واحدة فقط.
تخزين السلاسل العربية المركزية في ملف locales/ar.json.
استخدام المفاتيح في كل مكان في الواجهة (t("invoices.list.title")) بدل نص عربي مضمَّن مباشرة.

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

5. إضافة "حواجز حماية للذكاء الاصطناعي" داخل المستودع

بالنسبة لأداة مثل Lovable، المستودع يمثّل الشيفرة وسياقها في آن واحد. يمكن لمذكرة تصميم قصيرة أن تساعد في توجيه الوكيل:

rtl-guidelines.md يشرح: سياسة الاتجاه، والمكونات التي تبقى LTR، واستخدام الخصائص المنطقية، وقواعد عكس الأيقونات.
copy-guidelines.md يحدد نبرة الكتابة بالعربية، وخيارات المصطلحات، وكيفية التعامل مع أسماء المنتجات أو المعرّفات الإنجليزية.

بعد ذلك يمكن الإشارة إلى هذه الملفات صراحة في التعليمات (مثلًا: "اتّبع rtl-guidelines.md عند تحديث شيفرة التخطيط").

تدريب Lovable على توليد React متوافق مع RTL

يمكن لـ Lovable توليد تسميات عربية وحتى إضافة dir="rtl" عند طلب ذلك. المشكلة في الاتساق. من دون أنماط واضحة، كل شاشة جديدة مهددة بإعادة إدخال افتراضات إنجليزية.

البدء بمكتبة أنماط RTL صغيرة

بدل طلب لوحة تحكم كاملة مباشرة، يمكن أن يبدأ المشروع بمجموعة صغيرة من المكونات "المرجعية":

Form: نموذج قياسي متراص مع التسميات في الأعلى، ونصوص مساعدة، والتحقق الفوري من صحة المدخلات، ومسافات متوافقة مع RTL.
Table: جدول بيانات مع ترقيم صفحات، وعوامل تصفية في الأعلى، وعناوين أعمدة بالعربية.
Card: بطاقة ملخص تحتوي على عنوان، وعنوان فرعي، وإجراء أساسي، وبيانات ثانوية.
Navbar/sidebar: هيكل الإطار العام الذي يتعامل بشكل صحيح مع أيقونات RTL، وحالات الطي/التمديد، والسلوك المتجاوب.

في Lovable، يمكن طلب إنشاء كل من هذه المكوّنات بشكل صريح، على سبيل المثال:

"Create a reusable <RtlForm> component for Arabic-first SaaS.
Requirements:
- dir="rtl" at the top-level container
- Uses CSS logical properties (margin-inline, padding-inline, inset-inline-*), no left/right
- Labels, placeholders and validation messages in Arabic
- Uses our theme tokens from theme.ts
- Expose props for fields, submitLabel and onSubmit"

بمجرد إنشاء هذه المكوّنات، يمكن في الطلبات اللاحقة أن نطلب من Lovable إعادة استخدامها (مثلًا: “Use <RtlForm> to build the supplier creation screen”).

أنماط توجيه تقلّل أعطال الـ RTL

عند طلب أي تعديل في التخطيط أو إنشاء شاشة جديدة، يمكن تضمين قيود أساسية في التوجيه:

“Arabic-first، RTL layout، default language Arabic.”
“Use CSS logical properties؛ do not use left or right for spacing.”
“Use <RtlForm>، <RtlTable> and existing design system components instead of creating new custom layouts.”
“Keep all text in locales/ar.json، referenced via t() calls، not inline strings.”

هذا التكرار غالبًا ضروري طالما أن الأداة منحازة افتراضيًا إلى LTR.

استخدام Lovable لإعادة هيكلة منهجية، وليس للميزات الجديدة فقط

منشئو الذكاء الاصطناعي فعّالون في عمليات إعادة الهيكلة الميكانيكية عندما تكون القواعد واضحة. بعد تحديد أعراف الـ RTL، يمكن طلب التالي من Lovable:

“Scan the codebase and migrate any margin-left/margin-right usage to logical properties.”
“Replace duplicated ad-hoc forms with the shared <RtlForm> component where possible.”
“Extract all Arabic strings from components into locales/ar.json and replace them with t() lookups.”

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

متى يجب الانتقال إلى التعديلات اليدوية

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

مجالات تستفيد كثيرًا من التعديل اليدوي أو بمساعدة الـ IDE تشمل:

الجداول المليئة بالأرقام: الجداول المالية متعددة الأعمدة مع المجاميع والفروقات.
المخططات البيانية: السلاسل الزمنية، الخرائط، ولوحات التحكم المعقّدة التي تجمع بين تسميات عربية وأكواد لاتينية.
المحاور الزمنية والـ carousels: محتوى مختلط الاتجاه تكون فيه قرارات اتجاه التمرير وترتيب العناصر حاسمة.

لا يزال بإمكان Lovable إنشاء هيكل هذه المكوّنات، لكن أفضل من يقوم بعملية التحقق النهائية هو مراجع بشري (ومعه عند الحاجة مساعد ذكاء اصطناعي أكثر تركيزًا على الكود مثل Claude أو Cursor أو أي وكيل آخر مدمج داخل IDE).

تصميم المنتج لـ Arabic-first: ما بعد قلب واجهة المستخدم

حتى دعم RTL بشكل مثالي لا يضمن منتجًا Arabic-first. تشير الأبحاث حول تجربة المستخدم العربية ومواقع الويب العربية إلى أن الطباعة، وبنية المحتوى، والتعامل مع النصوص المختلطة من أبرز التحديات المتكررة.

التنقّل وتسلسل المعلومات الهرمي

الإجراءات الأساسية: في الأطر RTL، غالبًا ما توضع الإجراءات ذات الأولوية العالية في الجهة اليسرى بصريًا (نهاية المحور الأفقي). أزرار مثل “إضافة فاتورة” تتم محاذاتها عادة إلى inline-end لتبدو طبيعية.
مسارات التنقّل (Breadcrumbs): يمكن الحفاظ على ترتيب القراءة RTL، مع الانتباه للأكواد المضمّنة (مثل أرقام الفواتير) حتى لا “تنكسر” بصريًا.
عناصر الفرز والتصفية: عوامل التصفية المستخدمة بكثرة تعمل بشكل أفضل عندما تكون قريبة من البيانات التي تؤثر فيها، بدلاً من إخفائها في لوحات جانبية تتطلب خطوات إضافية على الهواتف.

الطباعة ومجموعات الخطوط للعربية + اللاتينية

تُظهر دراسات عن مواقع عربية مشاكل متكررة في طول السطر، وعدم الاتساق في الخطوط، وضعف التباين بين الخط العربي واللاتيني. من التوصيات العملية التي يطرحها الممارسون:

مجموعة خطوط Arabic-first: اختيار خط ويب عربي أساسي واسع الانتشار، وإقرانه بخط لاتيني بديل يتناغم معه في ارتفاع الأحرف ووزنها.
تمييز النص اللاتيني: تنسيق النص اللاتيني (الأكواد، عناوين البريد، المعرّفات) بشكل مختلف قليلًا (مثلًا font-family: system-ui;، حجم أصغر) ليبقى مقروءًا لكن مميزًا بصريًا.
طول السطر: إبقاء أسطر نصوص المتن قصيرة نسبيًا لتحسين القراءة؛ وغالبًا ما يُتجاهل هذا في لوحات التحكم المليئة بشاشات CRUD.

في مشروع Lovable، يمكن ترميز هذه الخيارات داخل theme.ts وفي الـ CSS العام، مع تكرار التوجيه: “use theme typography tokens، do not hard-code font families.”

النماذج، التحقق من صحة الحقول، وصيغ البيانات في المنطقة

تطبيقات SaaS Arabic-first التي تستهدف مشغّلي دول الخليج غالبًا ما تتعامل مع:

تنسيقات الهواتف المحلية، بما في ذلك رموز الدول وقواعد التحقق.
أرقام IBAN وأرقام الحسابات بصيغ خاصة بكل دولة.
التواريخ (توقعات العرض بين الميلادي والهجري) والفترات الزمنية الشائعة في الأعمال.

عند طلب بناء نماذج عبر Lovable، يمكن تحديد ما يلي في التوجيه:

“All field labels، placeholders and validation messages in Arabic.”
“Use a masking/validation helper for phone numbers and IBANs؛ error messages should be concise، actionable Arabic.”
“Date pickers must display in a format familiar to GCC operators؛ avoid ambiguous numeric-only formats.”

تدفّقات المحتوى عندما يفكّر الفريق الداخلي بالإنجليزية

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

يمكن أن يعكس المعمار البرمجي هذا التوتر:

استخدام نظام مفاتيح داخلي ("invoice.cancel.button") بدلًا من سلاسل عربية كمعرّفات.
التفكير في لوحة ترجمة داخلية بسيطة مبنية باستخدام Lovable تتيح لمستخدم ثنائي اللغة تحرير النصوص العربية دون لمس ملفات JSON.
تسجيل السلاسل التي لا تزال “غير مترجمة” أو تعتمد على الإنجليزية كخيار احتياطي، بحيث تبقى مديونية تجربة المستخدم العربية مرئية.

متى يُفضَّل الإبقاء على المحتوى LTR داخل إطار عربي

تشير دراسات واجهات الاستخدام عبر الثقافات إلى أن مجرد عكس كل شيء إلى RTL غالبًا ما يكون غير مثالي؛ فبعض المكوّنات تعمل بشكل أفضل إذا بقيت LTR حتى داخل أطر عمل RTL. ويؤكّد عمل حديث حول ممارسي التصوير البصري بالعربية الفكرة نفسها فيما يخص الرسوم البيانية وعروض البيانات.

مكوّنات غالبًا ما تُترك LTR من أجل الوضوح

المخططات الزمنية وتغذيات النشاط: يتصوّر كثير من المستخدمين حركة الزمن من اليسار إلى اليمين، خصوصًا عند التعامل مع تواريخ بصيغة ISO أو سجلات مليئة بالنصوص اللاتينية.
الشرائح الدوّارة للمحتوى المؤرَّخ: قد يكون التمرير الأفقي من اليسار إلى اليمين أكثر اتساقًا مع عروض التقويم والرسوم البيانية.
الجداول الرقمية: الجداول المالية ومؤشرات الأداء الرئيسية التي تعتمد كثيرًا على الأرقام والفواصل العشرية والرموز يمكن أن تكون أسهل في المسح البصري عندما تبقى LTR حتى ضمن واجهة عربية.

سياسة للمحتوى العربي–الإنجليزي المختلط

تؤكّد الأبحاث حول ممارسي التصوير البصري بالعربية أن المحتوى المختلط الاتجاه يحتاج غالبًا إلى قرارات تُتخذ حالةً بحالة. يمكن أن تكون سياسة المنتج البسيطة كالتالي:

دائمًا RTL: نصوص الفقرات، الملصقات، النصوص الوصفية، معظم الأزرار.
دائمًا LTR: رموز المنتجات، أرقام التتبّع، عناوين البريد الإلكتروني، عناوين URL، أرقام الحسابات البنكية.
حسب السياق: الجداول، الرسوم البيانية، المخططات الزمنية – تُحدَّد لكل ميزة وتُوثَّق.

تفاصيل التنفيذ في React

من الناحية التقنية، الأمر مباشر:

لفّ المكوّنات LTR داخل <div dir="ltr">...</div> حتى لو كانت ضمن صفحة RTL.
في المكوّنات القابلة لإعادة الاستخدام، أضِف خاصية direction بحيث تعتمد افتراضيًا على اتجاه التطبيق، لكن يمكن ضبطها صراحةً إلى "ltr".
استخدم خصائص CSS المنطقية في الحالتين؛ سيتولّى الوسم dir عكس قيم start/end حسب الحاجة.

الجزء الأهم هو التوثيق: قسم قصير في ملف rtl-guidelines.md يمكن أن يذكر المكوّنات التي يُقصَد إبقاؤها LTR، حتى لا يحاول Lovable لاحقًا “تصحيحها” وإرجاعها إلى RTL خلال عمليات إعادة الهيكلة.

الإطلاق باستخدام Lovable: سير عمل عربي أولًا

يوضح المخطط أدناه سير عمل عملي يوفّق بين ما يجيده Lovable (البناء السريع، والتحرير بالذكاء الاصطناعي ضمن المتصفح) وبين متطلبات SaaS عربية أولًا وباتجاه RTL في أسواق دول مجلس التعاون الخليجي. يمكنك اعتباره امتدادًا تطبيقيًا لدليل idea-to-launch-in-a-weekend Lovable playbook العام، لكن مع جعل قيود RTL والتوطين صريحة منذ اليوم الأول.