Jump to content

Wikipedia talk:Disambiguation/Archive 57

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 50←Archive 55Archive 56Archive 57

top/common ordering as a matter of style vs. navigation efficiency

I've noticed a few cases recently where MOS:DABCOMMON formatting was a bit of an issue:

Several of the discussions at Wikipedia talk:Manual of Style/Disambiguation pages/Archive 44 have been about ordering, too. The search of talk page archives here brings up a lot of discussions on ordering as well. Maybe we need to ponder this matter more coherently.

It seems to me that we should move the part of the style guideline that affects the top of a disambiguation page into the main guideline here, because this doesn't seem to be a matter of just style per se, rather it might be making a significant impact on ensuring that a reader who searches for a topic using a particular term can get to the information on that topic quickly and easily. --Joy (talk) 09:54, 25 July 2024 (UTC)

I'm not sure that advantage of having a common uses group at the top is always clear-cut. It can result in slowing navigation if readers jump to the relevant section expecting to find the specific item listed there only to have to look back up to the top. This is similar to what can happen with a primary topic as well and raises question of whether such entries should be duplicated within the appropriate section as well as at the top. older ≠ wiser 12:54, 25 July 2024 (UTC)
I agree, we should actually list the common items in both places. If the list is already relatively long, duplicating a couple of popular items shouldn't lengthen it unreasonably, and we hopefully catch most of those cases. --Joy (talk) 16:52, 25 July 2024 (UTC)
That and also with relatively short pages, it may be unnecessary or even counter-productive to try to pull out a couple. older ≠ wiser 17:21, 25 July 2024 (UTC)
Because of so much possible variety, we'd have to test on specific examples. For example, is it 1 common 20 uncommon, or 2 : 20, or 1 : 10, or 3 : 10, and then the varying levels of how common each of the common ones is, etc. --Joy (talk) 18:51, 26 July 2024 (UTC)
It looks like we found a case of such a relatively short page - at Deadlock, most of the common entries were in Other uses, and @Zxcvbnm removed them[1]. --Joy (talk) 07:14, 23 August 2024 (UTC)
Yeah, that seems reasonable as two of the duplicates were in "Other uses" section and the third was in weakly coherent "Politics and law" section that had only remaining entry merged into other uses. It's a bit odd that impasse remains duplicated in the see also section. older ≠ wiser 11:06, 23 August 2024 (UTC)
In the meantime, at King Charles, adding a duplicate listing in the appropriate section immediately below the top listing looks to have been helpful to at least half the readers who missed the top listing before, per two monthly measurements afterwards. --Joy (talk) 09:14, 6 September 2024 (UTC)

Capitalization of a disambiguation page title with both all-caps and lowercase senses

I seem to recall that there is a rule that if a disambiguation page has both all-caps and lowercase senses, then the title of the page should be at the lowercase title, if that is available. In particular, I am thinking of LOR (for which many Lor senses exist). Lor currently redirects to LOR. I am not asking for a page move here, but for where the rule on this can be found. If there is no rule on this, where should one be put? BD2412 T 01:58, 2 August 2024 (UTC)

I think what you're looking for is two of the bullets under WP:DABNAME:
  • A word is preferred to an abbreviation, for example Arm (disambiguation) over ARM.
  • The spelling that reflects the majority of items on the page is preferred to less common alternatives.
