Чувствительность и обнаружение HTML настраиваются через параметры темы.
Параметры
Название
Описание
emoji icon
Иконка эмодзи, отображаемая рядом с заголовком в модальном окне предупреждения о неформатированном коде.
disable at trust level
Отключить предупреждение для пользователей с уровнем доверия N или выше. -1 = включено для всех пользователей.
sensitivity
Чувствительность алгоритма обнаружения. 0 = плагин отключен; 1 = предупреждение для всего, что хоть немного похоже на код.
min post length to check
Минимальная длина поста для проверки (количество символов)
max post length to check
Максимальная длина поста для проверки (количество символов). -1 = без ограничения.
include 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 получит возможность прикреплять информацию о пользователе к темам.
Размещены у нас? Компоненты тем доступны для использования в наших тарифах Standard, Business и Enterprise.
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, чтобы достичь этой цели. Любые идеи или отзывы — самое время их озвучить!
Не уверен, уместно ли это, но было бы здорово, если бы это также предупреждало о наиболее распространённых ошибках в Markdown, которые нарушают форматирование.
Было бы здорово, если бы указывалось место, где обнаружен предположительно неформатированный код.
Я просто писал ещё один ответ и получил уведомление, хотя не вставлял никакого кода. Через некоторое время я понял, что это из-за слова topic_id… Но не очевидно, что детектор считает это слово кодом (и большинство людей так не подумают), на мой взгляд.
Я считаю, что наличие подчёркивания в слове не обязательно означает, что это код.
Спасибо всем за обратную связь, ребята! Мы добавим и немного скорректируем несколько настроек, чтобы снизить излишнюю чувствительность детектора.
@tpetrov, ещё один момент — понятно ли из формулировки всплывающего окна, что вы можете проигнорировать его и опубликовать сообщение, если считаете, что в нём нет кода? Или оно создаёт впечатление, что вы обязаны найти и «исправить» предполагаемую проблему?
Меня беспокоит, что многие люди не станут читать это…
Вы знаете, когда люди видят всплывающее окно с текстом более чем в одно предложение, они, похоже, игнорируют текст и ищут кнопку ОК (я принимаю файлы cookie, условия и т. д.).
Тем не менее, возможно, фразу «Похоже, в вашем сообщении есть неформатированный код» можно заменить на «Используете ли вы код в своём сообщении?», так как вопросы иногда привлекают больше внимания.
Я не эксперт по UX, но эта кнопка кажется немного чрезмерной: — я бы не хотел на неё нажимать. Что, конечно, и является целью — чтобы люди не просто пропускали это, а пытались лучше форматировать своё сообщение.
О-о-о, мне нравится эта идея… но у меня только что сработал ложный срабатывание:
Возможно, его сработали битые ссылки? Они просто берутся из шаблона и выглядят так: [keep things civilized](%{guidelines_url}). Или, может быть, HTML-тег img?
Мы внедряем новые тексты и формируем корпус положительных и отрицательных тестовых примеров постов для компонента. Пожалуйста, подождите немного — всё складывается отлично!
Небольшое замечание: по умолчанию в warning_modal.content запрашивается кнопка панели инструментов «code», однако в редакторе при наведении на эту кнопку мышью она называется кнопкой «Preformatted text».
Чтобы новым пользователям было проще найти эту кнопку (они не найдут кнопку с названием «code»), содержимое warning_modal.content следует изменить с «кнопка code» на «кнопка Preformatted text».
Ещё хуже: просто нажатие на поле ввода warning_modal.content и перемещение курсора стрелками приводит к подсветке поля ввода. После нажатия на зелёную галочку для сохранения «отредактированного» warning_modal.content (никаких изменений не было внесено, только перемещение курсора на один символ) форматирование нарушается, как показано выше.
@codinghorror@lionel-rowe, возможно, вам стоит изучить этот вопрос и соответствующим образом настроить warning_modal.content по умолчанию, учитывая пробелы и обратные кавычки (отсутствие пробелов в разделе “multiplelines”, насыщенном обратными кавычками, вызывало описанные выше проблемы).
Очевидно, пользователь пытался следовать инструкциям, но выбрал неправильный ключ для блоков кода ( ' вместо `). В прошлом я также видел ... вместо ```. Оба случая указывают на то, что пользователям нужны более явные инструкции о том, какой ключ выбрать.
Альтернатива: не путать пользователей этими ключами, а просто сказать: используйте кнопку «Форматированный текст», и всё готово.
@lionel-rowe Как я могу настроить поведение обнаружения?
В настоящее время shebang не распознаётся как код, и я хотел бы это изменить.
Ожидаемое поведение: #! указывает на начало скрипта и поэтому должно распознаваться как код.
Кроме того, для нас было бы полезно, если бы 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
На данный момент кастомизация для каждого сайта недоступна. Однако мы могли бы рассмотреть возможность добавления детекции shebang и командной строки в систему «code energy».
Большинство сайтов на Discourse используют его как инструмент для устранения неполадок. Подходит ли этот плагин для следующих задач, а не только для кода:
Linux:
Логи
Командная строка CLI Linux
Вывод терминала
Например:
Sensors:
System Temperatures: cpu: 78.0 C mobo: 36.0 C gpu: nouveau temp: 56.0 C
Fan Speeds (RPM): cpu: 0 fan-1: 3139 fan-3: 0 fan-5: 0
Power: 12v: N/A 5v: 2.90 3.3v: N/A vbat: 3.34
«Больше не показывать это сообщение» работает только для конкретного устройства, а не для конкретного пользователя. Это известная проблема, которая будет исправлена, как только Discourse получит возможность прикреплять информацию о пользователе к темам.
Размещены у нас? Компоненты тем доступны для использования в наших тарифах Standard, Business и Enterprise.
— я бы не хотел на неё нажимать. Что, конечно, и является целью — чтобы люди не просто пропускали это, а пытались лучше форматировать своё сообщение.
