Unformatierter Code-Detektor

[Discourse]

	Zusammenfassung	Unformatted Code Detector erkennt nicht formatierten Code und gibt vor dem Veröffentlichen eine Warnung aus.
	Vorschau	Vorschau im Discourse Theme Creator
	Repository-Link	https://github.com/discourse/unformatted-code-detector
	Neu bei Discourse-Themen?	Anfängerleitfaden zur Verwendung von Discourse-Themen

Dieses Theme-Komponente installieren

Da dies eine #offizielle Theme-Komponente ist, die vom Discourse-Team gepflegt wird, können #Support-, #Bug-, #UX- und #Feature-Anfragen in den jeweiligen Kategorien hier auf Meta gestellt und mit dem entsprechenden Theme-Komponenten-Tag versehen werden. Klicken Sie auf einen der folgenden Links, um einen neuen Beitrag zu starten.

 Support  Bug  UX  Feature

Funktionen

Benutzer, die nicht formatierten Code veröffentlichen, sehen eine Warnmeldung mit Anweisungen, wie sie den Code korrekt formatieren können.

Die Empfindlichkeit und ob HTML erkannt wird, sind über Theme-Einstellungen konfigurierbar.

Einstellungen

Name	Beschreibung
emoji icon	Das Emoji-Symbol, das neben dem Titel im Warnmodus für nicht formatierten Code angezeigt wird.
disable at trust level	Warnung für Benutzer mit einem Vertrauenslevel von N oder höher deaktivieren. -1 = für alle Benutzer aktiviert.
sensitivity	Empfindlichkeit des Erkennungsalgorithmus. 0 = Plugin deaktiviert; 1 = Warnung für alles, das auch nur leicht wie Code aussieht.
min post length to check	Minimale Beitragslänge zum Prüfen (Anzahl der Zeichen)
max post length to check	Maximale Beitragslänge zum Prüfen (Anzahl der Zeichen). -1 = kein Maximum.
include html	Auch auf HTML-Tags prüfen, nicht nur auf andere Code-Arten. Empfohlen zu deaktivieren, wenn Benutzer häufig benutzerdefiniertes HTML in ihren Beiträgen rendern müssen.