Those can sometimes be contradictory, but it's probably best to hash those out on a case-by-case basis. Station1 (talk) 06:01, 2 August 2024 (UTC)
The real question here is do we have to account for this merge in the first place? If you see distinct usage patterns based on capitalization, and if it would make navigation more efficient if the reader didn't have to wade through both lists together, they should simply be split up, as this guideline is not actually consistently applied in the first place, cf. Wikipedia talk:Disambiguation/Archive 56#WP:DABCOMBINE not actually with organic consensus in the acronym space.
In my browser, I have to do PgDn twice already to browse that list, so if that can be two lists of Lor and LOR and if these would be more straightforward, that would actually make more sense. The idea of merging is valid where we believe there's a huge amount of traffic of people e.g. typing in "lor" but wanting "LOR". If these could be served with a link to LOR visible on the first page without scrolling, that seems better than forcing the readers to go through two pages of a more complex list on every visit. And, it would become measurable, we could see in the statistics how many readers needed to do that. --Joy (talk) 07:25, 2 August 2024 (UTC)
... as this guideline is not actually consistently applied in the first place ...: It is a guideline, until it is modifed or removed. Until then, it's unclear if other examples are WP:OTHERSTUFF or WP:IAR.—Bagumba (talk) 09:53, 2 August 2024 (UTC)
Well, the WP:DABCOMBINE guideline is only useful if it actually makes sense. The current text is just too broad:
Terms that differ only in capitalization, punctuation and diacritic marks. These should almost always share a disambiguation page.
This just says 'terms', but it doesn't have to be that generic: for example, Mediawiki forces us to combine arm and Arm, but it doesn't force us to combine Arm and ARM. If we have 9 known meanings of Arm, 3 known meanings of both Arm/arm and ARM not because of laziness in typing (company, software, language), and 34 known meanings of ARM, it's neither trivial nor obvious to just advise these almost always need to be one list of 46 items, and we should not guide people towards that solution in such strong terms.
This guideline sounds like it was written only for short, more trivial use cases, and I sincerely doubt that anybody ever checked if it was actually battle-tested by analyzing its outcomes. We should change it to be less strong. --Joy (talk) 09:39, 6 September 2024 (UTC)
@Joy: I have seen much longer "merged" pages, and would be concerned that some people searching for "LOR" will not bother to capitalize when typing the letters into the search box. BD2412 T 17:50, 2 August 2024 (UTC)
In the case of long pages, that can be handled by adding, for example, "LOR (disambiguation)" to See Also, or even adding it as a hatnote if See Also is really far down the page. Even with merged pages I think it's easier for readers to find what they're looking for if the Lors and LORs are split into separate sections. Station1 (talk) 18:03, 2 August 2024 (UTC)

Cleaning up INCDAB

I've been going through Category:Disambiguation pages with (qualified) titles and cleaned up all the straight-forward cases, but I am not sure if my "solution" for the past few incdabs were going to far (and that I should self-revert them). Specifically, I created {{anchor}}s in list sections within articles (which are neither dab pages nor lists, as mentioned in WP:INCDAB) where the former incdabs now redirect.

The navigational/dab value is still intact, but I figure there might be problems with Wikipedia:Disambiguation pages with links down the line. Opinions? – sgeureka t•c 14:51, 11 September 2024 (UTC)

Avoiding confusing or astonishing readers

WP:D says in the lead:

[An important aspect to disambiguation is] ensuring that a reader who searches for a topic using a particular term can get to the information on that topic quickly and easily, whichever of the possible topics it might be.

I'd like to compare that to WP:CONS, which says:

The goal of a consensus-building discussion is to resolve disputes in a way that reflects Wikipedia's goals and policies while angering as few editors as possible.

Using that kind of a standard, I'd say we should make it an explicit aim of disambiguation (or more generally, navigation) to make sure we confuse or astonish as few readers as possible.

This would be aimed at helping balance the two major primary topic criteria and in general reinforce the idea of double-checking whether there is a primary topic at all. So, for example,

  • if there's very popular topics for a term, but they don't necessarily have long-term significance, we remind people to ponder if the average reader would be confused or astonished to see us 'push' one of these popular topics rather than present the ambiguity

Conversely,

  • if there's no particularly popular topics, but there are topics of long-term significance, we remind people to ponder if the average reader would be confused or astonished to see us 'promote' one of these significant topics rather than present the ambiguity

Often times in requested move discussions I notice people can be keen to just pick a topic as primary and be done with it, regardless of whether we have a sound analysis of the big picture - whether we can actually tell how big is the advantage of the most popular/important topic over the others. Too often we're just spitballing it, deciding based on personal biases. The guideline should do more to try to counteract that.

The current guideline text covers reader confusion and astonishment in a few places, notably:

To be clear, it is not our goal to astonish our readers, and the topic that comes first to mind indeed often is suitable as the primary topic. Anne Hathaway, as one of countless examples, takes the reader to the modern-day American movie star's page, not to the article on the wife of William Shakespeare. But in no case do "what comes first to mind" or "what is astonishing" have much bearing, either positive or negative, on which topic, if any, actually is the primary topic.

I don't think this final sentence is actually helpful or leading to good navigation outcomes - leaving things open like that is not a good guideline. --Joy (talk) 13:04, 10 October 2024 (UTC)

Location of self-reference tool templates {{srt}}, {{look from}}, {{intitle}}

