Wikipedia talk:Disambiguation/Archive 56

Archive 50

←

Archive 54

Archive 55

Archive 56

Archive 57

Middle names or parenthetical disambiguation?

There are two scholars on Wikipedia named Eric Higgs. Up until a few days ago, one was named Eric Sidney Higgs and the other Eric Higgs (environmental scholar). I thought that was strange, and since the dab guidelines say that "natural disambiguation that is unambiguous, commonly used, and clear is generally preferable to parenthetical disambiguation", I moved it to Eric Stowe Higgs. Further, a significant majority of his work (but not all) is published as "Eric S. Higgs". User:Ortizesp has a different take and thinks the parenthetical dab should remain. Although I am willing to admit that I'm wrong, I'm convinced that in recent years, best practice is to disambiguate biographical names using the middle name instead of the parenthetical. I would appreciate the opinions of others on this. For example, I recently created John Hunter Thomas. The literature partly uses John Thomas, partly uses John H. Thomas, and partly uses John Hunter Thomas. As you can see from our dab page on John Thomas, this is preferred. Wouldn't the same argument hold for Eric Higgs, such as, we want to have foresight and prepare for additional figures by that name by defaulting to the middle name preference? Viriditas (talk) 21:34, 10 October 2023 (UTC)

Well, WP:NATURALDIS says to favor natural over parenthetical, so let's favor it. There are edge cases, e.g. where someone's middle name is only found very rarely in sources and they are univerally known without it or an initial for it (posing a WP:RECOGNIZABLE issue – e.g. we would never move the singer Michael Jackson to "Michael J. Jackson" or "Michael Joseph Jackson", and for that matter we probably would not move the also rather famous beer author Michael Jackson (writer) to "Michael J. Jackson" or "Michael James Jackson"; both of them are universally known as "Michael Jackson"). But in the case of some academic whose name is rendered different ways in different publications, this is not a concern. That said, Eric S. Higgs seems like a poor choice for Eric Stowe Higgs because Eric Sidney Higgs is also an Eric S. Higgs. I would go with Eric Stowe Higgs, and have Eric S. Higgs be a (short) disambiguation page. Either that or redir it to E. Stowe's page, and use {{Redirect|Eric S. Higgs|the archaeologist|Eric Sideny Higgs}} there.  — SMcCandlish ☏ ¢ 😼  22:12, 10 October 2023 (UTC)

We also have the odd case of Iain Banks, who wrote mainstream fiction as Iain Banks and science fiction as Iain M. Banks. Fortunately, he seems to be unambiguous. Certes (talk) 23:20, 11 October 2023 (UTC)

His university profile page does not use his middle name or initial. Readers will be much better served by the parenthetical disambiguatio . The latest title, Eric S. Higgs is worse than the previous one as it does not distinguish him from the ogher man. PamD 22:11, 10 October 2023 (UTC)

Agree on the last point, but his university profile isn't particularly dispositive, compared to his published journal material.  — SMcCandlish ☏ ¢ 😼  22:14, 10 October 2023 (UTC)

• I think that it is important to look at the purpose of disambiguation, namely to inform the user which "Eric Higgs" or "John Doe" he is looking for. So long at the hatnotes and DAB pages contain adequate identifiers such as "environmental scholar" or "footballer" it doesn't matter what the title of each of the articles is from the point of view of the user seeking a particular bio. Therefore, use the middle name or initial as required, unless there is a primary target who either has no middle name or never uses it or a middle initial. Parentheticals should not be the default, just the stop-gap for the cases that don't fit, IAW "natural disambiguation". Here there seems to be no reason why the two articles cannot be entitled with full names, with an appropriate hatnote for the other "Eris S. Higgs". If neither is primary then rename Eric S. Higgs to Eric Stowe Higgs and have Eric S. Higgs point to the Eric Higgs DAB page.--Bejnar (talk) 22:42, 10 October 2023 (UTC)

  My experience is that a clear parenthetical is more useful than a rarely used middle initial, as at a glance it will point you to the subject you're interested in. And in this case, as you mentioned, the S. initial doesn't disambiguate. I have no issues moving this page to Eric Stowe Higgs, but only if "Stowe" is used enough that it's a useful disambiguator, if it's trivial I'd just prefer a parenthetical disambiguator unless policy or consensus says otherwise. Ortizesp (talk) 02:41, 11 October 2023 (UTC)

  My understanding is that both the archaeologist (Eric Sidney Higgs) and the ecological philosopher (Eric Stowe Higgs) publish with and without the middle initial. I realize you disagree, but in my mind this is the natural, unambiguous, form of disambiguation, except as editors, we use the full middle name to make this explicit. Because this uses less characters and doesn't require a parenthetical, it is more efficient, easier to link (no pipes or spaces needed) and better for readers and editors. There's also the limitations of precision when we use a parenthetical dab. Calling him an "environmental scholar" doesn't specify the nuances of ecology and philosophy, his specialties. Simply referring to him as "Eric Stowe Higgs" is ideal as it avoids the limitations of the parenthetical. On the other hand, I support the use of a parenthetical when we have two people (or things) with identical names. Since they have different middle names, no parenthetical is needed. That's my take. Viriditas (talk) 22:23, 11 October 2023 (UTC)

  Is your contention that, if "Eric S. Higgs" is a natural name to use for the Canadian, then "Eric Stowe Higgs" must also be one? And so that calling the article "Eric Stowe Higgs" follows the guidelines?

  WP:MIDDLE says that you should use a middle name in full "if reliable sources write out several or all of a subject's given names nearly as often as they use initials". WP:NATURAL is less prescriptive, but still expects a name "that the subject is also commonly called in English reliable sources". My understanding of what has been said here is that "Eric Stowe Higgs" meets neither version of the test.

  Aoeuidhtns (talk) 23:40, 20 November 2023 (UTC)

• I think if the middle name or middle initial is inconsistently used in reliable sources (or is itself ambiguous) then parenthetical disambiguation is clearer. However, many 18th and 19th century folks (as well as some more recent ones) were commonly known by their full name. older ≠ wiser 11:19, 11 October 2023 (UTC)

  There's also the strange phenomenon in the US (that nobody has ever explained), where a person accused of or convicted of a major crime suddenly has their middle name permanently added to their title. Some famous examples include Lee Harvey Oswald, Mark David Chapman, and John Wayne Gacy, although there are many others. Viriditas (talk) 22:07, 11 October 2023 (UTC)

  250 of 1,141 American male criminals and 20 of 114 American female criminals. It's probably from having their full name as used in a police statement or court charge reported in the media, that being the first time most people hear of the accused and the name they remember. Certes (talk) 22:30, 11 October 2023 (UTC)

  That, and just being more specific in a country with a large population and lots of people with coinciding first/last name pairs.  — SMcCandlish ☏ ¢ 😼  22:37, 11 October 2023 (UTC)

• Can someone help me understand why we have vastly different approaches here? For example, take a look at Eric Higgs and Hans Beimler. The page on Beimler seems to reflect the position of Ortizesp and others here. Viriditas (talk) 23:27, 11 October 2023 (UTC)

Wikipedia talk:WikiProject Automobiles#"Marque" and WP:PEACOCK

A discussion at Wikipedia talk:WikiProject Automobiles regarding the word "marque" and a proposal to replace it with "car brand" may be of interest to watchers of this page and additional input is welcome to generate consensus. Thank you. Andra Febrian (talk) 07:58, 1 December 2023 (UTC)

Banner shell assessment problems

There are two discussions at the foot of Wikipedia talk:Content assessment on problems resulting from the fact that Disambiguation is no longer accepted as a class for article assessment. Over the past two or three days, I have come across many new "unassessed" examples in wikiprojects including WP Women, WP Italy, WP Norway and WP Sweden. I have been encouraged to use Class=list in the banner shell rather than Class=Disambig which therefore needs to be deleted in the individually listed wikiproject assessments to avoid conflicts. Those associated with this project might like to comment.--Ipigott (talk) 15:16, 1 December 2023 (UTC)

Requesting feedback on Poling

I recently added the following at Poling:

• Poling, a method of moving small watercraft using a Setting pole

There are numerous other usages of the term 'Poling' (which all seem valid, afaict) and they all start off with the term '"Poling" linked to an article (maybe Poling piped to "Shunting" is not correct?). Only my recent addition does not link the title word, and I wondered if that is okay. I think it should be on this page somehow, because when I think of "poling", boat movement is the first thing I think of; and conversely, when I think of that type of boat locomotion, I don't know any other term for it other than "poling". Is my addition correctly formatted? Mathglot (talk) 23:36, 2 December 2023 (UTC)

I think that's what I would have done (except "setting pole" not "Setting pole" since it's not a proper name). In another thread above, someone has argued that every DAB entry should start with a link, but there doesn't seem much appetite for that.  — SMcCandlish ☏ ¢ 😼  11:37, 3 December 2023 (UTC)

Gonzalez/Gonzales, etc.

It has occurred to me that we should basically have a rule that where we have two relatively short disambiguation pages (or a pairing where one is very short) differing only by a phonetic spelling variation of a surname, like Pedro Gonzalez and Pedro Gonzales, we should merge these. BD2412 T 18:16, 13 December 2023 (UTC)

• No, we shouldn't have a rule like that.
• It would be reasonable to include both Pedro Gonzales in the Pedro Gonzalez DAB page because that wouldn't make it significantly longer. They should, at least, link to the other DAB page.--Jahalive (talk) 19:38, 13 December 2023 (UTC)

"Chetnik" as a disambiguator?

Three pages use "(Chetnik)" as a disambiguator (see Category:Chetniks). I have two questions regarding these: 1) Is the term sufficiently well known for this purpose? 2) Does it matter that none of the three were members of the Chetniks in World War II, the primary topic of that term? They were in other groups noted at Chetniks (disambiguation). Dimitrije Dimitrijević (Chetnik) was a Chetnik in World War I, Vladimir Kovačević (Chetnik) was a member of the Serbian Chetnik Organization and Mihailo Petrović (Chetnik) was in as many as four different Chetnik groups. I have no idea what would work better. If this is a case of WP:AINTBROKE, I'll quickly move along. —  AjaxSmack  00:18, 15 December 2023 (UTC)

@AjaxSmack: You might receive better input at Wikipedia talk:WikiProject Disambiguation. Rgrds. --Bison X (talk) 03:43, 27 December 2023 (UTC)

At what point is WP:PDABPRIMARY considered?

Since I recently proposed moving "30 (Adele album)" to "30 (album)", and a 99.5% pageview advantage is apparently not enough for primary disambiguation, is it time WP:PDABPRIMARY and the outcome of this RFC be discussed again? If no one except Michael Jackson and Taylor Swift can have one, I am not sure there should be a guideline implying this is much more frequently acceptable. The pageview ratio is a ridiculous 1200 vs 5 and that is not enough?--NØ 08:53, 23 December 2023 (UTC)

@MaranoFan: You might receive better input at Wikipedia talk:WikiProject Disambiguation. Rgrds. --Bison X (talk) 03:43, 27 December 2023 (UTC)

Second-round RfC on titles of TV season articles

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Naming conventions (television)#Follow-up RfC on TV season article titles.  — SMcCandlish ☏ ¢ 😼  21:54, 27 December 2023 (UTC)

Proposal to resolve nomenclatural confusion between split long lists and parenthentically disambiguated page names

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Naming conventions (lists)#Fixing disambiguation confusion.  — SMcCandlish ☏ ¢ 😼  22:47, 25 January 2024 (UTC)

RfC

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Content assessment#Request for comment — Martin (MSGJ · talk) 18:07, 1 January 2024 (UTC)

