Knowledge (XXG)

This is the talk page for discussing improvements to the Disambiguation page.

Put new text under old text. Click here to start a new topic. New to Knowledge (XXG)? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Shortcuts WT:D WT:DAB

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56Auto-archiving period: 60 days

The contentious topics procedure applies to this page. This page is related to the English Knowledge (XXG) article titles policy and Manual of Style, which has been designated as a contentious topic. Editors who repeatedly or seriously fail to adhere to the purpose of Knowledge (XXG), any expected standards of behaviour, or any normal editorial process may be blocked or restricted by an administrator. Editors are advised to familiarise themselves with the contentious topics procedures before editing this page.

This project page does not require a rating on Knowledge (XXG)'s content assessment scale. It is of interest to the following WikiProjects:

Disambiguation This page is within the scope of WikiProject Disambiguation, an attempt to structure and organize all disambiguation pages on Knowledge (XXG). If you wish to help, you can edit the page attached to this talk page, or visit the project page, where you can join the project or contribute to the discussion.DisambiguationKnowledge (XXG):WikiProject DisambiguationTemplate:WikiProject DisambiguationDisambiguation articles

Here's some more bits of info I've gathered after someone asked at Talk:Tupelo:

• Talk:Slow#followup to move
  • hatnote got up to 50% of traffic
  • after the move, the previously presumed primary topic barely registers though the common section does consistently get a measurably noticable chunk of traffic
• Talk:Panis#post-move
  • a primary redirect was in place and no hatnote
  • after the move, the previous presumed primary topic got ~1.2%, ~1.4%, ~2.4%, ~1.9%
• Talk:Zozo#post-move
  • hatnote got a small amount of traffic but almost all identifiable traffic anyway; RM received very little interest
  • after the move, the previous presumed primary topic got ~2.6%, ~1.9%, ~2.2%
• Talk:Mar#post-move
  • hatnote got ~5.2% compared to incoming traffic
  • after the move, the previous presumed primary topic got ~6.5%, ~4.3%, ~4%, ~2.9% (the latter being a weird month)
• Talk:Julius#followup to move
  • a primary redirect was in place before, hatnote got ~3.5% of traffic, we noted the redirect ratio back then as 68/91 = ~75%
  • after the move, the previous redirect destination got ~11%, ~5%, ~3%, ~4%
• Talk:Sola#followup to move
  • hatnote got ~10% of traffic
  • after the move the previous presumed primary topic got ~7%, ~7%, and then with the fall of overall traffic it was below the anonymization threshold (< 10/273 = < 3.66% with every source-destination combination - which doesn't mean it wasn't actually something different though still a minority).
• Talk:Tete#post-move
  • the hatnote got ~11% before the move
  • afterwards the previously presumed primary topic gets ~6%, ~7.2%, ~8.2%
• Talk:Uma#post-move
  • there was a primary redirect in place and the hatnote got ~25.3% of its traffic before the move and dis. traffic was much larger still
  • afterwards the previously presumed primary topic gets ~8.2%, ~9%, ~11% interest
• Talk:Ty#post-move
  • hatnote got a very small amount of traffic (max 220/13742 = ~1.6%), was only #5 in the top list
  • after the move, the previously presumed primary topic was sorted down in the list, got ~7% clicks the next month; sorted back up the following month it got ~8%, ~7.5%, ~5% clicks, though ~53% / ~55% / ~60% / ~47% of identifiable outgoing
• Talk:Hum#full disambiguation again
  • used to be primary redirected to human humming, went back and forth a bit
  • previous primary redirect destination gets ~10%, ~8%, ~8%
• Talk:Marr#post-move
  • hatnote got ~10% of traffic
  • after the move the previous presumed primary topic got ~11%, ~10.5%, ~11%, ~7.2%, ~9.6%
• Talk:Rara#post-move
  • hatnote got some traffic before, all small
  • after the move the previous presumed primary topic got ~11.9%, ~11.3%
  • closely connected topic also shows up in outgoing destinations, but nothing else
• Talk:Cam#post-move
  • hatnote got ~3.3% of traffic
  • after the move the previous presumed primary topic got ~11.5%, ~8.6%, ~12.3%, ~11.4%, ~17.8%, ~16.8%
• Talk:Luz#post-move
  • hatnote got ~9.7% of traffic, total disambiguation list traffic at times substantially higher as well
  • after the move the previous presumed primary topic got ~12%, ~7%, ~7.7% among several other topics
• Talk:Top#post-move
  • hatnote got ~2%
  • after the move the previous presumed primary topic got ~12%, ~9%, ~9%, ~9.5% and less than half of identified outgoing
• Talk:Kolya#post-move
  • hatnote got ~1.4%, total disambiguation list traffic substantially higher than that
  • after the move the previous presumed primary topic got ~13%, ~11%, ~8%, ~7.6%, ~7%
• Talk:Shoot#post-move
  • hatnote got ~1% of traffic
  • after the move, the previously presumed primary topic got ~11%, ~10%, ~11%, ~12%, ~14.5% interest
• Talk:Redd#post-move
  • hatnote got ~5% of traffic
  • after the move, the previously presumed primary topic got ~10.8%, 19.6%, ~10%, ~17%, ~15%
• Talk:Tupelo#post-move
  • hatnote got ~3% of traffic
  • after the move, the previously presumed primary topic got ~14%, ~28%, ~31%, ~30%
• Talk:Boyle#post-move
  • hatnote got <4% of traffic
  • after the move, the previously presumed primary topic got ~15.6%, ~33%, though it's not clear if this is an actual improvement as we know we're burying one notable part of it at least, ~40%, ~40%, ~36%
• Talk:Vic#post-move
  • hatnote got ~2%
  • after the move, the previously presumed primary topic got ~15.8%, ~15%, ~18%, ~20%, though most of outgoing
• Talk:Golden shower#disambiguated
  • hatnote was on top of Knowledge (XXG):WikiProject Disambiguation/Popular pages
  • after the move, the previously presumed primary topic got ~0.7%, ~0.75%
  • another popular meaning got ~15%, ~17.3% though >90% identified outgoing
• Talk:Bold#post-move
  • the previous stats indicated up to ~20% interest in the hatnote
  • after the move the interest in the previously presumed primary topic was ~16%, ~14.7%, ~18.4%, ~12.1%, ~14.3%
• Talk:Julia#post-move
  • hatnote got ~20% of traffic
  • after the move, the previously presumed primary topic got ~14%, ~16%, ~17%
• Talk:Slava#post-move
  • hatnote got ~13% of traffic
  • after the move, we continue seeing seasonal spikes for the previously presumed primary topic, and regardless of spikes it gets ~23%, ~15%, ~11%, ~9.5%, ~14%, ~11.5%, ~10%, ~14% interest
• Talk:Hamme#post-move
  • hatnote got relatively small traffic, was not measurable, most likely <10%
  • after the move, the previously presumed primary topic got ~16% interest
  • reverted, subsequent discussion resulted in no consensus
• Talk:Baudouin#post-move
  • primary redirect, hatnote got < 0.5% interest compared to total incoming traffic at destination, nobody checked a comparison of redirect and disambiguation traffic
  • after the move, the previously presumed primary topic got ~16%, ~23%, ~17% interest
• Talk:Warren#followup to move
  • hatnote got ~7% of traffic
  • after the move, the previously presumed primary topic got ~18%, ~12%, ~14%, ~15% interest
• Talk:Hamm#followup to move
  • hatnote got ~2.5% of traffic
  • after the move, the previously presumed primary topic got ~18.4%, ~21%, ~22.9% interest
• Talk:Mana#post-move
  • hatnotes combined got ~8% of traffic
  • after the move, the previously presumed primary topic got ~19%, ~17%, ~16% interest
