La sensibilità e la rilevazione dell’HTML sono configurabili tramite le impostazioni del tema.
Impostazioni
Nome
Descrizione
emoji icon
L’icona emoji da visualizzare accanto al titolo nella finestra di avviso per il codice non formattato.
disable at trust level
Disattiva l’avviso per gli utenti con un livello di fiducia pari a N o superiore. -1 = abilitato per tutti gli utenti.
sensitivity
Sensibilità dell’algoritmo di rilevamento. 0 = plugin disabilitato; 1 = avviso per qualsiasi elemento che assomigli anche solo leggermente a codice.
min post length to check
Lunghezza minima del post da controllare (numero di caratteri)
max post length to check
Lunghezza massima del post da controllare (numero di caratteri). -1 = nessun limite massimo.
include html
Controlla anche i tag HTML oltre ad altri tipi di codice. Si consiglia di disabilitare se gli utenti devono spesso renderizzare HTML personalizzato nei loro post.
Traduzione
Valore predefinito
warning_modal.title
Stai pubblicando del codice?
warning_modal.content
Sembra che il tuo post possa contenere codice o log. Per mantenere il post leggibile, ricorda di formattare il codice utilizzando il pulsante della barra degli strumenti Testo preformattato, o il tasto backtick ` sulla tastiera, come mostrato qui: [esempi]
warning_modal.do_not_show_again
non mostrare più questo messaggio
warning_modal.fix_post
Modifica post
warning_modal.ignore_and_post_anyway
Pubblica comunque
Debug
Se ricevi un avviso per un post che non include alcun testo, puoi stampare le informazioni di debug aprendo la console JS del browser e digitando debugUnformattedCodeDetector()Invio. Questo visualizzerà alcune informazioni su quali righe sono state considerate “codice” e quali sono le impostazioni di sensibilità.
“Non mostrare più questo messaggio” funziona solo per dispositivo, non per utente. Questo è un problema noto che verrà risolto non appena Discourse acquisirà la funzionalità di allegare le informazioni utente ai temi.
Ospitato da noi? I componenti del tema sono disponibili per l’uso nei nostri piani Standard, Business ed 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.
Una breve nota: stiamo per rendere ufficiale questo componente a breve e lavoreremo a stretto contatto con @lionel-rowe e @david per arrivarci. Se hai idee o feedback, questo è il momento giusto per condividerli!
Sarebbe ottimo anche avere un suggerimento su dove si trova il codice non formattato sospetto.
Stavo scrivendo un’altra risposta e ho ricevuto l’avviso, anche se non avevo incollato alcun codice. Dopo un po’ ho capito che era perché avevo usato la parola topic_id… Ma non è affatto ovvio che il rilevatore pensi che questa parola sia codice (e la maggior parte delle persone non penserebbe così), a mio avviso.
Penso che quando una parola contiene un trattino basso non significhi necessariamente che sia codice.
Grazie per tutti i vostri feedback finora, gente! Aggiungeremo e modificheremo alcune impostazioni per ridurre l’eccessiva sensibilità del rilevamento.
@tpetrov un’altra cosa — la formulazione del popup rende chiaro che puoi scegliere di ignorarlo e pubblicare comunque se non pensi che il tuo post contenga codice? O fa sembrare che tu sia costretto a trovare e “risolvere” il problema percepito?
La mia preoccupazione è che molte persone non lo leggeranno fino in fondo…
Sapete, quando oggi le persone vedono un popup con più di una riga di testo, sembrano ignorare il contenuto e cercare direttamente il pulsante Ok (accetto cookie, termini, ecc.).
Tuttavia, forse “Sembra che il tuo post contenga codice non formattato” potrebbe essere cambiato in “Usi il codice nel tuo post?”, poiché a volte le domande attirano più attenzione.
Non sono un esperto di UX, ma questo pulsante sembra un po’ troppo drastico: - qualcosa che non vorrei cliccare. Il che, ovviamente, è l’idea: che le persone non lo saltino semplicemente, ma provino invece a formattare meglio il loro post.
Oooh, mi piace questa idea… ma ho appena avuto un falso positivo:
Potrebbe essere stato a causa dei link rotti che l’hanno fatto scattare? Sono presi direttamente dal motore di templating e hanno questo aspetto: [mantieni le cose civili](%{guidelines_url}). O forse è il tag HTML img?
Stiamo rilasciando nuovi testi e stiamo creando un corpus di post di prova positivi e negativi per il componente. Abbiate un po’ di pazienza, poiché sta prendendo forma in modo eccellente!
Una piccola nota: l’impostazione predefinita per warning_modal.content richiede il pulsante della barra degli strumenti “code”, ma nel editor, quando ci passi sopra con il mouse, questo pulsante è chiamato “Testo preformattato”.
Per rendere più facile ai nuovi utenti trovare questo pulsante (non troveranno alcun pulsante “code”), il contenuto di warning_modal.content dovrebbe essere modificato da “pulsante code” a “pulsante Testo preformattato”.
Come posso aggiungere un link a un argomento con ulteriori esempi e istruzioni?
Ho provato semplicemente ad aggiungerlo alla fine di warning_modal.content, ma questo ha portato a questo (le mie aggiunte sono contrassegnate in giallo):
Ancora peggio: basta fare clic nel campo di input warning_modal.content e poi spostare il cursore con le frecce per far sì che il campo di input venga evidenziato. Dopo aver fatto clic sul segno di spunta verde per salvare il warning_modal.content “modificato” (non è stato apportato alcun cambiamento, solo lo spostamento del cursore di un carattere), la formattazione viene interrotta come mostrato sopra.
@codinghorror@lionel-rowe Forse dovreste dare un’occhiata a questo e adeguare di conseguenza il warning_modal.content predefinito per quanto riguarda spazi e backtick (gli spazi mancanti all’interno della sezione “multiplelines” pesantemente dotata di backtick stavano causando i problemi descritti sopra).
C’è qualche modo per rendere più chiaro all’utente quale tasto scegliere per i delimitatori di codice se lo fa manualmente (cioè non tramite il pulsante)?
L’utente ha ovviamente cercato di seguire le istruzioni, ma ha scelto il tasto sbagliato per i delimitatori di codice (' invece di `). In passato ho anche visto ... invece di ```. Entrambi i casi indicano che gli utenti hanno bisogno di istruzioni più esplicite su quale tasto scegliere.
In alternativa: non confondere gli utenti con quei tasti e dì semplicemente: usa il pulsante “Testo preformattato” e hai finito.
@lionel-rowe Come posso personalizzare il comportamento di rilevamento?
Attualmente lo shebang non viene rilevato come codice e vorrei modificarlo.
Comportamento atteso: #! indica l’inizio di uno script e quindi dovrebbe essere rilevato come codice.
In aggiunta a questo, per noi sarebbe utile se root@ venisse rilevato come codice.
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
Al momento non esiste alcun modo per avere personalizzazioni per sito, no. Potremmo sicuramente prendere in considerazione l’aggiunta del rilevamento di shebang e prompt del shell al sistema ‘code energy’.
La maggior parte dei siti Discourse utilizza Discourse come strumento di risoluzione dei problemi. Questo plugin è adatto per le seguenti attività, non solo per il codice:
Linux:
Log
Comandi CLI di Linux
Output del terminale
Ad esempio:
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