Wikipedia:Filtro de ediciones/Implementación/Archivo 2019

Artículos buenos

Asunto

• El filtro 20 limita la capacidad de agregar la plantilla {{Artículo bueno}} a usuarios no autoconfirmados. Y sin embargo el filtro 19 limita la capacidad análoga con los {{Artículo destacado}} a los ACAD. Propongo que solamente los bibliotecarios y responsables de la sección de artícuos buenos (si los hay) sean los autorizados a agregar la primera plantilla, para evitar esta situación. Además hago notar la diferencia de programación entre ambos filtros, siendo el 19 mucho más exhaustivo en su comprobación, por lo que sugiero renovar el filtro 20 con la misma programación.

Comentario: de renovar el código, debería decir: "Añadido o retirada de plantilla de artículo bueno realizada por un usuario no autorizado (no bibliotecario)" --VR0: ニャー! Deja tu mensaje, ニャー! 01:34 7 ene 2019 (UTC)

Comentario Salvo que haya habido algún cambio de norma últimamente, no hay «responsables» específicos de los artículos buenos. Según el procedimiento, el que evalúa y aprueba un artículo es el que debe añadir la etiqueta de artículo bueno en los artículos.Dodecaedro (discusión) 20:04 7 ene 2019 (UTC)

Usuario que lo solicita

• Leoncastro (discusión) 19:38 6 ene 2019 (UTC)

Respuesta

Ver comentario de Dodecaedro, el requisito para poder aprobar un artículo como bueno es haber nominado con éxito un artículo a esta categoría. --Xana (discusión) 21:35 9 ene 2019 (UTC)

Filtro para impedir creación del artículos con la plantilla {{ficha de localidad}}

Puesto que está pendiente desde hace años la fusión de las plantillas {{ficha de localidad}} con la de {{ficha de entidad subnacional}} sería conveniente que se implementara un filtro para evitar que los usuarios siguiéramos creando artículos con la primera de las fichas para evitar trabajo extra a otros usuarios que posteriormente realizan el cambio a la plantilla principal, como por ejemplo aquí. El tema ha sido tratado en el café recientemente aquí.Dodecaedro (discusión) 14:48 7 ene 2019 (UTC)

De seguro vá al filtro 69. Algún bibliotecario debe agregar esta plantilla al filtro. --VR0: ニャー! Deja tu mensaje, ニャー! 17:20 7 ene 2019 (UTC)

 Hecho --Xana (discusión) 21:30 9 ene 2019 (UTC)

Please fix filter 82

Hi everyone, and sorry for writing in english. I'm here to kindly ask someone to please take a look at Especial:FiltroAntiAbusos/82. Per logstash metrics, the filter has a really poor performance and it can take up to 30 seconds to be executed (happened at least three times in the last 24 hours). I think it's not acceptable to delay a user's edit that much. My suggestion is to optimize the regex, although I'm not coming here with a ready solution :/ In case you need a bit more of context in order to tune the regex (and given that the filter is public), I can say that this is one of the edits which caused a timeout. Should you need some help, feel free to ask but please ping me. Many thanks, --Daimona Eaytoy (discusión) 17:01 9 ene 2019 (UTC)