These templates help a lot with cutting down on non-essential WP:PARTIAL matches, but it's not really clear WHERE in the See also section they should appear. I always put them at the top because that's how I saw them first in Draw#See also about 15 years ago. But in recent times, I tend to see them (70%) as the very last thing in the See also section, below other XXX (disambiguation) and alternative-spellings. Is there a good reason to do it one way or the other, or deliberately leave it to the editor? – sgeureka t•c 12:15, 15 August 2024 (UTC)

@Sgeureka: I would put them first, using the guideline at MOS:DABSEEALSO. Shhhnotsoloud (talk) 11:44, 13 October 2024 (UTC)

followup to how page views can change between having and not having a primary topic or primary redirect

Wikipedia talk:Disambiguation/Archive 56#a change in page views between primary topic and primary redirect got archived, but I keep finding more of these examples:

  • Talk:Jump drive - went from 4k views/month to almost nothing after being turned into a primary redirect
  • Talk:Tuk#post-move - went from less than ~200 views/month to consistently over, spiking at ~350

--Joy (talk) 22:28, 18 October 2024 (UTC) --Joy (talk) 19:32, 25 October 2024 (UTC)

Editor insists on adding references and external links to the disambiguation page Ionex

User:MolecularPilot has added references and external links to the disambiguation page Ionex, and has readded them following my removal of them. It has been explained to this editor that these are forbidden on disambiguation pages, but the editor persists. Will someone please explain this point of policy to them in a way that will cause them to conform their conduct to policy? I am beginning to fear that a topic ban may be necessary. BD2412 T 01:25, 1 November 2024 (UTC)

@BD2412 Hi! I'm so sorry. What happens: I added new content with references, reporter undid them. I wanted to add the content back without references (as they are in the article) but I'm in mobile now so it was a bit tricky so I undid the reporters undo and then I removed the references. I think they might just have seen the undo notification and not checked the page history for what I did. MolecularPilot 01:29, 1 November 2024 (UTC)
I accept this explanation, given the difficulties that sometimes arise with editing on a mobile device. BD2412 T 01:32, 1 November 2024 (UTC)

Nutshell

Moved from user talk:The Mountain of Eden
 – The Mountain of Eden (talk) 20:26, 1 November 2024 (UTC)

Hi, I undid your edit to the nutshell but accidentally hit the return key before typing an edit summary! The problem is that "disambiguation" occurs in a variety of ways, not only via disambiguation pages, but also by hatnotes and "see also" links in articles. Your rewrite suggested that the topic is limited solely to disambiguation pages. --R'n'B (call me Russ) 20:07, 1 November 2024 (UTC)

  • I don't think "see also" sections are used for disambiguation purposes. They are used for making links to related articles.
  • While hatnotes can be used for disambiguation purposes, they are only good when the number of possible links is very limited (2 or 3 at the most)
  • Most importantly: I don't think that the existence of hat notes invalidates the proposed text "Disambiguation pages serve as navigation guides that allow a reader to quickly find the article that best fits what they had in mind in cases when the search term could reasonably apply to more than one article."