This is on the distinction between disambiguation pages and set-index articles and whether we should still have the latter (in case anyone's wondering).  — SMcCandlish ☏ ¢ 😼  22:48, 25 January 2024 (UTC)

on the quality of clickstream and pageviews usage data

I've done a decades-long poor man's research into primary topics by usage in the area of anthroponymy at "Tito", and I've made another update to at Talk:Tito (disambiguation)#followup to move. We now have data from both before and after we changed the navigation layout.

So it's a topic where there's by all accounts a rather clear primary topic by long-term significance, as well as a reasonably clear one by our conventional understanding of usage. Yet we now have pretty conclusive proof that the inherent ambiguity of human given names and surnames is measurable in our statistics even when in such a clear minority. --Joy (talk) 18:16, 26 January 2024 (UTC)

on annotated biography links

Some anonymous user recently pointed me to a discussion from 2018 in [1]. Now, obviously I could just disregard this is some sort of block evasion and egregious WP:POINT, but whatever. The {{anbl}} template was made by someone else this month, and I immediately started using it because it seems quite useful - it allows us to stop copying and pasting short descriptions of people in navigation lists and instead just reuse them. Wherever it becomes a problem, e.g. if it prevents list consistency or something like that, we can do it the regular way, but it seems quite sensible in most cases. Is there an actual concern about this that I'm missing here? --Joy (talk) 21:26, 3 February 2024 (UTC)

User:Joy, thank you for bringing this here, though I could do without the WP:ABF, please note that I have explained this further at Talk:Sharafutdinov, and that WP:WRAPPERs merely extend the functionality of existing templates and so are not new in any meaningful sense. 2601:5CC:8300:A7F0:2D98:B108:5F54:7DA0 (talk) 21:32, 3 February 2024 (UTC)

I've replied over there, what was written there was nonsensical. If you actually want to contribute something useful, this is a pretty bad start. --Joy (talk) 21:34, 3 February 2024 (UTC)

User:Joy if you believe the community's reasoning is nonsensical you may seek to overturn it at anytime through an WP:RFC, in the meantime not liking community consensus does not give anyone the right to violate it. 2601:5CC:8300:A7F0:2D98:B108:5F54:7DA0 (talk) 21:43, 3 February 2024 (UTC)

Come on now. This went through Wikipedia:Redirects for discussion/Log/2024 January 20#Sharafutdinov with the use of {{anbl}} and nobody even noticed, yet now you're making it sound like some sort of a gross violation of consensus. That is just silly. --Joy (talk) 22:13, 3 February 2024 (UTC)

It is a violation of community consensus. What is silly is bringing up the RFD, where the only participant who even mentioned the template was you. 2601:5CC:8300:A7F0:F4CC:EB10:74C:7D86 (talk) 22:57, 3 February 2024 (UTC)

CycloneYoris explicitly said use that draft after I mentioned it. I guess I'm just going to have to ignore further trolling. --Joy (talk) 09:21, 8 February 2024 (UTC)

User:Joy no one is trolling you, and diffless accusations of trolling are clearly prohibited WP:ASPERSIONS. Even if we were to interpret the one remark on the RFD as suggesting use of the template, which we shouldn't since they don't mention any particulars, the agreement of two editors at one time and place does not overturn a consensus community discussion. Now given the multiple instances of you grasping at straws to try and get your way when no one supports you, or calling quotations of summarized community consensus nonsensical because you don't like them, someone unfamiliar with how confusing things can be here might interpret your actions as trolling with some justification, but you'll notice that despite repeated personal attacks I have not done so, because the remarks could also come from someone who is deeply confused. It is however time for you to either drop the WP:STICK or start an WP:RFC. You are not required to like current consensus, but you should abide by it until it is overturned through another community discussion. 2601:5CC:8300:A7F0:98C5:A273:98F2:4560 (talk) 21:40, 8 February 2024 (UTC)

@Joy I haven't come across either {{anbl}} or the {{anl}} of which it's a variation, but looking at that led me to a 2018 discussion at Wikipedia talk:Disambiguation/Archive 50#Use of annotated links which comes down pretty firmly against the use of such templated annotations in dab pages. One main concern was that if the templates were used the content of the dab page could then be altered, invisibly to page watchers of the dab page. PamD 21:45, 3 February 2024 (UTC)

@PamD that is technically true, but that goes for all other uses of templates in Wikipedia. Why is this so different, what sort of extra abuse are we expecting here? That someone would edit short description templates on the destination articles with the intent of having something abusive shown in their respective lines in the indices of people? And that this would go unnoticed in the destination article, but be shown in the list of biographies to a much larger audience? Or that someone would do it on articles that don't have that tag, so to track the history one has to go to Wikidata?

All this seems like a lot of very contrived scenarios, because our lists of people are hardly the mecca for vandals, we've been observing a number of navigation issues related to them, i.e. they get fewer eyeballs than expected, so a high potential for vandalism is barely on anyone's radar AFAICT. Besides, I was once told the SDs render up front on the articles themselves in the mobile app, and that they're numbered in the millions already (which was cited as the reason why we couldn't change the default order of templates). Why would we be unconcerned with the existing anti-abuse mechanisms of that, but concerned with this rather indirect potential of abuse? --Joy (talk) 22:09, 3 February 2024 (UTC)

@Joy The main problem is that a short description will not always be suitable for a dab page entry: in particular, for biographical items, WP:SDDATES encourages the addition of dates, but these will be at the end of the SD, while the annotation in a dab page puts them first - I notice that in the case of Sharafutdinov you added the dates by using the "abbr" parameter of the template, but in many cases the date would have been imported as part of the SD, but in a way incompatible with WP:MOSDAB. I've now added the dates to both the Sharafutdinovs' SDs, having been alerted to the fact that they were missing. PamD 08:42, 4 February 2024 (UTC)

Yeah, so that's all I'm saying - if we can use it to format the list entry, we should be free to use it without the risk of getting insta-reverted. If it doesn't work, don't do it / get it reverted. --Joy (talk) 09:58, 4 February 2024 (UTC)

