Last modified: 2014-07-24 08:31:09 UTC
At meta (290KB) and at w:en (160KB) the sbl has got many many entries, so it gets hard for some users to edit those pages. Some javascripts seem to fail already on some user's machines. One can think of many different work-arounds. One fast solution could be, to use transcluded pages, s.t. example\.org {{some transcluded page}} example\.com where "some transcluded page" consists of only foo bar will be treated by the extension as example\.org foo bar example\.com The advantages would be: * sbl gets arbitrarily smaller, so editing gets easier * rendered sbl looks still the same, because transclusion works anyway * admins may chose, whether they want to use that feature (i.e. downward compatibility!) * doesn't need much programming on sbl extension
If we are going to use this at meta, then I believe this breaks downward compatibility. That's too bad, because I really like this solution.
How should this break downward compatibility? (Maybe my explaination was bad.)
[[mw:Extension:SpamBlacklist]] and the source code says that the URL for fetching the spam blacklist is: http://meta.wikimedia.org/w/index.php?title=Spam_blacklist&action=raw&sb_ver=1 This is just the wiki source of the page and does not expand transclusions (see e.g. http://en.wikipedia.org/w/index.php?title=Main_Page&action=raw in your favorite text editor). The character { followed by } is likely to make older spam blacklists spew errors. Perhaps we can have a syntax like: #SB_INCLUDE<page> where the # conveniently comments out the line for those who can't understand it.
Then again, maybe spewing errors to get people to upgrade might be a good idea.
Oh, I didn't know that other (non-wikimedia) wikis use our sbl. Afaics this would be the only compatibility problem. We could use a combination of our proposals: #{{some transcluded page}} So the first line of that transcluded page is ignored and could be used for a comment instead, e.g. ----%<---- please insert a space before each line foo bar ---->%---- Would that fix the problem, you mentioned?
Yes.
Or you could start actually maintaining those blacklists, rather than merely adding a link every time it gets used for spam.
(In reply to comment #7) > Or you could start actually maintaining those blacklists, rather than merely > adding a link every time it gets used for spam. The blacklists are maintained already. Maybe you want to discuss that in detail at the meta talk page.
This seems like a duplicate of bug 14322.
