Last modified: 2010-11-20 17:36:47 UTC
In fall 2009, some English Wikipedians surfaced an important issue, but apparently did not find a way to get any action taken on their conclusions. Summary: The "Special:PrefixIndex" function, which is only a couple clicks away from any page, by default includes a listing of all mainspace articles, alphabetically. Thus, on English Wikipedia, it starts with "!!!Fuck You!!!", a thrash metal album. The Wikipedians discussing this suggested that the initial view of the "Special:PrefixIndex" page should not include ANY articles until a search string has been entered. Seems perfectly reasonable, but needs a techy to implement.
Suggest WONTFIX. Special:Prefixindex is really just a special mode of Special:Allpages, which does the same thing AFAIK.
If some project doesn't like the default implementation for some weird reason (there's [[WP:NOTCENSORED]], by the way), they could tweak it with site JS.
Max, just to be clear about the request: nobody suggested censoring Wikipedia. The Wikipedians who discussed this felt that there was no benefit or encyclopedic value to showing the first n articles alphabetically, which is an arbitrary sample generally beginning with punctuation characters. The fact that the first entry is !!!Fuck You!!! is just the thing that started the discussion, not the justification for making a change. Could you explain your suggestion? I don't know what "site JS" is, or how one would go about tweaking it to meet this need.
Roan, The idea that Special:PrefixIndex is a special case of Special:Allpages makes sense, and I don't think the original folks requesting this realized it (I know I didn't). And of course a page intended to list "all pages" has to start somewhere, so I doubt there's any desire to change Special:Allpages behavior in this way. But I'm not sure I understand how this relationship between the features affects the original request. Is it impossible, or very difficult, to change the default first display of Special:PrefixIndex without changing the behavior of Special:PrefixIndex? What's the issue that makes you suggest not fixing it?
Regardless of the underlying original reason for requesting this change, I think it's reasonable to say that there isn't any good particular reason that the initial form shows entries. A user navigates to [[Special:PrefixIndex]] to find all pages beginning with some character. To show results before the user has entered anything is confusing and unnecessary. I've adjusted the bug summary to be clearer and less ideological.
(In reply to comment #4) > Roan, The idea that Special:PrefixIndex is a special case of Special:Allpages > makes sense, and I don't think the original folks requesting this realized it > (I know I didn't). And of course a page intended to list "all pages" has to > start somewhere, so I doubt there's any desire to change Special:Allpages > behavior in this way. > > But I'm not sure I understand how this relationship between the features > affects the original request. Is it impossible, or very difficult, to change > the default first display of Special:PrefixIndex without changing the behavior > of Special:PrefixIndex? What's the issue that makes you suggest not fixing it? I have no idea how difficult this is, it's just that to me this request made no sense. But I agree that the current behavior arguably doesn't make sense either. What Max meant by "site JS" is that you can put some JavaScript in [[MediaWiki:Common.js]] that would then hide these links. This should be easy for someone with JS experience (and there's plenty of them out there, enwiki has a fairly large base of custom JS).
(In reply to comment #5) > Regardless of the underlying original reason for requesting this change, I > think it's reasonable to say that there isn't any good particular reason that > the initial form shows entries. > Especially since we do that with every search-like form I believe.
Fixed in r75314.
*** Bug 21143 has been marked as a duplicate of this bug. ***
There was a regression which caused no results to be shown for the prefix '0', as this evaluates to false in boolean context -- this is what the isset checks were there for, as they don't give that false negative. Ah, PHP. :) Fixed in r75402; comparing against '' does the job we want here just fine.
Oh the joys of PHP. Thanks Brion :)
*** Bug 26024 has been marked as a duplicate of this bug. ***
Created attachment 7842 [details] Jimmy Wales appeal seeming to lead into offensive line coincidence Here just for the record is the odd juxtaposition of the fund raising appeal vs. the dirty words, if one clicks the link on the pre-fixed bug to get to that page.
(In reply to comment #13) > Created attachment 7842 [details] > Jimmy Wales appeal seeming to lead into offensive line coincidence > > Here just for the record is the odd juxtaposition of the fund raising appeal > vs. the dirty words, if one clicks the link on the pre-fixed bug to get to that > page. That's no different to what would happen on viewing any other "offsensive" title, and I don't see how it's related to this bug.
The content of attachment 7842 [details] has been deleted by Chad H. <innocentkiller@gmail.com> who provided the following reason: Bogus The token used to delete this attachment was generated at 2010-11-20 17:36:38 UTC.
