Wikipédia:Filtro de edições/38
| Sequência longa sem espaços | |
|---|---|
| Status | |
| Etiquetando | |
| Manutenção | |
| Resumo | |
| Ferramentas | |
| Falsos positivos | |
| Total | 33 |
| Lista | Lista filtrada (com gadget) (PS: futuramente, poderíamos ver os 5 mais recentes aqui mesmo) |
| Tarefas | |
Mais um filtro desatualizado em relação a versão anglófona en:Special:AbuseFilter/135. O atual não conseguiu detectar este vandalismo. Minha sugestão é atualizar o código, monitorar e eventualmente no futuro acionar um aviso.OTAVIO1981 (discussão) 18h45min de 24 de junho de 2013 (UTC)
- Neste exemplo o que aconteceu foi que a regex "
[^ \,\n\|\/\-]{50,}" não detecta "== Níveis tróficos ==vfghgkfhksdyghvhkneaknc" pois há no máximo 25 caracteres consecutivos (bem menos do que 50) satisfazendo a condição indicada. Helder 16h30min de 25 de junho de 2013 (UTC) - No entanto, o filtro original é o en:Special:AbuseFilter/231 (no spaces) não o en:Special:AbuseFilter/135 (repeating characters). Helder 16h38min de 25 de junho de 2013 (UTC)
- O filtro anglófono consegue detectar este vandalismo? O código
(old_size > 0) &daqui me parece desnecessário pois sempre será um valor positivo. Talvez atualizar já seja o suficiente. Se após um período de testes ficar bem, podemos deixar no modo avisar.OTAVIO1981 (discussão) 17h24min de 25 de junho de 2013 (UTC)- Este filtro tem uma boa quantidade de disparos e está configurado para fazer nada. Acredito que deveria ser o próximo a ser atualizado para monitorar e alterar. Já fiz a primeira amostragem dele, focando nos salvamentos visto que em alguns casos o editor não prossegue salvando visto que ele tem um conflito com o filtro 3 e 10.OTAVIO1981 (discussão) 17h32min de 10 de julho de 2013 (UTC)
- O filtro anglófono consegue detectar este vandalismo? O código
- 1352325 detectou o cabeçalho da tabela, feito sem espaço, provavelmente copiado de outro lugar
!Part.!!Goles!!Part.!!Goles!!Part.!!Goles!!Part.!!Goles(cabeçalho, sem espaço). Talvez uma exceção para linhas que começam com!ou com|? Ou para edições que adicionam uma linha{|(início tabela) para não detectar ocorrências em linhas começando com!e|? Rjclaudio msg 13h37min de 19 de julho de 2013 (UTC)
- Eu preferiria utilizar uma "lista explicita das letras e números" (
[a-záâãéêíóôõúçA-ZÁÂÃÉÊÍÓÔÕÚÇ0-9]), como na wiki em inglês em vez de "negar que sejam símbolos especiais" ([^ \,\n\|\/\-]). Caso contrário, pode não ficar confiável o bastante para passar a avisar os editores. Helder 14h22min de 19 de julho de 2013 (UTC)- Enquanto não se decide se usamos uma lista explícita ou não, mudei o filtro para ignorar o _ para evitar casos como o abaixo (e outros que achei). Rjclaudio msg 14h22min de 28 de julho de 2013 (UTC)
Feito, exceção para ! na sequencia de caracteres. Vai deixar de detectar alguns vandalismos, mas ao menos não vai detectar essas edições válidas. Rjclaudio msg 13h49min de 15 de agosto de 2013 (UTC)
- 1347843 teve um qnd adicionaram um link interno que usa
_no lugar de espaço. Outra exceção? Caso a linha tenha[[contar_como espaço? Rjclaudio msg 13h39min de 19 de julho de 2013 (UTC)
- Feito, não conta _ na sequencia. Rjclaudio msg 13h49min de 15 de agosto de 2013 (UTC)
- 1352199 , campo de predef é uma lista, usando a tag <code>br</code> para a quebra de linha. Expandir o filtro para espaço ou br? Rjclaudio msg 13h57min de 19 de julho de 2013 (UTC)
- Feito, exceção para edições que adicionem a tag <code>br</code> Rjclaudio msg 13h49min de 15 de agosto de 2013 (UTC)
- 1352199 (mesmo acima) a linha detectada passava dos 90 caracteres qnd a edição adicionou uns 10 caracteres. Então, só detectar se as linhas removidas não tiverem + de 50 caracteres? Chato um usuário adicionar conteúdo seguindo o padrão que já existia e receber um aviso. Rjclaudio msg 13h57min de 19 de julho de 2013 (UTC)
- 1352041 usaram nbsp; no lugar de espaço ( [[O Homem de La Mancha|''Man of La Mancha'' (play)]]: ) , não sei pq (acho que é para o texto não ter quebra de linha no meio do texto). Outra exceção? Rjclaudio msg 13h57min de 19 de julho de 2013 (UTC)
- Feito, exceção para edições que adicionem <code>nbsp</code> Rjclaudio msg 13h49min de 15 de agosto de 2013 (UTC)
- 1351797 a url começa com ftp:// então não deve ter detectado Rjclaudio msg 13h57min de 19 de julho de 2013 (UTC)
Exceção para outros filtros[editar código-fonte]
A maior parte das ocorrências também são detectadas pelo Filtro 39 - Sequência de pontuação ou pelo Filtro 10 - Caracteres repetidos. Então coloquei no código uma exceção para não detectar os casos que já são pegos por esses dois filtros. Ao menos para os testes, isso deve limpar um pouco os registros e melhorar a nossa análise do filtro. Depois que o filtro aumentar de nível retiramos isso. Rjclaudio msg 14h24min de 18 de agosto de 2013 (UTC)
- Interessante este recurso. Significa que dá para estruturar os filtros numa ordem específica. Por exemplo, podemos colocar o de remoção de predefinição para disparar somente quando o branqueamento (2) não for disparado. E se colocarmos esta exceção como a primeira condição, as aumenta o tempo de execução do filtro pois as incidências são poucas para o branqueamento (2), por exemplo.OTAVIO1981 (discussão) 13h32min de 30 de agosto de 2013 (UTC)
- De certa forma eu já fazia isso, alguns filtros tinham um
new_size>40. A ideia é voltar a usar isso? Só colocar onew_size>40, ou um! (new_size < 40 & old_size > 500)? Colocaria isso em todos (?) os filtros de remoção e de strings? Mts casos de ofensas / strings aleatórias, também são branqueamento. Rjclaudio msg 16h19min de 30 de agosto de 2013 (UTC)- Vou precisar de mais tempo para amadurecer a idéia de como podemos tirar proveito disso. Por enquanto estou só processando a novidade. 17h vou entrar no IRC, se quiser conversar disso vai ser muito bom.OTAVIO1981 (discussão) 17h34min de 30 de agosto de 2013 (UTC)
- De certa forma eu já fazia isso, alguns filtros tinham um
Unused variable[editar código-fonte]
@!Silent:
(Apologize for using English. I don't know how to write Portuguese.)
Hello! My tool discovers that Special:AbuseFilter/38 creates a variable sequence_counterFP but does not actually use it. There are two possibilities why this could happen: either sequence_counterFP is not needed, and it could be safely removed, or the filter is buggy, and it should be corrected. Please let me know if you need any additional information. --Nullzero (discussão) 05h49min de 7 de novembro de 2019 (UTC)