La sensibilité et la détection du HTML sont configurables via les paramètres du thème.
Paramètres
Nom
Description
icône emoji
L’icône emoji à afficher à côté du titre dans la modal d’avertissement pour le code non formaté.
désactiver au niveau de confiance
Désactiver l’avertissement pour les utilisateurs ayant un niveau de confiance de N ou plus. -1 = activé pour tous les utilisateurs.
sensibilité
Sensibilité de l’algorithme de détection. 0 = plugin désactivé ; 1 = avertir pour tout ce qui ressemble même légèrement à du code.
longueur minimale du message à vérifier
Longueur minimale du message à vérifier (nombre de caractères)
longueur maximale du message à vérifier
Longueur maximale du message à vérifier (nombre de caractères). -1 = aucune limite maximale.
inclure html
Vérifier les balises HTML ainsi que d’autres types de code. Il est recommandé de désactiver cette option si les utilisateurs doivent fréquemment rendre du HTML personnalisé dans leurs messages.
Traduction
Défaut
warning_modal.title
Publiez-vous du code ?
warning_modal.content
Il semble que votre message contienne du code ou des journaux. Pour garder votre message lisible, n’oubliez pas de formater votre code en utilisant le bouton de la barre d’outils Texte préformaté, ou la touche accent grave ` de votre clavier, comme ceci : [exemples]
warning_modal.do_not_show_again
ne plus afficher ce message
warning_modal.fix_post
Modifier le message
warning_modal.ignore_and_post_anyway
Publier quand même
Débogage
Si vous recevez un avertissement pour un message qui ne contient aucun texte, vous pouvez afficher les informations de débogage en ouvrant la console JS du navigateur et en tapant debugUnformattedCodeDetector()Entrée. Cela affichera des informations sur les lignes considérées comme du « code » et sur les paramètres de sensibilité.
« Ne plus afficher ce message » ne fonctionne que par appareil, et non par utilisateur. Il s’agit d’un problème connu qui sera résolu dès que Discourse disposera de la fonctionnalité permettant d’attacher les informations utilisateur aux thèmes.
Hébergé par nous ? Les composants de thème sont disponibles pour une utilisation sur nos offres Standard, Business et Entreprise.
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.
Petite précision : nous allons officiellement intégrer ce composant sous peu et travaillerons en étroite collaboration avec @lionel-rowe et @david pour y parvenir. Toute idée ou tout retour, c’est le moment de les partager !
Je ne sais pas si cela a du sens, mais ce serait formidable si cela pouvait également alerter sur les erreurs Markdown les plus courantes qui brisent la mise en forme.
Ce serait également super d’avoir un indice indiquant où se trouve le code présumé non formaté.
Je rédigeais simplement une autre réponse lorsque l’alerte s’est affichée, bien que je n’aie collé aucun code. Après un moment, j’ai réalisé que c’était parce que j’avais utilisé le mot topic_id… Mais il n’est pas évident que le détecteur considère ce mot comme du code (et la plupart des gens ne penseraient pas cela), à mon avis.
Je pense qu’un mot contenant un underscore ne signifie pas nécessairement qu’il s’agit de code.
Merci pour tous vos retours jusqu’à présent, les amis ! Nous allons ajouter et ajuster quelques paramètres pour réduire la sensibilité excessive de la détection.
@tpetrov une autre chose — le libellé de la fenêtre contextuelle indique-t-il clairement que vous pouvez choisir de l’ignorer et publier quand même si vous ne pensez pas que votre message contient du code ? Ou donne-t-il l’impression que vous êtes obligé de trouver et de « corriger » le problème perçu ?
Mon inquiétude est que beaucoup de gens ne liront pas tout le texte…
Vous savez, quand les gens voient une fenêtre contextuelle avec plus d’une phrase de texte de nos jours, ils semblent ignorer le texte et chercher le bouton Ok (J’accepte les cookies, les conditions, etc.).
Pourtant, peut-être que « Il semble que votre publication puisse contenir du code non formaté » pourrait être remplacé par « Utilisez-vous du code dans votre publication ? », car parfois les questions attirent plus l’attention.
Je ne suis pas expert en UX, mais ce bouton semble un peu nucléaire : - quelque chose que je n’aimerais pas cliquer. Ce qui est bien sûr l’idée : que les gens ne le sautent pas simplement au lieu d’essayer de mieux formater leur publication.
Oooh, j’aime bien cette idée… mais je viens d’avoir un faux positif :
Peut-être que ce sont les liens brisés qui ont déclenché le problème ? Ils sont simplement extraits du moteur de templating et ressemblent à : [keep things civilized](%{guidelines_url}). Ou peut-être la balise HTML img ?
Nous déployons de nouveaux textes et constituons un corpus d’exemples de publications de test positives et négatives pour le composant. Merci de votre patience, car cela prend une belle forme !
Une petite remarque : par défaut, le contenu de warning_modal demande le bouton d’outil « code », mais ce bouton est nommé « Texte préformaté » dans l’éditeur lorsque vous passez la souris dessus.
Pour faciliter la tâche aux nouveaux utilisateurs afin qu’ils trouvent ce bouton (ils ne trouveront aucun bouton « code »), le contenu de warning_modal devrait être modifié de « bouton code » vers « bouton Texte préformaté ».
Pire encore : il suffit de cliquer dans le champ de saisie warning_modal.content, puis de déplacer le curseur avec les flèches pour que le champ de saisie soit surligné. Après avoir cliqué sur la coche verte pour enregistrer le warning_modal.content « modifié » (aucun changement n’a été apporté, juste le déplacement du curseur d’un caractère), la mise en forme est brisée comme illustré ci-dessus.
@codinghorror@lionel-rowe Vous devriez peut-être examiner cela et ajuster le warning_modal.content par défaut en conséquence concernant les espaces et les accents graves (les espaces manquants dans la section « multiplelines » lourdement équipée d’accents graves étaient à l’origine des problèmes décrits ci-dessus).
Existe-t-il un moyen de rendre plus clair pour l’utilisateur quelle touche choisir pour les délimiteurs de code s’il le fait manuellement (c’est-à-dire pas via le bouton) ?
L’utilisateur a évidemment essayé de suivre les instructions, mais a choisi la mauvaise touche pour les délimiteurs de code ( ' au lieu de `). Par le passé, j’ai également vu ... au lieu de ```. Dans les deux cas, cela indique que les utilisateurs ont besoin d’instructions plus explicites sur la touche à choisir.
Autre option : ne pas confondre les utilisateurs avec ces touches et simplement indiquer : utilisez le bouton « Texte préformaté » et c’est terminé.
@lionel-rowe Comment puis-je personnaliser le comportement de détection ?
Actuellement, le shebang n’est pas détecté comme du code, et je souhaiterais modifier cela.
Comportement attendu : #! indique le début d’un script et devrait donc être détecté comme du code.
En plus de cela, il serait utile pour nous que root@ soit détecté comme du code.
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
Il n’existe actuellement aucun moyen de personnaliser chaque site, non. Nous pourrions cependant envisager d’ajouter la détection du shebang et de l’invite de shell au système « code energy ».
La plupart des sites Discourse utilisent Discourse comme outil de dépannage. Ce plug-in convient-il aux tâches suivantes, et pas seulement pour le code :
Linux :
Journaux
Ligne de commande Linux (CLI)
Sortie du terminal
Par exemple :
Capteurs :
Températures du système : CPU : 78,0 °C, carte mère : 36,0 °C, GPU : nouveau temp : 56,0 °C
Vitesses des ventilateurs (tr/min) : CPU : 0, ventilateur-1 : 3139, ventilateur-3 : 0, ventilateur-5 : 0
Alimentation : 12 V : N/A, 5 V : 2,90, 3,3 V : N/A, batterie : 3,34
« Ne plus afficher ce message » ne fonctionne que par appareil, et non par utilisateur. Il s’agit d’un problème connu qui sera résolu dès que Discourse disposera de la fonctionnalité permettant d’attacher les informations utilisateur aux thèmes.
Hébergé par nous ? Les composants de thème sont disponibles pour une utilisation sur nos offres Standard, Business et Entreprise.
- quelque chose que je n’aimerais pas cliquer. Ce qui est bien sûr l’idée : que les gens ne le sautent pas simplement au lieu d’essayer de mieux formater leur publication.
