لدي مستخدمون يعدلون بناء جملة الاقتباس بشكل سيء مما يتسبب في فشل وظيفة الاقتباس. على سبيل المثال، لدينا هذا المثال من موضوع حالي. هذا النص غير مُهْرَّب:
[quote=“CFO.Digest.Input, post:1, topic:3258”]
اقترح عليّ أن أعيد وضع الزيت المعدني. [/quote]
المشكلة هي أن وسم الإغلاق [/quote] موجود في السطر، بينما وسم الافتتاح [quote] موجود في سطر منفصل. لقد اكتشفت أنه يمكنك استخدام أي منهما، لكن يجب أن يتطابقا. على سبيل المثال، هذا يعمل (تمت إضافة علامة الاقتباس المفردة ’ للهروب من الدالة):
'[quote=“CFO.Digest.Input, post:1, topic:3258”]
اقترح عليّ أن أعيد وضع الزيت المعدني.
'[/quote]
وهذا يعمل أيضًا:
'[quote=“CFO.Digest.Input, post:1, topic:3258”]اقترح عليّ أن أعيد وضع الزيت المعدني.[/quote]
… لكن لا يمكنك دمج الأنماط.
أعلم أن شخصًا ما سيقول “إذن لا تفعل ذلك” أو “استخدم زر الاقتباس”، لكن لا يزال لدينا مستخدمون لا يقومون بذلك بشكل صحيح.
يا إلهي… إذن نحن في الأساس نطبق معايير البرمجة على عملائنا ومستخدمينا؟
بينما أتفق مع تحليل سام للتنسيق، هناك فرق بين أن يكون النص صعب القراءة على الكاتب، وصعب القراءة على الجميع الذين يشاهدون المنشور. يبدو الأمر كما لو أننا نعاقب القراء على أخطاء الكاتب…
أظن أنني سأستمر في تحرير المنشورات عندما يفسدها الناس.
تعديل: خيار آخر قد يكون إجبار إضافة سطر جديد بعد [/quote] إذا لم يكن موجودًا… أي تعديل التنسيق تلقائيًا لتحسين القراءة.
قمت بتحرير المنشور بإدراج سطر جديد بعد وسم إغلاق الاقتباس، لكنني ما زلت أجد من المدهش ألا يتم تحليل تدفق النص مثل HTML حيث لا تؤثر سطور التغذية أو سطور الإرجاع على وظيفة الوسوم. يبدو لي أن هذا خطأ برمجي…
الترتيب ليس عشوائيًا، بل هو سليم تمامًا. لكن على عكس HTML، في هذا النظام، يهم مكان وقوع أحرف السطر الجديد.
كل ما تطلبه لإصلاح المنشور المعطّل هو إضافة سطر جديد / CR بعد علامة الإغلاق.
أنا مستعد لاستمرار التعديل اليدوي للمنشورات عندما يفشل المستخدمون في الامتثال للهيكل المطلوب، لكنه لا يزال يبدو غريبًا أن يكون لأحرف السطر الجديد أي تأثير على المحلل…
نظرة على مواصفات Markdown. على عكس HTML، يعتمد Markdown كليًا على وضع أسطر جديدة في الأماكن الصحيحة.
فكسر سطر خاطئ داخل عنصر <h1> لن يكون له أي تأثير على العرض، لكن:
هنا في عالم Markdown
يحدث ذلك.
هذا ينطبق على العديد من العناصر؛ فجدولات Markdown تتعطل بشدة بسبب وجود أسطر جديدة إضافية، بينما جداول HTML على العكس من ذلك لا تتأثر.
لا أعتقد أن تشبيه HTML مفيد أو دقيق، فالمستخدمون لا يُطلب منهم كتابة HTML. تخيلوا فقط ألم النسيان في وضع <p> و </p> و <br>؟ ستصبح الجدران النصية حرفيًا.
إذا فكرت في “Markdown أولاً” وهو ما يعتمد عليه Discourse، بدلاً من “HTML أولاً” وهو ما لا يعتمد عليه Discourse مطلقًا، فستبدأ التحديات الناتجة عن إضافة وسوم دون احترام البنية في أن تبدو منطقية.
أنا على استعداد لتوجيه المستخدمين خلال هذه الأمور، مثل أي مبرمج، لكن مستخدمينا من عامة الناس وقد يظنون أن لغة ماركداون لها علاقة بالأسعار في متجر وولمارت.
وكما تقول، لحسن الحظ نحن لا نطلب منهم كتابة كود HTML! فما الذي يُكسبه إجبارهم على تطبيق تنسيقات ماركداون؟ يبدو أن قليلًا من ذكاء البرمجة سيحميهم من هذه واقعيات عالمنا.
لا أعرف مدى تعقيد الأمر لفرض سطر جديد تلقائيًا بعد [/quote] (طالما أنه ليس داخل كتلة كود أو ما شابه ذلك…)، وأنا أدرك أن هناك هيكلية يجب مراعاتها عند استخدام تنسيق الماركداون.
ولكنني أدرك أيضًا مدى الإحباط الذي قد يسببه ظهور اقتباس غير صحيح في رسالة مستخدم بسبب “خطأ” بسيط جدًا مثل كتابة نص على نفس السطر الذي ينتهي فيه [/quote] (لست متأكدًا مما إذا كان يمكنني تسمية ذلك خطأ).
هل هناك حالة مقصودة يُكتب فيها نص على نفس السطر مع [quote]؟
إذا لم تكن هناك مثل هذه الحالة، فأشعر أنه لا يوجد أي سبب لوجود نص على نفس السطر، ويمكن أن يكون فرض سطر جديد بعد وسم إغلاق الاقتباس مفيدًا لكل من المستخدمين والموظفين. لكنني أيضًا متأكد من أن الأمر ليس بهذه البساطة كما يبدو.
صحيح. الطبيعة الأساسية للغة Markdown هي أن سطرًا جديدًا (أو سطرين جديدين) يعادلان وسم الفقرة. وبسبب ذلك، تتطلب بعض الوسوم وجود سطور جديدة قبلها أو بعدها لكي يتم تفسيرها بشكل صحيح. أعتقد أن هذا جزء من المواصفات.
