Create new namespace aliases on en.wiki
Closed, DeclinedPublic

Description

Author: happy_melon

Description:
Per discussion at http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=253867565#P:_and_T:_Pseudospaces there seems to be support for adding two new namespace aliases. "P" should be aliased to the "Portal" namespace, and "T" should be aliased to the "Template" namespace. That is, change the en.wiki entry in our LocalSettings.php to read

// bug#6313, bug#THISBUG

  'enwiki' => array(
      'P'  => 100,
      'T'  => NS_TEMPLATE,
      'WP' => NS_PROJECT,
      'WT' => NS_PROJECT_TALK,
),

and run whatever magic voodoo script is used to move the pages that fall under the alias to the Template: or Portal: namespace respectively. All the existing pages are redirects, in the majority of cases there is no corresponding page in the relevant namespace to conflict with. Where conflicts do exist, the system of moving the redirect to a subpage of the new title that was employed for the WP/WT conversion should be effective.


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_56#P:_and_T:_namespace_aliases

Details

Reference
bz16452
P.Copp added a comment.Dec 3 2008, 6:07 PM

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

mathsmart9 wrote:

Add Cat: for Category: as well.

Wiki.Melancholie wrote:

Any progress on this?
...almost 6 months.

happy.melon.wiki wrote:

It's actually *not* particularly easy; the RefreshLinks maintenance script needs to be run, which is no small operation on a pagelinks table the size of enwiki's. And we don't use easy for shell requests anyway. But I second the request for an update: is this sitting in an appropriate queue to actually get implemented (maybe as part of a wider set of updates that all require the same post-change maintenance?), or is it just floating around in the ether?

catlow wrote:

Actually, though I supported this at the time, I think I've changed my mind. I believe now that aliases are generally pretty undesirable, since if you have T: defined as an alias, it's actually *impossible* (as far as I can tell) to create an article or redirect called T:1 or anything else starting with T: . What would be nice, though, would be for some sort of default matching in the search box, just like case-insensitive matching already works - if you enter T:xxx and press Go, and there isn't a page called T:xxx (including alternative capitalizations), then the search module should go on to look for Template:xxx etc. In fact that's a feature that might offer other interesting possibilites (e.g. a user enters "xyxys" and gets taken to "List of xyxys" if the latter exists but the former doesn't - that sort of thing) - anyone ever thought about this?

Since the linked consensus is over a year old and I've got the feeling the proposal may have become more controversial in the meantime, I reopened discussion at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#P:_and_T:_namespace_aliases .

jeluf wrote:

The voting has been archived, and there's some opposition. So what's the result? WONTFIX?

happy.melon.wiki wrote:

Roan's discussion ended up at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_56#P:_and_T:_namespace_aliases, but I don't at all agree that there was a lack of consensus; unanimity has never been a requirement.

Mass-unassigning shell bugs from myself to Rob; I used to do them once, but I
don't have time for them any more.

jeluf wrote:

(In reply to comment #8)

unanimity has
never been a requirement.

Might be, but it's not us who decide whether the support is sufficient or not. So please find someone authorized enough to decide what the result of the poll is.

Removing shell keyword, until such time as results are well defined

Marking resolve LATER : pending for enwiki consensus.

(In reply to comment #7)

The voting has been archived, and there's some opposition. So what's the
result? WONTFIX?

Switching from LATER to the second most relevant resolution for fear of information loss. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65116

Add Comment