My file has 2805+ bad words, but its only allowed 2000 bad words, how can i add more words? If i want to add 10,000 bad words, from a text file, how to do it? as right now it allows me only to add max 2000 entries.
There are no plans to increase this limit at the moment. If this is a deal breaker you should look into writing, or commissioning, a plugin for it.
2 Me gusta
Me veo potencialmente alcanzando este límite al usar palabras observadas para combatir el spam repetitivo, y tuve algunas ideas sobre lo que podría ser útil en el futuro para otros, si no para el OP.
Una forma de lidiar con esto sin ningún cambio de código es cambiar a Using Regex with Watched Words y combinar muchas palabras en una sola expresión regular. Es fácil equivocarse si no estás familiarizado con las expresiones regulares, pero es técnicamente factible. (Esta es la dirección que probablemente tomaré, porque conozco las expresiones regulares).
Además, esperaría que haya dos formas de escribir un plugin aquí.
La razón del límite de 2000 es que el algoritmo no escala muy bien y se ejecuta de forma síncrona, pero es un límite arbitrario. Esperaría que un plugin simple pudiera parchear el límite de 2000 palabras para aceptar la penalización de rendimiento. ¡Pero yo mismo no haría eso para 10000 entradas!
El otro enfoque, posiblemente complementario, sería tener una lista separada específicamente para marcar, y hacerlo de forma asíncrona desde un trabajo de sidekiq que se activa para cada creación/edición de publicación.
1 me gusta
Como otros, he seguido este camino:
- Empieza con una lista, quizás descargada de un repositorio actual de GitHub.
- Inmediatamente se topa con el límite de 2000 entradas.
- ¡Oh, puedo usar Regex, es genial!
- Las expresiones regulares complejas superan fácilmente los 100 caracteres.
- Divídelas.
- Refina una expresión regular, ¡ups, también superó los 100 caracteres!
- Divídela aún más.
Lidiar con los límites no es prohibitivo, es simplemente molesto, especialmente cuando los límites son artificiales. Dicho esto, entiendo que este filtrado es síncrono y que el procesamiento extendido puede generar problemas de rendimiento, y aprecio la dificultad de intentar establecer límites que funcionen para la mayor audiencia posible. Así que, aunque lucho con los límites, no puedo discrepar razonablemente con ellos.
Veo el código para el filtrado aquí en word_watcher.rb. Como desarrollador, estaría feliz de intentar escribir un plugin, pero ese código no parece extensible. No tendría idea de cómo conectar JavaScript en un plugin para aumentar los procesos de Ruby… o si eso es posible con la forma en que está escrito el código de word_watcher.
Aquí hay una idea para una mejora que ayude a aliviar parte de la carga de procesar listas extensas.
En lugar de procesar la lista completa para cada tipo de lista de vigilancia, considere un bucle a través de diferentes bloques de filtros. Por ejemplo, podemos poner los filtros más comunes y abusivos en el bloque1 y otros en los bloques2-n. El proceso de filtrado síncrono solo procesará un bloque a la vez y solo realizará un bucle completo a través de todos los filtros en la operación de Guardado final. Los bloques pueden operar sobre listas existentes, por lo que no es necesario que nadie haga un cambio. Las listas existentes se dividirán en bloques de 1000 entradas, por lo que el bloque1 es 1-1000, el bloque2 es 1001-2000, etc. Los administradores que deseen optimizar ahora pueden optar por mover sus filtros de mayor prioridad más arriba en la lista.
Una ventaja de esto es que no es necesario procesar toda la lista para detectar un problema. Los problemas más probables se detectarán con un bloque más pequeño y el proceso síncrono podrá devolver más rápido el procesamiento del bloque más pequeño. Claro, si el texto de vigilancia no se encuentra en el primer bloque, será necesario procesar otro bloque. Eso es una sobrecarga ligeramente mayor para detectar abusos menos probables. Esto se convierte en una cuestión de ajuste opcional, si es que alguien alguna vez se preocupa por hacerlo.
Una opción adicional aquí sería que el Administrador elija el tamaño de los bloques. Al reducir el tamaño de los bloques, tal vez a 500 entradas por ciclo de bucle, cada proceso síncrono será más rápido, pero puede haber más bloques que procesar. Esto depende del tipo de abuso presente y de qué tan bien esté priorizada la lista. Nuevamente, este tipo de ajuste sería opcional y, francamente, dudo que muchos administradores hagan mucha optimización de este tipo.
Tenga en cuenta que el ajuste fino implica que tenemos métricas cuantificables: ¿Cuánto tiempo dedicamos al procesamiento de palabras de vigilancia y cuántos problemas estamos detectando realmente? Esta cantidad de detalle nerd debería dejarse para una mejora posterior o un plugin si realmente es deseable.
En última instancia, si se implementa el “procesamiento de bloques de palabras de vigilancia” como se describe aquí, el número de elementos en la lista se puede extender más allá de 2000. Sí, habrá una sobrecarga al leer listas más largas y dividirlas. Una vez más, si tenemos métricas sobre cuánto tiempo se consume en este proceso, los administradores pueden determinar su propio umbral de optimización… pero dudo que mucha gente se adentre profundamente en esto. La guía publicada podría ser algo como “El límite sigue siendo 2000 palabras de vigilancia sin procesamiento de bloques de palabras de vigilancia. Con el procesamiento de bloques, no hay un límite específico, pero el límite práctico podría estimarse en alrededor de 5000, con una degradación notable del rendimiento que aumenta a medida que aumenta el número de entradas”.
¿Alguna alegría aquí?
Al final del día, si hacemos esto en el servidor, podemos tener un tamaño “infinito”, dividir la publicación en palabras y luego realizar una única consulta contra una tabla de “bloques”, que en el peor de los casos es un escaneo de tabla.
Creo que si lo que necesitas son listas de bloques GIGANTES, te recomendaría crear un plugin personalizado.
2 Me gusta
De los más de 20 lenguajes y dialectos de código que he aprendido, Ruby no es uno de ellos. Así que un plugin desde cero es un desafío que no creo que pudiera asumir. Con gusto lo haría en otro idioma… o esperaría hasta que alguien más lo hiciera. 
Gracias.
Acabo de tener un problema como este: Hit the blocklist limit for blocking words on the forum
Creo que este límite podría aumentarse a 10.000 o ser personalizable según la cantidad de palabras que necesites.