The Mountain of Eden (talk) 20:33, 1 November 2024 (UTC)
No, it does not adequately provide a nutshell of what disambiguation is. This guideline page is about much more than disambiguation pages. older ≠ wiser 20:54, 1 November 2024 (UTC)
Point taken. We can modify the proposed text to say "Disambiguation pages and hatnotes serve as navigation guides ..." -- The Mountain of Eden (talk) 21:01, 1 November 2024 (UTC)
I don't see that there was any actual problem with the current text. older ≠ wiser 21:25, 1 November 2024 (UTC)
The problem with the existing text of the nutshell is that it starts out with "It is necessary ....". Since that is the very first sentence, the pronoun "it" is ambiguous. That's why I rewrote the nutshell. —The Mountain of Eden (talk) 21:51, 1 November 2024 (UTC)
Is there some stylistic prohibition about this on Wikipedia? It seems a fairly common imperative construction using a dummy pronoun. Is there evidence readers are finding this construction ambiguous? older ≠ wiser 22:02, 1 November 2024 (UTC)
Why use a dummy pronoun when it can easily be written out? The Mountain of Eden (talk) 22:11, 1 November 2024 (UTC)
Sometimes writing it out is not an improvement. And if there is no actual problem, then what the is need to fix anything.older ≠ wiser 22:41, 1 November 2024 (UTC)
Removing the dummy pronoun makes it less colloquial. The Mountain of Eden (talk) 00:23, 2 November 2024 (UTC)
Still don't see that there is any problem that needs fixing.older ≠ wiser 00:40, 2 November 2024 (UTC)
Do you think the proposed text is worse than the existing text? If so, how? —The Mountain of Eden (talk) 06:03, 2 November 2024 (UTC)
The question to start with is to specify precisely what is it that you are trying to "fix" aside from a possible stylistic weakness and gain consensus that this is actually a problem. Then discussions about solutions can be more fruitful. older ≠ wiser 10:38, 2 November 2024 (UTC)
I have already stated what I'm trying to fix (eliminate the use of the dummy pronoun). In your opinion, it's not broke, and you are entitled to hold that opinion. So now the question is even though you don't think the existing text is broken, is the new proposed text worse than the existing text, and if it is worse, why? The Mountain of Eden (talk) 14:17, 2 November 2024 (UTC)
It provides an incomplete summary of the page. And your suggestion for making it more complete would be more unwieldy and less efficient than the current text. older ≠ wiser 14:29, 2 November 2024 (UTC)
It sounds to me like you are saying that the fix of the additional words "and hatnotes" to give "Disambiguation pages and hatnotes serve as navigation guides ..." makes the proposed text a good summary.
I fail to see your point that "Disambiguation pages and hatnotes" is any more unwieldy than the existing text of "links and disambiguation pages". The Mountain of Eden (talk) 15:36, 2 November 2024 (UTC)
No, that's not what I'm saying. You object to the current text on a stylistic basis, not on any actual deficiency. I do not think what you propose is any sort of improvement. older ≠ wiser 15:58, 2 November 2024 (UTC)
You have made your point abundantly clear that you don't like the proposed text. Up to now, you have failed to communicate what you think is wrong with the proposed text. The Mountain of Eden (talk) 16:02, 2 November 2024 (UTC)
You have failed to demonstrate any actual deficiency in the current text. older ≠ wiser 16:07, 2 November 2024 (UTC)
That's not true. I have already pointed out that the existing text uses the dummy pronoun, which is too colloquial. The Mountain of Eden (talk) 17:29, 2 November 2024 (UTC)
That's your opinion, not an actual defect. older ≠ wiser 17:37, 2 November 2024 (UTC)
It's your opinion that it's not a defect. So given that you cannot point to any defects in the proposed text, I will go ahead and put it into the project page. The Mountain of Eden (talk) 17:39, 2 November 2024 (UTC)
You've already been reverted by another editor. I suggest that you first gain consensus that there is an actual problem with the current text. Then there perhaps can be some productive discussion about how to address that. older ≠ wiser 18:09, 2 November 2024 (UTC)

I have to agree with older ≠ wiser on this. The page is about disambiguation generally. In fact, the first two of three bullets start out by mentioning titling and wikilinks. There are several methods of disambiguating topics, including titles, incoming wikilinks, outgoing links not just in hatnotes, although that is most common, but also in the lead or body of articles or See Also sections. The focus of the page is not just hatnotes and dab pages. It might be possible to improve the nutshell, but the focus is not just hatnotes. Station1 (talk) 18:07, 2 November 2024 (UTC)

Good points. How about this proposed text?
Disambiguation helps readers quickly find the article that best fits what they had in mind in cases when the search term could reasonably apply to more than one article.
This takes takes out the details of what tools are used for disambiguation, is much shorter and cleaner than the existing nutshell (29 words for the proposed text, 33 words in the existing text), and most importantly (at least for me), takes out the dummy pronoun "it is" that gives the nutshell a colloquial tone. The Mountain of Eden (talk) 19:26, 2 November 2024 (UTC)
This is progress. I'd suggest leaving out mention of the reader's mind and also "search term", as the process isn't only about searching -- it is also about ensuring articles are named in a way to minimize ambiguity. How about:
Disambiguation helps readers quickly find a desired article in cases when a term could reasonably apply to more than one article.
older ≠ wiser 19:39, 2 November 2024 (UTC)
Even better !! Only 21 words. -The Mountain of Eden (talk) 19:54, 2 November 2024 (UTC)
That sounds good to me. Station1 (talk) 02:01, 3 November 2024 (UTC)
Shouldn't the last word be topic rather than article? PamD 05:25, 3 November 2024 (UTC)
I don't think so. It's about finding the right article when multiple articles can reasonably apply to a term. The Mountain of Eden (talk) 05:46, 3 November 2024 (UTC)
This is nice and clear and concise. I agree it applies to articles, not topics. There may be multiple articles with similar titles but different topics: that's what disambiguation is usually about. Shooterwalker (talk) 13:51, 3 November 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Disambiguation/Archive_57&oldid=1267061197"
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy