Last modified: 2011-03-13 18:05:24 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.
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".
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.
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)?
When I say 'efficient', I mean primarily avoiding DB query spam.
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.
Yes, I'd edit the interface message 'linkstoimage' instead.
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.
Changed summary to clarify what this bug is about.
Done in r39342
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.
I thought you said "as described in comment #1"? Anyway, you should it indicated that state on category pages and such?
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.
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.
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.
Working on 15250 instead
