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.

The whole point of disabling subpages in the main NS is that the / character doesn't have any special meaning.

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

wikimedia wrote:

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.

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.

wikimedia wrote:

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.

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.

matthew.britton wrote:

(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.

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.