Wikipedia talk:WikiProject Disambiguation/Malplaced disambiguation pages

Lan/LAN

Moved from Malplaced disambiguation pages

 – LittleWink (talk) 17:30, 6 May 2019 (UTC)

1. Lan redirects to LAN (disambiguation) (of course, this also hinges on a reading of WP:DABNAME)

• I'd say this is correct. Lan is ambiguous – Lan (film), Lan (tribe), etc. – and there are also all-caps meanings such as LAN Airlines. Lan isn't an English word, so we capitalise the title. LAN is a primary redirect, so LAN (disambiguation) is the right title, and Lan correctly redirects there. Certes (talk) 11:55, 11 March 2019 (UTC)
  • I find that reasoning surprising. "Lan" is pronounced as a word (even in English), so I'm not sure why we should prefer the all-caps version when most of the entries are lower-case anyway. – Uanfala (talk) 22:06, 18 March 2019 (UTC)
    • I was just going by WP:DABNAME: When no word can be formed, all capitals is preferred. Technically I suppose a word can be formed, though not an English one, so neither option is clearly wrong and I certainly wouldn't object to anyone moving the dab to Lan. Certes (talk) 22:19, 18 March 2019 (UTC)
      • If you went by this interpretation, then you'd have all-caps for all non-English titles, even in the absence of a single all-cap entry on the page. You know, placenames and the like are words too.... But wait, this will also be true of acronyms. Acronyms are words as well. Hmm.... time to consult the oracles: Wikipedia_talk:Disambiguation#DABNAME,_words_and_acronyms. – Uanfala (talk) 02:34, 19 March 2019 (UTC)
        • Good idea. I've chipped in too, in case my ideas stimulate the oracles to produce something better. Certes (talk) 10:53, 19 March 2019 (UTC)
          • The conclusion appears to have been in favour of "Lan", and the article has now been moved. – Uanfala (talk) 20:10, 6 May 2019 (UTC)

Formosa discussion

@Dudley Miles: I had removed the discussion because the two pages Formosa and Formosa (disambiguation) are no longer malplaced, so the discussion is resolved as far as this project is concerned. There may still be are undoubtedly discussions about various Taiwan pages still going on, but for the narrow scope of this page, this one is done. — Gorthian (talk) 21:27, 2 July 2019 (UTC)

• If I understand correctly - which I may not - there is a malplaced disambiguation issue. Formosa redirects to Geography of Taiwan, which is only one of several uses of the term. I moved it to redirect to Formosa (disambiguation), but this creates a malplaced disambig. An editor has - wrongly in my view - changed it back to Geography of Taiwan but there is still a malplacement problem with the correct redirect. It may be that the correct solution is to make Formosa the disambig rather than a redirect to Formosa (disambiguation) but I do not know what issue this would raise. Dudley Miles (talk) 22:24, 2 July 2019 (UTC)

  Formosa is a primary redirect to Geography of Taiwan, which has a hatnote to Formosa (disambiguation). In the narrow remit of this project page, the dab is not malplaced. Some editors feel that the dab would be a better destination for Formosa. If a consensus forms for that change then the dab should move to the base name. If someone simply retargets Formosa then the page will appear on our automated report as a malplaced dab again. I don't think we need to worry about it until that happens. Certes (talk) 08:33, 3 July 2019 (UTC)

  Correct. WP:PRIMARYREDIRECT is fine. Use WP:RM to discuss the moving of the disambiguation page to the base name. -- JHunterJ (talk) 11:35, 4 May 2020 (UTC)

The problems with MALPLACED?

SmokeyJoe, you mentioned elsewhere that this guideline creates a number of problems? Do you think you'd be interested in elaborating here? This would be a good place to discuss what looks like a significant question. Uanfala (talk) 15:05, 6 August 2022 (UTC)

I wrote elsewhere:

A problem that feeds these problems is the bad old idea and practice of DABNAME and MALPLACED, which means that if there is no PrimaryTopic, the disambiguation page goes at the basename. This is bad because disambiguation pages at basenames cause several problems. To avoid these problems, editor like to overgenerously assign PrimaryTopic to one of the alternatives. In doing so, the PrimaryTopic intent is corrupted, with spin-off problems around.

The solution is to repudiate DABNAME and MALPLACED, and for dab pages like mercury to be at Mercury (disambiguation), with the basename redirecting to it. Then, editors will not need to contrive PrimaryTopic arguments where there is no PrimaryTopic. SmokeyJoe (talk) 14:54, 6 August 2022 (UTC)

I’ve written similarly a large number of times, mostly not garnering responses. Opposition to my suggestion seems to me to be mostly “this is what we’ve done for a long time”, which I find so fallacious that I don’t have a response.

