Page MenuHomePhabricator

Reorganize Special:Specialpages
Closed, ResolvedPublic

Description

Author: ayg

Description:
Okay, when we had like ten special pages the current setup may have been fine, but I count 59 special pages on enwiki filed under "for all users". First-pass suggested organization:

  • General page lists
    • All pages
    • All pages with prefix
    • Categories
    • Disambiguation pages
    • Redirects
  • Maintenance page lists
    • Articles with the fewest revisions
    • Articles with the most categories
    • Articles with the most revisions
    • Broken redirects
    • Cross-namespace links
    • Dead-end pages
    • Double redirects
    • Long pages
    • Most linked to categories
    • Most linked to images
    • Most linked to pages
    • Most linked-to templates
    • Oldest articles
    • Orphaned pages
    • Pages without language links
    • Protected pages
    • Short pages
    • Uncategorized categories
    • Uncategorized images
    • Uncategorized pages
    • Uncategorized templates
    • Unused categories
    • Unused files
    • Unused templates
  • Tools
    • CategoryTree
    • Cite
    • Expand templates
    • Export pages
    • File path
    • MIME search
    • Random article
    • Random redirect
    • Search
    • Upload file
  • Logs and information
    • Blocked IP addresses and usernames
    • Book sources
    • External links
    • Files
    • Gallery of new files
    • Logs
    • New pages
    • Recent changes
    • Statistics
    • System messages
    • User contributions
    • Users
    • Version
    • Wanted categories
    • Wanted pages
    • Wikimedia Board of Trustees election
    • Wikimedia wikis
  • Personal pages
    • My preferences
    • My watchlist
    • Sign in / create account
  • Restricted special pages (as now)

This should be done in multiple columns for better readability, I guess using floats or something so it displays in one column if there's not enough available space, but that might be best as a separate bug. Many of these should also be merged with each other: most obviously wanted pages/categories, uncategorized X, unused X, most linked to X, and so on, but also things like All pages/Categories/Redirects, and preferably pairs like Short/Long pages as well. But that's definitely another bug. As is showing all special pages, which I think is the most expected and useful thing to do and I've never been clear on why we don't.


Version: unspecified
Severity: enhancement

Details

Reference
bz10457

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:50 PM
bzimport set Reference to bz10457.

robchur wrote:

Note that in the forthcoming changes to reporting (in branch), reports are split off into a separate section (and some *are* merged together); the list looks quite a bit tidier.

Special:Specialpages reworked with r31590. The page is customizable by editing [[MediaWiki:specialpages-tpl]].

I have some questions/comments:

  • What happens with special pages of extensions?
  • When there is a new special page in MediaWiki, I assume the developer has to add it to every translated message?

An idea could be to use {{int:specialpages-blabla}} in the headings of the "specialpages-tpl" message, so the message shouldn't be translated to other languages.

Reverted in r10457.

This is far too fragile. It's a bad interface (witness the huge troubles with sidebar customization as it is), doesn't handle extensions well, doesn't handle localization well, and is generally just going to make things confusing and inconsistent.

Resolving as WONTFIX.

Sorry, that's r31595. Cut-and-pasted wrong number. :)

ayg wrote:

Reopening, since none of the concerns expressed have to do with the bug itself, they have to do with Raymond's implementation. The message interface should not be used, except of course for the messages themselves (e.g., titles of special page groupings). The issue itself remains valid. See the above-linked thread for discussion on alternative implementations.

Created attachment 4766
Patch to group Specialpages list into sections - v1

Further to our discussion a couple of weeks ago on wikitech-l, here is the first draft of my suggested solution. This is just the basic method of implementation - there are various extra features that I would like to add if the general method is approved (which can be added as part of this patch, or later as separate features) plus there are several questions that need discussion before final implementation.

The new page lists pages by section, where 'section' is defined as part of each special page definition. 'section' can be any text, which allows extensions to create new sections if needed. In order to avoid a lot of single item sections, any single-item sections are merged with the general 'miscellaneous' section.

Some questions:

  • 'misc' is always at the bottom of the list, but the earlier sections are sorted alphabetically. It might be better to have a fixed 'logical' order, based on most common usage. In this case unrecognised categories (i.e. those added by extensions) would probably be listed alphabetically between the built-in sections and the misc section.
  • Currently each section consists of an h3 header, followed by an un-ordered list. Would it be better to do this as nested un-ordered lists?

Some suggested improvements:

  • It might be better to merge the restricted pages into the main list, highlighting restricted items (e.g. with an *) and noting that they are restricted and not available to all users. (Ideally it would also indicate the restriction (bureaucrats only, sysadmins only, etc.) but I'm not sure whether this information is easily available.) What do people think about this?
  • CSS classes needs to be added - will do that when the overall structure is fixed.

Note that the sections I have used are based on my own structure, as I've only just seen this bug and the suggested layout above. I am happy to change the groupings if the above method is thought to be better, but I've held off doing it until I see what feedback it gets.

Attached:

Forgot to mention - the above patch is against MW 1.12.0, not HEAD.