A sensibilidade e se o HTML é detectado são configuráveis por meio das configurações do tema.
Configurações
Nome
Descrição
ícone emoji
O ícone emoji a ser exibido ao lado do título no modal de aviso de código não formatado.
desativar no nível de confiança
Desativar o aviso para usuários com nível de confiança N ou superior. -1 = ativado para todos os usuários.
sensibilidade
Sensibilidade do algoritmo de detecção. 0 = plugin desativado; 1 = avisar para qualquer coisa que pareça minimamente com código.
tamanho mínimo da postagem para verificar
Tamanho mínimo da postagem para verificar (número de caracteres)
tamanho máximo da postagem para verificar
Tamanho máximo da postagem para verificar (número de caracteres). -1 = sem máximo.
incluir html
Verificar tags HTML, além de outros tipos de código. Recomendado desativar se os usuários frequentemente precisarem renderizar HTML personalizado em suas postagens.
Tradução
Padrão
warning_modal.title
Você está postando código?
warning_modal.content
Parece que sua postagem pode conter código ou logs. Para manter sua postagem legível, lembre-se de formatar seu código usando o botão da barra de ferramentas Texto pré-formatado, ou a tecla de crase ` do seu teclado, assim: [exemplos]
warning_modal.do_not_show_again
não mostrar esta mensagem novamente
warning_modal.fix_post
Editar Postagem
warning_modal.ignore_and_post_anyway
Publicar Mesmo Assim
Depuração
Se você receber um aviso para uma postagem que não inclui nenhum texto, você pode imprimir informações de depuração abrindo o console JS do navegador e digitando debugUnformattedCodeDetector()Enter. Isso imprimirá algumas informações sobre quais linhas foram consideradas ‘código’ e quais são as configurações de sensibilidade.
“Não mostrar esta mensagem novamente” funciona apenas por dispositivo, não por usuário. Este é um problema conhecido e será corrigido assim que o Discourse ganhar a funcionalidade de anexar informações do usuário aos temas.
Hospedado por nós? Componentes de tema estão disponíveis para uso em nossos planos Standard, Business e 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.
Nota rápida: em breve vamos oficializar este componente e trabalharemos em estreita colaboração com @lionel-rowe e @david para chegar lá. Qualquer ideia ou feedback, agora é o momento de compartilhar!
Seria ótimo também se houvesse uma indicação de onde está o código não formatado suspeito.
Estava apenas escrevendo outra resposta e recebi o alerta, embora não tivesse colado nenhum código. Depois de um tempo, percebi que foi porque usei a palavra topic_id… Mas não é óbvio que o detector considera essa palavra como código (e a maioria das pessoas não pensaria assim), na minha opinião.
Acho que, quando uma palavra tem um sublinhado, isso não significa necessariamente que seja código.
Obrigado por todo o feedback até agora, pessoal! Vamos adicionar e ajustar algumas configurações para reduzir a sensibilidade excessiva da detecção.
@tpetrov uma outra coisa — o texto do popup deixa claro que você pode optar por ignorá-lo e publicar mesmo assim, se achar que sua publicação não contém código? Ou ele dá a impressão de que você é obrigado a encontrar e “corrigir” o problema percebido?
Minha preocupação é que muitas pessoas não vão ler tudo…
Sabe, quando as pessoas veem um pop-up com mais de uma frase de texto hoje em dia, elas parecem ignorar o texto e procurar pelo botão Ok (Eu aceito cookies, termos, etc.).
Ainda assim, talvez “Parece que sua postagem pode conter código sem formatação” possa ser alterado para “Você usa código em sua postagem?”, já que às vezes perguntas chamam mais atenção.
Não sou especialista em UX, mas esse botão parece um pouco nuclear: - algo que eu não gostaria de clicar. O que, claro, é a ideia: que as pessoas não simplesmente ignorem isso em vez de tentar formatar melhor sua postagem.
Oooh, gostei dessa ideia… mas acabei de ter um falso positivo:
Pode ter sido os links quebrados que confundiram o sistema? Eles são apenas extraídos do motor de template e se parecem com: [mantenha as coisas civilizadas](%{guidelines_url}). Ou talvez seja a tag HTML img?
Estamos lançando novos textos e construindo um corpus de postagens de teste positivas e negativas para o componente. Aguentem firme, pois isso está tomando forma de maneira muito boa!
Pequeno detalhe: O padrão do warning_modal.content está pedindo o botão da barra de ferramentas “code”, mas esse botão é chamado de botão “Texto pré-formatado” no editor quando você passa o mouse sobre ele.
Para facilitar que novos usuários encontrem esse botão (eles não encontrarão nenhum botão “code”), o warning_modal.content deve ser alterado de “botão code” para “botão Texto pré-formatado”.
Pior ainda: basta clicar no campo de entrada warning_modal.content e depois mover o cursor com as setas para fazer o campo de entrada ficar destacado. Após clicar no marca de verificação verde para salvar o warning_modal.content “editado” (nenhuma alteração foi feita, apenas movendo o cursor um caractere), a formatação é quebrada como mostrado acima.
@codinghorror@lionel-rowe Talvez vocês devam investigar isso e ajustar o warning_modal.content padrão de acordo, com relação a espaços e crases (espaços ausentes dentro da seção “multiplelines” fortemente equipada com crases estavam causando os problemas descritos acima).
Existe alguma maneira de tornar mais claro para o usuário qual tecla escolher para os blocos de código se ele estiver fazendo isso manualmente (ou seja, não via botão)?
O usuário obviamente tentou seguir as instruções, mas escolheu a tecla errada para os blocos de código (' em vez de `). No passado, também vi ... em vez de ```. Ambos os casos indicam que os usuários precisam de instruções mais explícitas sobre qual tecla escolher.
Alternativamente: Não confunda os usuários com essas teclas e diga apenas: Use o botão “Texto pré-formatado” e está feito.
@lionel-rowe Como posso personalizar o comportamento de detecção?
Atualmente, o shebang não é detectado como código, e eu gostaria de alterar isso.
Comportamento esperado: #! indica o início de um script e, portanto, deve ser detectado como código.
Além disso, seria útil para nós se root@ fosse detectado 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
No momento, não há como ter personalizações por site, não. Poderíamos, certamente, considerar a adição de detecção de shebang e prompt de shell ao sistema de ‘code energy’.
A maioria dos sites Discourse usa o Discourse como ferramenta de solução de problemas. Este plug-in é adequado para as seguintes tarefas, não apenas para código:
Linux:
Logs
Comandos CLI do Linux
Saída do Terminal
Por exemplo:
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
“Não mostrar esta mensagem novamente” funciona apenas por dispositivo, não por usuário. Este é um problema conhecido e será corrigido assim que o Discourse ganhar a funcionalidade de anexar informações do usuário aos temas.
Hospedado por nós? Componentes de tema estão disponíveis para uso em nossos planos Standard, Business e Enterprise.
- algo que eu não gostaria de clicar. O que, claro, é a ideia: que as pessoas não simplesmente ignorem isso em vez de tentar formatar melhor sua postagem.
