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)
أرى نفسي قد أصل إلى هذا الحد من استخدام الكلمات المراقبة لمكافحة البريد العشوائي المتكرر، وكان لدي بعض الأفكار حول ما قد يكون مفيدًا في المستقبل للآخرين، إن لم يكن للمستخدم الأصلي.
طريقة للتعامل مع هذا دون أي تغيير في الكود هي التغيير إلى Using Regex with Watched Words ودمج العديد من الكلمات في تعبير عادي واحد. من السهل أن تخطئ إذا لم تكن على دراية بالتعبيرات العادية، ولكنها ممكنة تقنيًا. (هذا هو الاتجاه الذي من المحتمل أن أسلكه، لأنني أعرف التعبيرات العادية.)
بالإضافة إلى ذلك، أتوقع أن هناك طريقتين لكتابة إضافة هنا.
السبب وراء حد الـ 2000 هو أن الخوارزمية لا تتوسع بشكل جيد ويتم تشغيلها بشكل متزامن، ولكنه حد اعتباطي. أتوقع أن تتمكن إضافة بسيطة من تعديل حد الـ 2000 كلمة لتجاوز التأثير على الأداء. لكنني لن أفعل ذلك لـ 10000 إدخال!
النهج الآخر، الذي قد يكون مكملاً، هو وجود قائمة منفصلة مخصصة للتمييز، والقيام بذلك بشكل غير متزامن من مهمة sidekiq يتم تشغيلها لكل إنشاء/تعديل للمنشور.
إعجاب واحد (1)
مثل الآخرين، لقد سلكت هذا المسار:
- ابدأ بقائمة، ربما تم تنزيلها من مستودع GitHub حالي.
- الوصول فورًا إلى حد 2000 إدخال.
- أوه، يمكنني استخدام التعبيرات العادية (Regex) - رائع!
- التعبيرات العادية المعقدة تتجاوز بسهولة 100 حرف.
- قسمها.
- قم بتحسين تعبير عادي، يا إلهي لقد امتد لأكثر من 100 حرف أيضًا.
- قسمها أكثر.
الرقص مع الحدود ليس مانعًا، إنه مزعج فقط، خاصة عندما تكون الحدود مصطنعة. ومع ذلك، أتفهم أن هذا الترشيح متزامن وأن المعالجة الممتدة يمكن أن تسبب مشاكل في الأداء، وأنا أقدر صعوبة محاولة وضع حدود تعمل لأكبر عدد ممكن من الجمهور. لذلك، بينما أكافح مع الحدود، لا يمكنني الاعتراض عليها بشكل معقول.
أرى الكود الخاص بالترشيح هنا في word_watcher.rb. بصفتي مطورًا، سأكون سعيدًا بتجربة كتابة إضافة (plugin)، لكن هذا الكود لا يبدو قابلاً للتوسيع. ليس لدي أي فكرة عن كيفية ربط JavaScript في إضافة لتعزيز عمليات Ruby … أو ما إذا كان ذلك ممكنًا مع كيفية كتابة كود word_watcher.
إليك فكرة لتحسين للمساعدة في تخفيف بعض عبء معالجة القوائم الموسعة.
بدلاً من معالجة القائمة بأكملها لكل نوع من قوائم المراقبة، فكر في حلقة عبر كتل مختلفة من المرشحات. على سبيل المثال، يمكننا وضع المرشحات الأكثر شيوعًا وإساءة استخدامًا في الكتلة 1 والمرشحات الأخرى في الكتل 2-ن. ستقوم عملية الترشيح المتزامنة بمعالجة كتلة واحدة فقط في كل مرة، ولن تقوم بحلقة كاملة عبر جميع المرشحات إلا عند عملية الحفظ النهائية. يمكن للكتل العمل على القوائم الموجودة، لذلك لا حاجة لأي شخص لإجراء تغيير. سيتم تقسيم القوائم الحالية إلى كتل من 1000 إدخال، لذا الكتلة 1 هي 1-1000، والكتلة 2 هي 1001-2000، وهكذا. يمكن للمسؤولين الذين يرغبون في التحسين الآن اختيار نقل مرشحاتهم ذات الأولوية الأعلى إلى أعلى القائمة.
إحدى مزايا هذا هي أنه لا يلزم معالجة القائمة بأكملها لاكتشاف مشكلة. سيتم اكتشاف المشكلات الأكثر احتمالاً باستخدام كتلة أصغر، ويمكن لعملية المعالجة المتزامنة أن تعود في وقت أقرب من معالجة الكتلة الأصغر. بالتأكيد، إذا لم يتم العثور على النص المراد مراقبته في الكتلة الأولى، فستحتاج كتلة أخرى إلى المعالجة. هذا يصبح مسألة عبء إضافي طفيف لالتقاط إساءة استخدام أقل احتمالاً. يصبح هذا مسألة ضبط اختياري - إذا أراد أي شخص الاهتمام بذلك.
خيار إضافي هنا سيكون للمسؤول اختيار حجم الكتل. عن طريق تقليل حجم الكتل، ربما إلى 500 إدخال لكل دورة، ستكون كل عملية متزامنة أسرع، ولكن قد يكون هناك المزيد من الكتل للمعالجة. هذا يعتمد على نوع الإساءة الموجودة ومدى جودة ترتيب القائمة. مرة أخرى، سيكون هذا النوع من الضبط اختياريًا، وبصراحة أشك في أن العديد من المسؤولين سيقومون بالكثير من الضبط مثل هذا.
لاحظ أن الضبط الدقيق يعني أن لدينا مقاييس قابلة للقياس: كم من الوقت نقضيه في معالجة الكلمات المراد مراقبتها وكم عدد المشكلات التي نلتقطها بالفعل؟ يجب ترك هذه التفاصيل التقنية لكمية كبيرة لوقت لاحق أو إضافة إذا كانت مرغوبة حقًا.
في النهاية، إذا تم تنفيذ “معالجة كتل الكلمات المراد مراقبتها” كما هو موضح هنا، فيمكن زيادة عدد العناصر في القائمة إلى ما بعد 2000. نعم، سيكون هناك بعض العبء الإضافي في قراءة قوائم أطول وتقسيمها. مرة أخرى، إذا كانت لدينا مقاييس حول مقدار الوقت المستهلك في هذه العملية، فيمكن للمسؤولين تحديد عتبتهم الخاصة للتحسين … لكنني أشك في أن الكثير من الناس سيتعمقون في هذا. يمكن أن يكون الدليل المنشور شيئًا مثل “يظل الحد 2000 كلمة مراقبة بدون معالجة كتل الكلمات المراد مراقبتها. مع معالجة الكتل، لا يوجد حد محدد، ولكن قد يُقدر الحد العملي بحوالي 5000، مع تدهور ملحوظ في الأداء يزداد مع زيادة عدد الإدخالات.”
هل هناك أي فائدة هنا؟
في نهاية المطاف، إذا قمنا بذلك على الخادم، يمكننا القيام بحجم “لا نهائي”، تقسيم المنشور إلى كلمات، ثم استعلام واحد مقابل جدول “كتلة”، وهو في أسوأ الأحوال عبارة عن مسح جدول واحد.
أعتقد أنه إذا كان ما تحتاجه هو قوائم كتل عملاقة، فسأوصي ببناء إضافة مخصصة.
إعجابَين (2)
من بين أكثر من 20 لغة برمجة ولهجات تعلمتها، الروبي ليست واحدة منها. لذا فإن إنشاء إضافة من الصفر هو تحدٍ لا أعتقد أنني أستطيع تحمله. يسعدني القيام بذلك بلغة أخرى … أو الانتظار حتى يقوم شخص آخر بذلك. 
شكرًا.
لقد واجهت مشكلة كهذه للتو: Hit the blocklist limit for blocking words on the forum
أعتقد أنه يمكن زيادة هذا الحد إلى 10,000 أو تخصيصه اعتمادًا على عدد الكلمات التي تحتاجها.