(ec)In addition to what PamD mentions, short descriptions are sometimes written in a way that can read oddly when included in a disambiguation list (i.e., (inconsistent with other entries or becomes an unusual grammatical contruct). I can't recall examples off the top of my head. Wikipedia:Manual of Style/Disambiguation pages#Images and templates also advises against transcluding templates, which is why ship name templates aren't used. As I recall at least part of the reasoning was to avoid introducing unnecessary complexity to the dab pages. Some of the templates are not exactly intuitive to use (e.g., the hopelessly confusing parameters for the hatnote templates). The documentation for the new template is spartan at present and based on what is there now, it is not what I'd call intuitive to use. older ≠ wiser 22:18, 3 February 2024 (UTC)

Ship templates aren't used in set indices? I thought I saw a few just recently... --Joy (talk) 22:34, 3 February 2024 (UTC)

Set index anrticles are not expected to ^follow^ (added later) the MOS for disambiguation pages. older ≠ wiser 00:21, 4 February 2024 (UTC)

OK, so the disambiguation list formatting for biographies, where anbl is useful, is effectively the same. The main reason I brought this up here is because the anonymous invoked the D guideline, even if the page was obviously anthroponymy only; this natural overlap was also mentioned in that recent RFC at Wikipedia talk:Content assessment. I suppose we should just go ahead and clarify these concepts in the guideline text in an effort to dissuade pointless edit-warring. --Joy (talk) 10:08, 4 February 2024 (UTC)

Or ask at Wikipedia:WikiProject Anthroponymy to clarify guidance for surname pages. My main concern is that the template is quite confusing to use and is thus more prone to errors that are easily avoided by not using the template. What is actually gained by using the template? For the time being at least, I don't see any illumination forthcoming from the discussion at Wikipedia talk:Content assessment. older ≠ wiser 13:22, 4 February 2024 (UTC)

Well, it's just so much easier for the editor. When composing a list from scratch, you just have to do the composition -- recognize the ambiguity, exclude partial title matches, etc -- and not worry about the captions (well, at least for the large majority of cases I tried so far). --Joy (talk) 20:41, 5 February 2024 (UTC)

WP:PRIMARYTOPIC is not for historical events

The rules of WP:PRIMARYTOPIC work when there are multiple topics in different domains that have the same name, and one is clearly the primary. For example, George Washington and George Washington (book). People searching for "George Washington" are looking for the person, not the book with that title, and the person is by far the primary, so it makes sense to call the article "George Washington" and not "George Washington (person)."

This rule does not work well, however, for historical events with the same name. For example, "Gaza War" -- there are like four or five of them. Even if one is the primary, they should all have a date, or readers will be confused. Typically, for historical events with the same name, readers are going to know that and they'll be looking for one with a specific date. I recently wrote a very long vote about this at Israel-Hamas war, where the year disambiguator was recently dropped. Srnec referenced my vote in another discussion at Talk:Siege of Baghdad, where the date disambiguator was also just dropped.

This is a hole in WP:PRIMARYTOPIC. It probably applies to other areas besides historical events with the same name. For example, if there is an album and a song with the same name, they should probably always be disambiguated, even if one is primary. If there is a book and a movie with the same name. Nobody is likely to confuse the book George Washington with the person, but people are likely to confuse a book with a movie of the same name, or multiple historical events with the same name that took place at different times (as another example, Sack of Rome).

I think PRIMARYTOPIC should be changed to account for "cross-domain" (for lack of a better term) primary topics (don't disambiguate), v. "within-domain" primary topics (disambiguate). Levivich (talk) 17:13, 10 February 2024 (UTC)

Good work is currently going on at Wikipedia:Partially disambiguated page names analysing cases such as Thriller (album) which share their titles with other albums, etc. These are a different species from Gaza War etc. but are closely related. Certes (talk) 18:15, 10 February 2024 (UTC)

I agree, closely related. Same principle at play at Talk:30 (album)/Archive 1#Requested move 22 December 2023, for example. Levivich (talk) 18:30, 10 February 2024 (UTC)

However, I think the format of the title makes a difference. Readers seeing a title Foo (bar) may well assume that there are other things called Foo, but none of them is a bar, because a qualifier normally disambiguates completely. That's not the case for a natural title such as Great War or Gulf War. I'm not convinced that we should apply a higher standard of primality here just because the alternative meanings are also wars. Certes (talk) 19:46, 10 February 2024 (UTC)

• I don't especially agree with this. If one usage is the WP:PRIMARYTOPIC, I don't see what it matters what "domains" they are in. I do agree that things like "Gaza War" should always be disambiguated (as in fact they all are), even if one usage, here a redirect to Israel-Hamas war, is held to be primary. So I would have agreed with you at Talk:Siege of Baghdad, but I'm not sure bringing "domains" in helps the argument. Johnbod (talk) 19:03, 10 February 2024 (UTC)
• I agree with Johnbod. If a topic is in fact primary topic, there is no reason to treat it differently based on what type of a thing it is. older ≠ wiser 20:34, 10 February 2024 (UTC)

I think PRIMARYTOPIC still applies to historical events, but perhaps with the proviso (which may apply to other situations as well) that we should be wary of declaring one topic to be the primary one based on which one happens to be current. Is the current war in Gaza THE Gaza War? Perhaps we shouldn't find that to be the case until a few years after, when, in retrospect, it may still be referred to as THE Gaza War, or maybe it will be seen as just one Gaza war among several. Largoplazo (talk) 20:55, 10 February 2024 (UTC)

I would think that a title like Gaza War should resolve to an article with a title like, List of wars in Gaza, or for something more in depth, History of military conflicts in Gaza. BD2412 T 20:57, 10 February 2024 (UTC)

Well, it doesn't, unless you want to create such a page. One would have to add in the bunch at Battle of Gaza, going back to 312 BC. But the disam page at Gaza War is effectively the same. What would be the point of ramming wars at totally different periods together? We don't have Wars involving the English Channel etc. Johnbod (talk) 21:32, 10 February 2024 (UTC)

Well then, History of post-World War II military conflicts in Gaza. BD2412 T 23:09, 10 February 2024 (UTC)

re Largoplazo, yes, I think the ongoing discussions as to WHAT to call the article indicates there is a deep question as to whether it is the primary topic -- at least in terms of long-term significance. It is nearly always the case that very high-profile current events will at least temporarily be the primary topic. older ≠ wiser 21:40, 10 February 2024 (UTC)

• I don't see any hole in WP:PTOPIC. The criteria are 1)frequency of usage and 2)historical significance, and how to weigh those two criteria is appropriately left to case-by-case consensus. This has worked well for all sorts of domains, historical and otherwise, for years. There's no added value in considering whether the top targets are "within the same domain". There is no reason to force an otherwise-clear PT to wear a parenthetical, and force all readers to a dab, just because the PT is "in the same domain" as less noteworthy topics. It looks to me like Levivich is frustrated at some recent PT determinations. But the matter of determining whether Israel–Hamas war and Siege of Baghdad are really PTs still comes down to how common those uses are relative to others of the same name, and how enduring that primality is. I don't know if the PT determinations made in those two cases were right or wrong, but I don't see any case for a change in the guidance on what makes a PT. —swpb^{T • beyond • mutual} 22:54, 10 February 2024 (UTC)

  "Frustrated" is such an odd choice of word. I just reread what I wrote and I'm scratching my head wondering where anyone sees frustration in what I wrote. I think the rule should be modified to make it better, I think the application of the rule has led to some "wrong" results, but I'm not frustrated about it. I perceive a weakness and I'm suggesting a way to strengthen the policy, but it's not frustrating or in any way emotional; my opinion is based in logic not emotion. I understand if you don't agree with my logic but I assure you I am not frustrated or otherwise feeling any kind of negative emotions about article titles. Levivich (talk) 02:50, 11 February 2024 (UTC)

@Levivich You say For example, if there is an album and a song with the same name, they should probably always be disambiguated, even if one is primary. If there is a book and a movie with the same name. You seem to be saying that everyone who wants either the book The Outrun or the film The Outrun (film) should land instead on a dab page, to then choose between them, the book being at The Outrun (book), so that everyone has one more click to make, rather than the current position where those who want the book get there immediately, those who want the film see a nice helpful hatnote and make one more click. I don't think your proposal benefits the reader. PamD 23:18, 10 February 2024 (UTC)

@PamD: That's not what I'm saying, and it's not what I wrote. I didn't write anything about dab pages. I'm talking about article titles. In your example--I'm not familiar with Outrun but assuming the book is primary and not the film--I'd make The Outrun a redirect to The Outrun (book), and if a dab page is needed, have it at The Outrun (disambiguation). I certainly agree "one more click" would not be an improvement. But adding "book" to the title of The Outrun would be an improvement, IMO. Levivich (talk) 02:53, 11 February 2024 (UTC)

In that case it appears that the objection here is to the idea of what is normally called "unnecessary disambiguation" (a corollary of WP:PRIMARYREDIRECT or, in the case of disambiguation pages, WP:MALPLACED), rather than to the rules about primary topics. I agree with the other comments above that historical events are fully covered under the current rules under the ideas of frequency of usage and historical significance. Dekimasuよ! 04:34, 11 February 2024 (UTC)

I don't think that's the objection here because I don't understand what it means. But I would agree that in some cases (like years of some historical events), keeping the disambiguator in the name of the primary topic can be helpful even if not necessary, and so the dab for a primary should not always be removed. Or something like that. Which could be summed up as "unnecessary disambiguators may still be helpful." PTOPIC doesn't say otherwise AFAICS, but I think it'd be improved by stating this explicitly, because even though PTOPIC doesn't require the removal of a dab, in practice it seems like many editors apply it as if it does, e.g. the disucssion is, "it's a PTOPIC, therefore no dab, end of story." Levivich (talk) 05:02, 11 February 2024 (UTC)

Well, that would presumably conflict with WP:CONCISE (and WP:OVERPRECISION, cf. the entry on Energy there) once it has been determined that there is a primary topic, so perhaps then the objection is to the criteria at WP:AT. Dekimasuよ! 05:13, 11 February 2024 (UTC)

(Why are you guessing what my objection is? I'm trying to tell you what my "objection" is, which is not an objection, it's an idea for improving this page.)

Maybe it'll help if I give another example besides the two above about events. A classic example is Thriller (album) and Thriller (song). The reason those are dab'd is because there's no consensus that either are primary. But irrespective of that, I find it very helpful that those two articles have "(album)" and "(song)" in the title, because it tells me right away whether I'm reading the article about the album, or about the song.

Harry Potter, the novel series, is the clear primary. But when I look at that article, I wish it would have "(book series)" or something in the title so I knew I was reading the article about the book series and not Harry Potter (film series), Harry Potter (TV series), or Harry Potter (character). Those other three titles have dabs so I don't have the confusion, but the primary one doesn't.

The primary article does say, right at the top, "This article is about the novel series," which is what clears up that confusion. But it'd be even easier if it said it in the title, particularly in lists of article titles. E.g., if you type "Harry Potter" into the search form, the short desc does help you find the one about the book series, but still I think it'd be easier if it was just called "Harry Potter (book series)" (or "novel series" or "literature series," both phrases are used elsewhere).

Aside from current events and historical events, these are two other examples of where I'd find unnecessary dabs useful, and I wish PTOPIC would say that it's ok to keep helpful but unnecessary dabs (subject of course to consensus that they're helpful for any a particular article). Levivich (talk) 05:22, 11 February 2024 (UTC)

@Levivich Are you saying that as soon as an article was written for the film,The Outrun, the article on the book (at the undisambiguated title) should have been moved to the disambiguated title? PamD 06:44, 11 February 2024 (UTC)

No, not as soon as and not necessarily ever. I'm saying this page should tell editors they can decide to do that (have a dab in a primary title) if they think it's helpful. But not automatically or in every case. (I'm not familiar enough with that particular work to know if it's 'helpful' in that case.) Levivich (talk) 06:55, 11 February 2024 (UTC)

It's helpful if and only if the film is almost as likely as the book to be the topic a reader is seeking when they look for "The Outrun". That's already covered by WP:PRIMARYTOPIC. I'm a big fan of dabs, but by putting one at the base name here we'd be adding one more step for readers seeking the book without shortening the path for the (presumably much smaller) number of readers seeking the film. Certes (talk) 10:53, 11 February 2024 (UTC)

In what way does adding a dab to a primary add one more step for readers? Levivich (talk) 17:05, 11 February 2024 (UTC)

I'm comparing two options for handling a case which I think matches what we're talking about, specifically where we have two Foo Wars in 1234 and 1987, of which 1987 is the more notable and passes WP:PRIMARYTOPIC. Current practice is to call the 1987 article Foo War with a hatnote to Foo War (1234). What I think you are suggesting is to move the PT to Foo War (1987) and write a dab called Foo War. This change has little effect on the minority of readers interested in the 1234 war, who now click on a dab entry rather than a hatnote. However, it hampers the majority who seek the 1987 war, who now have to click on a dab entry rather than being presented with their desired topic immediately. If I've misunderstood, please explain how my statement differs from your proposal. Certes (talk) 17:37, 11 February 2024 (UTC)

That's not what I'm suggesting. That's what Pam thought I was suggesting, too, and I cleared that up with Pam just above.

"write a dab called Foo War" is not anything I said in my OP I don't get why people think this is something I'm suggesting :-P

Foo War (1987) would be the name of the article, Foo War can be a redirect to Foo War (1987), not a dab page, and no extra click. If a dab page were needed, it would be at Foo War (disambiguation). (This is all assuming Foo War (1987) is the primary.)

And to repeat myself, all I'm suggesting is that PTOPIC should mention that it's OK for editors to come to consensus to do this if they think it's worth doing on a particular article. Not that this should be done automatically or in every case. Nor do I think the primary topic should be turned into a dab, or that any extra clicks should be created at all. Nor do I object to or want to repeal any other part of any policy. I'm just saying ... and all I'm saying ... is we should acknowledge that sometimes it makes sense to have a dab in the title of a primary topic (and I am suggesting nothing more). Levivich (talk) 17:45, 11 February 2024 (UTC)

What you are describing is pre-disambiguating the article titles, which in several earlier discussions has usually been soundly rejected. Of course, consensus can change, but if you are only looking for singular exceptions, WP:IAR can always apply on a case-by-case basis provided there is a good reason for ingnoring the rule(s) in any particular case. There is no reason to update this guideline to address rare exceptions. older ≠ wiser 18:16, 11 February 2024 (UTC)

I'm learning a lot of new terms like "unnecessary disambiguation" and "pre-disambiguation" :-) Yeah, this can be done now without any changes to any policies or guidelines. I don't think it's even WP:IAR because there is no rule against it. Neither WP:DAB nor WP:AT nor anything else I'm aware of prohibits dabs on primaries, or says all primaries must have dabs removed. So I don't really see it as an "exception" to any rule. But it is certainly rare. The reason to update this guideline would be so editors know it's an option. Levivich (talk) 19:15, 11 February 2024 (UTC)

@Levivich So your intended outcome is this, in some cases:

• The article at title "ABC" is agreed to be the primary topic but you believe it would help the reader to put it at title "ABC (onething)"
• There would be a redirect from "ABC" to "ABC (onething)"
• At "ABC (onething)" there would be a hatnote directing readers to "ABC (otherthing)" (or perhaps to "ABC (disambiguation)".

A problem is that any editor familiar with disambiguation will see this, spot an apparent problem, and move "ABC (onething)" to "ABC" because it's the primary topic. Or they will move the disambiguation page to "ABC" because all the titles have been disambiguated, so it looks as if someone has already decided that none of them is the primary topic. Giving an article a disambiguated title is, in most cases, an indication of the fact that the person naming it does not think it is the primary topic.

So if you IAR to give the primary topic a disambiguated title, you need a lot of annotation (hidden comment plus talkpage note, perhaps?) to explain your reasoning to the helpful editor who comes across the article and tries to tidy things up according to usual practice, so that "corrections" don't get made and reverted without further discussion, wasting editors' time.

Is all this really needed, given that the short description and the lead sentence will both make quite clear which war, or which format of the creative work, the article is about? PamD 19:40, 11 February 2024 (UTC)

@PamD: So your intended outcome is this... Yes, exactly.

A problem is that any editor familiar with disambiguation will see this, spot an apparent problem, and move... Yes, unless we add a sentence to WP:PTOPIC that says "it's OK for a PTOPIC to have a dab if editors decide so by consensus" or "dabs on primary titles are not prohibited" or some kind of words to that effect.

I agree that IARing is difficult for the reasons you point out. This is exactly why I think PTOPIC should be explicit in saying "this is OK to do sometimes" or "there is no rule prohibiting this" or some kind of words to that effect (and I mean like something short, one sentence). Levivich (talk) 19:53, 11 February 2024 (UTC)

Thank you for the clarification. Continuing the example above, I think we agree that typing Foo War should lead the reader to the article on the 1987 war, and it's perfectly reasonable for Foo War (1987) to lead there too. So, the question is whether we title the article Foo War and have Foo War (1987) redirect there, or vice versa. We normally do the former per WP:CONCISE. There are systematic exceptions such as US places (Sacramento redirects to Sacramento, California) but they're generally prescribed by WP:COMMONNAME. Is there a convention amongst historians to refer to wars with their years even when the unadorned title would obviously mean that year's war? Certes (talk) 19:53, 11 February 2024 (UTC)

I appreciate everyone taking the time to engage in this discussion. I don't think there is such a convention among historians for wars generally. I don't believe there is any kind of categorical rule. But I do think there are some specific instances where historians do commonly include the year of an event even if the event is what we'd call "primary," eg 1066 Battle of Hastings and 410 Sack of Rome. I suppose one might say that for any historical event, adding the year to the title would help orient the reader, but I'm still not in favor of categorical rules. Which is to say, even if historians had such a convention, I'm not sure Wikipedia should necessarily follow it (common name, after all, is not the be-all and end-all of article titling), but I think we should maintain flexibility on the issue (i.e., not automatically remove all dabs from all primary titles). Levivich (talk) 20:15, 11 February 2024 (UTC)

I've always just called it the Battle of Hastings, but then I'm not aware of any other notable conflicts there. "Battle of Hastings, 1066" rolls off the tongue but I think that's a sentence fragment rather than a title. I agree with the current title of Sack of Rome (410), because it doesn't seem primary over the other sackings. Certes (talk) 20:38, 11 February 2024 (UTC)

Of the 8 Sack of Rome events listed, Sack of Rome (1527) is pretty clearly primary, at least for art historians. Johnbod (talk) 01:44, 12 February 2024 (UTC)

temporarily vacating WP:MALPLACED for one title?

We had a move request last year for "Rachel" that relates to ambiguity. In Talk:Rachel#followup to move discussion, I analyzed the statistics further and came to the conclusion that it would be worthwhile to change to a primary redirect in order to be able to get better measurements. However, I don't know that there's a good alternate title that doesn't involve parenthetical disambiguation, so moving the article about the biblical figure would necessarily run afoul of WP:MALPLACED, and it would have to stay there for over a month (ideally over three, to get a better sample). Nevertheless, the two proposals discussed so far, Rachel (Old Testament) (2010) and Rachel (biblical figure) (2023) both seem reasonably unlikely to astonish many readers during the experiment.

Does anyone see a big problem with running this kind of an experiment? Should the consensus for it be examined locally at Talk:Rachel, with a WP:RFC, and/or a discussion here or some other global forum? --Joy (talk) 09:27, 16 February 2024 (UTC)

Switching to an -ing for in the middle of a disambiguation list

FYI

 – Pointer to relevant discussion elsewhere.

Please see WT:Manual of Style/Disambiguation pages#Switching to an -ing for in the middle of a disambiguation list.  — SMcCandlish ☏ ¢ 😼  21:24, 21 February 2024 (UTC)

A specific question on disambiguation

I recently promoted Therapy Dogs (2022 film) from AfC to mainspace. I would like to disambiguate Therapy Dogs (currently a redirect to Therapy dog) but I am not sure if the best action would be to create a disambiguation page at Therapy Dogs, linking the film and the dog, or a hatnote at Therapy dog. I tried to follow the guideline but I'm not sure how to interpret it in this case. Broc (talk) 11:40, 28 February 2024 (UTC)

There seems no reason for the capitalised plural to redirect to Therapy dog, and none was offered when the redirect was created, nor any Rcat added to explain it, so I would suggest a Move Request to move the film to Therapy Dogs, with hatnotes from film to dog and v.v. PamD 14:57, 28 February 2024 (UTC)

Yes, the policy WP:SMALLDETAILS seems relevant for considering "Therapy Dogs" being the film. —Bagumba (talk) 17:09, 28 February 2024 (UTC)

"DAB page" listed at Redirects for discussion

The redirect DAB page has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 March 2 § DAB page until a consensus is reached. Jay 💬 16:06, 2 March 2024 (UTC)

a change in page views between primary topic and primary redirect

A few years ago, I had noticed Sumber, Cirebon was at "Sumber" and moved it away, but kept a primary redirect because it wasn't clear if there was not a primary topic. Now that I had a look at the graph of monthly page views it looks like that change significantly altered the overall traffic at "Sumber" - it went from an average of >200 a month to <20 a month.

This difference of an order of magnitude seems to be another confirmation for how our choices about navigation influence traffic in unforeseen ways - it looks like if we put something in a presumed primary topic position, the search engines drive traffic there way more than they do otherwise, even with a primary redirect in place. This sort of puts a significant dent in our logic of figuring out primary topic by usage - once we have a presumed primary topic, we can't really trust our statistics about that to tell a straightforward story.

Now, this property of the system could have both positive and negative effects - maybe we should think of this in terms of: by choosing to put a topic in the primary topic position, we can intentionally drive traffic to it and more effectively contribute to the spreading of knowledge. At the same time, this indicates a need to have more substantive long-term significance discussions, because we if we have a chance to influence reader traffic like this, we want to make sure we do it for the right topics, as opposed to doing it arbitrarily and/or effectively hiding ambiguity. --Joy (talk) 10:16, 9 March 2024 (UTC)

I just found another case of this, just in the other direction: Talk:Bosut (disambiguation)#primary topic. --Joy (talk) 10:28, 9 March 2024 (UTC)

At Talk:Bold#post-move, we see a change from primary redirect to disambiguation page leading to significantly more traffic at the latter. --Joy (talk) 21:20, 14 March 2024 (UTC)

The Fifth Avenue Hotel

What would be the best way to name this article, given that we have Fifth Avenue Hotel for a different (former) hotel on the same avenue? I don't think using the word "The" is the correct way — Martin (MSGJ · talk) 11:31, 5 April 2024 (UTC)

Options include using the date it opened, i.e. The Fifth Avenue Hotel (opened 2023) or the street it is on, i.e. The Fifth Avenue Hotel (28th Street) — Martin (MSGJ · talk) 11:33, 5 April 2024 (UTC)

As long as the correct title is The Fifth Avenue Hotel in accordance with WP:THE, then WP:SMALLDIFFS kicks in, and we needn't add anything further to the title. All we need is hatnotes on each article pointing to the other. Station1 (talk) 03:55, 6 April 2024 (UTC)

RDAB speedy criteria

See Wikipedia talk:Criteria for speedy deletion#RFC new R5 for a proposal to make RDAB errors a speedy criteria. Crouch, Swale (talk) 19:09, 6 April 2024 (UTC)

Proposed DAB category - Greek Letter Organizations

examples include: Sigma Phi Beta and Phi Kappa. Would contain about 20-30 dab pages, willing to generate a list. Can't find the guideline here, though it seems smaller than most of the existing.Naraht (talk) 15:25, 29 April 2024 (UTC)

How should redirects to list entries be disambiguated?

Following this RfD, Quantum realm was retargeted to Features of the Marvel Cinematic Universe#Quantum Realm. There were mentions in the RfD discussion about putting a hatnote to Quantum mechanics at the target; however, as the redirect points to an entry in a list rather than to a section, there doesn't seem to be a good way to include a hatnote template. I was therefore wondering if there was any guidance or ideas about how these sorts of redirects can be disambiguated.

All the best, ‍—‍a smart kitten_[meow] 12:28, 6 May 2024 (UTC)

I don't know a standard way to do this but we might replace

* The '''{{visible anchor|Quantum Realm}}''' ...

by something like

{{anchor|Quantum Realm}}{{redirect|...}}

* The '''Quantum Realm''' ...

However, that's a bit intrusive for readers simply browsing the list. Certes (talk) 15:59, 6 May 2024 (UTC)

That's the option that occurred to me, as well. It is, as you say, a bit intrusive, but something needs to be there so that users looking for quantum mechanics aren't left hanging. Another possibility is an inline pointer:

* The '''{{visible anchor|Quantum Realm}}''' (not to be confused with [[quantum mechanics]]) ...

But that seems kind of awkward, especially because there's already a parenthetical in that sentence. —ShelfSkewed Talk 17:06, 6 May 2024 (UTC)

That's an innovative approach. It feels wrong, but perhaps only because we don't do it elsewhere. It's analogous to {{confuse}}, which is mainly for typographically similar words such as Astroid vs Asteroid, but "quantum realm" is the correct spelling of a colloquial term for quantum mechanics as in [2]. I think {{redirect}} is the tool for the job, as per your first instinct. Certes (talk) 18:31, 6 May 2024 (UTC)

Well, let's give it a try. I added a hatnote (with a leading colon to distinguish it from the section above) with an edit summary linking to this discussion. Maybe someone will have another idea. —ShelfSkewed Talk 19:08, 6 May 2024 (UTC)

One thing I'd note here is that there was still some amount of acrimony about whether the term was truly ambiguous. In this sort of a case, the primary redirect method should not generally be preferred because it doesn't allow us precise measurements. We should instead default to erring on the side of caution and first disambiguating these with normal disambiguation lists, and then be able to look at the page views and clickstream statistics specifically for that. I know it seems like seven editors agreeing at RfD is a true sign of consensus, but when it's not backed by a volume of empirical data, but is rather largely assertions, it could well be wrong. I came to this stance after seeing how the stats changed after RfDs for forced march and Celebi. --Joy (talk) 19:22, 6 May 2024 (UTC)

WP:DABCOMBINE not actually with organic consensus in the acronym space

I noticed this a month ago in Talk:PAG, last comment. Would be nice if someone could analyze the data more thoroughly. --Joy (talk) 07:52, 31 May 2024 (UTC)

Wikipedia talk:Content assessment#Request for comment

In the discussion linked above, we have something of a weak consensus to stop strictly sequestering disambiguation from set indices in all cases. Does anyone see any reason not to draft changes to this guideline to incorporate some of these possibilities? --Joy (talk) 15:44, 6 March 2024 (UTC)

In the meantime the RFC thread was archived at Wikipedia talk:Content assessment/Archive 9#Request for comment.

As there's no objection, I think we need these kinds of changes:

• Make it clear in the text of WP:PTM that the exception applied to toponymy can apply to anthroponymy as well, and we shouldn't shy away from listing some of the latter on disambiguation pages
• Make it clear in the text of WP:NAMELIST that the strict separation of disambiguation and set index content should be weighed against the possibility that we introduce extra hurdles to readers just because some ambiguous topics also qualify for a set index
• Possibly a section here about the practical interaction of disambiguation and set index articles, as opposed to just a See also link

--Joy (talk) 13:01, 28 April 2024 (UTC)

I've split out item #1 above into #including the most notable set index topics on human name disambiguation pages. --Joy (talk) 11:26, 4 June 2024 (UTC)

Semi-protected edit request on 5 July 2024

Edit purpose: The page section in the example no longer exists. The section and the redirect now use "American Football" instead of "Football".

Current text: In some cases, it may be more appropriate to redirect readers to a list rather than a disambiguation page. For example, Cleveland (NFL) should not be a disambiguation page, but should instead redirect to List of Cleveland sports teams#Football.

Replacement text: In some cases, it may be more appropriate to redirect readers to a list rather than a disambiguation page. For example, Cleveland (NFL) should not be a disambiguation page, but should instead redirect to List of Cleveland sports teams#American Football. Solid kalium (talk) 18:09, 5 July 2024 (UTC)

I reverted "American" on a U.S. topic page, so it works again. Hyphenation Expert (talk) 18:42, 5 July 2024 (UTC)

MOS:DABNOENTRY is contradicted by WP:PTM

MOS:DABNOENTRY states: "On a page called Title, do not create entries merely because Title is part of the name ... This does not apply if the subject is commonly referred to simply by Title." On the other hand WP:PTM says: "Placenames are often divided between a specific and generic part, for example North Carolina (where "Carolina" is the specific, and "North" the generic part). Common generics are compass points, upper/lower, old/new, big/small, etc. It is entirely proper to include such placenames in disambiguation pages with the specific title (North Carolina is properly listed at Carolina (disambiguation))". DABNOENTRY would exclude North Carolina from Carolina (disambiguation) because the state is never called simply Carolina, just as New York is never referred to as York (York Yankees?). In my opinion, DABNOENTRY takes precedence (and makes the most sense), and the wording in PTM should be removed. Clarityfiend (talk) 14:48, 17 June 2024 (UTC)

"Nothing could be finer than to be in Carolina in the morning ..." —Carolina in the Morning, Gus Kahn and Walter Donaldson.

References to "the Carolinas" or "the Dakotas" aren't unusual. Largoplazo (talk) 15:24, 17 June 2024 (UTC)

I have no objection to the Carolinas. As for the song, I venture to guess it's talking about the Carolinas, but it wouldn't scan properly as "be in the Carolinas". Also, DABNOENTRY states "commonly referred to". One song isn't going to cut it. Clarityfiend (talk) 10:13, 18 June 2024 (UTC)

How about 2? "Carolina in My Mind". The songwriter was specifically referring to his home in North Carolina.--User:Khajidha (talk) (contributions) 13:21, 6 July 2024 (UTC)

Or three? "Carolina". --User:Khajidha (talk) (contributions) 13:23, 6 July 2024 (UTC)

The key words in DABNOENTRY are "merely because". It's saying PTMs are not generally helpful to include. WP:PTM is pointing out a subclass of PTMs that often are helpful. There's no direct contradiction, but there could be better alignment – I'd say changing WP:PTM from "entirely proper" to "often proper" would bring it more in line with both DABNOENTRY and best practice, and that the two sections should link to each other with hatnotes. —swpb^{T • beyond • mutual} 15:35, 17 June 2024 (UTC)

This started with Talk:Vic#French places. I think the main criterion is pretty clear - if the average English reader is going to encounter ambiguous references to a topic in practice, they should be listed. --Joy (talk) 18:18, 17 June 2024 (UTC)

I often put partial matches like that in See also; I must have been in a particularly deletionist mood that day. That's the sort of thing I would do with the bizarre New York (disambiguation) entry in York (disambiguation). Who would look for the Big Apple under York? In fact:

Proposal: Reword what PTM currently says to "It is entirely often proper to include such placenames in the See also section of disambiguation pages with the specific title". Clarityfiend (talk) 10:13, 18 June 2024 (UTC)

I don't think this is just for see also, because I have encountered numerous examples of toponyms where this would not match real-world circumstances, and this sort of a thing could well be controversial. --Joy (talk) 14:05, 18 June 2024 (UTC)

I think in the case of "Vic", for most places like "Vic-sur-Aisne" it is common to use plain "Vic" when there is no ambiguity. For instance in the neighbouring town Cœuvres-et-Valsery the road leading to Vic-sur-Aisne is called "Route de Vic", Similarly, the "Route de Rabastens" leads to Rabastens-en-Bigorre. So yes, I think places like Vic-sur-Aisne should be listed on the disambiguation page "Vic". The "-sur-Aisne" is not really generic, more a specifier or disambiguator (because there are several places named "Vic"). Markussep ^Talk 08:09, 20 June 2024 (UTC)

Shield and sword

 Courtesy link: Shield and Sword – a neo-Nazi music festival
 Courtesy link: Shield and sword – red link
 Courtesy link: Sword and shield – a disambig page

Can someone help me unscramble all this?

• "shield and sword" is a metaphor for the function of grand juries; see Grand jury#Purpose for usage (no redirect there by that name)
• A search-bar query for "shield and sword" (lowercased, without quotes) takes you to Shield and Sword, a neo-Nazi music festival, via the redirect Shield And Sword
• "sword and shield theory" is an analysis of Marshal Pètain's leadership of Vichy France in WW2, and redirects to Vichy syndrome#"Sword and shield" argument
  • A query for "sword and shield" (lowercased, without quotes) goes to disambig page Sword and shield (which doesn't link the festival, which has Shield first)
• There is no disambig page Shield and sword (that slot is already taken by the festival article).

Starting with the easy stuff: it seems pretty clear that D-page Sword and shield should contain an entry that links the festival article, right? Do we need to move the festival to Shield and Sword (festival) so we can create "Shield and sword" anew as a disambig page, so it can point to the festival, and also to Grand jury page, and maybe also the theory about Marshal Pètain? Thanks for any advice. Mathglot (talk) 08:51, 6 July 2024 (UTC)

• I would move the festival and redirect Shield and Sword (and Shield and sword) to Sword and shield as an alternative form. BD2412 T 21:05, 6 July 2024 (UTC)

  Makes good sense to me. I'll wait some days to see if there are more thoughts about this before acting. Oh, and what would you do about the Grand jury sense of "shield and sword"; add it to the D-page? Mathglot (talk) 02:15, 7 July 2024 (UTC)

Primary Topic

There is a move proposal at Talk:Rallying#Requested move 12 June 2024 suggesting the article should be disambiguated. Another user has supported, mentioning the policy of WP:PRIMARYTOPIC. However, no other Rallying topic articles can be found - making the move unnecessary under that very policy. Is that correct, does primary topic only mean a primary Wikipedia article and not common usage of a word within multiple contexts? I'd be grateful if anybody could clarify that within the discussion, or here for me. Thanks. Rally Wonk (talk) 16:38, 10 July 2024 (UTC)

traffic pattern changes between redirects, broad-concept articles and disambiguation pages

Here's a bit of a continuation of Wikipedia talk:Disambiguation/Archive 56#a change in page views between primary topic and primary redirect:

The term national bank was recently replaced by disambiguation through a WP:MALPLACED redirect, but it used to be read by ~4k readers a month. Likewise happened for state bank, which used to be read by ~1k people a month.

All-time page view statistics for these topics and the disambiguation pages

The change seems to have caused the reader traffic to practically instantly drop to 0.4k and 0.2k a month, respectively.

So it looks like the change caused us to effectively relinquish 80-90% of readers looking up a term like that, as their search engine stopped sending them our way (or at least I can't think of another scenario why this pattern change would happen). --Joy (talk) 18:05, 26 June 2024 (UTC)

Here's another one: Talk:Ottoman#followup to the merge of plural - once we squashed plural and singular, 80% of incoming traffic magically disappeared. --Joy (talk) 11:47, 27 June 2024 (UTC)

I happened to notice Talk:Pharos (disambiguation)#readership statistics today - a change from disambiguation page to primary redirect in 2016 also caused ~80% of previously recorded incoming traffic to disappear. --Joy (talk) 09:35, 16 July 2024 (UTC)

including the most notable set index topics on human name disambiguation pages

This is effectively a continuation of Wikipedia talk:Disambiguation/Archive 55#effects of WP:NAMELIST on navigation outcomes for anthroponymy entries which went stale and got archived out, but still applies.

More examples have since cropped up where we see from the available data that readers would benefit from us including the most popular given name and surname entries on the base disambiguation pages whenever a separate name list (set index) exists:

• Talk:Boyle
• Talk:Luka

I wanted to title this section "WP:NAMELIST considered harmful", but it's not really, just the overly strict implementation we employ right now. :)

If there are no objections, I would go ahead with making this change:

Lists of names

To prevent disambiguation pages from getting too long, long lists of given name or surname holders can be moved out of disambiguation pages into separate set indices. In cases where there are distinctly popular entries in such lists, such as those with substantially large usage or long-term significance compared to the rest of the list, links to such articles should be retained on the base disambiguation page. This kind of extra listing should in turn still be constrained by the base list size, so it should not typically exceed five to ten entries.

We reasonably expect to see Abraham Lincoln at Lincoln (disambiguation), but very few sources would refer to the waltz composer Harry J. Lincoln by an unqualified "Lincoln", nor is he a topic of outsized reader interest, so he is listed only at the Lincoln (surname) anthroponymy article. Conversely, it's reasonable to expect that a lot of readers might want to navigate to Andrew Lincoln because of consistently measurable outsized usage, so he should be listed at both.

footnote here: All-time page views for all entries listed at Lincoln (name) All time monthly page views comparing the aforementioned 'Lincoln' topics

This does not necessarily prejudice primary topic considerations. For example, many highly notable people are called Herb, but typing in Herb gets you an article on plants. However, as the usage statistics show the interest in Herb Alpert to be typically exceeding the reader interest in the plant topic, the hatnote at Herb or the list at Herb (disambiguation) may include a link to that biography, next to the links to Herb (surname) and Herb (given name), where articles on people named "Herb" are listed. Consensus among editors determines if an article should be listed on the disambiguation page.

footnote here: All-time page views for all entries listed at Herb (given name) All time monthly page views comparing the aforementioned 'Herb' topics

--Joy (talk) 11:25, 4 June 2024 (UTC)

This covers the most pressing topic of #Wikipedia talk:Content assessment#Request for comment. The other issue, whether to encourage keeping anthroponymy lists merged, needs more discussion because it may detract from the goals of this - e.g. if we squash a short list like Herb (surname) back into Herb (disambiguation), and don't squash the given name list, that may give undue prominence to people with the surname. We already have a problem with the long tail of ambiguity cluttering disambiguation pages. I'd prefer to deal with the complexities of that separately. --Joy (talk) 11:29, 4 June 2024 (UTC)

I've applied this change, but something confused me with note formatting in https://en.wikipedia.org/w/index.php?title=Wikipedia:Disambiguation&oldid=1227556919#Lists_of_names - if someone could render assistance, I'd appreciate it.

I also swapped out Andrew Lincoln for Jon Hamm, because the difference in reader traffic is even more stark there. --Joy (talk) 13:30, 6 June 2024 (UTC)

I've reverted these changes. So much detail is couterproductive per WP:CREEP. It also changes the default to having WP:PTM names on dab pages from current general consensus that they are exceptions. Most PTM name lists belong in anthroponymy articles. Station1 (talk) 19:30, 6 June 2024 (UTC)

@Station1 you might have missed the reams of data I provided in discussions above and linked in the archive, explaining how readers looking for biographies are being so badly served by our navigation. I'd appreciate it if you could review it.

I think this idea of a general consensus that people's names are just partial title matches, as opposed to instances of actual ambiguity, are not based on an accurate observation of reader behavior, rather it appears more based on an opinion of a relatively small group of us editors. By moving links to biographies behind another click, and by not helping readers to the most common navigation choices, we've been artificially modifying reader navigation as opposed to enabling it.

In a few recently documented examples such as Tito, Charlotte and Luka, hints of their actual behavior still came through. --Joy (talk) 20:26, 6 June 2024 (UTC)

The trouble with Tito (disambiguation), for example, is that the 3 or 4 things actually called Tito are buried at the bottom of a huge list of people who aren't named solely Tito. Station1 (talk) 20:43, 6 June 2024 (UTC)

Yes, exactly this. That one or a very few might be looked as a mononym is not a good reason to abandon the current guidance. older ≠ wiser 20:54, 6 June 2024 (UTC)

I don't know what you mean, because the proposed wording doesn't talk of mononyms, rather it encourages thinking about outsized usage and long-term significance. A mononymous usage of a name by a relatively minor person should not be prioritized over a normal usage of a name by a relatively major person. (Or in turn by relatively minor toponyms, fictional characters and other items that habitually clutter our disambiguation lists.) IOW we should start thinking about ambiguity in navigation not just through what is technically ambiguous, but what is practically ambiguous for the average English reader, and how the compendium of knowledge about an ambiguous term is most effectively presented to them. --Joy (talk) 22:01, 6 June 2024 (UTC)

I'm sorry, but this is just continuing on the same "mononymity rules!" party line without evidence... I had a look in the clickstreams, and found in November '20 that the link to the acronym, "TITO", was clicked at least 20 times, in the same month when the 2019 film was clicked 10 times. The link to TITO has always been in the last section, See also, which is below the film section. No other entry from the film section crossed the anonymization threshold that month, but Jackson (15), Ortiz (11) and two of the footballers +did (11 and 12 resp.). The footballers are in the top mononymous section, while the other two are in the general sections. Maybe it's more likely that we forced the readers looking for the Jacksons and the Ortizes to have to comb through the general lists to find them, and the number of them who gave up and went back to Google might be higher than the number looking for the films? --Joy (talk) 21:47, 6 June 2024 (UTC)

Dab pages are not search engines, and were never meant to be search engines. They are necessary navigation aids where there are two or more topics that would or could have identical or nearly identical titles. That's because of the technical impossibility of two articles having the same title. They were always intended to be as short as possible, in order to be as easy to use as possible. WP has a search engine for people who can't remember or spell someone's last name, which is far superior to anything human editors could put on a page. We also have "intitle" and similar templates to stick on the bottom of dab pages when useful. An occasional IAR exception for a very popular easily misspelled topic is fine, but we shouldn't turn dab pages into inferior search engines. Station1 (talk) 22:24, 6 June 2024 (UTC)

Yes, and there are readers who think a person with the name Foo Bar has an identical name to a person with the name Foo Baz or Foo Quux, because that's how human names work.

But even so, regardless of this generic argument, I still don't see how the proposed wording doesn't match with what you described in your last sentence. Even if you think Abraham Lincoln isn't an identical enough match for Lincoln, you allow it to be listed already, because whatever, people use that like that. It turns the dab page into an inferior search engine, but you see the usefulness. Likewise, allowing Jon Hamm to be listed at Hamm would be useful, as the same thing happens. The Lincoln biography is read by 400 thousand people a month, while the comparable city articles are read by 20 and 15 thousand, respectively. The Hamm biography is read by 200 thousand people a month, while the comparable city article is read by 2 thousand. In the latter case it's a difference of 100 : 1, we're not talking subtle nuance here, and it's significantly larger than the 10 : 1 difference in the former.

Fundamentally, the encyclopedia describes, it does not prescribe. Making huge contingents of readers jump through hoops because we don't feel like they're using these words the right way - is the latter. --Joy (talk) 06:57, 7 June 2024 (UTC)

Lincoln is often referred to as Lincoln, and could conceivably be a PRIMARYREDIRECT like Einstein or Churchill, so belongs on the Lincoln dab page. To my knowledge Jon Hamm is not referred to as just Hamm. Even so, I wouldn't object to adding him to the dab page per WP:IAR, but it would be a bad idea to add the 18 other people at Hamm (surname). - Station1 (talk) 17:06, 7 June 2024 (UTC)

With these kinds of numbers, it seems probable that even the amount of accidental or cursory references to him as just Hamm are statistically relevant.

No argument about not listing the other 18 people there, absolutely, that's why the phrasing was very careful to weed that out. Did you notice the part that said In cases where there are distinctly popular entries in such lists, such as those with substantially large usage or long-term significance compared to the rest of the list. Is that not strict enough? --Joy (talk) 08:41, 8 June 2024 (UTC)

Since this discussion died down, the same kind of problems have cropped up in a few more places, for example at "Dina", described at Talk:Dina (disambiguation), and at Wikipedia talk:WikiProject Anthroponymy#Splitting lists of names articles when clearly different names. --Joy (talk) 17:42, 26 June 2024 (UTC)

BTW Talk:Julius is another such case. We have it on the record that nobody calls him just Julius, yet when we started presenting readers with the choice to click him or to click mononymously named people, the readers consistently choose him. :) --Joy (talk) 08:53, 18 July 2024 (UTC)

how many months it takes for disambiguation usage statistics to change

I'd like to point out an aspect of #on what statistics should look like for hatnotes, primary redirects, primary topics that is becoming increasingly clear - we don't need a lot of time to detect changes in readership navigation patterns. Usually whatever happened with one month after a change was quite indicative of the pattern of traffic going forward, there's never a serious fluctuation.

We should use this to our advantage - to be more willing to experiment for e.g. two months, because that will usually suffice to get measurements and decide if the change was good or not. --Joy (talk) 18:16, 10 May 2024 (UTC)

There's another corollary to this - our traffic patterns are sometimes remarkably stable. At times, it's actually too stable - some of these examples defy a logical expectation of organic variety in reader interest. It makes me think that most of the traffic is heavily moderated by external search engine algorithms, and the little variety that we do see is actually organic traffic. --Joy (talk) 22:17, 20 July 2024 (UTC)

Question: "/" in parenthetical disambig?

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)

Proposal for change in determining primary topic

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 Wikipedia 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)

Is this a disambiguation page?

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)" [Malaysia] and "Turtle Islands" [Philippines]. (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)

Aliasing

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)

What does "under certain circumstances" mean in WP:DABSISTER

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 Wikipedia 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)

