Last modified: 2011-04-14 15:12:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13119 - Talk subpages link to main subpages even when they are turned off
Talk subpages link to main subpages even when they are turned off
Status: NEW
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Low trivial with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Talk:Fis...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-22 23:00 UTC by Will Hirsch
Modified: 2011-04-14 15:12 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Will Hirsch 2008-02-22 23:00:55 UTC
If, like on Wikipedia, you are viewing a sub-pages of a talk page, such as [[Talk:Foo/bar]], for a page in a namespace with subpages turned off, then the navigation links you to the (usually redlinked) logical corresponding subpage, [[Foo/bar]]. Since if /bar really is a subpage of the talk page, [[Foo/bar]] is unlikely to exist, it would be far better to link back to [[Foo]]. This bothers me a lot when browsing talk archives.
Comment 1 Brion Vibber 2008-02-22 23:10:59 UTC
Well, here's the problem.

At [[Talk:OS/2]], we need the article tab to link to [[OS/2]], not [[OS]].

One possibility _might_ be to check for the matching article, then *if and only if* it doesn't exist, walk up the subpage chain (in the talk namespace, where subpages exist) looking for a talk page that has an article page that exists, and then link to that if we find one.

Personally I think this is a little icky, with some potential for inconsistent behavior. But probably it would do the "right" thing nearly always, and it would only have a performance drain if there's not a directly matching page.
Comment 2 Roan Kattouw 2008-02-24 19:44:05 UTC
The whole point of disabling subpages in the main NS is that the / character doesn't have any special meaning.
Comment 3 Brion Vibber 2008-02-27 20:35:04 UTC
Right, but it does have meaning in the talk namespace right next to it. So we need some kind of magic way for it to have meaning on *part* of the name, but not the whole thing.

Horrid isn't it? :D
Comment 4 Will Hirsch 2008-02-27 22:26:52 UTC
Why do talk pages of mainspace pages containing slashes (such as [[Talk:OS/2]]) not breadcrumb? Surely the two things are directly related. If a breadcrumb displays, then the page is presenting the title as being of subpage structure. Since it knows that the article namespace doesn't use subpage structure it should be able deduce that the corresponding article is that of the top level talk page in the breadcrumb.
Comment 5 Brion Vibber 2008-02-27 22:45:50 UTC
Because [[Talk:OS]] doesn't exist on en.wikipedia.org at this moment. If it did, then you would see a breadcrumb link on [[Talk:OS/2]] precisely because it doesn't know that that particular "/" would be meaningless.
Comment 6 Will Hirsch 2008-02-28 00:45:50 UTC
Oops, silly oversight!

Well I'm not sure where the rule you suggested in Comment #1 would fail where there aren't currently problems. If the title of a talk page subpage is the same as another article with a slash in it, the problem still exists with how the pages can be named so as not to occupy the same name. If the longer article exists in the mainspace, then it should be a fair assumption that the talk page belongs to that article. If the shorter article wanted a talk subpage with a name /foo/bar where /foo was also a name of an article, MW still wouldn't breadcrumb back to the shorter talk page properly.

In any case, any adverse behaviour would only give a different kind of counter-intuitive link, and probably one where the meaning is really ambiguous anyway. The current problem affects pretty much every sub-page of a talk page there is.

Assuming that Special:Allpages/n is fairly low-load, surely a lookup for the pages alphabetically between the shortest title without a slash, and that name followed by the letter alphabetically after the slash character, would very quickly yield a very short list that can be checked through. It doesn't seem to be too heavy a check to have to make. I suppose it could also be cached as some attribute to the page as well.
Comment 7 Aaron Schulz 2009-01-02 11:14:18 UTC
I'm not sure this is really a bug. Talk:X corresponds to page X, whether that page has a '/' or not. It's not really consistent to jump around based on whether x/y exist and/or x exists.
Comment 8 Gurch 2009-01-02 11:47:52 UTC
(In reply to comment #7)
> I'm not sure this is really a bug. Talk:X corresponds to page X, whether that
> page has a '/' or not. It's not really consistent to jump around based on
> whether x/y exist and/or x exists.

It's not so much a bug as an unfortunate consequence of having a system with pairs of pages where one half of the pair has subpages and the other doesn't. No doubt if we started from scratch we'd do it differently. But yeah, I can't think of a solution to this that wouldn't be awkward and probably break navigation somewhere.
Comment 9 Cenarium 2009-04-16 11:40:13 UTC
A magic word removing surpage links from a page, could handle cases like [[Talk:OS/2]], or [[Talk:AC/DC]]. It would be added on a case-by-case basis, and may have uses in other namespaces, such as project space, too.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links