Last modified: 2011-12-14 17:37:22 UTC
It would be very helpful if the File links section on image description pages could display (or have the option in Preferences to display) the pages used in alphanumeric order, including by namespace (articles first (talk), then images (talk), WP (talk), User (talk) etc) in order to make it easier for editors to find usages of images, as well as grouping certain kinds of usage together. For instance, if the pages were sorted by namespace (article space first), one could see at a glance a rough count of how many articles used the image, instead of having to hunt through the list to find anything without a namespace tag. Likewise, if certain images were not meant to/only meant to be used in a certain namespace (Wikipedia:, User: or Talk:) it would be easier to find instances of use/misuse, as each namespace would be grouped together.
First time I've used Bugzilla, let me know if I've done anything wrong as I do want this to be taken seriously. The lack of this feature has been bugging me for quite some time (pun maliciously intended).
User:Vanderdecken on en-wiki.
That would require an extra sort; ok for short lists. Since they're displayed inline anyway I suppose it wouldn't hurt too much.
(In reply to comment #1)
> That would require an extra sort; ok for short lists. Since they're displayed
> inline anyway I suppose it wouldn't hurt too much.
Any idea of a timeframe for the implementation of this? Don't mistake me for being impatient, I don't mind waiting - I wasn't even sure that the proposal would be accepted so easily.
Would it be possible to do the same sort for the list of templates transcluded on pages in the save preview? Should I submit a separate bug for that?
Yes, open a separate bug for it but go ahead and mention it here since they'd be easy to both do at once.
A problem with the file links in specific is that for very frequently used images the number of using pages can be very high indeed... http://en.wikipedia.org/wiki/Special:Mostimages
I think we just have a silent cutoff currently for the displayed list, with no ability to page or search it. Sorting a long paged list wouldn't be feasible without denormalizing the database schema.
(In reply to comment #4)
> Yes, open a separate bug for it but go ahead and mention it here since they'd
> be easy to both do at once.
> A problem with the file links in specific is that for very frequently used
> images the number of using pages can be very high indeed...
> I think we just have a silent cutoff currently for the displayed list, with no
> ability to page or search it. Sorting a long paged list wouldn't be feasible
> without denormalizing the database schema.
Right, I'll try to translate that for myself - sorry, the last sentence went over my head, I'm a prolific user but nothing like a developer, I can just about understand parser functions if I try. According to this: http://www.siue.edu/~dbock/cmis564/denormal.htm, denormalizing the database schema is a way of... uh... optimizing the layout of a relational database for a performance increase at the end user GUI level? By doing what, reducing, sorting and organizing the foreign key layouts? Like making a zigzag relation into one straight line? Sorry, I'm trying to understand, but I've never particularly tried to learn databases in the past, ATM I'm doing it for AS Level at school and it's a lot to take on.
Re your second paragraph - basically you mean that if the number of image links was high (e.g. 784,739 links for Portal.svg) then sorting the list rather than taking the records in a random order from the database would put enormous load on the server(s) each time the list was regenerated, therefore each time the image was added to another page and the image page was viewed there would be massive server load spikes, right? Each time the server would have to dynamically generate _and sort_ 784,739 links.
Your final paragraph... silent cut off for the list... you mean that on the image page with 784,739 links it stops generating the list when it hits, say 100,000, silently? So is there actually any way on the current build that a user or administrator can force MediaWiki to show them the full 784,739? If the database load would be so high to generate the entire list, there's no way that we could sort the list, right? And to properly sort the list, the database would have to generate the entire thing first, even if it didn't display it on the page, which would still be a load spike.
I've created the second bug as bug 12644. I'm sure you will not hesitate to inform me if I'm spouting [[w:en:WP:complete bollocks]].