Putting non-PrimaryTopic disambiguation pages at the basename serves no reader, and messes readers. It fails PRECISE. Readers expecting their idea of a PrimaryTopic topic are astonished by not getting it. People wanting, or not wanting, the disambiguation page are misserved by the imprecise titling of these disambiguation pages. Further, I suspect that the common mislinking to dab pages can be attributed to this DABNAME practice, and would be fixed by repudiating this old practice.

The other problems I referred to are the logical contrivances frequently used to establish a PrimaryTopic where there shouldn’t be one. SmokeyJoe (talk) 15:19, 6 August 2022 (UTC)

The question I have is, how does placing mercury at mercury (disambiguation) solve anything? Readers who type in "mercury" thinking they'll get the planet or the element are still going to end up at the dab page. And is having "(disambiguation)" in the title that much of an aid to readers who are looking for the dab page? In other words, wouldn't readers who know enough to look for the dab page recognize one when they find it - and if there's a redirect at mercury (disambiguation), if they type that into the search bar, won't they get where they're going? It seems to me that there isn't a way to make everyone happy if there isn't a clear primary topic, and shuffling deck chairs around here won't do anything to keep Titanic afloat. Parsecboy (talk) 19:37, 6 August 2022 (UTC)

There are multiple problems that it solves. One is that the title and url and hovertext doesn’t inform the reader that they are about to download a disambiguation page.

Having the title describe the contents is a help.

“Wouldn’t readers who know enough…” is the wrong way to look at things. Barriers should be reduced. Reader training with Wikipedia oddities, like imprecise titling and convoluted titling that result in reader-facing inconsistencies, should be avoided.

One unhappiness in argument for over-generous assignment of a primary topic, is that nearly no reader wants the disambiguation page and so better to please the majority over the minority. The root of this problem is the the page being a disambiguation page is being hidden from the reader until they download it. If the page is a disambiguation page, “disambiguation” belongs in the title. PRECISE and CONSISTENT.

Who do you think would be unhappy to find the mercury disambiguation page titled “Mercury (disambiguation)”? SmokeyJoe (talk) 02:14, 7 August 2022 (UTC)

I do see some merit in this proposal. It would be a lot of work, and would break many vital tools (including Dispenser's, which we can't mend), but we must still put readers above technical difficulties. However, the few reader-facing wikilinks go via Mercury (disambiguation). Where do the title and url and hovertext of dab Mercury itself appear – in search, accompanied by a short description which indicates that it's a dab? Certes (talk) 13:15, 7 August 2022 (UTC)

In the drop-down suggestions of the search box, there's no way of knowing if something is a dab page or an article. Uanfala (talk) 13:18, 7 August 2022 (UTC)

WP:INTDABLINK insures that reader-facing links in mainspace will see "disambiguation" in hovertext. The problem I see with this proposal is that if disambiguation pages are uniformly at their "Foo (disambiguation)" title, that will leave the "Foo" titles as redirects more open to manipulation, which will not be as easily caught, because who really pays attention to redirects. For example, if Roger Johnson is a redirect to Roger Johnson (disambiguation), and someone comes along and decides to turn that title into an article on some barely-notable "Roger Johnson", they won't have to go through an WP:RM to do it. BD2412 T 16:25, 7 August 2022 (UTC)

NPP should catch articles which overwrite redirects. However, I don't think we have a mechanism for catching articles which overwrite dabs, which is what Roger the obscure's fan would currently have to do. (That may be a suggestion for improving NPP rather than an argument for or against this proposal.) Certes (talk) 20:33, 7 August 2022 (UTC)

Basename redirects to disambiguation pages could be protected. A newcomer with a minority perspective that their topic is primary would be very tempted to overwrite the redirect, if it were a matter of simply editing it. SmokeyJoe (talk) 22:26, 7 August 2022 (UTC)

We have seen plenty of instances of IPs (who are unable to create new articles) overwriting redirects to bypass that restriction. I would be particularly concerned about that happening with this class of pages, since we would still need the incoming links functioning to see where errors have been made. As long as procedures are in place to insure that a disambiguation page (or a redirect to one) is not made into something else without discussion, I don't think that it matters enough to take a position in opposition. I would note, however, that if this were to be done, we would want to preserve the edit history of the disambiguation pages, which would require several hundred thousand page swaps, with the swapped redirect being fixed so that it points to the disambiguation page rather than itself. BD2412 T 22:45, 7 August 2022 (UTC)

We have procedures (WP:NPPREDIRECT) in place to review (but not prevent) a redirect (to dab or to article) being made into an article (or a dab). There's nothing to stop a dab being overwritten by an article and, as far as I know, no systematic detection. Sadly, like cut-and-paste moves, doing this the right way in MediaWiki requires more privileges than doing it the wrong way. Certes (talk) 08:36, 8 August 2022 (UTC)

A Phabricator ticket T314762 just appeared – thanks, Novem Linguae. Certes (talk) 08:37, 8 August 2022 (UTC)

I think exactly the same about projectspace DAB pages, like WP:S and WP:PS. SmokeyJoe (talk) 23:02, 11 August 2022 (UTC)

