La sensibilidad y si detecta HTML son configurables mediante la configuración del tema.
Configuración
Nombre
Descripción
emoji icon
El icono de emoji que se mostrará junto al título en el modal de advertencia de código sin formato.
disable at trust level
Desactivar la advertencia para usuarios con un nivel de confianza de N o superior. -1 = habilitado para todos los usuarios.
sensitivity
Sensibilidad del algoritmo de detección. 0 = el complemento está desactivado; 1 = advertir por cualquier cosa que parezca ligeramente código.
min post length to check
Longitud mínima del mensaje a verificar (número de caracteres)
max post length to check
Longitud máxima del mensaje a verificar (número de caracteres). -1 = sin máximo.
include html
Verificar etiquetas HTML además de otros tipos de código. Se recomienda desactivar si los usuarios necesitan renderizar HTML personalizado con frecuencia en sus mensajes.
Traducción
Predeterminado
warning_modal.title
¿Estás publicando código?
warning_modal.content
Parece que tu mensaje puede contener código o registros. Para mantener tu mensaje legible, recuerda formatear tu código usando el botón de la barra de herramientas Texto preformateado, o la tecla de comillas invertidas ` en tu teclado, así: [ejemplos]
warning_modal.do_not_show_again
no mostrar este mensaje nuevamente
warning_modal.fix_post
Editar mensaje
warning_modal.ignore_and_post_anyway
Publicar de todos modos
Depuración
Si recibes una advertencia por un mensaje que no incluye ningún texto, puedes imprimir información de depuración abriendo la consola JS del navegador y escribiendo debugUnformattedCodeDetector()Enter. Esto imprimirá información sobre qué líneas se consideraron ‘código’ y cuáles son los ajustes de sensibilidad.
“No mostrar este mensaje nuevamente” solo funciona por dispositivo, no por usuario. Este es un problema conocido y se solucionará una vez que Discourse obtenga la funcionalidad para adjuntar información de usuario desde los temas.
¿Alojado por nosotros? Los componentes del tema están disponibles para usar en nuestros planes Estándar, Empresarial y Corporativo.
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 nota rápida: pronto haremos oficial este componente y trabajaremos de cerca con @lionel-rowe y @david para lograrlo. ¡Si tienes alguna idea o comentario, este es el momento de compartirlos!
También sería genial si hubiera una pista sobre dónde se encuentra el código sin formato sospechoso.
Estaba escribiendo otra respuesta y recibí la alerta, aunque no había pegado ningún código. Después de un tiempo me di cuenta de que era porque usé la palabra topic_id… Pero no es obvio que el detector piense que esta palabra es código (y la mayoría de la gente no lo pensaría), en mi opinión.
Creo que cuando una palabra tiene un guion bajo, eso no significa necesariamente que sea código.
¡Gracias a todos por sus comentarios hasta ahora, gente! Vamos a añadir y ajustar algunas configuraciones para reducir la sensibilidad excesiva de la detección.
@tpetrov, otra cosa: ¿el texto del mensaje emergente deja claro que puedes elegir ignorarlo y publicar de todos modos si no crees que tu publicación contiene código? ¿O da la impresión de que estás obligado a buscar y “arreglar” el problema percibido?
Mi preocupación es que mucha gente no lo leerá…
Sabes, cuando la gente ve un popup con más de una frase de texto hoy en día, parece que ignoran el texto y buscan el botón Ok (Acepto cookies, términos, etc.).
Aun así, quizás “Parece que tu publicación puede contener código sin formato” podría cambiarse por “¿Usas código en tu publicación?”, ya que a veces las preguntas llaman más la atención.
No soy experto en UX, pero este botón parece un poco nuclear: — algo que a mí no me gustaría hacer clic. Lo cual, por supuesto, es la idea: que la gente no lo omita simplemente, sino que intente formatear mejor su publicación.
¡Oooh, me gusta esta idea… pero acabo de obtener un falso positivo:
¿Podría haber sido que los enlaces rotos lo activaron? Solo se toman del motor de plantillas y se ven así: [mantén las cosas civilizadas](%{guidelines_url}). ¿O tal vez la etiqueta HTML img?
Estamos implementando nuevos textos y creando un corpus de publicaciones de prueba positivas y negativas para el componente. Tengan un poco de paciencia, ya que todo está tomando buena forma.
Una pequeña observación: el valor predeterminado de warning_modal.content solicita el botón de la barra de herramientas “code”, pero este botón se llama “Texto preformateado” en el editor cuando pasas el mouse sobre él.
Para facilitar a los nuevos usuarios la búsqueda de este botón (ya que no encontrarán ningún botón llamado “code”), el contenido de warning_modal.content debería cambiarse de “botón code” a “botón Texto preformateado”.
Peor aún: simplemente hacer clic en el campo de entrada de warning_modal.content y luego mover el cursor con las flechas hace que el campo de entrada se resalte. Después de hacer clic en la marca de verificación verde para guardar el warning_modal.content “editado” (no se ha realizado ningún cambio, solo mover el cursor un carácter), el formato se rompe como se muestra arriba.
@codinghorror@lionel-rowe Quizás deberían revisar esto y ajustar el warning_modal.content predeterminado en consecuencia con respecto a los espacios y las comillas invertidas (la falta de espacios dentro de la sección “multiplelines” muy equipada con comillas invertidas estaba causando los problemas descritos anteriormente).
¿Existe alguna manera de hacer más claro para el usuario qué tecla debe elegir para los delimitadores de código si lo hace manualmente (es decir, no mediante el botón)?
El usuario obviamente intentó seguir las instrucciones, pero eligió la tecla incorrecta para los delimitadores de código (' en lugar de `). En el pasado también he visto ... en lugar de ```. Ambos casos indican que los usuarios necesitan instrucciones más explícitas sobre qué tecla elegir.
Alternativamente: No confundas a los usuarios con esas teclas y simplemente di: Usa el botón “Texto preformateado” y ya está.
@lionel-rowe ¿Cómo puedo personalizar el comportamiento de detección?
Actualmente, el shebang no se detecta como código, y me gustaría cambiar esto.
Comportamiento esperado: #! indica el inicio de un script y, por lo tanto, debería detectarse como código.
Además de esto, sería útil para nosotros que root@ se detectara como código.
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
Por ahora, no hay ninguna forma de tener personalizaciones por sitio. Sin embargo, podríamos considerar añadir la detección de shebang y del indicador de shell al sistema de ‘code energy’.
La mayoría de los sitios de Discourse utilizan Discourse como herramienta de resolución de problemas. ¿Es este complemento adecuado para las siguientes tareas, no solo para código?
Linux:
Registros
Interfaz de línea de comandos (CLI) de Linux
Salida de terminal
Por ejemplo:
Sensores:
Temperaturas del sistema: cpu: 78.0 C placa_madre: 36.0 C gpu: nouveau temp: 56.0 C
Velocidades de ventiladores (RPM): cpu: 0 fan-1: 3139 fan-3: 0 fan-5: 0
Energía: 12v: N/A 5v: 2.90 3.3v: N/A vbat: 3.34
“No mostrar este mensaje nuevamente” solo funciona por dispositivo, no por usuario. Este es un problema conocido y se solucionará una vez que Discourse obtenga la funcionalidad para adjuntar información de usuario desde los temas.
¿Alojado por nosotros? Los componentes del tema están disponibles para usar en nuestros planes Estándar, Empresarial y Corporativo.
— algo que a mí no me gustaría hacer clic. Lo cual, por supuesto, es la idea: que la gente no lo omita simplemente, sino que intente formatear mejor su publicación.