Übersetzung	Standardwert
warning_modal.title	Veröffentlichen Sie Code?
warning_modal.content	Es scheint, als ob Ihr Beitrag Code oder Protokolle enthalten könnte. Um Ihren Beitrag lesbar zu halten, denken Sie bitte daran, Ihren Code mit dem Vorbereiteter Text-Symbol in der Werkzeugleiste oder der Backtaste ` auf Ihrer Tastatur zu formatieren, wie hier gezeigt: [examples]
warning_modal.do_not_show_again	Diese Nachricht nicht erneut anzeigen
warning_modal.fix_post	Beitrag bearbeiten
warning_modal.ignore_and_post_anyway	Trotzdem veröffentlichen

Debugging

Wenn Sie eine Warnung für einen Beitrag erhalten, der keinen Text enthält, können Sie Debug-Informationen ausgeben, indem Sie die JS-Konsole Ihres Browsers öffnen und debugUnformattedCodeDetector() Eingabe eingeben. Dies gibt Informationen darüber aus, welche Zeilen als „Code" betrachtet wurden, und welche Empfindlichkeitseinstellungen aktiv sind.

„Diese Nachricht nicht erneut anzeigen" funktioniert nur pro Gerät, nicht pro Benutzer. Dies ist ein bekanntes Problem und wird behoben, sobald Discourse die Möglichkeit erhält, Benutzerinformationen aus Themes zu übernehmen.

Von uns gehostet? Theme-Komponenten können in unseren Standard-, Business- und Enterprise-Plänen verwendet werden.

[robbiet480 (Robbie Trencheny)]

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?

Thanks so much!!

[lionel-rowe]

@robbiet480

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.

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.

@robbiet480

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?

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.

[robbiet480 (Robbie Trencheny)]

Already hit the edge cases issue within 30 minutes or so of hiding the elements, so they have been re-added.

I would be super interested in the modal being more interactive!

[codinghorror (Jeff Atwood)]

Kurze Anmerkung: Wir werden diese Komponente bald offiziell machen und eng mit @lionel-rowe und @david zusammenarbeiten, um das Ziel zu erreichen. Haben Sie Ideen oder Feedback? Jetzt ist der richtige Zeitpunkt, sie zu teilen!

[tpetrov (Toni Petrov)]

@codinghorror

Kurze Anmerkung: Wir werden diese Komponente bald offiziell einführen und arbeiten eng mit @lionel-rowe und @david zusammen, um dies zu erreichen. Falls ihr Ideen oder Feedback habt, teilt sie jetzt!

Tolle Neuigkeiten!

Ich bin mir nicht sicher, ob das sinnvoll ist, aber es wäre großartig, wenn dies auch auf die häufigsten Markdown-Fehler hinweisen könnte, die die Formatierung stören.

[tpetrov (Toni Petrov)]

Es wäre auch toll, wenn es einen Hinweis darauf gäbe, wo der vermutete nicht formatierte Code steht.

Ich habe gerade eine weitere Antwort geschrieben und die Warnung erhalten, obwohl ich keinen Code eingefügt hatte. Nach einer Weile wurde mir klar, dass es daran lag, dass ich das Wort topic_id verwendet habe… Aber es ist nicht offensichtlich, dass der Detektor dieses Wort für Code hält (und die meisten Leute würden das auch nicht denken), meiner Meinung nach.

Ich finde, dass ein Wort mit einem Unterstrich darin nicht unbedingt Code sein muss.

[lionel-rowe]

Vielen Dank für all euer Feedback bisher, Leute! Wir werden einige Einstellungen hinzufügen und anpassen, um die Überempfindlichkeit der Erkennung zu verringern.

@tpetrov noch eine Sache — ist aus der Formulierung des Pop-ups klar ersichtlich, dass ihr es ignorieren und trotzdem veröffentlichen könnt, wenn ihr nicht glaubt, dass euer Beitrag Code enthält? Oder lässt es den Eindruck entstehen, ihr müsstet das wahrgenommene Problem finden und „beheben"?

[tpetrov (Toni Petrov)]

Meine Sorge ist, dass viele Leute es nicht vollständig lesen werden…
Wenn Leute heutzutage ein Popup mit mehr als einem Satz sehen, ignorieren sie den Text oft und suchen direkt nach dem Button Ok (Ich akzeptiere Cookies, Bedingungen usw.).

Trotzdem könnte „It looks like your post may contain unformatted code

[mbauman (Matt Bauman)]

Oooh, ich mag diese Idee… aber ich habe gerade ein falsches Positiv erhalten:

Discobot tutorial generating modmail

It’s still early for our relatively small site but this is looking promising. In the month prior to changing this, 18 folks did that tutorial step and 4 flagged it wrong. In the month+ since 17 have done that step and 0 got it wrong. The new text adds a few more details about why you might flag a post but I’m guessing it’s the very small change to the final sentence that’s doing most of the work: We like our discussions friendly, and we need your help to keep things civilized. If you see a…

Vielleicht waren es die defekten Links, die es ausgelöst haben? Sie stammen einfach aus der Template-Engine und sehen so aus: [keep things civilized](%{guidelines_url}). Oder vielleicht das HTML-img-Tag?

[lionel-rowe]

@tpetrov

Vielleicht könnte man den Satz „Es sieht so aus, als ob Ihr Beitrag nicht formatierten Code enthalten könnte“ in „Verwenden Sie Code in Ihrem Beitrag?“ ändern, da Fragen manchmal mehr Aufmerksamkeit erregen.

Keine schlechte Idee, @david. Vielleicht können wir versuchen, den Titel des Dialogfensters in „Posten Sie einen Code-Schnipsel?“ zu ändern.

@tpetrov

Ich bin kein UX-Experte, aber dieser Button wirkt ein wenig zu extrem:
– etwas, das ich nicht anklicken möchte. Was natürlich die Absicht ist: Dass die Leute ihn nicht einfach überspringen, sondern versuchen, ihren Beitrag besser zu formatieren.

Ich denke, du liegst wahrscheinlich richtig. Die nächste Version wird diesen Button als standardmäßigen grauen Button haben.

@mbauman

Vielleicht waren es die defekten Links, die den Fehler ausgelöst haben? Sie stammen direkt aus der Template-Engine und sehen so aus: [keep things civilized](%{guidelines_url}). Oder vielleicht das HTML-Tag img?

Es stellte sich heraus, dass es beides war! Die nächste Version mit den Standardeinstellungen wird diesen Beitrag nicht mehr auslösen.

[codinghorror (Jeff Atwood)]

Wir führen neue Texte ein und bauen eine Sammlung positiver und negativer Test-Beiträge für die Komponente auf. Habt etwas Geduld, denn das entwickelt sich gut!

[tmomas]

@codinghorror

Ideen oder Feedback? Jetzt ist der richtige Zeitpunkt, sie zu teilen!

Kleiner Kritikpunkt: Der Standardwert für warning_modal.content verweist auf die Symbolleiste-Schaltfläche „code“, doch in der Editor-Oberfläche wird diese beim Überfahren mit der Maus als „Vorformatierter Text“-Schaltfläche bezeichnet.

Um neuen Nutzern die Suche nach dieser Schaltfläche zu erleichtern (da sie keine „code“-Schaltfläche finden werden), sollte der Inhalt von warning_modal.content von „code button“ in „Preformatted text button“ geändert werden.

[tmomas]

Wie kann ich einen Link zu einem Thema mit weiteren Beispielen und Anweisungen hinzufügen?

Ich habe versucht, ihn einfach am Ende von warning_modal.content hinzuzufügen, aber das hat folgendes Ergebnis geliefert (meine Ergänzungen sind gelb markiert):

Wie kann ich unter dem aktuellen Inhalt einen Text und einen Link hinzufügen?

Edit:

Mir ist gerade aufgefallen, dass bereits die Änderung eines einzigen Zeichens in warning_modal.content die Formatierung zerstört.

Noch schlimmer: Wenn ich einfach nur in das Eingabefeld warning_modal.content klicke und dann den Cursor mit den Pfeiltasten bewege, wird das Eingabefeld hervorgehoben. Nach dem Klicken auf das grüne Häkchen, um den „bearbeiteten

[tmomas]

Gibt es eine Möglichkeit, dem Nutzer klarer zu machen, welchen Schlüssel er für die Code-Abgrenzungen wählen soll, wenn er dies manuell tut (also nicht über den Button)?

Heute habe ich Folgendes gesehen:

Der Nutzer hat offensichtlich versucht, den Anweisungen zu folgen, hat aber den falschen Schlüssel für die Code-Abgrenzungen gewählt ( ' statt `). In der Vergangenheit habe ich auch ... statt ``` gesehen. Beide Fälle deuten darauf hin, dass die Nutzer deutlichere Anweisungen benötigen, welchen Schlüssel sie wählen sollen.

Alternativ: Verwirren Sie die Nutzer nicht mit diesen Schlüsseln und sagen Sie einfach: Verwenden Sie den Button „Vorformatierter Text“ und Sie sind fertig.

---

@lionel-rowe Wie kann ich das Erkennungsverhalten anpassen?

Derzeit wird der Shebang nicht als Code erkannt, und ich möchte dies ändern.

Erwartetes Verhalten: #! kennzeichnet den Beginn eines Skripts und sollte daher als Code erkannt werden.

Beispiel für keine Erkennung:

---

#!/bin/sh

echo “test”

. /lib/upgrade/common.sh

firmware=“/tmp/firmware.img”
tmpdir=“/tmp/_upgrade”
output=“/dev/ttyS0”
before=“before-upgrade.sh”
after=“after-upgrade.sh”

---

Zusätzlich dazu wäre es für uns nützlich, wenn root@ als Code erkannt würde.

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

[codinghorror (Jeff Atwood)]

@tmomas

Zusätzlich dazu wäre es für uns hilfreich, wenn root@ als Code erkannt würde.

@david, gibt es eine Möglichkeit, die Erkennung anzupassen?

[david (David Taylor)]

Es gibt derzeit leider keine Möglichkeit, benutzerdefinierte Anpassungen pro Site vorzunehmen. Wir könnten jedoch durchaus prüfen, die Erkennung von Shebangs und Shell-Prompts in das „Code Energy"-System aufzunehmen.

[david (David Taylor)]

@tmomas

Wenn man einfach in das Eingabefeld warning_modal.content klickt und dann den Cursor mit den Pfeiltasten bewegt, wird das Eingabefeld hervorgehoben. Nach dem Klicken auf das grüne Häkchen, um den „bearbeiteten" warning_modal.content zu speichern (es wurde überhaupt keine Änderung vorgenommen, nur der Cursor um ein Zeichen verschoben), ist die Formatierung wie oben gezeigt kaputt.

Danke, dass du das angesprochen hast – sieht nach einem Kernfehler bei mehrzeiligen Theme-Übersetzungen aus. Ich habe einen PR erstellt, um das zu beheben:

FIX: Use <textarea> for theme translations (#14322)

[hhlp]

Die meisten Discourse-Sites verwenden Discourse als Fehlerbehebungstool. Ist dieses Plugin für die folgenden Aufgaben geeignet, nicht nur für Code:

Linux:

• Protokolle
• Linux-Befehlszeile (CLI)
• Terminalausgabe

Beispiel:

Sensoren:
  Systemtemperaturen: CPU: 78,0 °C Mainboard: 36,0 °C GPU: nouveau Temperatur: 56,0 °C
  Lüfterdrehzahlen (U/min): CPU: 0 Lüfter-1: 3139 Lüfter-3: 0 Lüfter-5: 0
  Stromversorgung: 12V: N/A 5V: 2,90 3,3V: N/A vbat: 3,34

Mit freundlichen Grüßen,