Looking again, I wrote a new version of the filter here. The regex is slightly different, but way quicker. Please check it out (and feel free to delete the sandbox if you don't want that around). Thanks again, --Daimona Eaytoy (discusión) 18:13 9 ene 2019 (UTC)

Bump. This filter still has horrible performance. Today, it even delayed an edit by 75 seconds! I can help you for whatever you need with abuse filters, but please fix this filter ASAP. It's highly unacceptable to delay an edit that much. Ping @XanaG: which seems to be active here. --Daimona Eaytoy (discusión) 12:23 24 ene 2019 (UTC)

Hi, I have to have a look at this when I have more time. I get the impression that the regexps are not exactly equivalent, but it may just be that I don't understand fully what exactly the filter is doing. I was hoping that one of the authors would pick this up instead.--Xana (discusión) 19:30 24 ene 2019 (UTC)

Con permiso, XanaG, efectivamente las dos expresiones regulares no son equivalentes, sin embargo hay bastantes cosas que se pueden implementar ya sin alterar tal expresión. Para empezar, en la propuestra de Daimona Eaytoy, se simplifica de entrada la doble comprobación «contiene 'confirmed'» y «contiene 'autoconfirmed'» en una sola comprobación, dado que 'confirmed' forma parte de 'autoconfirmed'. En la segunda línea se vuelve a simplificar la comprobación de la página. Y pasando por alto la diferencia en la expresión, las funciones lcase no aportan absolutamente nada, pues la expresión actual usa \S, que abarca tanto mayúsculas como minúsculas, y en la expresión propuesta se usa el calificativo (?i) para ignorar el estado de las capturas [a-z]. Esos tres cambios ya pueden —y deberían— hacerse.

Sin embargo, el principal problema creo que está en la propia expresión, pues usa bloques perezosos (lazy quantifiers; aquellos con +?), que fuerzan a capturar el bloque de menor tamaño posible (y no el de mayor tamaño, que es la opción por defecto). Las diferencias entre ambas empresiones se pueden visualizar mejor con la siguiente comparativa

 Act. :     (   \S+?  (?:\s   \S+?  )*)(?:\s+\1){6,}\b
 Prop.: (?i)([a-z]+ \s(?:  [a-z]+ \s)*)(?:\s*\1){6,}\b

La expresión actual busca el menor conjunto de caracteres aislados o no entre espacios, que además se copie consecutivamente al menos seis ocasiones más.

La expresión propuesta busca el mayor grupo de palabras o frases, que además se copie consecutivamente al menos en seis ocasiones más.

La diferencia principal está en las variaciones menor-mayor, y luego en que la actual tiene en cuenta los signos de puntuación (admiraciones, comas, puntos, comillas, corchetes, etc.) y la propuesta no (es decir, que \S no es igual a [a-z], incluso aunque se use el insensitive). Consecuencia del cambio: la propuesta se activa en muchos menos casos que la actual. Pro: mayor velocidad. Contra: ignora determinados casos. Un sencillo ejemplo que quedaría sin contemplación sería repetir «feo! feo! feo! feo! feo! feo! feo!», simplemente por culpa de la admiración.

Por lo tanto propongo una nueva alternativa, muy similar a la actual, pero sin los bloques perezosos. Sería el paso intermedio marcado en amarillo:

 Act. :     (   \S+?  (?:\s   \S+?  )*)(?:\s+\1){6,}\b   (ver ejemplo en https://regexr.com/4730o)
 Nueva:     (   \S+   (?:\s+  \S+   )*)(?:\s+\1){6,}     (ver ejemplo en https://regexr.com/4730u)
 Prop.: (?i)([a-z]+ \s(?:  [a-z]+ \s)*)(?:\s*\1){6,}\b   (ver ejemplo en https://regexr.com/4730r)

Se pueden ver ejemplos de cómo se comporta cada caso en los enlaces indicados.

Nótese que se mantienen los conjuntos de caracteres incluyendo puntuaciones y no solamente palabras, se prescinde de los bloques perezosos, se agrega la opción de contener espacios múltiples y se elimina el separador de palabra final que no viene al caso e incluso perjudica la captura de ciertos casos.

Por tanto —y perdón por toda esta cansina eplicación—, mi propuesta consiste en el siquiente código:

!('confirmed' in user_groups) /** Checks for 'autoconfirmed' too */
& !(equals_to_any(page_title, "Zona de puebras", "Taller"))
& action == 'edit'
& (
 texto:="(\S+(?:\s+\S+)*)(?:\s+\1){6,}";
 rcount(texto, added_lines) > rcount(texto, removed_lines)
 | summary rlike texto
)

Saludos. -- Leoncastro (discusión) 22:51 24 ene 2019 (UTC)

Gracias por la explicación. Precisamente no acababa de entender qué efecto tenía en la práctica el bloque perezoso y restringir la expresión a [a-z] me parece que tampoco detectaría acentos (¿o sí?). Probemos lo que sugieres.--Xana (discusión) 09:38 25 ene 2019 (UTC)

Sorry for writing in english again, I could understand alone most of the message above but cannot reply in spanish :/ @Leoncastro: You are right, the expression I proposed is not equivalent, and was meant to greatly simplify performance. First of, the improvements on the first lines are of course safe, and I also suggest you to apply them on every other filter (although that's not urgent). As for testing the new regex, you could also use the AbuseLog entry I posted above (this one), and I can also provide you the one which took 75 seconds, this one. Testing your proposed regex with the latter shows that it still times out, proof. The actual problem is the use of nested quantifiers in (\s+\S+)*, which creates tons of backtracking in an exponential fashion. My regex attempts to solve this by reducing the amount of allowed characters, although in fact this doesn't match in many cases, for instance when punctuation is used. Right now I don't have other proposed regexps, but a possible improvement would be to cap the amount of matches. For instance, supposing that the repeating pattern won't be longer than 5 words, you may change this

(\S+(?:\s+\S+)*)(?:\s+\1){6,}

to this

(\S+(?:\s+\S+){0,5})(?:\s+\1){6,}

And even if 5 isn't fine, you can increase it to 10, or even 20. In all cases the regex engine won't backtrack anymore and complete the match in a matter of milliseconds. Another tiny improvement is to remove the trailing comma in the last quantifier, i.e. change {6,} to {6}, although IIRC that has no effect as the regex engine already optimizes it. It would also be possible to cap the length of every word inside the repeating group. In short, a possible regex would be

(\S{1,20}(?:\s+\S{1,20}){0,20})(?:\s+\1){6}

which is a bit longer to write, but should match almost the same as the original one, and doesn't timeout neither on the first example (proof), nor the second (proof). It still doesn't have an optimal performance, but should reduce the impact for edge cases like these. --Daimona Eaytoy (discusión) 09:50 25 ene 2019 (UTC)

@XanaG: Watch out, there's an error in the regex: it is

(\S{1,20}(?:\s+\S{1,20})){0,20}(?:\s+\1){6}

instead of

(\S{1,20}(?:\s+\S{1,20}){0,20})(?:\s+\1){6}

note the third {0,20} which should be between two closed parentheses, instead of out of both. Thanks for fixing the filter! --Daimona Eaytoy (discusión) 11:27 25 ene 2019 (UTC)

Thanks for the headsup. --Xana (discusión) 12:14 25 ene 2019 (UTC)

@Daimona Eaytoy, sorry but I don't write english very well, and my message was addressed to XanaG who speak spanish. Spanish language usually uses characters with tildes, so [a-z] is not a good solution here. I tried to explain it to XanaG proposing to reduce the lazy quantifiers in the regexp. Thank you for improving the regexp. But note that remains some common cases unmatched. See that my proposal match here (1 match, ~620ms), but your solution goes to timeout with the same input. May be any other improvement here?

@XanaG, no te olvides de borrar las funciones lcase, que no están aportando absolutamente nada. -- Leoncastro (discusión) 20:46 25 ene 2019 (UTC)

┌──────────────────────────┘
@Leoncastro: No problem, after all this is eswiki, and anyway I can sort of understand Spanish :-) There are a couple of problems in your test regex: first, the link with my version has the wrong regex, see here. You tested the first version, but the correct one is the second (currently used by the filter). Testing the right one will still return no match, but won't timeout. Second, I suggest you to use PCRE mode (on the left) for testing, as that's the flavour of regexps used by AbuseFilter. Third, the /u/ modifier should be turned on, as it is for AbuseFilter; however, this doesn't help with tildes. I'm also well aware of the problem, since in Italian it's the same with accented characters... Sometimes we use [a-zàèéòìù] for that. On top of that, in the example you linked the repeating paragraph is very long, and goes past the cap of 20 words. Allowing more than 20 words would probably end up timing out again on different texts. Unfortunately I don't really have a well-performing alternative regex. All I can say is that filter 82 is now executing in an acceptable time, and you can partly see that yourselves on grafana. --Daimona Eaytoy (discusión) 10:53 26 ene 2019 (UTC)

Respuesta

 Hecho --Xana (discusión) 12:14 25 ene 2019 (UTC)

Artículos spameo masivo

En los últimos días he visto la creación de varios artículos (masivos) en inglés y referentes a diversos productos. Son cuentas creadas bien por usuarios verificados o por IP anónimos. Todo en inglés y son revertidas añadiendo etiquetas de spam y artículo publicado en otro idioma y sin traducción. Pero quisiera saber si los bibliotecarios pueden realizar alguna acción, crear algún filtro o bloquear proxys abiertos. Pichu VI (discusión) 15:55 3 mar 2019 (UTC)

Vandalismo/spam recurrente

Asunto

• Últimamente se está reproduciendo con frecuencia un modo de vandalismo/spam determinado que afecta a la interfaz general (véanse estas ediciones de diferentes vandalismos). Solicito un filtro que prevenga de la inclusión de tales ediciones, por ejemplo impidiendo la inclusión de estilos de posición fija, de las imágenes transparentes, o incluso de enlaces a retransmisiones en vivo de YouTube (que por cierto en este tipo de vandalismo es siempre el mismo enlace recurrente).

Estas DIFF que vi debería estar en el filtro de vandalismo con patrones específicos (Filtro Nº 2). --VR0: ニャー! Deja tu mensaje, ニャー! 16:55 18 feb 2019 (UTC)

• Comentario: nueva insistencia detectada. -- Leoncastro (discusión) 04:19 2 mar 2019 (UTC)

Usuario que lo solicita

• Leoncastro (discusión) 04:27 16 feb 2019 (UTC)

Respuesta

 Hecho, incluido en el filtro 2.--Xana (discusión) 18:47 7 mar 2019 (UTC)

Filter 82... Again

Hi everyone! Some time ago I reported that filter 82 was very slow to be executed (up to a minute) due to a faulty regex. Since a few days ago, I started seeing this filter on logstash again, because a catastrophic backtracking occurs and the filter doesn't match. See here for an example of it happening. Could someone please fix it again? Ping @XanaG: who made the last edit to the filter. Thanks! P.S. Please ping me back. --Daimona Eaytoy (discusión) 18:19 22 mar 2019 (UTC)

I think (or hope) that it is not backtracking so much any longer, although it looks like we still may have false positives with tables.--Xana (discusión) 09:33 24 mar 2019 (UTC)

No permitir que se inserte «TBA»

Debería haber un filtro que no permita que se inserte «TBA» en artículos y anexos. Es un anglicismo que se supone que hay que evitar, pero hay usuarios que insisten en colocarlo aunque los reviertan varias veces (como se puede ver aquí, pueden ver en el historial como el usuario insiste con eso, y aquí), sin mencionar que no hacen caso cuando se les envía un mensaje diciéndoles que eso es incorrecto. Por ello, lo mejor que se puede hacer es implementar un filtro para así evitar que los demás editores pierdan su tiempo revirtiendo esas ediciones y que se sobrecarguen los historiales.—191.126.11.200 (discusión) 06:08 27 abr 2019 (UTC)

Intento de edicion pero el sistema me pone que lo comente con Bibliotecario. Help ! :-)

hola , buenos dias . Queria modificar este espacio con una pequeña mejora y no me deja, pone que hable con un bibliotecaria, me gustaria que me ayudaras.

___Este espacio: https://es.wikipedia.org/wiki/Usuario:Francisco_revaliente Quiero poner el texto abajo escrito , algo mas actualizado ya que paso el tiempo --->

___Texto a poner a cambio: "Francisco Revaliente nacio en Melbourne (Australia) en el año 1972, aunque nació en las antípodas, es Valenciano de adopción. Este empresario de vocación lleva toda la vida en el mundo empresarial, creando varias proyectos muchos de ellos con gran renombre. APP informática fue la empresa más importante creada junto a dos socios haya por el año 1992, en plena crisis del país. Pero eso no impidió crear el grupo mas importante durante muchos años del sector informático alcanzando en su momento cumbre mas de 700 tiendas en toda España y facturaciones por encima de los 60 millones de euros. En el año 2016 se desvinculo de la empresa vendiendo sus participaciones a los actuales socios, para desarrollar nuevas inquietudes y proyectos.

Otra empresas creadas por Francisco Revaliente fueron Zone Evil marca de accesorios de vídeo juegos, Vinooferta.com una tienda de vinos online, y las dos empresas que tiene activas en este momento: Malvarrosa Sunglasses, marca de gafas de sol en madera, y Grupo My Little, una empresa turística que la componen varios pequeños hoteles urbanos en la ciudad de Valencia. El Grupo My Little engloba varias marcas y formas de alojar como My Little Apartamento, My Little Lofts o My Little Beach. Grupo My Little en tan solo seis años se ha convertido en uno de los principales grupos de pequeños alojamientos de la capital del Turia." — El comentario anterior sin firmar es obra de Mylittleapartamento (disc. • contribs • bloq). 11:53 27 may 2019‎

Este no es lugar para esta solicitud, respondo en la página de discusión del usuario.--Xana (discusión) 18:14 31 may 2019 (UTC)

Revisar filtro

Asunto

• No hace mucho XanaG implementó en el filtro 2 una regla contra un tipo específico de vandalismo, según esta solicitud. El vandalismo es especialmente molesto para el usuario, dado que se antepone a la interfaz propia de Wikipedia, superponiendo sobre esta una imagen invisible que fuerza la pulsación a un enlace externo. Desconozco los criterios finalmente adoptados para detectar y filtrar este tipo de ediciones, pero está claro que actualmente los vándalos han sabido evadirlas. Supongo que se implementó detectando el enlace o la imagen, lo cual no es efectivo porque están usando acortadores y redirecciones para el primero, e imágenes alternativas para el segundo. Véanse recientemente estas ediciones: 1, 2, 3, 4 o 5 (nota: algunas de estas ediciones ya fueron ocultadas por Geom).
  Propongo nuevamente detectar —especialmente en plantillas— la inclusión de divisiones con estilos de posición fija, e imágenes de tamaños desproporcionados con cualquier enlace externo.

Usuario que lo solicita

• Leoncastro (discusión) 11:06 4 jul 2019 (UTC)

Respuesta

He ampliado la definición para que abarque todos estos casos (la modificación anterior estaba demasiado orientada al vandalismo específico y no al caso general).--Xana (discusión) 10:50 6 jul 2019 (UTC)

Evitar eliminación fraudulenta de denuncias

Hola, sugiero que un filtro de ediciones evite que se eliminen denuncias en WP:VEC para evitar que estas se eliminen fraudulentamente.

Estas acciones fraudulentas han sido realizadas por Jack Gaines (Usuario que utiliza cuentas títere para evadir el bloqueo) y puede ser realizada por cualquiera.

Ha ocurrido en: [1], [2], [3], [4].

Al principio propuse en el café que un bot lo revirtiera y me dijeron que era más fácil que lo pidiera aquí.

(Obviamente Jembot debe tener inmunidad al filtro)

Usuario que lo solicita

--SRuizR | ¡Para servirles! 00:30 2 jun 2019 (UTC)

Respuesta

 Hecho en el nuevo filtro 109, contemplando diversas formas de alteración de las denuncias (obviamente no daré detalles por WP:LLAVE). Aunque he hecho algunas pruebas satisfactorias contra ediciones pasadas, SRuizR, se agradecerá que vayas comprobando los disparos (o los posibles falsos negativos) y comentando cualquier ajuste o sugerencia que veas oportuno. - José Emilio –jem– Tú dirás... 08:36 14 jun 2019 (UTC)

Gracias -jem-, comprobaré los disparos y reportaré si hay un falso positivo o negativo. --SRuizR ¡Para servirles! 20:04 14 jun 2019 (UTC)

Falso negativo

@-jem-: Reporto falso negativo [5].

Respuesta

 Hecho. @SRuizR: Modifiqué el filtro para que también abarque casos como ese. Un saludo. —— ♠♠♠ Mr.Ajedrez  Comenta la jugada ♠♠♠ —— 12:42 6 jul 2019 (UTC)

Otro falso negativo

@-jem-:, @Mr.Ajedrez: [6] --SRuizR ¡Para servirles! 02:07 13 jul 2019 (UTC)

Respuesta

 Hecho, SRuizR. Con mis últimos cambios ya se impiden ese tipo de ediciones. Saludos, - José Emilio –jem– Tú dirás... 14:23 13 jul 2019 (UTC)

¿Bloquear?

@-jem-: Hola, se me ocurrió que talvez podría ser oportuno configurar el filtro antiabusos para bloquear automáticamente al usuario que altere una denuncia ya que si un usuario no confirmado está haciendo acciones que se consideran vandalismo, es reportado y elimina o altera su denuncia es bastante obvio que es un vándalo. Si se implementara esto sería útil advertir en las instrucciones de las páginas donde hay denuncias como WP:VEC o las secciones del tablón de bibliotecarios que estas no se alteren ya que resultaría en bloqueo. Si el filtro antiabusos notifica esto debería también decir "Si crees que fue un falso positivo puedes poner {{desbloquear|motivo de desbloqueo}} en tu página de discusión".

Creo que sería práctico ya que este filtro tiene un muy bajo número de falsos negativos ya que prácticamente ningún usuario de buena fe altera denuncias.

(Habría que configurar $wgAbuseFilterActions 'block' = true, ¿verdad?)

--SRuizR ¡Para servirles! 20:46 26 jul 2019 (UTC)

 En contra de activar un bibliotecario automático sin consultar debidamente a la comunidad. -- Leoncastro (discusión) 21:34 26 jul 2019 (UTC)

Procederé a plantearlo en el café, gracias.--SRuizR ¡Para servirles! 21:35 26 jul 2019 (UTC)

Planteado--SRuizR ¡Para servirles! 22:08 26 jul 2019 (UTC)

Comentario SRuizR, me doy por enterado y estaré al tanto de lo que se decida en el Café. Es una decisión que requiere valorar cuidadosamente si se obtienen más beneficios que inconvenientes (yo tengo algunas dudas), y en todo caso habría que esperar al proceso burocrático en Phabricator antes de que pudiéramos tener disponible esa opción de bloqueo en los filtros. - José Emilio –jem– Tú dirás... 08:20 29 jul 2019 (UTC)

Quiero poner esto en espera hasta que implementemos WP:BLOQUEO y se haga una votación correctamente.--SRuizR 23:00 5 ago 2019 (UTC)

Decisión final

 No, saludos--SRuizR 00:41 9 sep 2019 (UTC)

Respuesta

Tras descartarlo el proponente y ante la falta de consenso, también descarto y cierro la solicitud para que se archive. - José Emilio –jem– Tú dirás... 20:33 9 sep 2019 (UTC)

Renombrar filtros

Lista de filtros

• Filtro 49: Posible spam a blogs.
• Filtro 99: Vandalismo de Google Butts.
• Filtro 105: Spam de Matusalén en resúmenes de edición.

Usuario que lo solicita

--VR0: ニャー! Deja tu mensaje, ニャー! 17:12 18 feb 2019 (UTC)

Respuesta

@VR0: ¿Por qué lo quieres cambiar? ¿Solo para que aparezca en español?

Por ejemplo, el filtro 105 dice "Mathusalem" porque es la palabra que detecta. El resto del título está en inglés para no mezclar idiomas.

Platonides (discusión) 21:39 12 sep 2019 (UTC)

Filtros 18 y 78

Asunto

¿Alguien podría añadir este contenido? Gracias

Usuario que lo solicita

Metrónomo's truth of the day: «persevera y triunfarás» 11:49 27 jul 2019 (UTC)

Respuesta

 Hecho en el filtro 18, Metrónomo. Respecto al filtro 78, parece un subconjunto del del 18, así que yo más bien lo retiraría. Como autor de este último, ¿hay alguna razón especial para tenerlo como un filtro separado? Platonides (discusión) 21:41 12 sep 2019 (UTC)

Platonides: hoy en día no lo se, no les he dado un vistazo, pero en su momento el 78 era una copia del 18 con un cambio. El 18 prevenía la edición a los usuarios no autoconfirmados impidiéndoles guardarlo. Lo que hice fue crear un aviso destinado a los que si son autoconfirmados que se activaría en el 78 y les obligara a hacer un segundo clic para guardar la edición. Esto debido a que tras revisar las ediciones del bot Panderine! (disc. · contr. · bloq.) noté que todas las ediciones que marcaba eran hechas por usuarios autoconfirmados (lógico, estando activo el filtro 18) y, obviamente, eran errores de dedo. La idea era que el aviso te advierta y retires al añadido accidental antes de grabar el cambio. En cambio, el 18 estaba más enfocado en prevenir vandalismos del tipo prueba de edición, tan increíblemente comunes. Saludos, Metrónomo's truth of the day: «persevera y triunfarás» 23:55 12 sep 2019 (UTC)

Falsos positivos en el filtro 80

Ver ejemplo. Tal vez el filtro detectó palabras largas (no sé cuales) pero de ser así no las escribió el editor en ese momento, habría que ajustar el filtro para que solo tome en cuenta la edición real, añadidos, modicaciones y/o eliminaciones de contenido y no lo que ya había anteriormente. Este es un filtro que suele tener un alto número de falsos positivos. Jcfidy (discusión) 08:37 10 sep 2019 (UTC)

El filtro en teoría «Detecta ristras de 80 o mas caracteres, exluyendo url, enlaces a archivos, plantillas y formulas», pero la realidad es que detecta párrafos donde se agrega texto y que contengan ristras de 60 caracteres sin espacios, aunque esas ristras ya estuvieran en el mismo párrafo; lo que ocurre en ese caso por culpa del enlace FTP —que ya sabes que no debería ir en el cuerpo del artículo—. Supongo que se resuelve agregando el protocolo FTP al mismo condicional donde se detecta el HTTP. -- Leoncastro (discusión) 14:02 10 sep 2019 (UTC)

Pues tal vez haya que añadir esa excepción también. Jcfidy (discusión) 15:04 10 sep 2019 (UTC)

 Hecho Añadido ftp y otros protocolos Platonides (discusión) 21:49 12 sep 2019 (UTC)

Usuario nuevo blanqueando artículos

Asunto

Creo que el filtro 13 no está funcionando correctamente o que se podría mejorar. Esta edición, aunque no literalmente, puede encajar en el significado de «blanqueamiento de artículos». Más ejemplos similares. El filtro debería bloquear esas acciones sin dejar el trabajo al bot o a los reversores, y sin dar lugar a alargar innecesariamente el historial. Como el filtro es privado no puedo ofrecer ninguna propuesta de solución.

Usuario que lo solicita

Leoncastro (discusión) 14:15 10 sep 2019 (UTC)

Respuesta

 Hecho El problema es que se estaba comprobando una variable (accountname) que solo se establece en la creación de cuentas. Platonides (discusión) 18:30 14 sep 2019 (UTC)

Filtro 44

Asunto

Por favor añadir "staff" a la lista de grupos globales exentos de este filtro. Razón: el departamento legal a veces marca las páginas de usuarios expulsados de los proyectos de la Fundación con la cuenta WMFOffice, la cual no está autoconfirmada, y hace saltar el filtro.

Usuario que lo solicita

—MarcoAurelio 15:06 21 oct 2019 (UTC)

Respuesta

 Hecho Fijate si quedo bien Esteban (discusión) 00:17 26 oct 2019 (UTC)

@Ezarate: Lo siento, hay un error. De hecho y para simplificarlo (dado que el filtro es público no creo que haya problemas en poner la sintaxis):

!('autoconfirmed' in user_rights)
& (article_namespace == 2)
& !(user_name in article_text)

La variable user_rights verifica los permisos que el usuario posee, sean locales o globales. Dado que lo que se pretende es que los usuarios que no pueden editar páginas semiprotegidas, verificar las ediciones contra autoconfirmed como permiso, no como grupo cubriría localmente a bots, autoconfirmados y bibliotecarios, y globalmente a unos cuantos grupos más incluyendo stewards, global sysops y staff. Además reducimos el consumo de condiciones. Un saludo, —MarcoAurelio 22:51 29 oct 2019 (UTC)

 Hecho Esteban (discusión) 11:44 30 oct 2019 (UTC)

Gracias. Parece que sigue funcionando. Además hemos reducido el consumo de condiciones de 1,7 a 1,3. Granito no hace granero, pero ayuda al compañero. —MarcoAurelio 14:23 30 oct 2019 (UTC)

Filtro 109

Asunto

Acabo de notar una disrupción en WP:SVU aquí, por lo que solicito que se aumente la estrictidad aunque signifique que los autoconfirmados no podamos evadirlo. Saludos.

Usuario que lo solicita

SRuizR 18:16 14 oct 2019 (UTC)

Comentarios

Supongo que los recientes cambios de Ezarate para que solo los bibliotecarios sean inmunes a este filtro responden a esta petición, pero me parece que es pasarnos al otro extremo, y Leoncastro me ha comentado en mi discusión que ha sufrido un falso positivo. Por favor, opinen todos los implicados (SRuizR?), pero personalmente considero que como mucho podríamos dejar el límite para tener inmunidad en 200-300 ediciones, sin considerar permisos. - José Emilio –jem– Tú dirás... 11:38 30 oct 2019 (UTC)

Ok, a mi me parecía excesivo también pero ya que se planteó aquí me pareció oportuno probar Esteban (discusión) 11:41 30 oct 2019 (UTC)

@-jem-: @Ezarate: Concuerdo en que es excesivo limitarlo a solo bibliotecarios, pero es posible que alguien llegue al estado de autoconfirmado y cause una disrupción como la que señalé. Lo primero que se me ocurrió fue ponerlo a sysop in user groups pero la verdad nunca me gustó la idea de limitarlo así. Me parece bien poner el límite de inmunidad en 200 o 300 ediciones como indicó -jem-, y también podríamos además poner confirmed in user groups para que los confirmados también puedan (no se si ya está). (PD: Me alegro de no haber implementado lo de bloquear) Saludos.--SRuizR 23:20 30 oct 2019 (UTC)

Es inconcebible que no pueda uno editar ni siquiera sus propios mensajes en el Café con la excusa de «Alteración de denuncias» (véase mi reciente registro del filtro antiabusos). ¿Qué denuncia hay en el Café? Es un lugar de debate. Solicito encarecidamente que se revise este filtro, o en caso contrario que se anule hasta que no cause semejantes falsos positivos. CC: -jem-, Ezarate, SRuizR. -- Leoncastro (discusión) 13:12 1 nov 2019 (UTC)

Respuesta

 Hecho, límite establecido en 250 ediciones. He retirado la admisión de dos intentos que había añadido Ezarate porque me parece peor solución (los vándalos pueden insistir), pero podemos reevaluarlo más adelante, según veamos cómo va funcionando el filtro. Disculpa los inconvenientes, Leoncastro. - José Emilio –jem– Tú dirás... 20:42 1 nov 2019 (UTC)

Filtro 2, nuevos casos

Asunto

El filtro 2 no está detectando las variaciones que se presentan en este tipo de vandalismos, como sucedió recientemente en esta edición o esta otra. CC: XanaG.

Usuario que lo solicita

Leoncastro (discusión) 13:18 23 nov 2019 (UTC)

Respuesta

Controlalo ahora por favor Esteban (discusión) 00:38 24 nov 2019 (UTC)

No sé...me parece que hay que filtrar los enlaces en función de la etiqueta y de la posición, y no del url. A ver si tengo hoy tiempo de mirarlo.--Xana (discusión) 11:50 24 nov 2019 (UTC)

Comentario, como expliqué en anteriores ocasiones, hay que detectar divisiones con estilos de posición fija e imágenes de tamaños desproporcionados con cualquier enlace externo. Es decir, por un lado style *\=.*?position: *fixed, por otro lado \[\[ *([Ff]ile|[Ii]mage|[Mm]edia|[Aa]rchivo) *:.*?\| *([6-9]\d\d|\d+\d\d\d)px y por último \[\[ *([Ff]ile|[Ii]mage|[Mm]edia|[Aa]rchivo) *:.*?\| *(link|enlace) *= *http. Si se cumplen las tres condiciones se trata seguramente de este vandalismo. CC: Ezarate, XanaG. -- Leoncastro (discusión) 14:15 24 nov 2019 (UTC)

@Leoncastro:, cuando pruebo la versión del filtro que edité yo, da positivo con las dos ediciones que pones. La diferencia con lo que pones tú es que no especifico lo que hay entre los atributos claves de div y el url, to cast a wide net. Como reversor puedes ver el filtro y el historial ¿no? Si es así, ¿lo puedes probar tú? Que recuerde, esto ya ha pasado antes.--Xana (discusión) 15:19 24 nov 2019 (UTC)

No XanaG, no puedo ver el filtro porque es privado; recibo este mensaje al tratar de ver el filtro: «No puedes ver detalles de este filtro porque su acceso público está restringido»; y este otro al tratar de acceder a su historial: «El filtro que has solicitado está oculto y no puedes ver su historial». -- Leoncastro (discusión) 15:58 24 nov 2019 (UTC)

@Ezarate, XanaG y Leoncastro:, aquí hay otras 2 ediciones vandálicas recientes [7] [8]. --ZebaX2010 [PRESS START] 04:43 5 dic 2019 (UTC)

Pues por muchas vueltas que le damos parece que no está funcionando el filtro ni de una forma ni de otra. ¿Se podría poner esa condición en un filtro independiente para ver si se activa alguna vez? -- Leoncastro (discusión) 20:01 5 dic 2019 (UTC)

Intentaré con un filtro nuevo, a ver si así....--Xana (discusión) 12:06 6 dic 2019 (UTC) PD: Implementado en el filtro 111. --Xana (discusión) 12:39 6 dic 2019 (UTC)