• Talk:Charlotte#post-move
  • the hatnote got ~0.7% before the move, yet there were hints that it could do better if reorganized because of ~20% measurements related to the primary redirect (which we sadly can't have in a lot of cases)
  • afterwards the previous presumed primary topic gets ~21%, ~23.5%, ~21.1%, ~22.9% interest
• Talk:Lili#post-move
  • the hatnote got ~2% before the move
  • after the move, the previously presumed primary topic got ~23.2%, ~15.4%, ~26.4% interest
• Talk:Gaga#post-move
  • the hatnote got ~1.5% before the move
  • after the move, the previously presumed primary topic got ~24.8%, ~29.9%, ~27.4% interest
• Talk:Saba#post-move
  • hatnote was in the top 5 of identifiable outgoing clickstreams, the ratio wasn't recorded then but was around 635/23806 = ~2.6%
  • after the move, the previously presumed primary topic got ~28.5%, ~26%, ~24%, ~23.5%, though around half of outgoing
• Talk:Frida#post-move
  • hatnote got ~2% of traffic
  • after the move, the previously presumed primary topic got ~27%, ~19%, ~27%, ~24.2%
• Talk:Thomastown#post-move
  • hatnote got ~1%
  • after the move, the previously presumed primary topic got ~25%, ~28%
• Talk:Forced march#post move to disambiguation
  • was a soft redirect between 2011 and 2015, when it was made a primary redirect, and in 2023 it was disambiguated after a discussion
  • previous primary redirect destination gets ~29%, ~27%, ~44%, ~34.1%, another meaning that wasn't even mentioned in the RFD gets much more
• Talk:Major#post-move
  • the previously discussed primary topic was moved after a lot of discussions, at the time of the RM the hatnote had max 431/17909 (~2.4%) interest
  • afterwards it shows up with ~30.6%, ~30.3%, ~25%, ~28%, ~21.3%, ~26.9%, ~37.1% of reader interest, though three quarters of outgoing
• Talk:Ultra#post-move
  • the hatnote got ~2% before the move
  • afterwards the previously presumed primary topic gets ~29%, ~30.6%, ~26.5%, ~23%, ~26.9%, ~20.6%
• Talk:Quantum leap#post-move
  • the hatnotes got ~21% before the move
  • afterwards the previously presumed primary topic gets ~32%, ~29.7%, ~32.5%
• Talk:San Juan#followup to move discussion
  • before the discussion, the most popular link is alphabetically sorted in the middle of a big list and got ~22% clickstreams
  • after the discussion, it's on top of a MOS:DABCOMMON section, and gets ~29%, ~38%, ~26%
• Talk:Sokol#post-move
  • hatnote got ~3-4%
  • afterwards the previously presumed primary topic got ~33%, ~21%, ~30%
• Talk:Rasna#post-move
  • hatnote got ~1%
  • afterwards the previously presumed primary topic got ~20.9%, ~23.2%
  • move got reverted, went through a RM
  • afterwards the previously presumed primary topic got ~37%, ~38%, ~39%, ~53%
• Talk:Severian#post-move
  • hatnote got ~1.7%
  • after the move, previously presumed primary topic got ~37%, ~33%, ~31%, ~25%, ~35%, ~23%, ~29%, ~24%
• Talk:Tiro#post-move
  • primary redirect was in place and we could measure ~18% of interest in the hatnote
  • after the move, previously presumed primary topic got ~36%, ~28%, ~36%
• Talk:Lio#post-move
  • before the move, hatnote got ~1%
  • after the move, previously presumed primary topic got ~35.6%, ~37.9%, though >90% outgoing
• Talk:Mons#post-move
  • hatnote got ~2%
  • after the move, previously presumed primary topic got ~38.5%, ~33.3%, ~32.3%, ~40.9%
• Talk:Starwood#post-move
  • hatnote got ~2%
  • after the move, previously presumed primary topic got ~38.5%, ~35%, ~36.6%
• Talk:Dave Hill#post-move
  • hatnote got ~0.5%
  • after the move, previously presumed primary topic got ~39%, ~46.1%, though almost all outgoing
• Talk:Alnair#post-move
  • had a primary redirect
  • after disambiguation, previously presumed primary topic got ~46.5%, ~38%, ~41.5%
• Talk:Angles#followup to move discussion
  • with primary topic in place, hatnote got less than 0.5% compared to incoming traffic and wasn't even in top 20 clickstreams
  • after the move, the previously presumed primary topic gets ~46.5%, ~43.6%, ~43.7%, ~42%
• Talk:ATB#post-move
  • hatnote got ~1%
  • after the move, previously presumed primary topic got ~47%, ~45%, though almost all identifiable outgoing
• Talk:Lord Cameron#followup to move discussion
  • proposed primary redirect quite recent, no consensus
  • proposed primary topic later got ~47%, ~54.8%, ~36.3%, ~54.2%, ~52.4% of incoming traffic
• Talk:Give Me Liberty#post-move
  • hatnote did not get an observable level of interest
  • after the move, previously presumed primary topic got ~62%, ~39%, ~42.5%
• Talk:Erasure#post-move
  • hatnote got < 0.3% interest, I myself doubted that there's a navigation issue there, but it wasn't completely clear
  • after the move, the previously presumed primary topic got ~48%, ~47%, ~44%, ~47.9% interest
• Talk:AEG#post-move
  • hatnote got ~1% of traffic, I was skeptical because of that and long-term significance aspects
  • after the move the previous presumed primary topic got ~49%, ~47.5%, ~47.3% interest, though ~90% of identifiable outgoing
• Talk:Motul#followup to move discussion
  • proposed primary topic gets ~51%, ~49%, ~52%, ~48%, ~51%
  • no consensus to move
• Talk:Nabis#post-move
  • hatnote had ~1% interest
  • after the move the previous presumed primary topic got ~50%, ~58%, ~42%, ~49%, ~51%
• Talk:King Charles#post-move
  • several RMs, kept disambiguated
  • proposed primary topic gets ~60%, ~55.9%, ~58.4%, ~61.7%, ~61.8%, ~59.1% interest, though ~80% of identifiable outgoing, and hints of more
• Talk:Sugar Man#post-move
  • was a primary redirect, the ratio between redirect views and disambiguation views was between ~23% and ~43% but then mostly going back
  • after the move the previous redirect destination got ~60%, ~61.5%, ~61%, ~68.2%
• Talk:Heavy metal music/Archive 13#Requested move 12 June 2023
  • proposed primary topic got ~60% of traffic, though a fair bit of of it came from there, too
  • the discussion was overwhelmingly against the move regardless
• Talk:Sean O'Malley (fighter)#Requested move 5 March 2024
  • proposed primary topic got ~71% or ~84% of traffic, one other topic identifiable as well
  • no consensus
• Talk:Michael Fagan#Requested move 17 February 2024
  • proposed primary topic got between around 70 to around 85 percent of traffic for years and across spikes in usage
  • no other major topics by long-term significance, consensus to move by usage

I think I'll have to keep updating this summary here to build up a knowledge base. --Joy (talk) 15:19, 1 March 2024 (UTC)

--Joy (talk) 14:44, 6 April 2024 (UTC)

--Joy (talk) 18:05, 10 May 2024 (UTC)

--Joy (talk) 06:55, 5 June 2024 (UTC)

--Joy (talk) 16:37, 11 July 2024 (UTC)

--Joy (talk) 13:25, 5 September 2024 (UTC)

This isn't to say that all of these moves were truly warranted or that there aren't a plethora of individual factors at play. But even with this spread of outcomes, there's something distinctly off with our current near-consensus interpretation of how stats should look like for primary topics by usage. This also means little for considerations of long-term significance. --Joy (talk) 15:30, 1 March 2024 (UTC)

Your numbers for % of "interest" are rather misleading, as they don't mention that in many cases, the largest percentage by far was "no traffic at all", i.e. no clickthrough, for whatever reason (visits not by humans? wanted target not available? info on disambig page sufficient?). E.g. for Hamme, you note "after the move, the previously presumed primary topic got ~16% interest", which was more than 4 times as much as the other topics "combined". Fram (talk) 14:51, 11 April 2024 (UTC)

Yes, I've mentioned this several times. I agree it is misleading to simply assume that every incoming view counts for something meaningful. Truth is that there is no way for us to know what if anything those 'dead-end' incoming page views signify. older ≠ wiser 15:34, 11 April 2024 (UTC)

@Bkonrad exactly, but it's not exactly that we don't know that they don't signify anything. There's multiple hints that they do:

First of all, there is a spread of cases here, ranging from where we see a lot of the incoming views translate into clicks, to where we see few of the incoming views translate into clicks. I didn't summarize all of that information on this talk page, you have to go click through the links to examine that. (I may find some time later to extract that dimension of data and extend the list above.)

That means that we're not just consistently seeing some ghost traffic always, rather, we've got to be observing actual reader behavior at least to an extent. So we can't just see e.g. 60% of traffic translate into clicks in a fresh case and then jump to the conclusion that most of the remaining 40% is ignorable.

Secondly, there are cases where we see almost all of the incoming views translate into clicks. The most recent such example I found is described at Talk:Forced march#post move to disambiguation, where our identification rate went from 34/55 (~62%) in the first month observed, to 96/96, to 95/95, to 135/135 in the last three months, amazingly enough, even at such a small amount of traffic.

This negates even the idea that there's always got to be at least some of this ghost traffic, because apparently we have a falsifying scenario that seems quite consistent. So we can't just see e.g. 75% of traffic translate into clicks and then jump to the conclusion that any part of the remaining 25% is ignorable.

--Joy (talk) 12:33, 14 April 2024 (UTC)

It should be noted that we since observed forced march getting more outgoing clicks than incoming ones. That's another scenario we can't account for - the same readers clicking multiple items in a list. --Joy (talk) 08:48, 18 July 2024 (UTC)

On the individual points raised by @Fram earlier:

• meta:Research:Knowledge (XXG) clickstream says it tries to exclude visits not by humans: We attempt to exclude spider traffic by classifying user agents with the ua-parser library and a few additional Knowledge (XXG) specific filters. It's certainly possible that it misses, but then the page views "User" category is likely missing, too, so I don't know that we should rely on that being a major effect.
• Wanted target not available - how would this improve the odds for the claim that there would have to be a primary topic, when there'd be topics that detract from there being a primary topic yet they're not even available? That would seem to just raise the risk of astonishing more contingents of readers. "These people don't even know about meaning X, and they proclaimed meaning Y as the main one - pfft!"
• Info on disambig page sufficient - this use case is indeed not studied at all, and I agree that it seems possible for at least some cases. Ultimately, why would we consider all navigations that do not result in another click bad? IOW surely this also detracts from the idea of there being a primary topic, if there is also the contingent of readers who we cannot convince to click on the link to read about the proposed primary topic (which is also usually the very first link in the list).
• More than 4 times as the other topics combined - I've explained already at Talk:Hamme (disambiguation) how you are making weirdly incorrect statements. Even if we compare 28 identified clickstreams and the 10 identified clickstreams, the ratio between those two numbers is 2.8, it is simply not 4. Likewise, both 28 and 10 are so close to the anonymization threshold that it's not at all clear that this ratio has to be precise. In other words, this could have been 4 or it could have been 2 with just a few more src-dest pairs of views identified as opposed to anonymized out. And none of these ratios are impressive when we also see a lot more traffic interested in neither of these.

In any event, thanks for the interest. --Joy (talk) 12:33, 14 April 2024 (UTC)

Yes, I'm not saying the count of incoming views should be completely ignored, only that trying to read into what it signifies is highly speculative and we should be very cautious about what significance we attribute to such dead-end views. If there is a sudden change in the number of such incoming views, that likely merits some further consideration. Similarly, if there is a consistent, very large gap between incoming and outgoing views, that also may merit some consideration. But even in such cases, deciding what readers reaching such dead-end views were looking for when arriving at a particular disambiguation page is still highly speculative. It could play a factor in arguing that there is no primary topic where there is none at present (i.e., where there is a request to replace a disambiguation page with a primary topic). I'm not sure what significance we could read into such dead-end views of a disambiguation page where there is an existing primary topic. It could be readers are just curious about what else might have the same name, without intending to look at any of them in more detail. We just don't know why such readers behave that way. older ≠ wiser 13:46, 14 April 2024 (UTC)

Agreed, the change in pattern would be a significant indicator. But on that front, I point again to evidence above - we often observe a clearly consistent pattern, and then we do a switch for whatever reason, and then we the data switches to observing a clearly different consistent pattern. Well, it often takes a few months for things to settle, and in the interim period there's a swing or two, but still.

In cases where there is already a primary topic selected, it's very hard to read into the no-clickthrough traffic. Because the content is larger and varied, it could be any number of possibilities. Just like it could be readers who are navigated wrongly and just immediately click away, it could also be misnavigated readers who stayed and learned something and then clicked away, or it could be a bunch of completely content readers who were absolutely happy to read what was in front of them and had no need to immediately learn more about another related topic. We don't have the tools to discern these.

With simpler pages like the disambiguation lists, however, it's less hard to understand the general reader behavior because we don't present people with huge amounts of possibilities, we reduce that number and streamline their options, and make it more likely we can understand the measurements of our existing tools.

What I think we should learn from all this is that we should not be too cautious and instead we should not be afraid to experiment as much as we have been so far.

In all this data I've tracked, we've yet to observe a case where there was a fresh reader complaining about disambiguation lists being the wrong choice. As long as we apply MOS:DABCOMMON, and we do, we have no indication that we're confusing or troubling any appreciable amounts of readers even in contentious cases. --Joy (talk) 14:35, 14 April 2024 (UTC)

In all this data I've tracked, we've yet to observe a case where there was a fresh reader complaining about disambiguation lists being the wrong choice. This seems a peculiar criterion. Quite aside from reactions to the lists you have been compiling, I can't recall the last time I came across a "fresh" reader ever complaining about an incorrectly placed disambiguation page where the complainant was not a myopic partisan seeking to promote their preferred topic.

Regarding What I think we should learn from all this is that we should not be too cautious and instead we should not be afraid to experiment as much as we have been so far. I'm glad you are taking a deeper dive into the data, but I hope no one is being misled that the reems of data of uncertain quality based on poorly documented functions represents an agreed upon approach to making decisions. older ≠ wiser 16:02, 14 April 2024 (UTC)

We actually have some interesting data points about that, too, cf. Talk:Tito (disambiguation), where nobody really paid attention for over a decade as disambiguation was in place, and then a consensus of editors practically instantly chose to apply a primary topic redirect mainly for long-term significance. (On the plus side, that flip allowed us to measure something else afterwards, Knowledge (XXG) talk:Disambiguation/Archive 56#on the quality of clickstream and pageviews usage data explains more.)

I'm pretty sure if we go through other cases we can also find similar timeframes, where some arbitrary navigation choice has been in place for years and decades, and then we arbitrarily decide to congregate, make fun new decisions and pat ourselves on our collective backs :)

IOW our decision-making process seems perfectly sound (mostly to me too, I'm not excluding myself here), but so much goes through the cracks that it's doubtful that much of it really matters as much as we think it does. --Joy (talk) 16:49, 14 April 2024 (UTC)

Wouldn't it be useful to either define what the words "under cetain circumstances" at WP:DABSISTER mean? or (even better) provide examples when a link to a foreign language Knowledge (XXG) would be useful and when it wouldn't be useful?
I would give it a stab, but I have no idea what those words mean. The Mountain of Eden (talk) 20:53, 16 July 2024 (UTC)

My feeling is that we should avoid linking to articles in other language wikipedias… instead, we should create articles here, and link to those. Blueboar (talk) 15:01, 28 July 2024 (UTC)

Since no one has provided a definition for "under cetain circumstances", how about this defintion:
In cases for which no article exists for a disambiguation term in the English Knowledge (XXG) but an article exists in a different language Knowledge (XXG), it is acceptable to use the {{interlanguage link}} template to link to the article in the sister project, with the disambiguating term counting as a blue link (so an additional blue link would not be necessary for the entry) only if the sister project has verifyability, notability and neutrality policies.

(the table still needs to be filled out -- I only filled out the first 25 entires in the table). The Mountain of Eden (talk) 01:46, 22 July 2024 (UTC)

• No, this would open the floodgates to dab pages listing vast numbers of entries with no information useful to the reader of English Knowledge (XXG) unless they happen also to be readers of the other language. A rule distinguishing between "good" and "bad" non-English wikis would be confusing and difficult to implement. PamD 08:00, 25 July 2024 (UTC)

  Props to TMoE for going through the effort of starting that list above, but this really sounds like something that would have to be standardized at e.g. meta before it would be really reliable. --Joy (talk) 11:48, 28 July 2024 (UTC)

This doesn't seem necessary. It hasn't been demonstrated that a problem actually exists with the current text, which allows for flexibility on a case by case basis. Remsense诉 01:50, 22 July 2024 (UTC)

This also misses one main reason not to include ills--even on wikis that have vnn standards, not every article in said wiki meets those standards. Just take a look at the amount of sheer crap that exists on the English wiki which supposedly has high standards. And besides that, the mere existence of an article in another language wiki provides zero indication whether that same topic has any notability at all in English. I thought the last discussion on this determined that at minimum, the term must be mentioned in a current article to provide at least some minuscule suggestion that the topic has some currency in English. older ≠ wiser 03:16, 22 July 2024 (UTC)

Just like notability is not a function of time, I wouldn't think it would be a function of the language used to write the article. But it is a function of the people who participate in the discussion, which is why consensus can cange. This is why I think we ought to have a clear policy, so we will have consistency. The current wording of WP:DABSISTER is meaningless to me, and in 5 days nobody was able to provide me a meaning for it. That's why I proposed something that has meaning.

While it is obvious that having policies for verifiability, notability, and neutrality does not assure that each and every article fully complies with the policies, it's better than having no policies. That's why I proposed it instead of of the vague "under some circumstances". The Mountain of Eden (talk) 06:51, 22 July 2024 (UTC)

I disagree, in that notability is very much dependent on language and culture. Your proposal in essence gives a green light to include ills to every single article in other languages that have some sort of vnn standards, regardless of whether any given term has any usage whatsoever in English. older ≠ wiser 10:56, 22 July 2024 (UTC)

Knowledge (XXG)'s notability policy says that notability is established with coverage by "reliable and independent sources". How would that be dependent on language and culture? The Mountain of Eden (talk) 02:56, 23 July 2024 (UTC)

This isn't really the right forum for discussing notability of foreign language topics on the English Knowledge (XXG). The concept of disambiguation arises within a language wiki when there is more than one topic that could have the same title. If there is no extant information about a foreign language topic on the English Knowledge (XXG), there is nothing to disambiguate. older ≠ wiser 03:40, 23 July 2024 (UTC)

I agree that disambiguation is needed "when there is more than one topic that could have the same title". The point is what do you do when there is no article on the English Knowledge (XXG). We have MOS:DABRED to handle that. But in cases when there is an article, just not on the English Knowledge (XXG), that's handled by WP:DABSISTER. The current verbiage in WP:DABSISTER with the words "under certain circumstances" is ambiguous at best, and meaningless at worst. The idea is to clean up the language to give a clear guideline. The Mountain of Eden (talk) 16:48, 23 July 2024 (UTC)

To add insult to injury, there is a footnote in WP:DABSISTER saying "There is no agreement on the conditions under which such links are acceptable." We should therefore come up with someting. Even if it's not perfect, it could be improved later on. The Mountain of Eden (talk) 16:52, 23 July 2024 (UTC)

Good luck on with reaching such agreement. Previous discussions were long with more or less intransigent partisans. I think like a lot of things on Knowledge (XXG), the guidelines cannot precisely prescribe what to do in every situation and some things are best left to case-by-case discussions. I do not think it is wise to assume any sort of equivalence between articles in various language Wikipedias. With the guideline as you proposed, it would be a very short roll downhill to having dab pages stuffed to the gills with ILL entries for any and every other language that has any semblance of VNN guidelines (regardless of how rigorously said guidelines are followed in practice). My take is essentially that disambiguation pages are meant to disambiguate articles in the specific language of that Wiki. That is, there is no title conflict between articles in English wiki and any other language wiki. Each one can have different articles with exactly the same title without any conflict. If a foreign term has any relevance for English, there should be some indications within the English Wiki (i.e., the term is at least mentioned somewhere in some article). older ≠ wiser 17:54, 23 July 2024 (UTC)

"he guidelines cannot precisely prescribe what to do in every situation." I fully agree with you.

ome things are best left to case-by-case discussions. I also agree with that. The problem is that the current wording at WP:DABSISTER, especially the footnote, is so useless, you might as well have nothing, and just treat the case of a red link in the English Knowledge (XXG) that a blue link in some foreign language Knowledge (XXG) the same as any other red link.

If we think that a red link on the English Knowledge (XXG) with a blue link to a foreign language Knowledge (XXG) should be handled differently from an ordinary red link, we should spell out what to do in such a case, rather than say there is no consensus on what to do.

My proposal may not be perfect, but at least it's something. If we put it into the page, it might spawn future editors with ideas on how to improve it. The Mountain of Eden (talk) 21:14, 24 July 2024 (UTC)

I don't think it should be handled differently from other red links. I don't think articles in foreign language wikis should be treated as equivalent to English articles for blue links in dab entries. In my opinion, there should be an existing English article that mentions the term. older ≠ wiser 22:53, 24 July 2024 (UTC)

Sounds good. If nobody else contributes to this discussion within the next 4-5 days, we'll call it a consensus and change the project page accordingly. The Mountain of Eden (talk) 23:24, 24 July 2024 (UTC)

What would you be changing if it is not what you originally proposed? older ≠ wiser 23:28, 24 July 2024 (UTC)

Good question. See below The Mountain of Eden (talk) 23:47, 24 July 2024 (UTC)

Change the wording of WP:DABSISTER to the following:

If an article doesn't exist on the English Knowledge (XXG), but exists on a sister project, that is likely an indication that an article should be created on the English Knowledge (XXG). However, at the end of the day, per WP:WRITEITFIRST, until an article is created on the English Knowledge (XXG), the term to be disambiguated is to be treated as prescribed in WP:DABRED.

The Mountain of Eden (talk) 23:47, 24 July 2024 (UTC)

• I think saying this is a likely indication is too strong. We don't really know that in general, and there's so much variation between languages that any such assessment seems like a generalization. A term might be a common word in a foreign language and have numerous meanings documented there, but few or none of these would exist in English as in English they'd be using the native word instead.

It seems to me that the existence of the dabsister section is mostly a safety provision to make sure people don't remove those external links from {{ill}} as we don't permit external links otherwise.

In general, I'd advise thinking about this from a readers first perspective - to large contingents of English readers, even adding interlanguage links isn't useful and might possibly be confusing, because they might click through the one blue link expecting to continue reading in English. Allowing these links is already generous enough, but requiring some other standard to be met (like dabmention) is safer. --Joy (talk) 11:57, 28 July 2024 (UTC)

I think there it is wrong to say that is likely an indication that an article should be created on the English Knowledge (XXG). The mere existence of an article in another language says nothing about whether the article should be created on the English Knowledge (XXG). And what happens to the footnote which provides an example of how the entry should be constructed (which example by the way satisfies MOS:DABRED). older ≠ wiser 00:28, 25 July 2024 (UTC)

We can replace "is likely an indication" with "may be an indication". The Mountain of Eden (talk) 05:36, 25 July 2024 (UTC)

• @The Mountain of Eden: Please give a couple of examples of cases where the current vagueness has been a problem. Noting that, as pointed out above, the single example in the current documentation, in endnote "f", doesn't make anything clear as Árbol is mentioned in Vilalba#Administrative_units so the dab page entry is fine with or without the {{ill}} link (let alone the complications of Vilalba vs Villalba in Spanish/Galician wikis, making it a pretty poor example). Some real examples would make this discussion more meaningful. Thanks. PamD 08:08, 25 July 2024 (UTC)

• The wording "at the end of the day" is not the sort of thing to see in documentation.

I think that the current wording probably works well: in almost all cases a blue link will be possible to an article which mentions the topic, but I can imagine occasional cases where there is an ambiguous term, easily confused with a topic in Eng.wiki, that is present in another wikipedia but not (yet) in en.wiki and where there is no obvious place to add a reliably sourced blue link.

Perhaps there's a Canadian poet newly-added to en.wiki, with a common given-name-and-surname combination, and a German poet with the same name but clearly different birthdate and bio in de.wiki. It's helpful to our reader to include a wikilink to the German poet alongside the entry for the Canadian poet of the same name, even though the German poet isn't mentioned in our List of German-language poets and we can't expect the editor who's just created an article about the Canadian, and is adding them to the name dab page, to research their German namesake beyond finding that they exist in German wikipedia and are identifiably a different poet. (But it would be much better to add the German to that list or some other appropriate article, or create a minimal stub for them.)

If we're changing WP:DABSISTER at all, the first sentence should perhaps read:

Redlinks for topics covered in other language Wikipedias can be enhanced by using {{Interlanguage link}} to link to those other Wikipedias, but a blue link to an article in English Knowledge (XXG) is still required unless there is an exceptional need to help our readers by disambiguating a topic not yet mentioned here.

Perhaps adding:

Editors are strongly encouraged to find an article or list where the topic can be mentioned, reliably sourced, so that a blue link can be created per WP:DABMENTION.

PamD 08:33, 25 July 2024 (UTC)

Basically that sounds like encouraging use of the {{Interlanguage link}} template whenenver applicable. This should be the case for any red link. If that's indeed the case, then the entire section WP:DABSISTER should be redirected to WP:DABRED, with WP:DABRED encouraging use of {{Interlanguage link}} template whenever applicable. The Mountain of Eden (talk) 21:11, 26 July 2024 (UTC)

No, just no. These are different things, although there is some overlap. Sister links are relatively uncommon. Red links are routinely added incorrectly by inexperienced editors. We need guidance for red links that is a clear as possible. Sister links are at best a sort of special case of red link. older ≠ wiser 21:23, 26 July 2024 (UTC)

"Sister links are at best a sort of special case of red link"

I would strike out the words "at best" and "sort of", to read "Sister links are a special case of red link", which means the two sections should be combined rather than spread out over two different pages. The Mountain of Eden (talk) 21:36, 26 July 2024 (UTC)

1. Eliminate WP:DABSISTER from this page and move the shortcut to MOS:DISAMBIGUATION under WP:DABRED.
2. Under the boxed Flibbygibby example add the following sentence (w/o the italics):

   "If the article to be disambiguated does not have an article on the English Knowledge (XXG), but has an article on a sister project in another language, the term may be linked to the sister project using the {{interlanguage link}} template."

3. WP:DABSISTER would link to this new proposed sentence.

The Mountain of Eden (talk) 22:38, 30 July 2024 (UTC)

• Could we redirect the shortcut without adding the text? Blueboar (talk) 01:06, 31 July 2024 (UTC)

::Sounds like that's proposal #4. But why not add that one sentence? The Mountain of Eden (talk) 01:54, 31 July 2024 (UTC)

Sorry, misread the question. I don't see how we can redirect the shortcut w/o adding the text since nothing in MOS:DAB talks about links to sister projects. We could either delete the shortcut, or if we change the shortcut to WP:DAB, we would somehow need to discuss links to sister project in MOS:DAB. The Mountain of Eden (talk) 02:02, 31 July 2024 (UTC)

• This proposal doesn't clarify whether the redlink guidance is also applicable to ILLs or whether this is just some appendage and that the blue link to the other language alone is sufficient. And further this removes the existing guidance at DABSISTER about not linking to other sister projects, like Wikidata or Wikivoyage. older ≠ wiser 02:07, 31 July 2024 (UTC)

  You lost me. By definition, you only add the {{interlanguage link}} template if there is no article on the English Knowledge (XXG). The proposed wording doesn't affect the existing wording in WP:DABRED. It just says that it's permissible to add the template to red links. The Mountain of Eden (talk) 02:11, 31 July 2024 (UTC)

  The text and placement makes it read like a non sequitur add-on. It isn't clear whether any of the conditions applicable to red links are applicable to ILLs or if they are an exception. And what about the other sister project text and the example in the footnote? older ≠ wiser 03:02, 31 July 2024 (UTC)

  I'm not sure why it's not clear. The proposed text neither modifies nor impacts the existing WP:DABRED. It just says that it's permissible to use the {{interlanguage link}} template. I think it's absolutely related because you would only use this template on red links. You would not use it if there is an existing article on the English Knowledge (XXG). The Mountain of Eden (talk) 03:13, 31 July 2024 (UTC)

  Placed at the end and without any example, this could be taken to mean that an entry with only an ill link is ok, regardless of whether it is mentioned in any existing article. It would be clearer if the example from the footnote were preserved. And what about the guidance regarding the other sister projects? older ≠ wiser 03:46, 31 July 2024 (UTC)

  I don't know what footnotes you're talking about. Regardless, we can also add a sentence that use of the {{interlanguage link}} template is not a substitute for the need to have a red link from an existing article.
  

  What guideline for other sister projects would be needed? The article either exists in a sister project, or doesn't. If it exists in a sister project, use of the {{interlanguage link}} template is OK, and if it does not then use of the template is not OK. The Mountain of Eden (talk) 03:56, 31 July 2024 (UTC)

Eliminate WP:DABSISTER entirely.

• Oppose - While the shortcut requires WP:TNT, deletion is not the answer. The Mountain of Eden (talk) 03:57, 31 July 2024 (UTC)

I have added this proposal (after the fact) simply because it should have been an option from the beginning. Blueboar (talk) 01:04, 31 July 2024 (UTC)

I have just reverted a change by @The Mountain of Eden: which added a statement to Knowledge (XXG):Manual of Style/Disambiguation pages which I think was plain wrong (unless I'm misunderstanding). The wording added was:

• If the article to be disambiguated does not have an article on the English Knowledge (XXG), but has an article on a sister project in another language, the term may be linked to the sister project using the {{interlanguage link}} template. Use of the {{interlanguage link}} template is not a substitute for the need to have a red link from an existing article as explained above.

I think the last phrase should probably be "blue link to" rather than "a red link from", but rather than try to hash it out on the live page it seems better to agree a wording here. The edit summary unhelpfully referred to " Implementing proposal 3 from WP:DISAMBIGUATION" rather than pointing to this talk page, and this particular bullet within the talk page. PamD 22:43, 12 August 2024 (UTC)

"a red link from" is correct per WP:DABRED which says that "A link to a non-existent article (a "red link") should be included on a disambiguation page only when a linked article (not just other disambiguation pages) also includes that red link." (emphasis added) The Mountain of Eden (talk) 23:22, 12 August 2024 (UTC)

Well, I did point out the addition is unclear, although you appear to have dismissed that as "token opposition". I gave up on trying to explain this as you seemed to be coming at this from a different dimension entirely. older ≠ wiser 12:56, 13 August 2024 (UTC)

Perhaps I missed it, but I don't know what's unclear. But I do agree that PamD has a valid point about a blue link. We can therefore add a few words (the underlined text below) to the second sentence to read:

If the article to be disambiguated does not have an article on the English Knowledge (XXG), but has an article on a sister project in another language, the term may be linked to the sister project using the {{interlanguage link}} template. Use of the {{interlanguage link}} template is not a substitute for the need to have a red link from an existing article for the disambiguating term, as well as a blue link to an existing article within the entry, as explained above.
The Mountain of Eden (talk) 15:03, 13 August 2024 (UTC)

Slightly better, but you are assuming a reader will see this as being a part of MOS:DABRED rather than some random non sequitur add-on (and that it is obvious what as explained above refers to). And we lose the example of how to use ill on a dab page (the template documentation covers a range of options available for general use that don't apply to disambiguation entries). And it is still not clear what happens to the general guidance that discourages links to sister projects such as Wikiquote, Wikitravel, etc. older ≠ wiser 18:09, 13 August 2024 (UTC)

• Why is it a non-squitur when it's within WP:DABRED and it's about cases when there is no article on the English Knowledge (XXG)?
• What example have we lost?
• How did we lose "the general guidance that discourages links to sister projects such as Wikiquote, Wikitravel, etc." when it doesn't currently exist?
• The text of the proposed text talks exclusively about non-English Wikipedias. We can transfer verbatim the sentence "Entries where the content is on any other sister project, like Wikidata or Wikivoyage, should not be created" from the current page.

The Mountain of Eden (talk) 18:18, 13 August 2024 (UTC)

• Non sequitur because it has its own shortcut and comes after another subsection with its own shortcut and examples. Visually, the connection is not very strong.
• Sigh, for the umpteenth time -- the example in the footnote that you are deleting from WP:DABSISTER.
• Transfer the text to where? And with which shortcut(s)?

Also, why are we creating this as a tangentially related subhead under MOS:DABRED when there is MOS:DABOTHERLANG. Seems this use case is much more directly related to that than it is to MOS:DABRED. older ≠ wiser 19:09, 13 August 2024 (UTC)

The way I'm reading MOS:DABOTHERLANG, it's about non-English characters. You would only use the template {{interlanguage link}} if there is a red link. There is no other reason to use it. Hence, it better fits under WP:DABRED.

I still don't see your point on the non-sequitur just becuase there is shortcut presented in the middle of a section. There are plenty of shortcuts on the page in the middle of a section. Take for example MOS:DABPERIOD, MOS:DABSHORT, MOS:DABNOLINK ....

So here is how we can incorporate the example in the footnote and the sentence discouraging other sister projects.

If the article to be disambiguated does not have an article on the English Knowledge (XXG), but has an article on a sister project in another language, the term may be linked to the sister project using the {{interlanguage link}} template.

• Árbol, Villalba, a parish in Vilalba, Spain

Use of the {{interlanguage link}} template is not a substitute for the need to have a red link from an existing article for the disambiguating term, as well as a blue link to an existing article within the entry, as explained above. Entries where the content is on any other sister project, like Wikidata or Wikivoyage, should not be created.

The Mountain of Eden (talk) 19:28, 13 August 2024 (UTC)

as explained above is a flag that you have little experience with writing hypertextually where the individual pieces are FREQUENTLY read (and cited) out of context. I see it differently., the only reason to use ill is if there is a non-English term that has some relevance in English and there is an article with helpful content in another language. Ideally, by using ILL, we are in fact hoping that the article will be brought over into the English wiki, thus making the ill link default to the English article. MOS:DABOTHERLANG is about non-English language terms, not characters. From a naive editor's perspective -- they likely not thinking "I want to create a red link in a dab entry" -- but rather more like, here is a foreign language term that has some significance in English but there is no English article, but there is a decent non-English article -- seems the instructions would be easier to locate for that use case under MOS:DABOTHERLANG. older ≠ wiser 19:58, 13 August 2024 (UTC)

I don't agree with your assertion that "the only reason to use ill is if there is a non-English term that has some relevance in English and there is an article with helpful content in another language". Here is a real example:
The disambiguation page Friendship Bridge has the entry Thai-Cambodia Friendship Bridge. There is absolutely no reason that there shouldn't be an entry for this bridge on the English Knowledge (XXG) other than the article hasn't been written yet (a little digging reveals that according to the Thai Knowledge (XXG) there are actually two such bridges: Thai-Cambodian Friendship Bridge (Aranyaprathet-Poipet) and Thai-Cambodian Friendship Bridge (Ban Nong Ien-Stung Bot) — but that's besides the point).
As this example illustrates, the use of the {{interlanguage link}} is all about handling cases for which there are no entries in the English Knowledge (XXG), but entries exist in other languages. And to drive home the point that this would be inappropriate in MOS:DABOTHERLANG, the example in MOS:DABOTHERLANG actually uses a term that does have an article on the English Knowledge (XXG) (hence no need to use the {{interlanguage link}} template).
As for your point on the "as explained above", we can replace that verbage with "as detailed in MOS:DABRED and MOS:DABBLUE". The Mountain of Eden (talk) 20:53, 13 August 2024 (UTC)

Perhaps I might have phrased differently, but the point is still valid -- very few editors are going to be looking for how to create a valid redlink. The redlink section is more a prohibition with some exceptions. The use of an ill may be a valid exception, provided criteria are acceptable. And no, I think you are misreading MOS:DABOTHERLANG. older ≠ wiser 22:32, 13 August 2024 (UTC)

And I'm not sure what the example of Thai-Cambodia Friendship Bridge is supposed to illustrate. Why would we want to subject English readers to having to choose between forked articles in another language about the same damn crossing? And other than a unsourced statement, it isn't even clear what the crossing is known as in English. That would be a very poor example of an ill worth including on a dab. older ≠ wiser 22:45, 13 August 2024 (UTC)

You're definitely lost. There are two bridges with the same name: One located at 13.6153°N 102.6098°E, and the other located at 13.6615°N 102.5495°E. This would not be a fork. In fact, we need to go into the Friendship Bridge disaambiguation page and present it as two separate bridges in the same manner that there are four bridges Thai-Lao Friendship Bridges listed.

The {{ill}} links to those bridges would provide the reader with additional information on those bridges when using Artifical intelligence to translate from Thai to English. The Mountain of Eden (talk) 23:03, 13 August 2024 (UTC)

I took a no response as concurrence, and added the new proposed text to MOS:DISAMBIGUATION. The Mountain of Eden (talk) 19:18, 26 August 2024 (UTC)

Wrong assumption, I saw no point in continuing to talk past each other. But if no one else cares enough to comment, then I've nothing further to add. older ≠ wiser 19:59, 26 August 2024 (UTC)

Not sure what to say. All I saw in your last comments are:

1. Questioning of the usefulness of the {{ill}} template, which made no sense since you did not propose prohibiting usage of the template
2. Objections to the location of the proposed text within the page at MOS:DISAMBIGUATION.

Feel free to clarify any concerns you have with the text that I added to MOS:DISAMBIGUATION. Perhaps we could improve it further. The Mountain of Eden (talk) 20:06, 26 August 2024 (UTC)

I'm not sure that there is any consensus for any of this, but your second sentence Entries where the content is on any other sister project, like Wikidata or Wikivoyage, should not be created. does not seem right. There is no reason not to include a topic as a red link on a dab page just because it has an article in Wikivoyage or Wikidata. As far as I know {{ill}} does not provide for making links to other projects such as Wikivoyage or Wikidata, so this sentence is unnecessary and unhelpful. Please remove it. PamD 20:26, 26 August 2024 (UTC)

That sentence in question is not mine. It's in the existing text, and Bkonrad insisted that it be transferred over. The Mountain of Eden (talk) 20:55, 26 August 2024 (UTC)

I didn't insist it be carried over as part of whatever this edit is. I questioned why it was being removed. older ≠ wiser 22:15, 26 August 2024 (UTC)

Then it sounds like we have a consensus to remove this sentence. The Mountain of Eden (talk) 22:18, 26 August 2024 (UTC)

Absolutely not. older ≠ wiser 22:19, 26 August 2024 (UTC)

Then perhaps I should open up a discussion over at Knowledge (XXG) talk:Manual of Style/Disambiguation pages because prohibitions should be justfied. The setnence, as written, does not provide any justification. The Mountain of Eden (talk) 22:24, 26 August 2024 (UTC)

I should mention that I don't necessarily agree with that sentence. I'm not sure why we cannot have links to those other sister projects, but that was beyond the scope of the proposal. The Mountain of Eden (talk) 20:57, 26 August 2024 (UTC)

Previous discussions had established that we should not be linking to sister projects on disambiguation pages. I don't think it fits as part o& the current edit, but it should not simply disappear without some clear consensus. older ≠ wiser 22:19, 26 August 2024 (UTC)

Perhaps I should be more clear: I transferred that sentence over in order to build consensus with Bkonrad. I too don't like that sentence. Therefore, PamD, you have my full support to remove that sentence at WP:DABSISTER. The Mountain of Eden (talk) 21:14, 26 August 2024 (UTC)

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

• Talk:IPA#clickstreams data - whether to sort items by reader interest etc
• Talk:Charlotte#post-move - whether to include some items and whether to make a section heading for the top list
• Talk:Cell#common section at the top + Talk:Cell (biology)#Requested move 13 July 2024 - whether to include more than one item in the top list, whether the formatting of the top section affected the clickthrough rates etc
• Talk:King Charles#followup to move discussion - whether a volume of clicks inside the first section is readers missing the single-item common list above
• Talk:The Sun (disambiguation)#followup to move discussion - whether the top link inside the sentence was good enough

Several of the discussions at Knowledge (XXG) 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. --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)

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. Knowledge (XXG) 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)

Currently working on rewriting WP:KOREA's guidance on mountain article titles. For disambiguations with multiple terms, I'm unsure of what is preferred, a "/" or an "and". For instance, here's a page with an "and": Taehwasan (Gangwon and North Chungcheong). Here's a page with a "/": Sinseonbong (Chungju/Goesan).

Are either formats acceptable? I know having multiple terms in the first place isn't great; but in the worst case scenario where we had multiple terms, what should we do? seefooddiet (talk) 07:53, 5 August 2024 (UTC)

Note, some relevant sections I found. WP:NCPLACE#Natural features and possibly a loose interpretation of WP:DISAMBIG#Format may suggest that we should avoid "/" as article titles don't typically have them? seefooddiet (talk) 07:55, 5 August 2024 (UTC)

I think the more usual approach in such cases is to use the mountain range as the disambiguating term. But that info is currently missing in the articles. older ≠ wiser 10:21, 5 August 2024 (UTC)

As Korea is quite small, and due to its geography, its mountains are often in the same few mountain ranges. Category:Mountains of South Korea Category:Mountains of North Korea Category:Mountain ranges of Korea.

Taebaek Mountains and Sobaek Mountains are two major mountain ranges. Should we try disambiguating by range first, then if not possible, by multiple location? seefooddiet (talk) 17:20, 5 August 2024 (UTC)

MOS:SLASH recommends against using slashes generally, with certain exceptions. In the context you're asking about, I would go with "and" when it's a choice between the two. Station1 (talk) 18:08, 5 August 2024 (UTC)

The consensus seems to be that compound names are ugly, so usually editors prefer to pick one variant, and add redirects for another. Alternatively, choose some sort of a different compromise.

For the latter, an example I can recall was a mountain of Kozjak on the border of Serbia and North Macedonia, where I chose Kozjak (mountain near Pčinja) as the compromise disambiguator, a nearby river that also passes through both. --Joy (talk) 08:27, 12 August 2024 (UTC)

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 12:15, 15 August 2024 (UTC)

There is one situation where I think our current rules for determining the primary topic fail. That's when one (and only one) of the listed articles is a vital article and yet may not be the page with the most pageviews. For example, The Void (philosophy) is a level-5 vital article, and yet instead of it being at The Void, we instead have a list of eponymously-named modern media. The current rules fail in a way here that make Knowledge (XXG) look stupid. Common sense would put the vital article at "The Void" and the list of eponymously-named modern media at The Void (disambiguation). A hundred years from now, The Void (2016 film) will hardly be the most searched for of the alternatives, so the current status fails WP:RECENTISM. Skyerise (talk) 10:57, 19 August 2024 (UTC)

Sorry, but no. The process for identifying vital articles is somewhat haphazard, especially for level-5 articles. There's nothing foolish about directing readers to the articles they are actually looking for in the most expeditious manner. There already is a case for primary topic based on long-term significance. If there is no consensus about the long-term significance of a topic, there is no reason to presume that it is the primary topic. older ≠ wiser 11:59, 19 August 2024 (UTC)

I don't see the value to the user of making it easiest to get to the most "vital" article when it isn't an article people are likely to be looking for. It's kind of like telling the user, not "Here's the article about the topic you're interested in", but "Here's the article about the topic we think you should be interested in".

At some point between now and a hundred years from now, there's nothing standing in the way of changing the primary topic then if relative levels of interest have shifted in that direction. For today, we're serving today's users. Largoplazo (talk) 20:11, 19 August 2024 (UTC)

Here's an interesting example I stumbled upon:

• All-time monthly page views for "Tivadar" and "Tivadar (given name)"

The name article was written in late 2019, and it immediately got some persistent traffic, which is not what I'd expect when it wasn't linked from "Tivadar" itself - a hatnote was missing throughout this period.

In early 2020, someone adds an indirect link to the name by linking Theodore (name) in a Name section, and the traffic at Tivadar seems to start dropping, while the traffic at Tivadar (given name) starts rising, and since 2021 it regularly overtakes the village traffic.

All this time, the list at Theodore (name) was still linking back to the (misplaced) village article, and again there was no hatnote even.

Seems like search engines learned where our navigation was lacking and worked around the problem - at least most of the time. --Joy (talk) 08:50, 20 August 2024 (UTC)

Hello all, I've just created Turtle Islands Heritage Protected Area which is the name of a protected area that is really two adjacent protected areas in bordering countries. There doesn't seem to be much of a point to a standalone page, following very quick research both sides seem to operate their parks separately, and both individual pages already exist. On the other hand, it's a used term that seems helpful for readers to find, I for example was searching for it, and it also already existed (well technically a variation with no s after "Island") as a redlink at Transboundary protected area. While not a traditional dab, it doesn't seem to be a set index article or a list either. I've IARed per MOS:DAB and created it as a disambiguation page for now, but thought I'd check to see if there was a better option. Best, CMD (talk) 15:39, 20 August 2024 (UTC)

It is more of a set index or perhaps an underdeveloped broad concept article rather than a disambiguation page. Neither of the individual areas for the two countries are named as "Turtle Islands Heritage Protected Area" but instead they appear to be constituent entities that comprise the jointly administered area. older ≠ wiser 16:38, 20 August 2024 (UTC)

I wonder if it should be a very short article, using the two refs in Transboundary protected area, adding coordinates, and explaining its status and that it is administered as the two areas. And add it to the dab at Turtle Islands. It clearly exists as an entity in the eyes of UNESCO and the GTPAN. And can have Category:Transboundary protected areas as well as some geographic cats. PamD 16:55, 20 August 2024 (UTC)

And I suspect that Turtle Islands National Park (Malaysia) should be moved back to Turtle Islands National Park: it was moved in 2008 with rationale "Philippines has Turtle islands too", but the Philippines area isn't called "Turtle Islands National Park"! ... Oh, WP:SOFIXIT: done. PamD 17:05, 20 August 2024 (UTC)

Seems a sensible move, is there a need to add a hatnote given Turtle Islands Wildlife Sanctuary is linked in the first paragraph? On the sources, from what I found UNESCO and GTPAN do not really treat it as one entity. The relevant UNESCO page is just for the Philippine area, and the GTPAN list considers it two areas, "Pulau Penyu (Turtle Islands)" and "Turtle Islands" . (I suspect the UNESCO page deals with the Philippine reserve as it's almost 140 times larger than the Malaysian one.) Perhaps we could craft some distinction by focusing on the MOA and what cooperation there is (at least some), but I'm still not sure that wouldn't be able to be included in the individual articles anyway. CMD (talk) 17:12, 20 August 2024 (UTC)

I wondered if it should just redirect to the Philippines one as primary topic but I think that would be politically inept. It would be helpful if the UNESCO page had a map ... instead it has inaccurate coordinates, as "E199 25" has to be a typo! The N coords don't cover the Malaysian place as it is at 6 deg north. Interesting! PamD 17:24, 20 August 2024 (UTC)

And our article on the Malaysian place says there are seven islands in the Philippines entity, while its article only claims six! PamD 17:28, 20 August 2024 (UTC)

I have created Aliasing (disambiguation) in partial response to Johsebb's question at the Teahouse. I think further follow-up may be needed, in particular, renaming Aliasing as 'Aliasing (signal processing)' (currently a redirect back to Aliasing), but that depends, I assume, on WP:PRIMARYTOPIC. Any thoughts on the best way to proceed, and have I missed anything? Thanks, Mathglot (talk) 18:14, 25 August 2024 (UTC)

Any thoughts on the best way to proceed ...: I assume you are referring to determining the primary topic? From the thread, it seems that potentially the topic with the most traffic is not what one domain expert considers the term's "main meaning". It's subjective how multiple factors that yield different potential primary topics are balanced to determine the ideal target. An WP:RM seems the route if it seems likely that an undiscussed move would be contested.—Bagumba (talk) 09:53, 26 August 2024 (UTC)

Yes, I think that's the main issue. I'm leaning towards WP:NOPRIMARY, but willing to be persuaded otherwise. And yes, an RM would probably qualify as non-obvious, so WP:RM#CM should be followed. Mathglot (talk) 09:59, 26 August 2024 (UTC)

I just realized I missed this part of Talk:Heimlich (disambiguation)#Requested move 18 August 2024:

any interpretation of the discrepancy between incoming and outgoing views in speculative. We know nothing about why it happens or what reasons readers who do not go on to an outgoing view might have for doing so. Sure, it is possible that some outgoing traffic might also be non-human agents. However, the bot portion of either is minor part of the point. The point once again is that the raw incoming view numbers tell us NOTHING about what readers might have been looking for, other than possibly that A) what they were looking for wasn't on the page or B) that what they found on the page was sufficient; and we can't even tell the difference based on this data. older ≠ wiser 11:20, 23 August 2024 (UTC)

If any interpretation of the discrepancy between incoming and outgoing views is speculative, and the comparison between incoming and outgoing views is the first graph of WikiNav, then we have to stop recommending people look at WikiNav for the purposes of deciding on how to organize navigation.

Or, on the other hand, we need to accept the simple fact that all we do with our statistical data is necessarily interpretation.

The idea that we should take a tool's partial output and treat it as if was gospel, and treat the other part of its output as if it was nothing, is frankly just nonsensical. This kind of dealing with extremes instead of trying to find the nuance is actually starting to look like this is somehow ideological :D --Joy (talk) 07:25, 28 August 2024 (UTC)

If any interpretation of the discrepancy between incoming and outgoing views is speculative ... Can you provide more specifics on the nature of the "interpretation" being questioned? —Bagumba (talk) 07:44, 28 August 2024 (UTC)

It's linked in the discussion above. People see a bunch of outgoing views to a single destination in WikiNav, and proceed to decide that it's best for navigation that we short-circuit. The discrepancy between incoming and outgoing views is by and large ignored through this process. --Joy (talk) 08:09, 28 August 2024 (UTC)

Yeah, sorry. I'm taking the TLDR route :-) A quick summary with your issue would be helpful. Thanks. —Bagumba (talk) 08:17, 28 August 2024 (UTC)

In short, we're having a persistent problem trying to figure out primary topics by usage.

• We have numerous cases of terms pointed to a single prominent topic for decades, or disambiguated away from a single prominent topic for decades, and there is comparatively very little reader response to it. It's very hard to tell if it's because of a lack of interest in complaining or because the readers are actually fine with it.
• We have a lot of variety in what happens when readers arrive at disambiguation pages - in some places clickthroughs are a tiny minority of traffic, in some places they're actually larger than the incoming traffic, and we observe almost everything else in between. We don't have any solid benchmarks as to what this means.
• Search engines modify our reader traffic very significantly - and work around our navigation. They affect the way our statistics work by completely modifying our input data in a way that we can only detect after the fact (or that we can never detect unless we do a change, for which we can't get consensus).
• We're lacking detailed data on what happens after readers navigate in a way they didn't want - do they stay and read the articles, do they click away, do they just close the browser tab, do they go to Wiktionary, etc
• Generally speaking, suggestions to move articles based on usage trickle in slowly on Talk pages, and we try to apply the guidelines, but are often constrained by lacking proper data - it becomes more of a my gut feeling vs your gut feeling type of discussion.
• Just like we have no concept of measuring outcomes from the status quo, we also don't measure outcomes from changes.
• We don't have a concept of experimentation, I never hear anyone else entertain the idea that we try something - the typical discussion statement is final and bolded up front.

How's that for a summary? :D --Joy (talk) 08:31, 28 August 2024 (UTC)

Thanks (though I take it that not all of these came up at this specific RM). From an optics view, I wouldn't say WikiNav is harmful. It generates statistics. Simple. Unless they are inaccurate, the "harmful" part you might be suggesting is how the WP community is interpretting the data and the subsequent actions it takes in response. Does that seem fair, or am I missing something? —Bagumba (talk) 08:44, 28 August 2024 (UTC)

Yes, this is a summary of the overall situation that is leading to RMs like the one at Heimlich.

I just used the cliche considered harmful as a bit of a ploy to get people to look at it, sorry about that. :)

I suppose it elucidates the main point nicely, though - just like we shouldn't judge a discussion by a portion of its title, we shouldn't judge usage statistics by a portion of its WikiNav output. --Joy (talk) 10:50, 28 August 2024 (UTC)

... in some places clickthroughs are a tiny minority of traffic, in some places they're actually larger than the incoming traffic, and we observe almost everything else in between More outgoing clicks than incoming clicks? Any explanation been given for that statistical anomaly? —Bagumba (talk) 11:59, 28 August 2024 (UTC)

Yes, in the list above I mention such a case, you can do a Ctrl+F for "forced march". --Joy (talk) 12:14, 28 August 2024 (UTC)

In the case of a page like forced march, if anything, it suggests that perhaps the descriptions are not clear enough to distinguish between the items or possibly simple curiosity about uses that hadn't occurred to a reader. Reading the current page, I have a hard time distinguishing between forced march (military exercise) and forced march (maneuver). older ≠ wiser 15:24, 28 August 2024 (UTC)

I think it could be that people are sometimes looking for a broad concept article, but only finding this, and then they go through all the meanings in order to get to what the unifying concept is. --Joy (talk) 17:08, 28 August 2024 (UTC)

BTW the way I understood it is the exercise is done more preventively, as a practice and a test, while the maneuver is doing the same thing at war time. If we had a BCA, it could probably explain that better. --Joy (talk) 17:10, 28 August 2024 (UTC)

There isn't even any mention of "forced march" in Maneuver warfare, the target of forced march (maneuver). And the first image is of a training exercise rather than war-time action (although not for a forced march). This is quite confusing. older ≠ wiser 17:20, 28 August 2024 (UTC)

IIRC it mainly came about through the disambiguation of links at Special:WhatLinksHere/Forced march (maneuver). All of those articles referenced forced marching, but in context that made it clear it wasn't about exercise, but warfare. --Joy (talk) 17:26, 28 August 2024 (UTC)

Ok. So possibly opening multiple new links on a new tab or window, or clicking "Back" maybe doesn't result in a new "incoming click" being logged. —Bagumba (talk) 15:46, 28 August 2024 (UTC)

These are reasonable guesses. Unfortunately, the documentation for WikiNav isn't very clear. older ≠ wiser 16:03, 28 August 2024 (UTC)

Perhaps someone at m:Research talk:Knowledge (XXG) clickstream might have insight? —Bagumba (talk) 16:20, 28 August 2024 (UTC)

Yes. You can open the F12 Network console in your browser while clicking back on a Knowledge (XXG) article, and see if it makes another network request. If it doesn't, there are no server-side logs that the clickstream analysis could use to gather data. TTBOMK we also don't use any spyware-ish Javascript-based software to track users to be able to catch and record these events inside the browsers. --Joy (talk) 17:12, 28 August 2024 (UTC)

Reader could have the dab page open in one tab and click on several different links using right-click and "open in new tab", exploring possible articles to find the one they need. Particularly if it's a name page and they have to explore a lot of different dab pages for different forenames. PamD 17:01, 28 August 2024 (UTC)

Yep, whenever we have multiple levels of navigation, we should probably expect desktop readers to be doing that. Not sure if it's practical on mobiles, though - there we might have to expect a bigger failure rate, that is, readers who just see an overly complex navigation process and give up. These possibly return through a search engine later, but can't be identified as such. --Joy (talk) 17:15, 28 August 2024 (UTC)

I've hardly ever looked at the incoming side of a WikiNav display: what matters is the outgoing side, showing where readers are going after landing on the dab page. I do not consider WikiNav to be harmful: it's useful. I disagree with your logic in the statement "If any interpretation of the discrepancy between incoming and outgoing views is speculative, and the comparison between incoming and outgoing views is the first graph of WikiNav, then we have to stop recommending people look at WikiNav for the purposes of deciding on how to organize navigation.": one can look at, and be informed by, the first graph without being interested in its left-hand side or the difference (hardly "discrepancy") between the sides. PamD 07:56, 28 August 2024 (UTC)

The app's authors show us a graph, and we're choosing to look at only the left-hand side, but when someone points out there's also a right-hand side, and there's a lot of variety in how these interact described in #on what statistics should look like for hatnotes, primary redirects, primary topics etc, the retort is this crass "you're just speculating!".

I don't think there's sufficient scientific rigor in deciding essentially arbitrarily what matters, and in turn accusing someone who tells you other things may matter too that they're engaging in an activity that has insufficient scientific rigor :) which is what Bkonrad's comment did there AFAICT. --Joy (talk) 08:17, 28 August 2024 (UTC)

The section heading here is misleading. WikiNav was not constructed with the purpose of determining primary topic in mind. It is simply a visualization of sources and destinations of page views and one use to which it has been put is to assist in determining primary topic. The extended quote above is from me, and as I said the portion that I think is being misused in primary topic discussions is the incoming page views. The outgoing views does provide a very clear data point for evaluating what readers are looking for. Incoming views tell us virtually nothing about what readers might have been looking for. As I mentioned to Joy in other discussions, where there is a large discrepancy between incoming and outgoing, that might be worth some further investigation, but by itself it provides no actionable information. older ≠ wiser 10:30, 28 August 2024 (UTC)

The outgoing views are a very clear data point, except for the huge gaping holes where we have no data points about outgoing views? :)

I think we've amassed enough experience by now to be able to consider some of these things actionable, at least as an experiment. But our process doesn't encourage any such thing.

By not measuring and not checking our outcomes, we're actually in speculative territory as it is, which is why I don't fancy being told my interpretation is speculative. --Joy (talk) 11:05, 28 August 2024 (UTC)

What "gaping holes"? I have not seen any convincing evidence that incoming views directly provide any useful information. We can certainly adjust processes where there is a need, but I've not seen any consistent indications that there is a systemic problem that can be easily remedied by a change in process. older ≠ wiser 11:15, 28 August 2024 (UTC)

The obvious gaping holes, the differences between incoming user traffic and outgoing clickthroughs that exist almost everywhere. You know, the thing I've spent many hours documenting in dozens of examples :D --Joy (talk) 12:19, 28 August 2024 (UTC)

I wouldn't characterize that as a gaping hole with regards to data points about outgoing views. It is a gaping hole with regards to incoming views, but there is no consistent or coherent account for how such differences between incoming and outgoing views affect the usefulness of the outgoing views. older ≠ wiser 15:11, 28 August 2024 (UTC)

Well, if you want to be more specific like that, there is actually one persistent gaping hole about outgoing views that we know about - the anonymization of clickstreams makes it certain that we do not see any long tail of traffic.

So wherever there's fewer than 10 source-destination pairs in a month, we know that this is explicitly deleted from view - so if a link was clicked by 9 people who came in with an empty referer, 9 people who came from a known search engine, 9 people who came from Wiktionary, 9 people who came from Main Page, 9 people who came from Related Topic #1, ... all of this traffic we will never see as outgoing clickstreams. And then the link below that is clicked by 8 people from X, 7 people from Y, 5 people from Z, ... ditto. And so on.

In some cases, where monthly traffic is really high, this issue should be ignorable. But there are so many discussions where we talk about e.g. 25 or 100 clickstreams, where this could really have an impact. --Joy (talk) 17:21, 28 August 2024 (UTC)

I would question why any anonymization is needed for anonymous sources such as other-search or other-empty. Do we actually know this is what happens or is this just another example of deficiencies in the documentation? older ≠ wiser 17:32, 28 August 2024 (UTC)

That's what the documentation describes... I'm not sure what the point is anyway, as even if we knew that e.g. 1 person came from any source and browsed a sensitive topic, and then was the sole person who clicked another link to another sensitive topic - the identity of that person is still unknown? What is even the scenario where someone is being spied upon using this data, that doesn't already involve much more data being known by the same spies? --Joy (talk) 17:43, 28 August 2024 (UTC)

The documentation is opaque about this. As unlikely as it seems and of such low value as to stagger the mind why anyone would try to exploit, it is theoretically possible to match user names visiting a low volume page during a specific period with the targets on WikiNav. Edit: thinking on this further, I don't see how user names could be correlated with WikiNav data, unless it is recorded somewhere else that isn't immediately obvious. older ≠ wiser 17:50, 28 August 2024 (UTC)

Even so, it would be better for purposes of determining primary topic if such data were somehow masked rather than omitted. E.g, a group category such a "Internal-masked for privacy". older ≠ wiser 17:56, 28 August 2024 (UTC)

I suppose it could be a way to to leak editor interests, for example if you see that in a certain month a single person edited pages X and Y, and there were only 3 clicks from Y to X, and only 2 clicks from X to Z, it's probable that the same person (account / IP address) visited Z.

Having this kind of data public could have a chilling effect on people editing.

What I see as a potential for improvement is to see if we can apply the threshold of 10 on a more aggregate set of data, so for example if there were 4 people going from empty via our page to X, and 7 people from search to X, and 3 people from Y to X, that we still get to know that 13 people went from our page to X. --Joy (talk) 18:53, 28 August 2024 (UTC)

I'm not sure I follow. Which side are we looking at? What is "our page" and what is 'X'? What does it mean to go from empty via our page to X?

Also, I just noticed that the Sources of Traffic section on WikiNav already lists the views for "Filtered", which if the footnote appearing at the head of the page is to be believed The pageviews from these removed observations are referred to as "filtered" elsewhere on this page. older ≠ wiser 20:26, 28 August 2024 (UTC)

What I mean by our page is a page that we're looking at in WikiNav. If we're trying to figure out if a lot of people are clicking from a page to go to X, we want to see the where do they go from anonymized sources, too. By "from empty" I mean from incoming views that had empty referrer.

Yes, the filtered views are generally visible there. The same you can see indirectly by comparing N incoming pageviews in the top table with the footnoted actual number of incoming pageviews received of M.

There are cases where the amount of these filtered views is obviously significant. One that I remember seeing recently was Split, where it was 33% (530). Nothing needs to be done there, thankfully, but if it was necessary to analyze that, that's a big chunk of data that we're missing.

I went looking for some others, and found there's a fair few after guessing some items from Knowledge (XXG):WikiProject Disambiguation/Popular pages, such as:

• Drake 30% (3330)
• Congo 27% (2041)
• Trump 23% (9516)
• Georgia 23% (2478)
• Macron 22% (1798)
• English 21% (2165)
• Tesla 18% (1730)
• Roma 18% (1170)
• Mash 17% (1116)
• Rugby 16% (1715)
• Kamala 16% (1344)
• Trap 15% (2278)
• Kill 14% (1293)
• Ass 14% (1208)
• Alcohol 14% (1042)
• Bing 13% (1035)
• It 13% (918)
• Brat 12% (828)
• Alien 10% (844)
• Kiwi 10% (753)
• Gaelic 10% (704)
• Phoenix 9% (644)
• Alcaraz 8% (690)
• John Hunt 7% (1239)
• Poop 6% (1124)
• IPA 8% (744)
• Amazon 8% (723)
• Go 6% (700)
• Yes 6% (680)
• Premium 2% (1347)

I included both the percentages and raw numbers to illustrate how sometimes there are are significant discrepancies.

A lot of pages I checked in turn also didn't have any appreciable number of these filtered views despite a lot of options and a lot of traffic, which I found to be somewhat odd, too.

In any case, that can definitely be a noticable chunk of traffic. --Joy (talk) 21:51, 28 August 2024 (UTC)

Does 'Filtered' ever show up in outgoing views? This could significant in that if the outgoing side of these pairs are removed from the outgoing views, then I agree that could be a problem. But if, for example the specific destinations are included with source masked, that really isn't any problem at all. older ≠ wiser 22:14, 28 August 2024 (UTC)

No, I think that's the point of the anonymization, that's the definition of filtered - these won't be used to show outgoing clickstreams. Even if they cumulatively end up all the way up to hundreds and even thousands of requests in some of these cases, the filtering comes first.

Note that this also happens for items where a destination has a lot of visible clickstreams - there can be e.g. 25 Foo->Bar clickstreams that get rendered, but only 8 Quux->Bar and 7 Baz->Bar clickstreams and the latter get filtered, and we don't necessarily even get a good picture of how many people went to Bar even if it's ostensibly visible in the graphs.

The whole thing is predicated on hoping that the statistical distribution is kinda normal, and in general it could well be, but in each individual case, it doesn't have to be. --Joy (talk) 08:18, 29 August 2024 (UTC)

Hmm, curiouser and curiouser. I finally took a look at one of the TSV data files and while Excel dropped some portion of the data over 1048576 rows, the smallest count in what I can see is 12, which suggests that any combo with low counts are simply dropped from the data set. But if that is the case, then how do they calculate the percentage of "Filtered" for the incoming views? If they are able to calculate that for incoming, it should also be possible for outgoing views and that would at least provide an aggregate indication of how large the trailing tail count is. older ≠ wiser 13:54, 29 August 2024 (UTC)

Yes, clickstream-enwiki-2024-07.tsv is over 34 million rows :)

WikiNav probably looks up the total incoming in the pageviews data, so for "split" that's like this: -> 1611

And then compares it to what it sees in the clickstreams:

% grep -P '\tSplit\t' clickstream-enwiki-2024-07.tsv | awk '{ t += $4 } END { print t }'

1081

So 1611 - 1081 = 530 is missing in that case, that's what got filtered by the program that generates clickstreams. --Joy (talk) 17:56, 29 August 2024 (UTC)

BTW, this is also missing the total incoming redirect traffic there, which is: 1771. So it could actually be 690 that got filtered out, almost 39%. --Joy (talk) 17:58, 29 August 2024 (UTC)

Interesting. At least for Split if makes little difference since there is no primary topic and the data doesn't support either of the two main destinations (unless you accept a fraction over 50% as primary). That likely would not change much based on the filtered rows unless all or most of them were for the city. I'm not sure about the redirects. The project page says Requests for pages that get redirected were mapped to the page they redirect to. I'm not sure what that actually means. It sounds like they are included and mapped to the target. Or it may refer only to the outgoing views. older ≠ wiser 20:30, 29 August 2024 (UTC)

Yes, like I said before, there's nothing to do in that particular case, but the encyclopedia is huge, and there could be a fair bit of this out there. I didn't record this ratio in my statistics tracking endeavors so far so I don't have a ready-made ratio among the known recent examples. I could start recording that for the future.

The redirect requests being mapped simply means it's all squashed together. So for example next month the requests for "Heimlich" will be added to the requests for "Abdominal thrusts", just like all these others already were. So if there were 3 views of Heimlich procedure from a source like external search, and 1 thousand of the same at Abdominal thrusts, that in turn went to Henry Heimlich, the filtering starts at 1003, and so forth. --Joy (talk) 12:13, 30 August 2024 (UTC)

But you are correct that this is a potential issue to consider with low-traffic pages. older ≠ wiser 17:35, 28 August 2024 (UTC)

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.

• https://en.wikipedia.org/search/?title=X_Factor_(Russian_TV_series)&redirect=no
• https://en.wikipedia.org/search/?title=Big_Brother_(French_TV_series)&oldid=1245182870
• https://en.wikipedia.org/search/?title=Ministry_of_Foreign_Affairs_(Korea)&oldid=1245184372

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

• Additional comment I figure, at least in the case of Ministry of foreign affairs#Lists of current ministries of foreign affairs, one could add {{setindex}} at the bottom of the list section and leave it to run-by editors to fix incoming bad links. – sgeureka 15:11, 11 September 2024 (UTC)