Proposed definition using the existence of quality control policies of Veifyability, Notability, and Neutrality

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 Wikipedia but an article exists in a different language Wikipedia, 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.

Standards of quality for the Wikipedias in the available languages

Wikipedia name in English Wikipedia name in native language Language Script (ISO 15924 code) Language code/prefix Verifyability Policy Notability Policy Neutrality Policy English Wikipedia English Wikipedia English Latn en Y link Y link Y link Simple English Wikipedia Simple English Wikipedia Simple English Latn simple Y link Y link Y link Abkhaz Wikipedia Аԥсуа авикипедиа (Apsua avikipedia) Abkhaz Cyrl ab N N N Acehnese Wikipedia Wikipèdia bahsa Acèh Acehnese Latn ace N N N Adyghe Wikipedia Адыгэ Википедие (Adıgə Vikipedie) Adyghe Cyrl ady N N N Afrikaans Wikipedia Afrikaanse Wikipedia Afrikaans Latn af Y link Y link Y link Albanian Wikipedia Wikipedia shqip Albanian Latn sq Y link Y link Y link Alemannic Wikipedia Alemannische Wikipedia Alemannic German Latn als N N N Southern Altai Wikipedia Тӱштӱк алтай Википедия (Tüštük altay Vikipediya) Southern Altai Cyrl alt N N N Amharic Wikipedia አማርኛ ዊኪፔዲያ (Amarəñña wikipediya) Amharic Ethi am N Y link Y link Amis Wikipedia Wikipitiya 'Amis Amis Latn ami N N N Angika Wikipedia विकिपीडिया Angika Deva anp N N N Arabic Wikipedia ويكيبيديا العربية (Wīkībīdiyā al-ʿarabiyya) Arabic Arab ar Y link Y link Y link Aragonese Wikipedia Biquipedia en aragonés Aragonese Latn an N Y link Y link Armenian Wikipedia Հայերեն Վիքիպեդիա (Hayeren Vikʿipedia) Armenian Armn hy Y link Y link Y link Aromanian Wikipedia Wikipedia pri Armâneaști Aromanian Latn roa-rup N N N Franco-Provençal Wikipedia Vouiquipèdia en arpetan Franco-Provençal Latn frp N N N Assamese Wikipedia অসমীয়া ৱিকিপিডিয়া (Ôxômiya wikipidiya) Assamese Beng as Y link Y link Y link Asturian Wikipedia Wikipedia n'asturianu Asturian Latn ast Y link N Y link Atayal Wikipedia Wikibitia na Tayal Atayal Latn tay N N N Atikamekw Wikipedia Atikamekw Wikipetcia Atikamekw Latn atj N N N Avar Wikipedia Авар Википедия (Avar Vikipedija) Avar Cyrl av N N N Awadhi Wikipedia अवधी विकिपीडिया (Avadhī vikipīḍiyā) Awadhi Deva awa N N N Aymara Wikipedia Aymar Wikipidiya Aymara Latn ay N N N Azerbaijani Wikipedia Azərbaycanca Vikipediya Azerbaijani Latn az Y link Y link Y link Balinese Wikipedia Wikipédia Basa Bali (ᬯᬶᬓᬶᬧᬾᬤᬶᬬ ᬩᬲᬩᬮᬶ) Balinese Latn ban Bambara Wikipedia Wikipedi Bamanankan Bambara Latn bm Banjarese Wikipedia Wikipidia basa Banjar Banjarese Latn bjn Bashkir Wikipedia Башҡорт Википедияһы (Başķort Vikipediya) Bashkir Cyrl ba Basque Wikipedia Euskarazko Wikipedia Basque Latn eu Toba Batak Wikipedia Wikipedia Batak Toba Toba Batak Latn bbc Bavarian Wikipedia Boarische Wikipedia Bavarian Latn bar Belarusian Wikipedia Беларуская Вікіпедыя (Bielaruskaja Vikipiedyja) Belarusian (official Narkamaŭka orthography) Cyrl be Belarusian Wikipedia (Classical) Беларуская Вікіпэдыя (Bielaruskaja Vikipiedyja) Belarusian (Taraškievica orthography) Cyrl be-tarask Bengali Wikipedia বাংলা উইকিপিডিয়া (Bangla uikipiḍiẏa) Bengali Beng bn Betawi Wikipedia Wikipédi basa Betawi Betawi Latn bew Bhojpuri Wikipedia बिहारी विकिपीडिया (Bihārī vikipīḍiyā) Bihari (Bhojpuri) Deva bh Bishnupriya Manipuri Wikipedia বিষ্ণুপ্রিয়া মণিপুরী উইকিপিডিয়া (Bişnupriya mônipuri u'ikipiḍiẏā) Bishnupriya Manipuri Beng bpy Bislama Wikipedia Wikipedia long Bislama Bislama Latn bi Bosnian Wikipedia Wikipedia na bosanskom jeziku Bosnian Latn bs Breton Wikipedia Wikipedia e brezhoneg Breton Latn br Buginese Wikipedia ᨓᨗᨀᨗᨄᨙᨉᨗᨕ ᨅᨔ ᨕᨘᨁᨗ (Wikipedia basa Ugi) Buginese Bugi bug Bulgarian Wikipedia Българоезична Уикипедия (Bǎlgaroezična Uikipediya) Bulgarian Cyrl bg Burmese Wikipedia မြန်မာဝီကီပီးဒီးယား (Mranma wikipi:di:ya:) Burmese Mymr my Catalan Wikipedia Viquipèdia en català Catalan Latn ca Cebuano Wikipedia Wikipedya sa Sinugboanon Cebuano Latn ceb Central Bikol Wikipedia Wikipedyang Bikol Sentral Central Bikol Latn bcl Chamorro Wikipedia Wikipedia Chamoru Chamorro Latn ch Chavacano Wikipedia Chavacano Wikipedia Zamboanga Chavacano Latn cbk-zam Chechen Wikipedia Нохчийн Википеди (Noxçiyn Wikipedi) Chechen Cyrl ce Cherokee Wikipedia ᏫᎩᏇᏗᏯ ᏣᎳᎩ (Wigiquediya tsalagi) Cherokee Cher chr Cheyenne Wikipedia Vekepete'a Tsėhésenėstsestȯtse Cheyenne Latn chy Chewa Wikipedia Wikipedia Chichewa Chewa Latn ny Old Church Slavonic Wikipedia Словѣньска Википєдїꙗ (Slověnĭska Vikipedija) Old Church Slavonic Cyrs cu Chuvash Wikipedia Чăваш Википедийĕ (Russian-based: Căvaš Vikipedijĕ, Turkish-based: Çovaş Vikipyediyö) Chuvash Latn cv Cornish Wikipedia Wikipedya Kernowek Cornish Latn kw Corsican Wikipedia Corsipedia or Wikipedia in lingua corsa Corsican Latn co Cree Wikipedia ᐎᑭᐱᑎᔭ ᓀᐦᐃᔭᐍᐏᐣ (Wikipitiya nēhiyawēwin) Cree Cans cr Crimean Tatar Wikipedia Qırımtatarca Vikipediya Crimean Tatar Latn crh Croatian Wikipedia Hrvatska Wikipedija Croatian Latn hr Czech Wikipedia Česká Wikipedie Czech Latn cs Dagbani Wikipedia Wikipidia Dagbani Dagbani Latn dag Danish Wikipedia Dansk Wikipedia Danish Latn da Maldivian Wikipedia ދިވެހި ވިކިޕީޑިޔާ (Dhivehi vikipīḍiyā) Maldivian Thaa dv Dinka Wikipedia Wikipedia Thuɔŋjäŋ Dinka Latn din Doteli Wikipedia डोटेली विकिपिडिया (Ḍōṭēlī vikipiḍiyā) Doteli Deva dty Dutch Low Saxon Wikipedia Nedersaksische Wikipedie Dutch Low Saxon Latn nds-nl Dutch Wikipedia Nederlandstalige Wikipedia Dutch Latn nl Dzongkha Wikipedia རྫོང་ཁ་ཝེ་ཁེ་རིག་མཛོད (Rdzong kha we khe rig mdzod) Dzongkha Tibt dz Egyptian Arabic Wikipedia ويكيپيديا مصرى (Wīkībīdiyā maṣri) Egyptian Arabic Arab arz Emilian–Romagnol Wikipedia Emiliàn e rumagnòl Vichipedèia Emilian–Romagnol Latn eml Erzya Wikipedia Эрзянь Википедия (Erzäń Vikipedija) Erzya Cyrl myv Esperanto Wikipedia Vikipedio en Esperanto Esperanto Latn eo Estonian Wikipedia Eestikeelne Vikipeedia Estonian Latn et Ewe Wikipedia Wikipiɖia Eʋegbe Ewe Latn ee Extremaduran Wikipedia Güiquipeya en estremeñu Extremaduran Latn ext Fante Wikipedia Fante Wikipedia Fante Latn fat Gurene Wikipedia Gurenɛ Wikipedia Farefare (Gurene) Latn gur Faroese Wikipedia Føroysk Wikipedia Faroese Latn fo Fiji Hindi Wikipedia Fiji Baat Wikipedia Fiji Hindi Latn hif Fijian Wikipedia Vaka-Viti Wikipedia Fijian Latn fj Finnish Wikipedia Suomenkielinen Wikipedia Finnish Latn fi Fon Wikipedia Wikipedya ɖò Fɔngbemɛ Fon Latn fon French Wikipedia Wikipédia en français French Latn fr Friulian Wikipedia Vichipedie par furlan Friulian Latn fur Fula Wikipedia Wikipedia Fulfude Fula Latn ff Gagauz Wikipedia Gagauzca Vikipediya Gagauz Latn gag Galician Wikipedia Galipedia or Wikipedia en galego Galician Latn gl Georgian Wikipedia ქართული ვიკიპედია (Kartuli vik’ip’edia) Georgian Geor ka German Wikipedia Deutschsprachige Wikipedia German Latn de Spanish Wikipedia Wikipedia en español Spanish Latn es Ghanaian Pidgin Wikipedia Ghanaian Pidgin Wikipedia Ghanaian Pidgin English Latn gpe Kikuyu Wikipedia Wikipedia Gĩgĩkũyũ Kikuyu Latn ki Gilaki Wikipedia گیلکی ویکیپدیاٰ (Giləki vikipөdiya) Gilaki Arab glk Konkani Wikipedia कोंकणी विकिपीडिया (Konknni Wikipidia) (ಕೊಂಕ್ಣಿ ವಿಕಿಪೀಡಿಯಾ) Konkani (Goan Konkani) Deva/Latn/Knda gom Gorontalo Wikipedia Wikipedia bahasa Hulontalo Gorontalo Latn gor Gothic Wikipedia 𐌲𐌿𐍄𐌹𐍃𐌺 𐍅𐌹𐌺𐌹𐍀𐌰𐌹𐌳𐌾𐌰 (Gutisk wikipaidja) Gothic Goth got Greek Wikipedia Ελληνική Βικιπαίδεια (Ellinikí Vikipaídeia) Greek Grek el Greenlandic Wikipedia Kalaallisut Wikipedia Greenlandic Latn kl Guarani Wikipedia Vikipetã avañe'ẽme Guarani Latn gn Guianan Creole Wikipedia Wikipédja an kriyòl gwiyannen French Guianese Creole Latn gcr Gujarati Wikipedia ગુજરાતી વિકિપીડિયા (Gujrātī vikipīḍiyā) Gujarati Gujr gu Gun Wikipedia Gungbe Wikipedia Gun Latn guw Haitian Creole Wikipedia Wikipedya kreyòl ayisyen Haitian Creole Latn ht Hausa Wikipedia Wikipedia Hausa Hausa Latn ha Hawaiian Wikipedia Hawai‘i Wikipikia Hawaiian Latn haw Hebrew Wikipedia ויקיפדיה העברית (Vikipedya ha-ivrit) Hebrew Hebr he Hill Mari Wikipedia Кырык марла Википеди (Kyryk marla Vikipedi) Hill Mari Cyrl mrj Hindi Wikipedia हिन्दी विकिपीडिया (Hindī vikipīḍiyā) Hindi Deva hi Hungarian Wikipedia Magyar Wikipédia Hungarian Latn hu Icelandic Wikipedia Íslenska Wikipedia Icelandic Latn is Ido Wikipedia Wikipedio en Ido Ido Latn io Igala Wikipedia Wikipídiya Igala Igala Latn igl Igbo Wikipedia Wikipedia Igbo Igbo Latn ig Ilocano Wikipedia Wikipedia nga Ilokano Ilocano Latn ilo Aramaic Wikipedia ܘܝܩܝܦܕܝܐ ܠܫܢܐ ܣܘܪܝܝܐ (Wīqīpedyāʾ leššānā suryāyā) Aramaic (Syriac) Syrc arc Inari Sámi Wikipedia Anarâškielâlâš Wikipedia Inari Sámi Latn smn Indonesian Wikipedia Wikipedia bahasa Indonesia Indonesian Latn id Ingush Wikipedia Гӏалгӏай Википеди (Ghalghaj Vikipedi) Ingush Cyrl inh Interlingua Wikipedia Wikipedia in interlingua Interlingua Latn ia Interlingue Wikipedia Wikipedia in Interlingue Interlingue Latn ie Inuktitut Wikipedia ᐃᓄᒃᑎᑐᑦ ᐊᕆᐅᙵᐃᐹ (Uikipitia inuktitut) Inuktitut Cans iu Iñupiaq Wikipedia Uiqipitia Iñupiatun Iñupiaq Latn ik Irish Wikipedia Vicipéid na Gaeilge Irish Latn ga Italian Wikipedia Wikipedia in italiano Italian Latn it Jamaican Patois Wikipedia Jumiekan Patwa Wikipidia Jamaican Patois Latn jam Japanese Wikipedia ウィキペディア日本語版 (Wikipedia nihongo-ban) Japanese Jpan ja Javanese Wikipedia Wikipedia basa Jawa Javanese Latn jv Banyumasan Wikipedia Wikipédia basa Banyumasan Banyumasan Latn map-bms Kabardian Wikipedia Адыгэбзэ Уикипедиэ (Adıgəbzə Wikipediă) Kabardian Cyrl kbd Kabiye Wikipedia Wikipediya kabɩyɛ Kabiye Latn kbp Kabyle Wikipedia Wikipedia taqbaylit Kabyle Latn kab Dusun Wikipedia Wikipedia Dusun Dusun Latn dtp Kannada Wikipedia ಕನ್ನಡ ವಿಕಿಪೀಡಿಯ (Kannaḍa vikipīḍiya) Kannada Knda kn Kapampangan Wikipedia Wikipediang Kapampángan Kapampangan Latn pam Karachay-Balkar Wikipedia Къарачай-Малкъар Википедия (Qaraçay-Malqar Wikipédiya) Karachay-Balkar Cyrl krc Karakalpak Wikipedia Qaraqalpaq Wikipediası Karakalpak Latn kaa Kashmiri Wikipedia کٲشُر وِکیٖپیٖڈیا (Kạ̄śur vikipīḍiyā) Kashmiri Arab ks Kashubian Wikipedia Kaszëbskô Wikipedijô Kashubian Latn csb Kazakh Wikipedia Қазақша Уикипедия (Qazaqşa Wïkïpedïya) (قازاقشا ۋىيكىيپەدىييا) Kazakh Cyrl/Latn/Arab kk Khmer Wikipedia វិគីភីឌាភាសាខ្មែរ (Vikiiphiidiaa phiăsaa khmae) Khmer Khmr km Kinyarwanda Wikipedia Wikipediya mu Ikinyarwanda Kinyarwanda Latn rw Kirundi Wikipedia Wikipediya mu Ikirundi Kirundi Latn rn Komi-Permyak Wikipedia Перем коми Википедия (Perem komi Vikipedija) Komi-Permyak Cyrl koi Komi Wikipedia Коми Википедия (Komi Vikipedija) Komi Cyrl kv Kongo Wikipedia Wikipedia kikôngo Kongo Latn kg Korean Wikipedia 한국어 위키백과 (Han-gugeo wikibaekgwa) Korean Hang ko Kotava Wikipedia Wikipedia men Kotava Kotava Latn avk Kurdish Wikipedia Wîkîpediya kurdî (ویکیپەدیا کوردی) Kurdish (Kurmanji) Latn/Arab ku Kusaal Wikipedia Wikipiidia Kʋsaal Kusaal Latn kus Kyrgyz Wikipedia Кыргыз Википедиясы (Kırgız Wikipediya) Kyrgyz Cyrl ky Ripuarian Wikipedia Wikkipedija en Ripoarisch Platt Ripuarian Latn ksh Ladin Wikipedia Wikipedia per ladin Ladin Latn lld Judaeo-Spanish Wikipedia Vikipedya en lingua Judeo-Espanyola Judaeo-Spanish Latn lad Lak Wikipedia Лакку мазрал Википедия (Lak:u mazral Vikipediaˤ) Lak Cyrl lbe Lao Wikipedia ວິກິພີເດຍ ພາສາລາວ (Wi ki phī dīa phasa lao) Lao Laoo lo Latgalian Wikipedia Vikipedeja latgaļu volūdā Latgalian Latn ltg Latin Wikipedia Vicipaedia Latina Latin Latn la Latvian Wikipedia Vikipēdija latviešu valodā Latvian Latn lv Lezgian Wikipedia Лезги Википедия (Lezgi Vikipediä) Lezgian Cyrl lez Ligurian Wikipedia Wikipedia Ligure Ligurian Latn lij Limburgish Wikipedia Limburgse Wikipedia Limburgish Latn li Lingala Wikipedia Lingála Wikipedia Lingala Latn ln Lingua Franca Nova Wikipedia Vicipedia en lingua franca nova Lingua Franca Nova Latn lfn Classical Chinese Wikipedia 文言維基大典 (Wéijī dàdiǎn wényán) Classical Chinese Hant zh-classical Lithuanian Wikipedia Lietuviškoji Vikipedija Lithuanian Latn lt Livvi-Karelian Wikipedia Livvinkarjalan Wikipedii Livvi-Karelian Latn olo Lojban Wikipedia ni'o la .uikipedi'as. pe lo jbobau Lojban Latn jbo Lombard Wikipedia Wikipedia in lombard Lombard Latn lmo Low German Wikipedia Plattdüütsche Wikipedia Low German Latn nds Lower Sorbian Wikipedia Dolnoserbska wikipedija Lower Sorbian Latn dsb Luganda Wikipedia Wikipediya Luganda Luganda Latn lg Luxembourgish Wikipedia Wikipedia op Lëtzebuergesch Luxembourgish Latn lb Macedonian Wikipedia Македонска Википедија (Makedonska Vikipedija) Macedonian Cyrl mk Madurese Wikipedia Wikipèḍia bhâsa Madhurâ Madurese Latn mad Maithili Wikipedia मैथिली विकिपिडिया (Maithilī vikipiḍiyā) Maithili Deva mai Malagasy Wikipedia Wikipedia amin'ny teny malagasy Malagasy Latn mg Malay Wikipedia Wikipedia Bahasa Melayu (ويکيڤيديا بهاس ملايو) Malay Latn ms Malayalam Wikipedia മലയാളം വിക്കിപീടിയ (Malayāḷaṃ vikkipīṭiya) Malayalam Mlym ml Maltese Wikipedia Wikipedija Malti Maltese Latn mt Manx Wikipedia Wikipedia yn Gaelg Manx Latn gv Marathi Wikipedia मराठी विकिपीडिया (Marāṭhī vikipīḍiyā) Marathi Deva mr Mazanderani Wikipedia مازرونی ویکی‌پدیا (Mazandarani vikipedi) Mazanderani Arab mzn Meadow Mari Wikipedia Олык Марий Википедий (Olyk Marij Vikipedij) Meadow Mari Cyrl mhr Meitei Wikipedia ꯃꯤꯇꯩꯂꯣꯟ ꯋꯤꯀꯤꯄꯦꯗꯤꯌꯥ (Meeteilon weekeepaydeeya) Meitei Mtei mni Minangkabau Wikipedia Wikipedia Minangkabau Minangkabau Latn min Mingrelian Wikipedia მარგალური ვიკიპედია (Margaluri vik’ip’edia) Mingrelian Geor xmf Mirandese Wikipedia Biquipédia an lhéngua mirandesa Mirandese Latn mwl Moksha Wikipedia Мокшень Википедиесь (Mokšenj Vikipedijesʹ) Moksha Cyrl mdf Mon Wikipedia ဝဳကဳပဳဒဳယာမန် (Wīkīpīdīya mawn) Mon Mymr mnw Mongolian Wikipedia Монгол Википедиа (Mongol Vikipyedia) Mongolian Cyrl mn Moroccan Arabic Wikipedia ويكيبيديا المغربية (Wīkībīdiyā maḡribiyy) Moroccan Arabic Arab ary Māori Wikipedia Wikipedia Māori Māori Latn mi N'Ko Wikipedia ߥߞߌߔߘߋߞߎ ߒߞߏ (Wkipdeku n'ko) N'Ko Nkoo nqo Nahuatl Wikipedia Huiquipedia nāhuatlahtōlcopa Nahuatl Latn nah Navajo Wikipedia Wikiibíídiiya Dinék'ehjí Navajo Latn nv Tarantino Wikipedia Uicchipèdie tarandíne Tarantino Latn roa-tara Neapolitan Wikipedia Wikipedia napulitana Neapolitan Latn nap Nepali Wikipedia नेपाली विकिपिडिया (Nepālī vikipiḍiyā) Nepali Deva ne Newar Wikipedia विकिपिडियाय् लसकुस (Vikipiḍiyāya lasakūsa) Newar Deva new Nias Wikipedia Wikipedia Li Niha Nias Latn nia Nigerian Pidgin Wikipedia Naijá Wikipedia Nigerian Pidgin Latn pcm North Frisian Wikipedia Nordfriisk Wikipedia North Frisian Latn frr Northern Sámi Wikipedia Davvisámegiel Wikipedia Northern Sámi Latn se Northern Sotho Wikipedia Wikipedia Sesotho sa Leboa Northern Sotho Latn nso Norwegian Wikipedia Norsk Wikipedia Norwegian (Bokmål) Latn no Novial Wikipedia Wikipedie in novial Novial Latn nov Norwegian (Nynorsk) Wikipedia Norsk (Nynorsk) Wikipedia Norwegian (Nynorsk) Latn nn Occitan Wikipedia Wikipèdia en occitan Occitan Latn oc Odia Wikipedia ଓଡ଼ିଆ ଉଇକିପିଡ଼ିଆ (Oṛiā uikipiṛiā) Odia Orya or Kalmyk Wikipedia Хальмг Бикипеди (Haľmg Vikipedi) Kalmyk Oirat Cyrl xal Old English Wikipedia Engliscan Ƿikipǣdia Old English Latn ang Oromo Wikipedia Oromoo Wikipedia Oromo Latn om Ossetian Wikipedia Ирон Википеди (Iron Vikipedi) Ossetian Cyrl os Pa'O Wikipedia ပအိုဝ်ႏဝီခီပီးဒီးယား (Pǎʼǒ wikhipi:di:ya) Pa'O Mymr blk Paiwan Wikipedia wikipidiya nua pinayuanan Paiwan Latn pwn Palatine German Wikipedia Pälzisch Wikipedia Palatine German Latn pfl Pali Wikipedia पालि विकिपीडिया (Pāli vikipīḍiyā) Pali Deva pi Pangasinan Wikipedia Wikipedia Pangasinan Pangasinan Latn pag Papiamento Wikipedia Wikipedia na papiamentu Papiamento Latn pap Pashto Wikipedia پښتو ويکيپېډيا (Pax̌tó wīkīpeḍyā) Pashto Arab ps Pennsylvania Dutch Wikipedia Pennsilfaanisch-Deitsche Wikipedelche Pennsylvania Dutch Latn pdc Persian Wikipedia ویکی‌پدیای فارسی (Vikipediā-ye Fārsi) Persian Arab fa Picard Wikipedia Wikipédia in lingue picarde Picard Latn pcd Piedmontese Wikipedia Wikipedia an piemontèisa Piedmontese Latn pms Norfuk Wikipedia Norfuk Wikkapedya Norfuk Latn pih Polish Wikipedia Polskojęzyczna Wikipedia Polish Latn pl Pontic Wikipedia Ποντιακόν Βικιπαίδεια (Pontiakón Bikipaídeia) Pontic Greek Grek pnt Portuguese Wikipedia Wikipédia em português Portuguese Latn pt Western Punjabi Wikipedia پنجابی وکیپیڈیا (Pañjābī vikīpīḍīā) Western Punjabi Arab pnb Punjabi Wikipedia ਪੰਜਾਬੀ ਵਿਕੀਪੀਡੀਆ (Pañjābī vikīpīḍīā) Punjabi Guru pa Quechua Wikipedia Qhichwa Wikipidiya Quechua (Southern Quechua) Latn qu Romanian Wikipedia Wikipedia în limba română Romanian Latn ro Romansh Wikipedia Vichipedia rumantscha Romansh Latn rm Buryat Wikipedia Буряад Википеэди (Buryaad Vikipjeedi) Buryat (Russia Buriat) Cyrl bxr Russian Wikipedia Русская Википедия (Russkaya Vikipediya) Russian Cyrl ru Rusyn Wikipedia Русиньска Вікіпедія (Rusîn'ska Vikipedija) Rusyn Cyrl rue Sakizaya Wikipedia Wikipitiya nu Sakizaya Sakizaya Latn szy Samoan Wikipedia Wikipedia gagana Sāmoa Samoan Latn sm Samogitian Wikipedia Žemaitėška Vikipedėjė Samogitian Latn bat-smg Sango Wikipedia Wïkïpêdïyäa na Sängö Sango Latn sg Sanskrit Wikipedia संस्कृतविकिपीडिया (Saṃskṛta vikipīḍiyā) Sanskrit Deva sa Santali Wikipedia ᱥᱟᱱᱛᱟᱲᱤ ᱣᱤᱠᱤᱯᱤᱰᱤᱭᱟ (Santaṛi wikipiḍiya) Santali Olck sat Saraiki Wikipedia سرائیکی ویٖکیٖپیڈیا (Sarā'īkī vikipīḍiyā) Saraiki Arab skr Sardinian Wikipedia Wikipedia in sardu Sardinian Latn sc Saterland Frisian Wikipedia Seelterfräiske Wikipedia Saterland Frisian Latn stq Scots Wikipedia Scots Wikipædia Scots Latn sco Scottish Gaelic Wikipedia Uicipeid na Gàidhlig Scottish Gaelic Latn gd Seediq Wikipedia Seediq Wikipidiya Seediq Latn trv Serbian Wikipedia Википедија на српском језику (Vikipedija na srpskom jeziku) Serbian Cyrl/Latn sr Serbo-Croatian Wikipedia Srpskohrvatska Wikipedija (Српскохрватска Википедија) Serbo-Croatian Latn sh Shona Wikipedia Wikipedhiya chiShona Shona Latn sn Shan Wikipedia ဝီႇၶီႇၽီးတီးယႃးတႆး (Wiː-kʰiː-pʰiː-tiː-jaɑː- táy) Shan Mymr shn Sicilian Wikipedia Wikipedia ’n sicilianu Sicilian Latn scn Silesian Wikipedia Ślůnsko Wikipedyjo Silesian Latn szl Sindhi Wikipedia سنڌي وڪيپيڊيا (Sindhi wikipidia) Sindhi Arab sd Sinhala Wikipedia සිංහල විකිපීඩියා (Siṁhala wikipīḍiyā) Sinhala Sinh si Slovak Wikipedia Slovenská Wikipedia Slovak Latn sk Slovene Wikipedia Slovenska Wikipedija Slovene Latn sl Somali Wikipedia Soomaali Wikipedia Somali Latn so Sorani Kurdish Wikipedia ویکیپیدیای کوردیی سۆرانی (Wîkîpîdiyay Kurdî Soranî) Kurdish (Sorani) Arab ckb Sotho Wikipedia Wikipedia Sesotho Sotho Latn st South Azerbaijani Wikipedia تورکجه ویکی‌پدیا (Azərbaycanca Vikipediya) South Azerbaijani Arab azb Dagaare Wikipedia Dagaare Wikipiideɛ Dagaare Latn dga Sranan Tongo Wikipedia Sranan Wikipedia Sranan Tongo Latn srn Moroccan Amazigh Wikipedia ⵡⵉⴽⵉⴱⵉⴷⵢⴰ ⵜⴰⵎⴰⵣⵉⵖⵜ ⵜⴰⵏⴰⵡⴰⵢⵜ (Wikibidya tamaziɣt tanawayt) Standard Moroccan Amazigh Tfng zgh Tibetan Wikipedia བོད་ཡིག་གི་ཝེ་ཁེ་རིག་མཛོད (Wylie: Bod yig gi we khe rig mdzod) Lhasa Tibetan Tibt bo Sundanese Wikipedia Wikipédia basa Sunda Sundanese Latn su Swahili Wikipedia Wikipedia ya Kiswahili Swahili Latn sw Swazi Wikipedia Wikipedia siSwati Swazi Latn ss Swedish Wikipedia Svenskspråkiga Wikipedia Swedish Latn sv Shilha Wikipedia Wikipidya taclḥiyt (ⵡⵉⴽⵉⵒⵉⴷⵢⴰ ⵜⴰⵛⵍⵃⵉⵜ) Shilha Latn/Tfng shi Tagalog Wikipedia Wikipediang Tagalog Tagalog Latn tl Tahitian Wikipedia Vitipetia Reo Tahiti Tahitian Latn ty Tajik Wikipedia Википедияи Тоҷикӣ (Vikipedijai Toçikī) Tajik Cyrl/Latn tg Talysh Wikipedia Tolyšə Vikipedijə Talysh Latn tly Tamil Wikipedia தமிழ் விக்கிபீடியா (Tamiḻ vikkippīṭiyā) Tamil Taml ta Tatar Wikipedia Татар Википедиясе (Tatar Wikipediäse) Tatar Cyrl tt Telugu Wikipedia తెలుగు వికీపీడియా (Telugu vikīpīḍiyā) Telugu Telu te Tetum Wikipedia Wikipédia iha lia-tetun Tetum Latn tet Thai Wikipedia วิกิพีเดียภาษาไทย (Wi-ki-phi-dia pha-sa thai) Thai Thai th Tigrinya Wikipedia ዊኪፐድያ ብትግርኛ (Wikipädya bətəgrəñña) Tigrinya Ethi ti Tok Pisin Wikipedia Wikipedia long Tok Pisin Tok Pisin Latn tpi Tongan Wikipedia Wikipedia ʻi lea fakatonga Tongan Latn to Tsonga Wikipedia Wikipediya Xitsonga Tsonga Latn ts Tswana Wikipedia Wikipedia Setswana Tswana Latn tn Tulu Wikipedia ತುಳು ವಿಕಿಪೀಡಿಯ (Tuḷu vikipīḍiya) Tulu Knda tcy Tumbuka Wikipedia Wikipedia Chitumbuka Tumbuka Latn tum Turkish Wikipedia Türkçe Vikipedi Turkish Latn tr Turkmen Wikipedia Türkmençe Wikipediýa Turkmen Latn tk Tuvan Wikipedia Тыва Википедия (Tıwa Vikipediya) Tuvan Cyrl tyv Twi Wikipedia Wikipidia Twi Twi Latn tw Tyap Wikipedia Wukipedia nTyap Tyap Latn kcg Udmurt Wikipedia Удмурт Википедия (Udmurt Vikipedija) Udmurt Cyrl udm Ukrainian Wikipedia Українська Вікіпедія (Ukrayinsʹka Vikipediya) Ukrainian Cyrl uk Upper Sorbian Wikipedia Hornjoserbska wikipedija Upper Sorbian Latn hsb Urdu Wikipedia اردو ویکیپیڈیا (Urdū vikipīḍiyā) Urdu Arab ur Uzbek Wikipedia Oʻzbekcha Vikipediya (Ўзбекча Википедия) Uzbek Latn/Cyrl uz Venda Wikipedia Wikipedia nga tshiVenḓa Venda Latn ve Venetian Wikipedia Wikipedia en łéngoa vèneta Venetian Latn vec Veps Wikipedia Vepsän Vikipedii Veps Latn vep Vietnamese Wikipedia Wikipedia tiếng Việt Vietnamese Latn vi Romani Wikipedia Romani Vikipidiya Romani (Vlax Romani) Latn rmy Volapük Wikipedia Vükiped Volapükik Volapük Latn vo Võro Wikipedia Võrokeeline Vikipeediä Võro Latn fiu-vro Walloon Wikipedia Wikipedia e walon Walloon Latn wa Waray Wikipedia Waray Wikipedia Waray Latn war Wayuu Wikipedia Wikipeetia süka wayuunaiki Wayuu Latn guc Welsh Wikipedia Wicipedia Cymraeg Welsh Latn cy West Flemish Wikipedia West-Vlamse Wikipedia West Flemish Latn vls West Frisian Wikipedia Frysktalige Wikipedy West Frisian Latn fy Western Armenian Wikipedia Արեւմտահայերէն Ուիքիփետիա (Arevmdahayerēn Uikʿipʿetia) Western Armenian Armn hyw Wolof Wikipedia Wikipedia Wolof Wolof Latn wo Xhosa Wikipedia Wikipedia isiXhosa Xhosa Latn xh Yakut Wikipedia Сахалыы Бикипиэдьийэ (Sahalyy Bikipieçje) Yakut Cyrl sah Yiddish Wikipedia יידישע וויקיפעדיע (Yidishe vikipedye) Yiddish Hebr yi Yoruba Wikipedia Wikipéédíà Yorùbá Yoruba Latn yo Zazaki Wikipedia Wikipediyay Zazaki Zaza Latn diq Zeelandic Wikipedia Zeêuwstaelihe Wikipedia Zeelandic Latn zea Zhuang Wikipedia Veizgiek Bakgoh Vahcuengh Zhuang (Standard Zhuang) Latn za Zulu Wikipedia Wikipedia isiZulu Zulu Latn zu Norman Wikipedia Augeron, Cotentinais, Percheron: Viqùipédie normaunde Auregnais: Ouitchipédie Nourmaounde Brayon, Cauchois, Rouennais: Viqùipédie normande Guernésiais: Ouitchipédie normande Jèrriais: Ouitchipédie Nouormande Sercquiais: Witchipedi Normãdi Norman Latn nrm Eastern Min Wikipedia Bàng-uâ-cê: Bànguâpedia or Mìng-dĕ̤ng-ngṳ̄ Wikipedia Eastern Min Latn cdo Southern Min Wikipedia Pe̍h-ōe-jī: Holopedia or Wikipedia Bân-lâm-gú Southern Min Latn zh-min-nan Hakka Wikipedia Pha̍k-fa-sṳ: Hakkâpedia or Hak-kâ-ngî Wikipedia Hakka Chinese Latn hak Chinese Wikipedia Traditional Chinese: 中文維基百科, simplified Chinese: 中文维基百科 (pinyin: Zhōngwén wéijī bǎikē) Chinese (written vernacular Chinese) Hans/Hant zh Gan Wikipedia Traditional Chinese: 贛語維基百科, simplified Chinese: 赣语维基百科 (Pha̍k-oa-chhi: Gon wéijī bǎikē) Gan Chinese Hans/Hant gan Wu Wikipedia Traditional Chinese: 吳語維基百科, simplified Chinese: 吴语维基百科 (Romanized: Wu-nyu Vi-ci-pah-khu) Wu Chinese Hans/Hant wuu Cantonese Wikipedia Traditional Chinese: 粵文維基百科 (Jyutping: jyut6 man4 wai4 gei1 baak3 fo1) Cantonese Hant zh-yue Uyghur Wikipedia UEY: ئۇيغۇرچە ۋىكىپېدىيە (ULY: Uyghur wikipëdiye) (UYY: Uyghur vikipediyə) (UKY: Уйғур википедийә) Uyghur Arab ug

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

