حتى في نص عربي بالكامل، تبقى رموز markdown نفسها — ** و* و# — تُكتب وتُقرأ من اليسار إلى اليمين، لأن Markdown نفسه لم يُصمَّم أصلًا مع وضع النصوص من اليمين إلى اليسار (RTL) في الحسبان.
الصياغة الأساسية
# عنوان— عناوين بمستويات مختلفة حسب عدد أحرف#.**عريض**و*مائل*— تأكيد النص.[نص](رابط)— رابط.- عنصرأو1. عنصر— قوائم نقطية ومرقّمة.- ``` — كتلة كود مع تمييز صياغة حسب اسم اللغة.
كيف تتعامل رموز التأكيد مع نص RTL
عند كتابة **عريض** ضمن فقرة عربية، تُعرَض النجمتان بصريًا على يمين الكلمة رغم أنهما تسبقانها في الترتيب المنطقي للنص — لأن خوارزمية Unicode bidi تحدد الاتجاه المرئي بناءً على نوع كل حرف، بينما يبقى ترتيب المصدر الفعلي كما كُتب، من اليسار إلى اليمين لرموز markdown نفسها. هذا لا يكسر التنسيق عادة، لكنه يجعل تحرير نص markdown عربي بمحرر بسيط أصعب من تحرير نص إنجليزي مكافئ.
عندما يلتقي كود إنجليزي بنص عربي
مقتطف كود مضمّن مثل npm install داخل جملة عربية يبقى بترتيب LTR داخلي، فيضع المتصفح حدًا اتجاهيًا (bidi boundary) حول النص الإنجليزي وسط الجملة العربية. إذا احتوى المقتطف على علامات ترقيم مثل الأقواس أو الشرطة، فقد يظهر ترتيبها معكوسًا بصريًا داخل الجملة العربية إذا لم يُحاط المقتطف بعلامات اتجاه صريحة، وهذه من الحالات التي تجعل معاينة Markdown ضرورية قبل النشر بدل الوثوق بالمظهر داخل المحرر النصي وحده.
Markdown الأصلي لم يكن يعرّف الجداول أصلًا
ماركداون الذي نشره جون غروبر عام 2004 كان وصفًا نثريًا لا قواعد صياغة رسمية، ولم يتضمن جداول ولا نصًا مشطوبًا ولا كتل كود بتمييز لغة. جاءت CommonMark عام 2014 لتثبيت قواعد دقيقة، وأضافت GitHub Flavored Markdown (GFM) فوقها الجداول وقوائم المهام التي أصبحت اليوم جزءًا بديهيًا من أي ملف README.
لماذا نحتاج هذا
- معاينة سريعة لكيفية عرض ملف ماركداون دون نشره.
- تحويل محتوى صفحة أو مستند إلى ماركداون لتخزينه في نظام تحكم الإصدارات.
- تحضير محتوى HTML لإدراجه في تطبيق يقبل ماركداون فقط.