Change Details

The title blacklist provides options applicable to a specific entry. The spam blacklist should do the same. Welcome options would be: - autoconfirmed: entry only applies to IPs and new users (current workaround: use of bots that revert the additions, problem: no warning, not user friendly, less efficient) - warnonly: after seeing the warning, the user should be allowed to save nonetheless (current workaround: use of abusefilter, problem: difficult to handle huge lists, less efficient, condition limit) - errmsg: provides a custom warning for this entry (current workaround: having a massive default message that tries to explain as much as it can, problem: obvious lack of usability/scalability)

The title blacklist provides options applicable to a specific entry. The spam blacklist should do the same. Welcome options would be: - autoconfirmed: entry only applies to IPs and new users workaround: use of bots that revert the additions limitations of workaround: no warning, not user friendly, less efficient - warnonly: after seeing the warning, the user should be allowed to save nonetheless workaround: use of abusefilter limitations of workaround: difficult to handle huge lists, less efficient, condition limit - errmsg: provides a custom warning for this entry workaround: having a massive default message that tries to explain as much as it can limitations of workaround: obvious lack of usability/scalability

The title blacklist provides options applicable to a specific entry. The spam blacklist should do the same. Welcome options would be: - autoconfirmed: entry only applies to IPs and new users (current workaround: use of bots that revert the additions, problem limitations of workaround: no warning, not user friendly, less efficient) - warnonly: after seeing the warning, the user should be allowed to save nonetheless (current workaround: use of abusefilter, problem: limitations of workaround: difficult to handle huge lists, less efficient, condition limit) - errmsg: provides a custom warning for this entry (current workaround: having a massive default message that tries to explain as much as it can, problemcan limitations of workaround: obvious lack of usability/scalability)