Why are dabs special in this respect? Is there not an equal case for moving Venus to Venus (planet) and having Venus redirect there, so readers who see the page listed in a search dropdown will understand that it's not about the deity? Certes (talk) 22:46, 7 August 2022 (UTC)

I don’t disagree, but don’t want to broaden the point out of fear of committing to engaging with even more inertia. For Venus, at least the reader isn’t misled about the page being an article. SmokeyJoe (talk) 23:01, 11 August 2022 (UTC)

Every week I catch inappropriate primary topic grabs due to the current setup, which I believe should be retained. Unfortunately, many disambiguation pages are not watched enough for such things to be caught immediately, and changing primary topic redirects is one of the easiest ways to cause disruption or start an edit war. Frequently, NPP does not catch these things because they can look appropriate on their face and require knowledge of the topic (and that there are other topics involved). Eliminating WP:MALPLACED would slightly reduce volume at WP:RM, but it would probably result in a persistent, unworkable overload at WP:RFD. As another side-effect, it would be more difficult to catch wikilinks that point not to dab pages, but to incorrect articles. In my case, I do not get surprised that a link is pointing to a dab because I have the wikilinks set to a different color for all dab pages; perhaps this could be instituted sitewide at some point. (As a side note, I find WP:ONEOTHER for page titles ending in "(disambiguation)" more disruptive. Getting rid of navigational pages when they aren't in the way doesn't help anyone.) Dekimasuよ! 02:35, 12 August 2022 (UTC)

Another few side notes: 1) titling criteria like WP:PRECISE are being raised above. I do not think WP:PRECISE applies, precisely because dab pages are not articles. If it did, the change suggested here would fail WP:CONCISE and the exception related to disambiguation in WP:CONSISTENT. The other criteria (naturalness and recognizability) clearly do not apply to dab pages because they do not have their own distinct topics. 2) I tried going back through the talk archives at WT:DAB to find previous discussions on this topic, and without exception they were objections raised by SmokeyJoe. On its own that does not mean that the objections are wrong, but it has mostly been a one-editor objection over the last five years or so. 3) I agree with Uanfala that this is one good place to discuss issues related to naming disambiguation pages, but it has only 64 watchers as opposed to 473 at WP:DPL, 762 at WP:DAB, and 613 at WP:WPDAB. At the least, before bringing this to WT:DAB it would make sense to ask WP:DPL and Russ about any problems a change might cause. Dekimasuよ! 02:57, 12 August 2022 (UTC)

Not expressing any opinion about the proposal, but just responding to Dekimasu's question. The script that populates WP:MALPLACED each week would need to be rewritten to look for redirects in the other direction. Apart from my innate desire to avoid work, that doesn't sound like a particularly difficult task. As for the lists that DPL bot maintains, currently the lists don't count any links to "Foo (disambiguation)" but do count links to titles that redirect to a "(disambiguation)" title. Presumably that rule would still work, since if I understand the proposal correctly, WP:INTDABLINK would continue to say that articles should not link directly to a "(disambiguation)" title unless it is an intentional link to the dab page. Please correct me if I'm wrong. --R'n'B (call me Russ) 18:24, 12 August 2022 (UTC)

I think PRECISE should have to apply to anything that a casual reader might think is the title/url for an article.

CONSISTENT applies in that every DAB page should be consistently recognisable to readers as a DAB page.

RECOGNIZABILITY applies as it should be recognizable to any reader that the page is, or is not, a DAB page.

MALPLACED is a root cause of recognised other problems. Few have either agreed or disagreed with me, I put it down to the MALPLACED practice being old and not terribly interesting. I think MALPLACED was a mistake, but reversing it is not a trivial undertaking.

On inappropriate PrimaryTopic grabs, for basename redirects to the DAB page, protect the redirect. Having all DAB pages suffixed “(disambiguation)” should immediately end inappropriate changing the DAB page into a single topic article page. SmokeyJoe (talk) 03:46, 13 August 2022 (UTC)

"Protect the redirect" might be a tall order in and of itself. We would need to convince the community that a widespread scheme of protection was warranted, and would still need to worry about those able to edit through protection unilaterally deciding that Amazon or Android or Georgia have a primary topic. BD2412 T 19:32, 13 August 2022 (UTC)

Yes it might be a tall order, but I think it might be necessary. PrimaryTopic grabs are done by people with strong conviction that their topic is the PrimaryTopic, and over-writing the redirect would be very tempting. This speaks to the very problem that started this conversation.

Protection will stop the newcomers from doing it unilaterally. For those able to edit through protection, they will be expected to know better, and if it happens “by accident in ignorance of the new practice” then WP:Editnotices could be used.

There is a good philosophy against preemptive protection, but if there were a clear consensus that “where there is no PrimaryTopic for the title it must redirect to a DAB page”, then it would be justified. SmokeyJoe (talk) 22:44, 13 August 2022 (UTC)