Oppose

• No, this would open the floodgates to dab pages listing vast numbers of entries with no information useful to the reader of English Wikipedia 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)

Discussion

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)

Wikipedia'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 Wikipedia. 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 Wikipedia, 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 Wikipedia. We have MOS:DABRED to handle that. But in cases when there is an article, just not on the English Wikipedia, 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 Wikipedia, 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)

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

[S]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 Wikipedia that a blue link in some foreign language Wikipedia the same as any other red link.

If we think that a red link on the English Wikipedia with a blue link to a foreign language Wikipedia 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)

Proposal #2

Change the wording of WP:DABSISTER to the following:

If an article doesn't exist on the English Wikipedia, but exists on a sister project, that is likely an indication that an article should be created on the English Wikipedia. However, at the end of the day, per WP:WRITEITFIRST, until an article is created on the English Wikipedia, 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)

Oppose

• 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)

Discussion

I think there it is wrong to say that is likely an indication that an article should be created on the English Wikipedia. The mere existence of an article in another language says nothing about whether the article should be created on the English Wikipedia. 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 Wikipedia 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)

Proposal #3

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 Wikipedia, 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)

Discussion

• 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 Wikipedia. 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 Wikipedia. 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)

Proposal #4

Eliminate WP:DABSISTER entirely.

Oppose

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

Discuss

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)

Where now?

I have just reverted a change by @The Mountain of Eden: which added a statement to Wikipedia: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 Wikipedia, 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 Wikipedia, 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 Wikipedia?
• 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 Wikipedia, 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 Wikipedia other than the article hasn't been written yet (a little digging reveals that according to the Thai Wikipedia 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 Wikipedia, 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 Wikipedia (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 Wikipedia 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)

WikiNav considered harmful

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:Wikipedia 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 Wikipedia 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 Wikipedia: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: [3] -> 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: [4] 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)

on what statistics should look like for hatnotes, primary redirects, primary topics

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 Wikipedia: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:Wikipedia 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 Wikipedia 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, Wikipedia 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)