Last modified: 2012-01-01 23:04:46 UTC
This is an attempt to focus an another small improvement steps with respect to the general concerns argued in Bug 6220. This bug seems to be impossible to resolve. Bug 6220 has achieved progress insofar, that the Wanted-but-not-wanted files (files that are not present locally, but present in a shared repository) are shown as struck-out bluelinks instead of redlinks in the output. Given that this has been achieved, I wonder whether the bug cannot be closed by simply adding a filter option to hide the struck-out bluelinks? I have no insight into the code, but it seems the filter could be added with very little performance loss, provided we don't expect the precise number of returns and the filter automatically switches to a high browsing interval (2000-5000), and adds an explanation like: "2000/ACTUAL NUMBER files have been found that are not present in the local wiki. Of these, some or many are available in a shared file repository. These are not shown below. As a result, the number or missing files shown is variable." This may be not ideal, but I believe it is better than the present consistent, but in my opinion rather useless behavior. Who is likely to browse through 100s of pages of struck-out blue links to find the truly missing red-links?
This could in fact be tackled together with Bug 28807 - splitting the present behaviour into two lists, with completely opposite interests. But it needs not, the broken file links are my real concern.
I'm suggesting WONTFIX. Aside from the QueryPage system not supporting this mechanism efficiently, it could also lead to empty results. This is a very expensive query that is cached. Instead of filtering out links that are currently blue links based on a list that is cached sounds like a bad idea. Already: * bug 6220: Actually support shared repositories the right way (this is the underlaying bug) * bug 16112: Refresh Special:Wanted* pages on WMF wikis And, if you just want a list of pages that have missing file links, there's a tracking category for that (bug 23816)
My non-programmer analysis is that the present page is not very useful or at least unnecessarily overloaded with 99.9% recognizable false positive. Adding a simple CSS display:none, supported by the proposed message would resolve the usability problem, while not adding any extra server load. One could probably already write a <li>del CSS rule with display:none, provided some additional supporting class that limits this to Special:WantedFiles. Technically, the request is to add a class on the OL that identifies which special page it is (currently it says only "special") and add a simple CSS rule. The current html is: <li> <del><a title="File:Redirectltr.png" href="/wiki/File:Redirectltr.png">File:Redirectltr.png</a></del> ‏‎ (<a title="Special:WhatLinksHere" href="/w/index.php?title=Special:WhatLinksHere&target=File%3ARedirectltr.png">689 links</a>) </li> I fail to see the drawback. It seems to me, that without any expense to the WMF servers the browser could do the work that currently the human eye is supposed to do. The problem with bug 6220 is that some believe Special:WantedFiles should disappear altogether, or a least it has Low (MAH) or Lowest (Nemo_bis) priority - meaning its likelihood of being fixed is very small (or at least whichever multiple of 6.5 years it is unfixed so far you like). The present proposal means to be a no-expense stop-gap, not a huge permanent solution. Please WONTFIX again if you are not convinced, I will not revert...
Consider enwikipedia. If we added the display none, at least the first 5 pages (probably significantly more) of special:wantedfiles would be blank. I don't think that's ok, so I tend to agree with Krinkle. However, i do think adding a class to the <li> so people could customize it on there own (via personal css) would be a good idea.
(In reply to comment #4) > Consider enwikipedia. If we added the display none, at least the first 5 pages > (probably significantly more) of special:wantedfiles would be blank. I don't > think that's ok I see the argument, I only think this is not worse than now. Currently the first 5 pages _look_ like filled, except in terms of the sought after information they _are_ empty. Personally I prefer to have empty page (with an explanation why this may happen, as proposed) than filled ones with misleading information. I propose to set the default paging number high. I just found another bug (Bug 33455): nobody realized that Special:WantedFiles is completely broken. Once 1000 files are from a shared repo, no locally missing files can be found - I think this is proof that the present implementation is not used, the long list of false positives is too offputting).
Closing myself. Per bug 33455 (one can NOT browse through the WantedFiles, because they are truncated at 1000, which is usually filled with the false positives even in a medium-sized Wiki) this does not work. Special:WantedFiles at present is not usable except for very small wikis or wikis that don't use shared repositories. ---- A css class on the ol element of any special page, identifying which special page list the list belongs, seems to make sense in general. However, I actually no longer have a concrete use case if it cannot be used to diminish the WantedFiles problem.
Suit yourself: Paste to: [[Special:Mypage/common.js]] if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Wantedfiles' ) { $('.mw-spcontent ol > li > del').parent().hide(); }
Or trough CSS you may check the class 'mw-special-Wantedfiles', which is added on the root element of Special:WantedFiles.
