Last modified: 2011-03-13 18:05:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14557 - Image, category pages list both draft and stable links, mixed together
Image, category pages list both draft and stable links, mixed together
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
FlaggedRevs (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Aaron Schulz
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-16 13:02 UTC by P. Birken
Modified: 2011-03-13 18:05 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description P. Birken 2008-06-16 13:02:18 UTC
The Image page tells you in which articles an image is used. However, this leads to some confusion in combination with flagged revs: If a noneditor adds an image, it is immediately mentioned in the image page, but if a noneditor removes an image, it is still mentioned in the image page, which is a bit confusing. 

See for example http://de.labs.wikimedia.org/wiki/Bild:Kiwi_%28Actinidia_chinensis%29_2_Luc_Viatour.jpg, and http://de.labs.wikimedia.org/wiki/Cookbook:Tempering, where the image was removed. 

The fix would be to mention this on the image page, for example like this:

* Hauptseite
* Cookbook:Tempering (Removed in current unreviewed version [[Difflink|Review]])
* Testlemma (Added in current unreviewed version [[Difflink|Review]])

The problem is also present for categories and the "what links here" page, but I don't know yet what a reasonable fix would be in those cases.
Comment 1 Aaron Schulz 2008-06-16 18:26:53 UTC
General explanatory text above the link list would be more efficient. "Items listed here are used in either the draft or stable version of pages".
Comment 2 P. Birken 2008-06-17 12:12:07 UTC
Well any time this happens and you would like to use that page, actions from an editor are required. Just one example: a local image was replaced by a noneditor, who then removed the image from all articles and puts the image up for speedy deletion. This then requires the admin to flag all respective edits first. So, explanatory text would be a huge improvement, but not more efficient. 
Comment 3 Adrian Lang 2008-06-17 12:14:11 UTC
Same applies for the links on this page and categorizations. IMHO quite a problem. How does this behave with "geprüfte versionen" (i. e. more than one stage of flagging)?
Comment 4 Aaron Schulz 2008-06-17 13:33:40 UTC
When I say 'efficient', I mean primarily avoiding DB query spam.
Comment 5 P. Birken 2008-06-17 15:58:38 UTC
Ah, OK, yeah, there's no arguing that. If you come up with an efficient way of doing that, go for it! Otherwise, do you know what are the relevant pages? For categories, it's probably best not to put this on every category page and simply use documentation in wiki-namespace, but for pictures and links?

@Codeispoetry: Quality versions do not change anything here, as far as I can see, although things would get very complicated if they were the default view. 
Comment 6 Aaron Schulz 2008-07-14 15:15:59 UTC
Yes, I'd edit the interface message 'linkstoimage' instead.
Comment 7 P. Birken 2008-08-10 20:16:35 UTC
Any chance of a solution here for categories? From the user point of view, I'd consider this the worst remaining problem with flagged revisions. It would be really neat to have something for categories as described in comment #1. 
Comment 8 Brion Vibber 2008-08-10 20:21:32 UTC
Changed summary to clarify what this bug is about.
Comment 9 Aaron Schulz 2008-08-14 15:06:28 UTC
Done in r39342
Comment 10 P. Birken 2008-08-15 20:16:21 UTC
Mh, I have to say that I don't like this solution. For one thing, a description on the help page regarding categories is sufficient, I don't like these new messages too much :-/ 

On the other hand, the real problem is unsolved. One more precise examples of problems: Sebmol has a bot that removes categories from all articles in that category to help us with categories that have been chosen to be deleted or moved. This doesn't work properly if an article has been edited by a noneditor before. IPs are hindered in helping with delinking articles, and so on. Some indication of the state of the article/link/image would be very useful. 
Comment 11 Aaron Schulz 2008-08-16 02:30:28 UTC
I thought you said "as described in comment #1"?

Anyway, you should it indicated that state on category pages and such?
Comment 12 P. Birken 2008-08-16 06:32:18 UTC
I meant this part on comment #1:

The fix would be to mention this on the image/category/what-links-here page, for example like this:

* Hauptseite
* Cookbook:Tempering (Removed in current unreviewed version
[[Difflink|Review]])
* Testlemma (Added in current unreviewed version [[Difflink|Review]])

If this were a list from what-links-here this would currently look like

* Hauptseite
* Cookbook:Tempering
* Testlemma

This solution is what I would prefer. Another would be to colorcode the respective pages or to add an exclamation mark. 
Comment 13 Aaron Schulz 2008-08-17 07:41:40 UTC
The "comment #1" links you have go to the same comment as before ("General explanatory text above the link list would be more efficient."). Note that the starting comment does not count as #1. That can cause some confusion.
Comment 14 Aaron Schulz 2008-08-17 07:45:02 UTC
There really does not seem to be any clean, efficient way to do any of the above. It would require duplicated fork tables and hooks to add a JOIN to all the category/image/WLH pages as needed.
Comment 15 Aaron Schulz 2008-08-22 19:04:06 UTC
Working on 15250 instead

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links