يمكن ضبط الحساسية وما إذا كان سيتم اكتشاف HTML عبر إعدادات الموضوع.
الإعدادات
الاسم
الوصف
أيقونة الإيموجي
أيقونة الإيموجي التي سيتم عرضها بجانب العنوان في نافذة التحذير للأكواد غير المنسقة.
تعطيل عند مستوى الثقة
تعطيل التحذير للمستخدمين الذين لديهم مستوى ثقة N أو أعلى. -1 = مفعّل لجميع المستخدمين.
الحساسية
حساسية خوارزمية الكشف. 0 = الإضافة معطّلة؛ 1 = تحذير لأي شيء يبدو وكأنه كود حتى لو بشكل طفيف.
الحد الأدنى لطول المنشور للتحقق
الحد الأدنى لطول المنشور للتحقق (عدد الأحرف)
الحد الأقصى لطول المنشور للتحقق
الحد الأقصى لطول المنشور للتحقق (عدد الأحرف). -1 = لا يوجد حد أقصى.
تضمين HTML
التحقق من وسوم HTML بالإضافة إلى أنواع الأكواد الأخرى. يُوصى بتعطيلها إذا احتاج المستخدمون غالبًا إلى عرض HTML مخصص في منشوراتهم.
الترجمة
الافتراضي
warning_modal.title
هل تنشر كودًا؟
warning_modal.content
يبدو أن منشورك قد يحتوي على كود أو سجلات. للحفاظ على قابلية قراءة منشورك، يرجى تذكر تنسيق الكود الخاص بك باستخدام زر شريط الأدوات نص منسق، أو مفتاح الشرجب ` في لوحة مفاتيحك، مثل هذا: [أمثلة]
warning_modal.do_not_show_again
لا تظهر هذه الرسالة مرة أخرى
warning_modal.fix_post
تعديل المنشور
warning_modal.ignore_and_post_anyway
النشر على أي حال
استكشاف الأخطاء وإصلاحها
إذا تلقيت تحذيرًا لمنشور لا يتضمن أي نص، يمكنك طباعة معلومات التصحيح بفتح وحدة تحكم JS في المتصفح، وكتابة debugUnformattedCodeDetector()Enter. سيؤدي هذا إلى طباعة بعض المعلومات حول الأسطر التي اعتُبرت “أكوادًا”، وما هي إعدادات الحساسية.
تعمل خيار “لا تظهر هذه الرسالة مرة أخرى” على كل جهاز على حدة، وليس لكل مستخدم. هذه مشكلة معروفة وسيتم إصلاحها بمجرد أن يحصل Discourse على وظيفة إرفاق معلومات المستخدم من المواضيع.
We at the Home Assistant forums think that this is the best thing invented since sliced bread. Or maybe Home Assistant. Thank you so so much @lionel-rowe!!!
Two minor request:
I don’t want to allow users to skip formatting or disable the dialog in the future. I want them to feel pain until they change their ways. I’m sadistic like that. Can you make the “Don’t show this message again” and “Post anyway” buttons optional? For now I’ve hid them with some CSS but would be better to just not include the HTML at all.
Unsure if you are doing language detection or not, but if you are, can you add the estimated language name after the first code fence so that users will properly syntax highlight too?
I wouldn’t recommend hiding them, especially if you leave the setting to include HTML detection on. Power users may still want to have their (sanitized) HTML parsed as such, not formatted as code. Two examples where this can be useful are kbd and abbr tags.
If you exclude HTML tags from detection (which may be viable depending on the scope of your forum), hiding the “don’t show this again” would probably be OK. I still wouldn’t recommend hiding the “post anyway”, though, because there are bound to still be some edge cases of false positives (I hit one the other day where I’d omitted a space before an opening parenthesis — poor typesetting, but not unformatted code). Then you’ll have a situation where users can’t post their question at all, and, unless they report the issue to you directly, you won’t even know about it.
Language detection is beyond the scope of this component, I’m afraid. Where possible, it looks for syntactical features shared by many languages, such as lines ending in semicolons, certain configurations of curly braces, and so on.
I am thinking about ways to enhance the UX, though. One big improvement would be to make it much more interactive. For example, instead of a simple modal, the user would be presented with a wizard that first asks them which language their post concerns (select from a dropdown), then a screen which asks them to select which ranges of their post are code (defaulting to lines that contain strings flagged by the plugin), then generating the appropriate markdown. This would still include a “skip and post anyway” option, though, for the reasons I mentioned.
I don’t have a timeline for this change, but it’d be good to know if it’s something people would be interested in.
ملاحظة سريعة، سنقوم بتوحيد هذا المكون قريبًا وسنعمل عن كثب مع @lionel-rowe و @david للوصول إلى ذلك. أي أفكار أو ملاحظات، الآن هو الوقت المناسب لمشاركتها!
سيكون من الرائع أيضًا وجود تلميح يوضح مكان الكود غير المنسق المشتبه به.
كنت أكتب ردًا آخر وحصلت على التنبيه، على الرغم من أنني لم ألصق أي كود. بعد فترة أدركت أن السبب هو استخدامي لكلمة topic_id… لكن ليس من الواضح أن الكاشف يعتبر هذه الكلمة كودًا (معظم الناس لن يعتقدوا ذلك) في رأيي.
أعتقد أنه عندما تحتوي كلمة على شرطة سفلية، فإن هذا لا يعني بالضرورة أنها كود.
شكرًا لكم جميعًا على كل التعليقات حتى الآن يا أصدقاء! سنقوم بإضافة وتعديل بعض الإعدادات لتقليل الحساسية المفرطة في الكشف.
@tpetrov هناك نقطة أخرى — هل صيغة النافذة المنبثقة توضح بوضوح أنه يمكنك اختيار تجاهلها ونشر منشورك على أي حال إذا كنت لا تعتقد أن منشورك يحتوي على كود؟ أم أنها توحي بأنك مُجبر على العثور على المشكلة “المفترضة” وإصلاحها؟
قلقُي هو أن الكثير من الناس لن يقرأوه بتمعن…
كما تعلم، عندما يرى الناس نافذة منبثقة تحتوي على أكثر من جملة نصية في الوقت الحاضر، يبدو أنهم يتجاهلون النص ويبحثون عن زر موافق (أوافق على ملفات تعريف الارتباط والشروط، وما إلى ذلك).
ومع ذلك، ربما يمكن تغيير عبارة “يبدو أن منشورك يحتوي على كود غير منسق” إلى “هل تستخدم كودًا في منشورك؟”، لأن الأسئلة أحيانًا تجذب انتباهًا أكبر.
أنا لست خبيرًا في تجربة المستخدم، لكن هذا الزر يبدو وكأنه إجراء جذري للغاية: - شيء لا أحب النقر عليه. وهو بالطبع الفكرة: أن الناس لن يتجاوزوه ببساطة بدلاً من محاولة تنسيق منشورهم بشكل أفضل.
أوه، أعجبني هذا الفكرة… لكنني حصلت للتو على نتيجة إيجابية خاطئة:
ربما كان السبب في ذلك هو الروابط المعطلة؟ فهي مأخوذة ببساطة من محرك القوالب وتظهر بهذا الشكل: [keep things civilized](%{guidelines_url}). أو ربما كان بسبب وسم HTML img؟
ملاحظة بسيطة: النص الافتراضي لـ warning_modal.content يطلب زر شريط الأدوات “code”، لكن هذا الزر يُسمى زر “النص المنسق مسبقًا” في المحرر عند تمرير الماوس فوقه.
لتسهيل العثور على هذا الزر للمستخدمين الجدد (لن يجدوا أي زر باسم “code”)، يجب تغيير النص الافتراضي لـ warning_modal.content من “زر code” إلى “زر النص المنسق مسبقًا”.
والأسوأ من ذلك: مجرد النقر داخل حقل إدخال warning_modal.content ثم تحريك المؤشر باستخدام مفاتيح الأسهم يجعل حقل الإدخال مُظللًا. بعد النقر على علامة الاختيار الخضراء لحفظ “المحرر” warning_modal.content (لم يتم إجراء أي تغيير على الإطلاق، فقط تحريك المؤشر حرفًا واحدًا)، يتعطل التنسيق كما هو موضح أعلاه.
@codinghorror@lionel-rowe ربما يجب عليكم النظر في هذا الأمر وتعديل warning_modal.content الافتراضي وفقًا لذلك فيما يتعلق بالمسافات والرموز الخلفية (كانت المسافات المفقودة داخل قسم “multiplelines” المزود بكثافة بالرموز الخلفية هي السبب في المشاكل المذكورة أعلاه).
من الواضح أن المستخدم حاول اتباع التعليمات، لكنه اختار المفتاح الخاطئ للأقواس البرمجية ( ' بدلاً من `). في الماضي، رأيت أيضًا ... بدلاً من ```. كلا الحالتين تشير إلى أن المستخدمين يحتاجون إلى تعليمات أكثر وضوحًا حول أي مفتاح يختارونه.
بديلًا عن ذلك: لا تُربك المستخدمين بتلك المفاتيح، بل قل ببساطة: استخدم زر “النص المُسبق التنسيق” وستكون قد انتهيت.
بالإضافة إلى ذلك، سيكون من المفيد لنا إذا تم اكتشاف root@ ككود.
root@OpenWrt:~# ip link add link eth0 name eth0.9 type vlan id 9
root@OpenWrt:~# brctl addbr br-foo
root@OpenWrt:~# brctl addif br-foo eth0.9
root@OpenWrt:~# ip link set eth0.9 up
root@OpenWrt:~# ip link set br-foo up
تعمل خيار “لا تظهر هذه الرسالة مرة أخرى” على كل جهاز على حدة، وليس لكل مستخدم. هذه مشكلة معروفة وسيتم إصلاحها بمجرد أن يحصل Discourse على وظيفة إرفاق معلومات المستخدم من المواضيع.
مستضافون معنا؟ مكونات المواضيع متاحة للاستخدام في خططنا القياسية، والتجارية، والمؤسسية.
- شيء لا أحب النقر عليه. وهو بالطبع الفكرة: أن الناس لن يتجاوزوه ببساطة بدلاً من محاولة تنسيق منشورهم بشكل أفضل.
