Consolidate special pages with namespace selector
Open, LowPublic

Description

Author: jnothman

Description:
There is a namespace selector on [[Special:Recentchanges]]; why nowhere else?

It could be used to consolidate:

  • {All pages, Categories, File list} into "Pages"
  • {Most linked to categories, Most linked to images, Most linked to pages} into "Most linked to pages"
  • {Uncategorized categories, Uncategorized pages} into "Uncategorised pages"
  • {Unused categories, Unused files, Orphaned pages} into "Orphaned pages"
  • {Wanted categories, Wanted pages} into "Wanted pages"

It will also make Pages with most categories, Pages with most revisions, New
pages, Short pages, Oldest articles be more generic.

And even these could ALL be combined into ONE page with subpages, or a
selection.

The listings could provide more info for the given namespace, ie links to the
image when referring to the Image: namespace.

Not only will this allow for less repetitive code, it will stop the ambiguity
between the terms "pages"/"articles" and "files"/"images".

If nothing else, it will save a lot of time adding the same enhancements to
multiple different special pages.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14485

Details

Reference
bz4204
bzimport raised the priority of this task from to Low.
bzimport set Reference to bz4204.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Dec 7 2005, 9:41 AM

avarab wrote:

One reason why we don't offer the option of select namespaces on certain pages
is that doing so could make them superexpensive as the indexes in place to
generate them would no longer be effective, one example of this could be
Special:Shortpages (let's presume for the sake of argument that the page table
didn't have a namespace index), generating a list of the 100 shortest pages with
an index on page_len would be inexpensive but allowing users to select a
namespace with no index on page_namespace could in a worst case scenario result
in a scan of hundreds of thousands of rows for a namespace that not a lot of
pages exist in (like Portal_talk).

Another reason for it might be that simply noone has bothered coding it yet, or
it's something that's inherantly much harder to do due to a certain structuring
in the code. One example of this is Wantedpages/Wantedcategories, the querycache
object currently works in a way that makes it impossible to have two different
SQL queries for a single special page based on arguments given to it if you want
to cache it.

jnothman wrote:

If caching is a problem, the same can be done by subpages instead of
arguments, ie Special:Pages/Wanted/Category. I presume here querycache would
allow different SQL queries?

*** Bug 6268 has been marked as a duplicate of this bug. ***

*** Bug 12689 has been marked as a duplicate of this bug. ***

  • Bug 5864 has been marked as a duplicate of this bug. ***
  • Bug 18273 has been marked as a duplicate of this bug. ***
  • Bug 29083 has been marked as a duplicate of this bug. ***

If people are serious about seeing this bug resolved, it should have an accompanying RFC: https://www.mediawiki.org/wiki/Requests_for_comment. This is going to require some thinking and planning.

Let's call bug 39660 a blocker (an instance of this): I think the dropdown is the best solution for it.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 23 2015, 9:17 PM

I would like to suggest; especially for Special:WantedPages, Special:WantedCategories, Special:WantedTemplates, and Special:WantedFiles; is those pages ignore everything outside of article space including Talk:. This way the special wanted pages are not cluttered with redlinks from non-article spaces where redlink fixing is not a priority. There may be a few users who have redlink farms in user space which would give undue weight to a topic. There is currently a discussion on En where people who regularly try to clean up redlink categories are bogged down with wanted categories in user space which are not meant for creation.

If you feel there is still a need to know what is wanted in other namespaces, it might be a good idea to have a subpage of the Special:Wanted pages. For example, Special:WantedTemplates would only show wanted templates in article space, but Special:WantedTemplates/In Templates would show templates wanted in template space. Special:WantedCategories would only show categories wanted in article space, while Special:WantedCategories/In User would show wanted categories in User space. Special:WantedFiles would show only files wanted in article space, Special:WantedFiles/In Help would show the wanted files in Help space.

This way, article space is featured, while other spaces are put in their proper place. The various /In Foo pages might not get updated as often, maybe once a week, while article space Special:Wanted gets updated daily. There are so many namespaces these days, but article space should get priority, while user space (and user talk space) might be the lowest priority getting scanned only on the first or last day of the month. Article talk space might get scanned every other day.

On en Wikipedia there are 32 different name spaces, 31 of which do not need as much attention as article space needs.

So, if the day of the month = 1, then all spaces get scanned causing the drives to whine a little. If day of the week eq Sunday, all spaces except user and user talk (unless day of the month = 1) get scanned. If the day of the month % 2 = 1, then article talk gets scanned along with article.

All spaces not article would get an /In Foo page, maybe for all Special: pages, though my target is the Special:Wanted pages at the moment. (I hope this belongs here and all makes sense.) - Lady Aleena

T177169 may help, if we want to change the criteria site-wide to something different from core. That still won't allow individual users to set their own namespaces to view, though.