Wikipedia talk:Manual of Style/Linking

Redirection to another article in an infobox

Gioachino Rossini
Rossini in 1865, photo by Étienne Carjat
Born	(1792-02-29)29 February 1792 Pesaro, Italy
Died	13 November 1868(1868-11-13) (aged 76) Passy, Paris, France
Works	List of compositions

Two days ago, I opened a discussion at Talk:Gioachino Rossini to debate the addition of an infobox. For those who may be unaware, WikiProject Composers has an age-old policy guideline that disallows infoboxes in composer biographies, but this has been changed in recent years. This question isn't about that; rather, this is about the inclusion of something within a possible Rossini infobox.

To the right is the infobox I proposed, similar in style to Mozart, Beethoven, Chopin, Shostakovich, Prokofiev, etc. The inclusion of the article link to "List of compositions" in the works parameter has been the subject of debate. @Gerda Arendt and I state that the inclusion is justified because the link shows that Rossini was notable for composing and this is the standard on many other composer articles. @Nikkimaria countered that MOS:FORCELINK, which is part of Wikipedia:Manual of Style/Linking, disallows these kinds of links per the words, "The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links." I argued that the very bullet point Nikki quoted also says, "Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence." (emphasis added) Infoboxes are certainly not sentences, but Nikki found this to still apply, since it "mak[es] it so readers could only understand the oeuvre of the article subject by following a link, which is what NOFORCELINK exists to combat".

So, now I am here. I understand the point Nikki is making and understand how it may apply to the infobox, but I want the input of people who frequent the MoS and deduce the sometime vague phrasing. Is the inclusion of the "List of compositions" link under the works parameter a violation of the MoS? MyCatIsAChonk (talk) (not me) (also not me) (still no) 00:18, 4 October 2023 (UTC)

As noted, MOS:INFOBOXPURPOSE is also relevant: "key facts at a glance", without having to chase links. Nikkimaria (talk) 00:20, 4 October 2023 (UTC)

I've always found links to lists in infoboxes slightly odd, but they're highly relevant to the subject, and reader data shows that having them is important for helping readers discover the list. The only alternative seems to be leaving them out, which doesn't feel optimal. And the NOFORCELINK argument seems rather weak per MyCat's argument. {{u|Sdkb}} ^talk 00:58, 4 October 2023 (UTC)

Also, this is a very widely adopted practice, used in FAs like Taylor Swift, so disallowing it would be a significant change. {{u|Sdkb}} ^talk 01:02, 4 October 2023 (UTC)

I'm not sure what conclusion you're trying to draw from the meta research, but it does not show that readers either want to read those links, or that they find them useful. All eyetracking software does is see what parts of a screen attract the eyes. It's why anything in a box, or an image or bullet points will always draw the eye away from the text. That's different from the claim that readers want those links or actively seek them out. - SchroCat (talk) 09:53, 9 November 2023 (UTC)

I believe what @Sdkb is getting at is that these links are just helpful. Regardless of reader data, people on devices will be able to easily navigate to other information through this box, and those not on devices will see "Thirty-nine operas" (see the second box proposal below). If these links are in violation of the MoS, why was it not caught at the Taylor Swift FAC? Because these links are simply helpful, and that's what editors truly care about. MyCatIsAChonk (talk) (not me) (also not me) (still no) 12:00, 9 November 2023 (UTC)

The rest of the sentence in question seems to have been conveniently forgotten: "The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links." Given the output without links is "Works List of compositions", I fail to see how that non-linking text fulfils the policy requirements. In other words, while some people will be able to use the link, a large number will not, and our policy is that it should not be allowed. Feel free to remove the non-compliant entry in Taylor Swift if you prefer, but WP:LOCALCONSENSUS cannot overrule policy. - SchroCat (talk) 12:05, 9 November 2023 (UTC)

That is solvable if we created a new parameter for a list page link (|list_of_works=)) and set the data row class in the infobox code to class="noprint". From what I understand from the noprint class it will remove that piece of text from pinted versions. Template:Infobox television episode does it with its episode list link. Gonnym (talk) 12:09, 9 November 2023 (UTC)

Not for re-users of our freely available product it doesn't, or for those that read offline. - SchroCat (talk) 12:39, 9 November 2023 (UTC)

Can't win them all. I prefer a better user-experience for 80% of users, than a sub-par for 100%. Gonnym (talk) 12:47, 9 November 2023 (UTC)

But that doesn't stop the use being against established policy. If that is to change, that needs to be re-written after an RFC that specifically allows us to ignore a proportion of our readers. - SchroCat (talk) 12:49, 9 November 2023 (UTC)

When you say "policy", do you mean this piece of text: Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence. The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links.? If so, that is a guideline, not a policy. Also, it says as far as possible, well, having the noprint class fixes most of the usage and that checks the "as far as possible" requirement. Unless you are referring to a different policy I missed in this discussion, there is no need for a RfC, unless you wish to start one. Gonnym (talk) 12:54, 9 November 2023 (UTC)

If you are happy that to ignore a proportion of readers and not serve them, then there is little I can say - or would even want to say. I would say it runs counter to everything we do, and as such an RFC would be the only way to get the community's input on the proportion of readers we should serve against those we should ignore. It is a position that is even less constructive than endless pushing for IBs into a range of articles, but whatever floats people's boats, I guess. - SchroCat (talk) 13:02, 9 November 2023 (UTC)

How big of a userbase (those that don't read online or printed versions) are we ignoring? Do you have a percentage? I highly doubt that it is anywhere near what you inferring it to be. Gonnym (talk) 13:09, 9 November 2023 (UTC)

I agree with Nikkimaria that this is not a helpful thing to put into this infobox. The first sentence of the lead of Gioachino Rossini says in part that he gained fame for his 39 operas, so we already know he's notable for composing. And of course the link to List of compositions by Gioachino Rossini is already in the article, under "Music" in a {{see also}}, so it's not something you'd have to hunt to find.

From a practicality standpoint, were this link to be added to the infobox, it would be a short time before uninvolved editors found it lacking in that it communicates no facts, and start adding examples they felt to be most notable while keeping the list as a link under the last example. This would evolve into an unpleasant argument between editors as to which examples to include, which compositions "most notable". Struck speculation not reflected in past events 15:28, 4 October 2023 (UTC)

As to whether it's an MOS violation, I'd say that it doesn't comply with WP:INFOBOXPURPOSE as noted. It's not a quick essential fact about the subject that Wikipedia has a list article about his compositions. Folly Mox (talk) 00:58, 4 October 2023 (UTC)

I should clarify that links to lists in infoboxes are not bad in all cases. Especially regarding my second paragraph, if there were a generally agreed upon subset of compositions that everyone knows are the most notable, it's not a problem. You have the best examples with the link to all at the bottom of that field. It is very helpful for discoverability as Skdb notes above in the edit mine conflicted with.

The problem for this case is that unless such an agreed upon subset of most notable compositions exists, you're going to end up back at none at all. Folly Mox (talk) 01:03, 4 October 2023 (UTC)

Quick thought: would something like Operas, cantatas and much else be sufficiently factual, or fall foul of WP:EASTEREGG or other good practice? NebY (talk) 12:57, 4 October 2023 (UTC)

I'm not really an MOS regular like User:MyCatIsAChonk is looking for: I just watchlist a few pages. Having had a look into how the infoboxes in liberal arts biographies have traditionally implemented this unproblematically, and given the usefulness argument presented above by User:Skdb, I feel like although just a bare link to another article doesn't fully comply with MOS:INFOBOXPURPOSE, it does serve the reader.

Having said that, for this case there is an additional issue in that List of operas by Gioachino Rossini has already been split from List of compositions by Gioachino Rossini, which links it as a "see also" in its first lvl2 subheading. If the lead sentence of the article says Rossini "gained fame for his 39 operas", that's what I'd expect to be linked in the infobox if a link is included in this parameter. If he's notable for the rest of his compositions similarly to his notability from operas, we could link both the articles and update the lead sentence to reflect that. Folly Mox (talk) 15:26, 4 October 2023 (UTC)

Gioachino Rossini
Rossini in 1865, photo by Étienne Carjat
Born	(1792-02-29)29 February 1792 Pesaro, Italy
Died	13 November 1868(1868-11-13) (aged 76) Passy, Paris, France
Works	Thirty-nine operas Other compositions

@Folly Mox, I was completely unaware of the list of operas, how silly of me. To the right is proposal two, with a similar format to Taylor Swift- thoughts? MyCatIsAChonk (talk) (not me) (also not me) (still no) 20:53, 4 October 2023 (UTC)

Maybe it should be "Operas" and "Other compositions", however? After all, operas are compositions too. Gawaon (talk) 21:45, 4 October 2023 (UTC)

That makes more sense, thank you- updated accordingly. MyCatIsAChonk (talk) (not me) (also not me) (still no) 21:49, 4 October 2023 (UTC)

Perhaps Thirty-nine operas or some such, on the WP:EASTEREGG principle that Operas would normally be expected to link to Operas, and to make the magnitude clear even without clicking on the link? NebY (talk) 08:06, 5 October 2023 (UTC)

Well, in the aforementioned Taylor Swift infobox, it doesn't say "10 albums" or "59 singles"; it just says albums, singles, etc. That being said, the general reader would likely be much more familiar with modern music practices than opera, but do you think the familiarity plays a part? MyCatIsAChonk (talk) (not me) (also not me) (still no) 10:56, 5 October 2023 (UTC)

One trade-off there is that, if we list the number, we then have to update it whenever the number changes. That's obviously less of a concern with a BDP than with someone mid-career. {{u|Sdkb}} ^talk 14:23, 5 October 2023 (UTC)

Very good point, I agree- updated MyCatIsAChonk (talk) (not me) (also not me) (still no) 15:25, 5 October 2023 (UTC)

The idea of naming the link "Thirty-nine operas" elegantly realizes MOS:INFOBOXPURPOSE's principle "key facts at a glance". It may be worth inclusion here, or at least at Wikipedia:Manual_of_Style/Infoboxes, so I suggested it there. ◅ Sebastian Helm 🗨 11:52, 23 October 2023 (UTC)

Many thanks- I'll likely open an RfC at Rossini once the discussion over there is concluded. MyCatIsAChonk (talk) (not me) (also not me) (still no) 15:29, 23 October 2023 (UTC)

FYI

Participants of this discussion may be interested in this RfC on the same topic: Wikipedia_talk:Manual_of_Style/Infoboxes#MOS:INFOBOXPURPOSE_and_links_to_related_articles. Sdkb ^talk 03:31, 8 March 2024 (UTC)

Order of links in an "External links" section?

Greetings and felicitations. This topic isn't mentioned in the project page, and a brief search of this talk page's archives (not including the those in the sidebar) did not turn up anything relevant. In my opinion it is best to start with Wikimedia project links, followed by official links (edit: and then everything else), but is there any consensus on this? —DocWatson42 (talk) 06:27, 6 November 2023 (UTC)

WP:ELORDER Moxy- 13:19, 6 November 2023 (UTC)

WP:ELORDER covers where in the article the external links section goes. The only thing it has to say about the order of the links within it is that an link to an official site should go first. However, the next section, WP:ELTEMP, says to put templates containing external links (such as for Wikipedia projects) after the external links section (or, equivalently, at the bottom of it). Largoplazo (talk) 16:48, 6 November 2023 (UTC)

Thank you both—that was what I was (fruitlessly) looking for, in the wrong places. ^_^ —DocWatson42 (talk) 04:52, 12 November 2023 (UTC)

Section links from citations

When adding the first citation of Mohammed Dajani Daoudi, first using Virtual Editor and then source editor, I tried to make a direct link from Fathom Journal/fathomjournal to the Fathom journal section of Britain Israel Communications and Research Centre based on the examples of Template:Section link but either the article and section titles were italicised or error notices appeared. In the end I left it as a link to Fathom Journal which redirects to the Centre. Should it be possible to make a direct link from the citation to the section? Mcljlm (talk) 22:17, 14 November 2023 (UTC)

I would say that you shouldn't link to the section, regardless. If Fathom Journal wikilinks should be targeted at Britain Israel Communications and Research Centre#Fathom journal, then the redirect should instead be updated to go directly to that section. (Redirects can totally do that.) That way, the decision about the correct destination for links to Fathom Journal is made centrally and by consensus, rather than each individual citation author making their own call. FeRDNYC (talk) 15:55, 21 December 2023 (UTC)

(Also, FWIW in the case of Fathom Journal in particular, I think linking to the overall Britain Israel Communications and Research Centre article makes the most sense. There's almost nothing IN the section on Fathom; certainly, nothing that helps to inform readers about the cited work. So, the fact that Fathom is published by the BICRC is the more relevant info.

If the Fathom journal section were fleshed out with more information about the publication, that might change things. But right now it's just not a good direct-link target.) FeRDNYC (talk) 17:13, 21 December 2023 (UTC)

References

"MOS: LINK" listed at Redirects for discussion

The redirect MOS: LINK 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/2023 December 5 § MOS: LINK until a consensus is reached. Utopes _{(talk / cont)} 04:03, 5 December 2023 (UTC)

"MOS: NOPIPE" listed at Redirects for discussion

The redirect MOS: NOPIPE 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/2023 December 5 § MOS: NOPIPE until a consensus is reached. Utopes _{(talk / cont)} 04:04, 5 December 2023 (UTC)

"MOS: OL" listed at Redirects for discussion

The redirect MOS: OL 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/2023 December 5 § MOS: OL until a consensus is reached. Utopes _{(talk / cont)} 04:04, 5 December 2023 (UTC)

MOS:DUPLINK rules for repeating links in articles

After the Wikipedia talk:Manual of Style/Linking/Archive_21#DL,_sections,_and_mobile_readers RFC, which demonstrated overwhelming consensus in support of relaxing the "once per article" rule for links to "once per section", RFC closer Mike Christie made a perfectly reasonable edit-of-least-disruption to the page, altering the introduction of MOS:DUPLINK like so:

Generally, a link should appear only once in an article, but it may be repeated if helpful for readers, such as in infoboxes, tables, image captions, footnotes, hatnotes, and at the first occurrence after the leadin a section.

Reasonable, sure. Least-disruptive, sure. But... accurate?

Now more than ever, the actual rules we've settled on contradict the statement, "Generally, a link should appear only once in an article". Whether or not that was even accurate before (given the long list of exceptions), in the wake of the RFC it certainly doesn't seem right anymore.

Generally, the community expressed broad consensus for generally eliminating that restriction, and links are now permitted once per section, generally. So, why are we still opening with a statement of the policy as it (generally) maybe used to be?

IMHO we should bite the bullet, embrace the change, and open with something like:

Generally, a term should be linked at most once in each section of an article, the first time it's mentioned in that section. Subsequent repetitions should not be linked. (Note that this is a maximum link frequency; if it's relevant to link a term in one section, but not relevant in another, the term is not required to be linked in both. Common sense should always prevail.)

Outside of the body text, additional mentions of the same term may be linked if helpful for readers, such as in infoboxes, tables, image captions, footnotes, and hatnotes.

FeRDNYC (talk) 15:47, 21 December 2023 (UTC)

That sounds reasonable to me, and an accurate summary of what we really do, though it could be considerably compressed:

Link a term at most once per section, at first occurrence. Common sense applies; do not re-link in other sections if not contextually important there. Other mentions may be linked if helpful, such as in infoboxes, tables, image captions, footnotes, and hatnotes.

That appears to get the same messages across in much less wording.  — SMcCandlish ☏ ¢ 😼  01:52, 18 January 2024 (UTC)

Sounds good to me. Gawaon (talk) 14:25, 24 January 2024 (UTC)

Very belatedly (see below) implemented the re-wording provided by SMcCandlish, who sure do use them words all purty-like. ...With the word "major" shoe-horned in before "section", because in the interim someone had taken the time to shoe-horn it into the old wording as well, and even stuffed an unnecessarily verbose explanation of the precisely-imprecise contextual meaning of "major" into a footnote (also preserved) to accompany it.

What was the holdup, ya bum?
(In my defense, back in October my left thumb went "offline", requiring surgery early February which resulted in my left hand being in a cast for weeks afterwards. Any activity involving typing has been neglected of late, on my part.)

Anyway,  Done FeRDNYC (talk) 08:51, 22 March 2024 (UTC)

someone ... even stuffed an unnecessarily verbose explanation of the precisely-imprecise contextual meaning of "major" into a footnote Heh, turns out that was also SMcCandlish's doing! FeRDNYC (talk) 08:56, 22 March 2024 (UTC)

Thanks for normalizing the material a bit; there are often bits of "straggler" text that need revision after a change as major as the end to only-one-link-per-article. The footnote might be shortenable in some way, but it's based on a lot of sometimes conflicting concerns, and is about the best balance I could work out between them. See #Section level and duplink for details.  — SMcCandlish ☏ ¢ 😼  10:14, 22 March 2024 (UTC)

MOS:EGG in Template:Infobox company

I've proposed updating Template:Infobox company's documentation to avoid a potential MOS:EGG issue. Please give your thoughts in that discussion. Ed ^{[talk] [OMT]} 01:24, 12 January 2024 (UTC)

Edit request

add

−

+

{{pp-semi-indef|small=yes}}

103.253.27.33 (talk) 22:32, 14 January 2024 (UTC)

 Done Largoplazo (talk) 01:01, 15 January 2024 (UTC)

A change to NOFORCELINK

Currently NOFORCELINK says Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence. The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links.. The literal interpretation of this My interpretation of this is that it requires that every word that could be considered specialist ("turboprop", "action platformer", "Laplace transform", "endpaper", ...) be explained in the text. I believe this is impossible and would be bad writing if it were possible. This has come up before, so I'll ping in everyone who was in that conversation, but what prompted me to post here was seeing a request from Gog the Mild in a current FAC (nominated by Aoba47) to clarify "action platformer". I think Gog's request is in sync with what NOFORCELINK actually says, but I don't think the change they are requesting is desirable.

In the discussion from last year, linked above, I wrote if knowledgeable readers feel that the flow is being broken up too much by inline explanations, non-knowledgeable readers should accept that, and be willing to accept links instead, or, if absolutely necessary, an explanatory note, and NebY was kind enough to say they thought this was a guiding principle. I won't repeat the examples from the linked discussion, but I recommend reading it as there are good arguments made on both sides.

I propose we insert into NOFORCELINK a form of words that codifies the "guiding principle" quoted. I think this is going to be difficult to do because we can't explicitly give a local discussion at a WikiProject authority over other editors -- this is the WP:LOCALCONSENSUS point that SMcCandlish often argues, and he's quite right. I think it's worth trying to do because as it stands NOFORCELINK has no get-out clause for an editor who argues that "bench-clearing brawl" requires an in-text explanation in an article about a baseball game. NebY's example in the prior discussion parodies what such an article would look like, and is a better argument than anything I could come up with.

If we can't add something like this, at least we should weaken the guidance to make it clear there are exceptions. Maths is the most obvious exception, to me, but the wording should make it clearer what the limits of "as far as possible" are, and to weaken or remove "The text needs to make sense to readers who cannot follow links."

Pinging from previous discussion and the current FAC: J Milburn, Lee Vilenski, Bagumba, Uanfala. Mike Christie (talk - contribs - library) 22:52, 17 January 2024 (UTC)

While, as ever, willing to listen to other opinions, my first thought on "if knowledgeable readers feel that the flow is being broken up too much by inline explanations, non-knowledgeable readers should accept that, and be willing to accept links instead, or, if absolutely necessary, an explanatory note" is to disagree. We are an encyclopedia, we are here to explain things for non-knowledgeable readers - that is actually our mission statement. To codify the generation of in-group language and articles which can only be understood if you already understand them is an admission of project failure. And I don't feel that setting up a straw man in the introductory remarks - " The literal interpretation of this requires that every word that could be considered specialist ("turboprop", "action platformer", "Laplace transform", "endpaper", ...) be explained in the text" - is helpful. Gog the Mild (talk) 23:11, 17 January 2024 (UTC)

Fair point on the straw man so I've struck and reworded it. And I take your general point, but can we agree that as articles get more and more specialized, descending through the fractal tree of some topic or other from the overview article to highly specialized articles such as sheaf (mathematics), eventually NOFORCELINK becomes actively unhelpful? I'm arguing that we should acknowledge that fact in the wording. Mike Christie (talk - contribs - library) 23:16, 17 January 2024 (UTC)

We certainly can, and we can then haggle over where we draw the line. Can we also agree that whatever is decided only FAC cares about it? It makes no difference whatsoever to any non-FA article, no one is going to be deleting text for non-compliance. GAN (and ACR) have even institutionalised non-compliance. Gog the Mild (talk) 23:37, 17 January 2024 (UTC)

And I really struggle to see how "as far as possible" equals "it requires that every word". It simply don't, it requires it "as far as possible", and no further. So sheaf (mathematics) already has its "out" and I look forward with interest to seeing what there is to discuss. Gog the Mild (talk) 23:37, 17 January 2024 (UTC)

Leaving my opinion to one side, re 'weaken or remove "The text needs to make sense to readers who cannot follow links." ', have you run this past the accessibility people? Their objection is usually taken to be the end of a discussion. Gog the Mild (talk) 23:47, 17 January 2024 (UTC)

I don't think it's a coincidence that noticing a FAC discussion about this brought me here, so you're right -- it's certainly going to be mostly FAC where this is relevant. (Actually that means I should post a note about this discussion at WT:FAC. I'll do that next.) But the guidance given should be correct whether or not that's true. No, haven't asked about accessibility, but good thought, so pinging Graham87 who is always helpful on such questions. Also pinging David Eppstein who I know has contributed to this sort of discussion in the past. Mike Christie (talk - contribs - library) 00:17, 18 January 2024 (UTC)

I don't think this has any special accessibility implications for users with disabilities. Graham87 (talk) 03:12, 18 January 2024 (UTC)

I completely agree with Mike Christie's take that explaining literally every technical word would, in many cases, send us down an endless rabbit hole of sub-explanations and sub-sub-sub-explanations to the point where no reader can read the article. The general audience readers cannot read it because they do not have the background to assimilate all the sub-explanations all the way down the chain and the experts cannot read it because they cannot find the actual content among all the "As You Know, Bob" explanations of things they already know. We need a happy medium. I think WP:ONEDOWN does a good job of setting a target audience and therefore setting the level of what terms need expansion and what can be assumed. Any further expansion beyond that level will not help, because people more than one level down are not ready to understand the article yet and so trying to make the article understandable to them is futile. Even a single level of expansion may be too much. As an example, the current lead of prime number states: A prime number (or a prime) is a natural number greater than 1 that is not a product of two smaller natural numbers. Here the terms "natural number" and "product" are linked, but not explained, because if you do not know how to count and multiply, you are not ready to learn about prime numbers. "Greater than" is not linked but in the same boat. This is not so much an issue of accessibility as of making our articles self-contained to those who can benefit from reading them. —David Eppstein (talk) 00:40, 18 January 2024 (UTC)

We have had a lot of trouble with this in the past and it has a reputation as one of the most obnoxious parts of the MOS. It directly contradicts WP:SUMMARYSTYLE. It demands that every link be explained. Our normal out at FAC and GA is that we don't have to conform to the MOS.This was added without consensus in 2015. [1] Strongly recommend restoring the original version: Do not unnecessarily make a reader chase links: if a highly technical term can be simply explained with very few words, do so. Hawkeye7 (discuss) 00:50, 18 January 2024 (UTC)

Strongly disagree. That is not a good rule, because it does not generate a method that terminates in a bounded number of expansions. It is entirely possible to have a highly technical term that can be simply explained with very few words, some of which are themselves highly technical but can be simply explained with very few words, some of which are themselves highly technical but can be simply explained with very few words, etc. In fact the chain of explanations may even be circular. We need a rule that tells us the level of explanation that is appropriate: which highly technical terms need expansion because they are technical even to people ready to read the article, and which highly technical terms should be left to stand because if you don't already understand them you also won't understand anything else that follows. WP:ONEDOWN is that rule. —David Eppstein (talk) 00:58, 18 January 2024 (UTC)

Yes, we already have this covered. And "do not force a reader to use that link to understand the sentence" does notmean "make the material understandable to a five-year-old", it means if the sentence is outright confusing to the average reader then probably needs some clarification. Confusing does mean "not sure what this word means", confusing means "can't even really parse the sentence as meaningful". Any of our physics articles (to pick a technical topic at random) like graviton and string theory and even elementary particle contain plenty of technical terminolgy from the lead sentence, but even someone who doesn't know what most of them mean for certain can pick out at least a bare gist of it even if they have to look some stuff up. If they don't understand any of these terms at all, then they need to start with a more basic article. We aren't going to right in the lead sentence explain what a quantum is, explain what physics in, explain what a particle is, explain what a point is, explain what gravity is, etc. All of such articles could probably be improved but they are not fundamentally broken.  — SMcCandlish ☏ ¢ 😼  01:44, 18 January 2024 (UTC)

There is always going to be room for disagreement on which technical terms need explanations and which don't, because different people have different levels of knowledge. I know what a graviton is but not what an action platformer is. It might also depend on the type of article and whether its readers can be expected to know a term. I think the question is most important in FAC and content review processes; I usually explain the term when asked, unless it is intuitive for laypeople.

There is a separate question of where to put explanations when they are needed. I generally put them in footnotes, not inline, because the explanations are distracting and break the flow of the text.

Jo-Jo Eumerus (talk) 09:33, 18 January 2024 (UTC)

My interpretation of how this should work is that it's important to explain information that is required to understand the content. Taking wording from my field of view, something like John Higgins made a century break of 104. - a century break is a phrase that under the current wording would have to be explained in every snooker article as "a series of shots which gives a score of over 100 in one turn", which is overkill except in the article in which we link. However, you can easily move on from this sentence if you dont know what a century break is, it's enough to know that he did a thing.

The difference is when the information is required information for future reading within that article. We shouldn't force readers to click outside links to understand the article you are reading, but equally we shouldn't be causing readers to read an explanation for every term. So, another example where we might need to explain would be the event was played as a double-elimination tournament. I think most readers would have difficulty understanding this, and even if you do know what this is, you wouldn't worry too much about a later sentence saying players who lost one match would be moved to the "loser's side" of the bracket and be eliminated after a second loss. for example. The last thing we should do is be explaining every link inline. Imagine if we had to explain what a goal, a battle or a table is. Lee Vilenski ^{(talk • contribs)} 10:00, 18 January 2024 (UTC)

The key words are as far as possible. Articles are not limited to experts, but it shouldn't be bogged down for people with a bit of familiarity. WP:ONEDOWN is mentioned by some below.—Bagumba (talk) 09:54, 19 January 2024 (UTC)

I suspect what I'm going to say here will be unpopular, but that's never stopped me before. I think Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links is an obsolete concept. Wiki says A wiki ... is a form of online hypertext publication Right there in the lead sentence it emphasizes "online" as well as "hypertext". These are fundamental attributes of what we are.

Yes, our license allows people to print articles out, and I'm sure some people do, but that's an exceptionally minor edge case. And, yes, people do republish our stuff on-line, but if they're republishing it in a form which doesn't preserve the links, they're doing it wrong. A lot of that is SEO fodder, click-bait, or just plain plagiarism which fails to comply with even the trivial requirements imposed by CC-BY-SA. I care not a whit about the quality of the experience provided by those bottom feeders. As for off-line reading, Enwiki is 4.3 billion words, so figure 25 GB (probably more like 3 GB compressed). Even low-end phones these days have enough storage to load the entirety of enwiki. So there's no good reason why the off-line experience can't include links.

I'm not saying we shouldn't be providing in-line explanations of terms when it's appropriate. Just that we shouldn't be letting obsolete concepts of how people consume the encyclopedia be a significant driver of our writing style. It's a good thing for us to say "we allow (even encourage) you to do this". It's also a good thing to say "we'll expend significant resources (XML dumps, etc) to facilitate you doing this". It's not a good thing to say "we'll degrade our product to accommodate you doing this".

I'm absolutely in support of making our content more accessible to people with disabilities, but I'm not convinced that providing in-line explanations of every link is a positive step. I know in my own reading, concise writing aids my comprehension. If I have to wade through parenthetical explanations of terms to get to the meat of the sentence, it's harder for me to understand. RoySmith (talk) 16:54, 25 January 2024 (UTC)

It would be wonderful if it were obsolete. Unfortunately the privilege of bandwidth is not evenly distributed around the world - there are millions of users of offline versions of Wikipedia. Nikkimaria (talk) 00:00, 26 January 2024 (UTC)

Gog's point that a change to NOFORCELINK would mostly affect FAC seems plausible to me, so I searched the promoted FAC pages for uses of NOFORCELINK and FORCELINK. That only finds the few reviewers who use this shortcut rather than simply requesting further explanations without linking to the MoS; there are certainly other reviewers who make the same points. With that caveat, here are some of the results. Some of these seem clearly legitimate requests and are why we have NOFORCELINK; others seem to me to be requesting more than is needed. I tried searching for "gloss" but in many of the results I found the comment was "since there's no link for this specialist term we need a gloss instead"; those are not relevant as the reviewer is clearly saying that just a link is enough.

In a couple of cases below I've given the outcome, just to reinforce the point that many of these are perfectly legitimate applications of NOFORCELINK.

• member of the Société Honoraire de Français from the FAC for Lisa Nowak. Nominators Neopeius and Hawkeye7; reviewer requesting the explanation The Rambling Man. Current wording in the article: member of the Société Honoraire de Français, which required students to maintain an A average in French and a B average in all other subjects. I think a link would have sufficed here.
• possibly because of Jacobite sympathies from the FAC for Thomas Hardy (Royal Navy officer, died 1732). Nominator Pickersgill-Cunliffe; reviewer requesting the explanation Gog the Mild. Current wording in the article: possibly because, as a Tory, he continued to support the deposed House of Stuart after the succession of the House of Hanover. Particularly given that this is in the lead I think the expansion was the right call.
• A long list of words, including gracile, holotype, and braincase, in the FAC for Bajadasaurus. Nominator Jens Lallensack; reviewer The Rambling Man. That FAC contains a debate about the usage of NOFORCELINK with comments from multiple reviewers.
• 137 break from the FAC for 2022 World Snooker Championship. Nominator Lee Vilenski; reviewer Gog the Mild. I think this is the one that led to the last NOFORCELINK discussion.
• frigate in the FAC for HMS Aigle (1801). Nominator Ykraps; reviewer Gog the Mild.
• "a metal cast plaque in champlevé (carved) enamel in the FAC for Clonmacnoise Crozier. Nominator Ceoil; reviewer Gog the Mild. Current wording in the article is simplified rather than expanded: in champlevé enamel.
• "Tribal Hidage" in the FAC for Benty Grange hanging bowl. Nominator Usernameunique; reviewer UndercoverClassicist.
• hero pulp and weird menace in the FAC for The Spider (magazine). Nominator Mike Christie; reviewer UndercoverClassicist.
• Chagatai literature in the FAC for Fuzuli (poet). Nominator Golden; reviewer UndercoverClassicist.
• A reverse usage: in the FAC for I Don't Wanna Cry, nominated by Heartfox, reviewer MaranoFan questioned the details of a sentence and Heartfox responded that it was required by NOFORCELINK.

David suggested that WP:ONEDOWN is the principle that should be used to determine whether more than a link is required. I like that idea in theory but would like to see that it would be helpful in resolving the above examples. For example, in the FAC for The Spider, UC requested glosses for "weird menace" and "hero pulp". Is the ONEDOWN level a reader who knows about pulp magazines but not about this one? If so no gloss is needed. Or is the ONEDOWN level a reader who knows about the magazine industry but not pulps? In which case a gloss is likely to be helpful. Mike Christie (talk - contribs - library) 13:40, 18 January 2024 (UTC)

For what it's worth, as I seem to feature quite frequently up here, my principle is that we should explain a term in text if:

a) We think it is important for a reader to understand that term, in order to understand its significance in the article.

b) We think that at least a significant chunk of the readership won't automatically understand that term, bearing in mind that we write assuming that our audience don't generally have much background knowledge outside the article.

c) Explaining the term is relatively "cheap" (that is, a succinct, useful explanation exists, which can be inserted into the article text without creating other problems of readability, verbosity or general barbarity).

Echoing Mike, I like the idea of ONEDOWN as the basic standard, but would emphasise his point that it's always going to be a nuanced decision: I'd suggest that any too-monolithic set of rules is likely to fail. UndercoverClassicist ^T·C 14:21, 18 January 2024 (UTC)

Over the years, FAC reviewers pushed me to avoid more and more technical terms. In hindsight, I am pretty happy about that, as I want people to understand these articles. I am still surprised how much is possible here that really makes a difference to the reader. Providing in-text explanations is only one possible solution. Sometimes, a little hint is sufficient (e.g., writing "Late Cretaceous epoch" instead of just "Late Cretaceous"). Often, it is possible to replace the term with a more widely understood one without sacrificing too much precision, or even replacing the term with an explanation. But I first had to learn this the hard way, which was not easy, and I was quite reluctant to stop using terms that, for me, are part of every-day language. So I think that having a guideline that pushes authors towards this direction is not necessarily a bad thing!

But we always have to remember: It is not our goal to strictly abide to guidelines. Our goal is to write the best-possible articles. Guidelines can only help us with that, but they can never be the goal themselves. When we start optimizing our articles to comply with a guideline, article quality tends to improve – but there inevitably comes a point where we over-optimize and article quality decreases sharply. Therefore, a reviewer should not make the mistake to blindly check an article against a particular guideline and oppose because of non-compliance, possibly without even reading the article. Instead, a reviewer should always have our primary goal in mind (to improve the article), and apply common sense with respect to the article in question, asking "could this article be improved by more closely abiding to that guideline"? --Jens Lallensack (talk) 16:12, 18 January 2024 (UTC)

Hyperlinking allows us to provide our readers a higher level of service than is possible in print media. We shouldn't try to emulate that high level by also adding inline explanations that are disruptive for most readers, even those who aren't online.

Print readers know very well that if we see unfamiliar terms, we may have to look elsewhere for definitions. Sometimes we make a good guess, sometimes we keep going because we're not trying to understand everything, sometimes we'll find a glossary in the back, grab a dictionary or primer, or look on Wikipedia. Print writers and publishers know they'll lose their target audience if they keep interrupting their reading, and WP editors should learn from them if we really are writing for those who print our pages (an ever-shrinking proportion of readers in this digital age, plus some publishers of expensive print-on-demand collections of our articles).

Happily, many of our articles, even FAs, don't explain inline and often don't even link (century break, to take one of Lee's examples above, top of the fourth, right field foul pole and the others I mentioned before, or second yellow card, edging a delivery, or false flat). They're still good articles. Wikipedia editors shouldn't be told to degrade them to cater for print readers in ways that print publishers can't and don't. NebY (talk) 18:13, 18 January 2024 (UTC)

• I have wrestled with this question as both writer and reviewer, and I'm still forming my own views. I believe at the outset, though, that we need to recognize that at some level the audience for every article is different; geographically, educationally, linguistically. I don't think it is possible or desirable for every article to be equally accessible to all readers (I'm not setting up a straw man here — I don't believe anyone is advocating for this — I'm only expressing a principle). As such it seems to me the guideline should be written such that explanations can be provided or requested based on a) the degree of specialization in the article, and b) editorial judgement. Vanamonde93 (talk) 18:28, 18 January 2024 (UTC)

In response to NebY's suggestion that inline explanations only benefit print readers: there's a wider picture to consider here. Most obviously, there are people who, for accessibility reasons, cannot or cannot as easily follow hyperlinks (those using screen readers). There is also a major cognitive load issue with requiring people to navigate away from a page, and so break their flow of concentration, and then to return back to it: again, that's an accessibility issue when we consider things like ADHD and dyslexia, which affect a sizeable chunk of our readers. UndercoverClassicist ^T·C 18:37, 18 January 2024 (UTC)

Those are good points, but I'm not suggesting that inline explanations only benefit print readers. I am arguing against inline explanations that are disruptive, pointing out that we often do without them, quite rightly, despite NOFORCELINK, and generally expanding on your qualification of your well-made point (c) above. As you go on to say, it's always going to be a nuanced decision; one useful way to approach it is "would print media insert such an explanation here?" NebY (talk) 19:03, 18 January 2024 (UTC)

If the term can be explained in two or three words, an inline description might be appropriate. If not, then I'm of the opinion that a link on its own is the better option. After all, isn't that the great advantage of a digital encyclopaedia. I certainly wouldn't fail a FAC because of NOFORCELINK but might insist on a footnote where no link is available. --Ykraps (talk) 18:56, 18 January 2024 (UTC)

I agree with the idea of applying WP:ONEDOWN to both explanations and links. The text should make sense to its target audience, without following links (but that doesn't mean the reader can avoid hard thinking or re-reading tricky sentences). Thus, a "zero levels down" idea might be both linked and explained. A "one level down" idea might be linked only (for any "two levels down" readers; or to fill in the occasional knowledge gap of a target reader). Anything "two levels down" or more goes unlinked.

In Scott–Curry theorem (created by me), the meaning of set is obvious (more than two levels down), so it goes unlinked and certainly without a lengthy definition. In Addition the same word needs a link. In a non-maths article it may need a link and explanation ("the artist was inspired by the concept of a set, which contains distinct, unordered objects"). — Bilorv (talk) 21:44, 18 January 2024 (UTC)

I have always taken "the average reader" to mean "the average reader of this particular article". I would presume that someone reader an article about a football match knows something about football. The reader of a highly technical article probably has a solid background in the subject and is looking for some detailed information. Mathematical articles sometimes have trouble in this regard, as they may be turned to by a broad audience, so they tend to start simple and get more complicated as you go along. WP:ONEDOWN also conflicts with NOFORCELINK (as does WP:NOTPAPER) but I would favour applying the former to links instead of the unenforceable NOFORCELINK. Hawkeye7 (discuss) 00:50, 19 January 2024 (UTC)

At the risk of putting in a lot of oars here, it's worth remembering that there are plenty of avenues -- DYK, Random Article, On This Day, TFA... -- by which we encourage people to look at articles outside their normal areas of expertise. Articles also often cross into different areas: I've written a lot of biographies of academics who did military service, so we end up with quite a lot of technical language and detail about ranks, units, wars and so on. Again, I think the basic concept is sound, but will be tricky to turn into a hard-and-fast rule that applies across all types of article. NOFORCELINK is already part of the MoS, and the whole MoS has the standing caveat to the effect of "all rules here should be treated as general guidelines and disregarded when appropriate": by definition, when a reviewer cites it, they're saying that they think it's right to apply it here, not that it should be blindly applied everywhere. UndercoverClassicist ^T·C 07:34, 19 January 2024 (UTC)

Wording proposals

There's enough support above for something based on ONEDOWN to try to formulate something here. Currently NOFORCELINK says:

Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence. The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links.

and ONEDOWN says:

A general technique for increasing accessibility is to consider the typical level where the topic is studied (for example, secondary, undergraduate, or postgraduate) and write the article for readers who are at the previous level. Thus articles on undergraduate topics can be aimed at a reader with a secondary school background, and articles on postgraduate topics can be aimed at readers with some undergraduate background. The lead section should be particularly understandable, but the advice to write one level down can be applied to the entire article, increasing the overall accessibility. Writing one level down also supports our goal to provide a tertiary source on the topic, which readers can use before they begin to read other sources about it.

ONEDOWN is an essay so rather than refer to it I think we have to rephrase it and summarize it. How about these extra sentences?

The text needs to make sense to readers who are at or one step below a level of study that would familiarize them with the material. For example, in an article on spinal medical issues, it would suffice to link facetectomy without an inline explanation; if the term were used in an article about general medical treatment it might need a footnoted explanation, and in an article not about medicine at all, the meaning of the term would have to be explained inline.

This is just a way to get the wording discussion started; please criticize or suggest changes or improvements. Mike Christie (talk - contribs - library) 15:05, 19 January 2024 (UTC)

I like it Lee Vilenski ^{(talk • contribs)} 15:40, 19 January 2024 (UTC)

WP:ONEDOWN is not an essay, but rather part of Wikipedia:Make technical articles understandable, which is an editing guideline. —Bagumba (talk) 16:04, 19 January 2024 (UTC)

I must admit that I like everything except the specific example here: a large chunk of the audience for spinal medical articles are patients who might have been given a diagnosis of e.g. cervical rhizalgia and want to look up what that means -- those people definitely do need facetomy explained to them in the context of "this might be a surgery that happens to you". I'd propose a more abstract hierarchy whereby we have three options:

1. Explain the term in text (not necessarily a full definition or context, but enough to understand its function in this situation)

2. If that's felt to be too awkward for readability, add an EFN explaining the same.

3. If that's felt to be unnecessary, simply use the link.

Personally, I'd favour a model whereby 1. is the default and general practice, 2. is used where the explanation isn't that important and the readability/aesthetic hit is felt to be significant, and 3. is used only where the term is considered to be at least two steps below the reader's expected level, and it is felt that both 1. and 2. would require excessive tradeoffs (for instance, that there are so many technical terms used that explaining/footnoting them all isn't sensible). However, I think I'm slightly more hawkish than the overall consensus on this latter point. 16:13, 19 January 2024 (UTC) UndercoverClassicist ^T·C 16:13, 19 January 2024 (UTC)

I personally feel that this is too specific and too rigid to be a general guideline. I like the idea behind ONEDOWN, it is good rule of thumb, but as was already noted, I also think it is only applicable to parts of our articles. We often do not have such clear hierarchical levels. For example, a highly specialized article about a roman vase can get considerable public attention if it is exhibited in a museum. And since we are mostly concerned with FAC here: Every specialised FA will get considerable attention from general readers when it is on the main page as TFA. I would prefer something simpler and more general here instead. Maybe: It is recommended to provide inline explanations for terms that are crucial for the understanding of the text or might be unfamiliar to the target readership. However, the article should find a balance between the number and length of inline explanations and the overall conciseness and readability of the article. Jens Lallensack (talk) 17:00, 19 January 2024 (UTC)

I like this: perhaps add a suggestion that footnotes can sometimes be a useful compromise when striving for that balance? UndercoverClassicist ^T·C 17:10, 19 January 2024 (UTC)

Yeah; I personally think that footnotes are great when some lengthy explanations are required. When it comes to simple definitions of terms, though, they are imo not so much better than simple wiki-links (as both require a click), at least for online readers. --Jens Lallensack (talk) 17:17, 19 January 2024 (UTC)

Footnotes include a link back to precisely where the reader was before, whereas wikilinks don't -- but it's a fairly minor difference, as we always have the browser's "back" button and then scrolling/ctrl-f-ing to wherever on the page we were. UndercoverClassicist ^T·C 17:19, 19 January 2024 (UTC)

I think we also need something to avoid the situation that NebY parodied in the earlier discussion: if an article on a baseball game gets to the front page, many readers who know nothing of the sport will read it, but we still should not include footnotes *or* inline explanations for terms such as "inning", "base on balls", "bench-clearing brawl", or "infield fly rule". Jens said "might be unfamiliar to the target readership". We should rarely expect that the target readership is the same as overall Wikipedia readership, or this wording change won't achieve anything. Mike Christie (talk - contribs - library) 17:26, 19 January 2024 (UTC)

I feel strongly that if a reader needs to look up links to understand an article in general terms, which they probably would for the second and last expressions above, then it does not "exemplify Wikipedia's very best work", so would not become an FAC nor a TFA and thus the hypothetical example seems moot. Gog the Mild (talk) 18:05, 19 January 2024 (UTC)

You may be right, but it strikes me that the net effect here is the same: either way, we shouldn't plead that an article expects an unusually technically-expert audience to avoid explaining technical terms, which weighs against strictly using ONEDOWN and towards something more like what Jens proposes. UndercoverClassicist ^T·C 18:19, 19 January 2024 (UTC)

@Mike Christie: You are right that the part about the target readership is not ideal. What about: It is recommended to provide inline explanations for the most difficult terms of an article, so that the widest possible audience can directly understand the article in general terms without having to follow wiki-links. This still retains some element of ONEDOWN as it is restricted to the "most difficult terms" ("most difficult" relative to the overall technicality of the article in question). But yes, this would mean that even the baseball article should provide such explanations to a reasonable extent (and I think, why not?). Jens Lallensack (talk) 23:40, 19 January 2024 (UTC)

Of course it's "reasonable extent" that's going to be hard to define, though. I think Brooklyn Dodgers 1, Boston Braves 1 (26 innings), a recently promoted FA, is a good test case. The nominator was Wehwalt; Harrias reviewed it and there was an exchange in the FAC about whether the level of jargon was appropriate - worth having a look at Harrias and SchroCat's comments as neither are baseball aficionados. If you can find a form of words that supports the wording that Wehwalt ended up with, and which passed FAC, I think that's what we're looking for. I feel NOFORCELINK's current wording doesn't support the FAC version, and I don't think your proposed wording does either. Or do you think the article is in fact too jargon-heavy? Mike Christie (talk - contribs - library) 03:43, 20 January 2024 (UTC)

As I expressed here, sport articles are necessarily going to use the language of sport. As I noted in the above comments to Harrias, which did not receive a reply, that is true regardless of whether it is a baseball article, or football (as in the FA nominated by Harrias that I examined for the identical fault they had found in my article they had reviewed), or cricket (which, had I chosen one of those articles, would surely have made my point more than amply, but I invoked the mercy rule).

It is impossible to avoid using the language of sport, and if you slow to explain each term as you go, you not only make the prose difficult for those who may actually use the article, but cause WP:V problems, for certainly a baseball source that tells us that the designated hitter scored with one out and the bases loaded on a squeeze play after being unable to advance on a pop fly on which the infield fly rule was called will not stop to explain each term. If linking is not sufficient (and it should be), the editor will either have to insert their understanding of each term, go to a myriad of definitional sources, or dumb it down, losing meaning important to baseball readers. The reasons for doing this do not seem strong enough. Wehwalt (talk) 11:42, 20 January 2024 (UTC)

I would assume that inline explanations are covered by WP:BLUE and do not need a citation? I have inline explanations in all my FAs and never provided an additional source for them; it is not material that is "challenged or likely to be challenged". Jens Lallensack (talk) 12:21, 20 January 2024 (UTC)

I don't think you can use BLUE for a technical term. Especially when you have a dedicated article to explain it. In my field, a foul and a miss would be something that has quite a few interpretations, and the rules can be quite oblique. In practice, using a term like that it isn't all that relevant that you know what it is, or how it happens, if the next sentence says what happened next. Lee Vilenski ^{(talk • contribs)} 12:54, 20 January 2024 (UTC)

Article writing is not possible without interpretation of the sources. This includes interpretation of the terms that are used in the source. Adding an inline explanation does therefore not really add new information that is not somehow implied in our writing anyways, in my opinion. Citing those things is citation overkill. Jens Lallensack (talk) 13:12, 20 January 2024 (UTC)

Thats the thing though, if you start extrapolating like that, you don't cite anything. An explanation of what something is isn't really as simple as explaining what you see. Considering we are talking about FA level articles, I wouldn't be happy with an article like that just stating an interpretation without a single source. Lee Vilenski ^{(talk • contribs)} 15:47, 20 January 2024 (UTC)

I've mentally invoked WP:BLUE when, for example, a source says "the rebuilding happened during the reign of Justinian" -- I would say it's unreasonable to assume that our readers all know his dates, so I might write something like "the rebuilding happened under Justinian, who ruled between 527 and 565 CE". Assuming that those dates are uncontroversial, I wouldn't ask for a specific citation, but there's equally no harm in doing something like this. UndercoverClassicist ^T·C 06:34, 26 January 2024 (UTC)

UndercoverClassicist ^T·C 06:34, 26 January 2024 (UTC)

(EC) Yes, it is difficult to impossible to define what a reasonable extent is. But I think that the same issue applies to your original wording – I personally have no idea how I would apply ONEDOWN to my dinosaur articles. Does it mean I should provide more inline explanations or less? The mentioned baseball article does not seem to provide any inline explanations at all; this does not seem to comply with my suggestion or with ONEDOWN?

I am starting to think if it would be best to simply remove MOS:NOFORCELINK. We would still have the point Do not unnecessarily make a reader chase links: if a highly technical term can be simply explained with very few words, do so. – which seems to cover our baseline quite well already. We also have the WP:MTAU guideline stating Wikipedia articles should be written for the widest possible general audience, which points out many different possible ways to make an article understandable, and ONEDOWN is already covered there. If, in a FAC, an article is too technical in our opinion, we can still push for better comprehensibility by pointing at those guidelines. --Jens Lallensack (talk) 12:15, 20 January 2024 (UTC)

I'm not sure I've understood: are you proposing removing Do not unnecessarily make a reader chase links: if a highly technical term can be simply explained with very few words, do so from the MoS? It strikes me that everyone here is in agreement with that principle: it then creates a discussion around the word unnecessarily, which is where the nuance of each individual situation can come in. It's extremely valuable to be able to point at a MoS page to explain a rule that is generally held to be good sense, especially when we do so very often ("per MOS:NOFORCELINK" is much easier on the fingers and eyes than writing out a full explanation!). Reading again, I'm not totally sure where the boundaries of NOFORCELINK are, but I might suggest that the quoted phrase would be usefully included under it. UndercoverClassicist ^T·C 13:06, 20 January 2024 (UTC)

I was suggesting to remove this part: Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence. The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links. I fear now that this is just not helpful. Does it mean that every important term should be explained in-line (which is arguably "possible")? We would keep Do not unnecessarily make a reader chase links: if a highly technical term can be simply explained with very few words, do so. We could formulate this one a bit more strictly if needed. But my argument is now that this sentence is enough, and that the alternative wordings suggested above by Mike and me are basically redundant to this and the WP:MTAU guideline. Jens Lallensack (talk) 13:28, 20 January 2024 (UTC)

How about Do not unnecessarily make a reader chase links: if a term that is highly technical, given the likely readership of the article, can be simply explained with very few words, do so? Mike Christie (talk - contribs - library) 14:20, 20 January 2024 (UTC)

I'm not seeing an improvement there: yes, it gives us a way in to discuss the bounds of highly techinical, but we've also realised in this discussion that identifying "the likely readership" of an article and putting a lower bound on their level of expertise is difficult and perhaps unwise. I think the core of Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence is sound: if we think that all readers will understand the term without following the link, there's no need to explain it: conversely, as far as possible gives a way out if an explanation is felt to be impractical. ''UndercoverClassicist ^T·C 14:28, 20 January 2024 (UTC)

I just do not see what this sentence ("Use a link when appropriate …") adds. As an enforcable rule, it does not really work because "as far as possible" can be interpreted to both extremes. As additional advice, it still seems redundant to what we already have. Jens Lallensack (talk) 14:45, 20 January 2024 (UTC)

I think there's a difference in emphasis between if a highly technical term (formatting mine) -- which suggests that we generally don't explain, unless the term is highly technical -- and as far as possible do not force a reader to use that link to understand the sentence, which errs on the side of explanation. There are plenty of terms that may not be highly technical but which many of our readers, through reasons of age, first language, education, interest etc (WP:POPE), will not understand -- I think we should generally expect editors to explain them, at least when prodded to do so at FAC, unless there's a good reason to do otherwise. UndercoverClassicist ^T·C 14:51, 20 January 2024 (UTC)

But when the first sentence tells me to only explain "highly technical" terms, while the other tells me to explain all terms whenever "possible", aren't they simply contradicting each other? Shouldn't we at least combine these into a single, coherent point, to make this useful? Jens Lallensack (talk) 14:59, 20 January 2024 (UTC)

I'm not sure: compare an instruction like:

At the start of a sentence, use a capital letter. You should use a capital letter for proper nouns.

We don't understand the two to be contradictory. With that said, you're right that it would be neater, more elegant and generally better to roll the two into one statement. UndercoverClassicist ^T·C 15:27, 20 January 2024 (UTC)

You are probably right. But still, it is very unclear what "as far as possible" means. How would you apply it to the baseball article mentioned by Mike? What would be a good reason to not follow this guideline? Jens Lallensack (talk) 15:43, 20 January 2024 (UTC)

I think it's a mistake to expect or ask the MoS to be hard-and-fast: we already have plenty of deliberately vague statements of the same kind, so as to make any individual implementation a matter of nuance, discussion and consensus. A couple of examples I picked out fairly randomly -- all emphasis mine:

• Unjustified changes from one acceptable, consistently-applied style in an article to a different style may generally be reverted.
• A title should be a recognizable name or description of the topic that is natural, sufficiently precise, concise, and consistent with those of related articles. If these criteria are in conflict, they should be balanced against one another.
• [For section titles] Normally use nouns or noun phrases: Early life, not In early life
• In rare cases, a hyphen can improve clarity if a rewritten alternative is awkward, but rewording is usually preferable

UndercoverClassicist ^T·C 16:00, 20 January 2024 (UTC)

"As far as possible" is very strong - it's always possible to include explanations. I'm seeing various overlapping conditions here for inserting an inline explanation: the term

• might be obscure or unknown to the likely readership
• is unlikely to be intuited in context
• must be understood to understand the sentence (or article?) (or to put it another way, a failure to understand it would have a marked impact)
• can be simply explained in a very few words.

Whether that can be expressed in a very few words is a challenge. NebY (talk) 14:57, 20 January 2024 (UTC)

Yes. I personally use an additional condition: I will provide in-line explanations if the term cannot be easily understood even when consulting the link. This is the case when the context is crucial for interpreting the term. Jens Lallensack (talk) 15:36, 20 January 2024 (UTC)

@Mike Christie: I guess that your addition "given the likely readership of the article" is needed if we accept that the baseball article can do without any inline explanations despite having numerous technical terms (do you think we already have a consensus for that?), as otherwise it would fail this condition. Jens Lallensack (talk) 15:32, 20 January 2024 (UTC)

I'll just point out that explanations of 'technical' language don't always have to be inline. Footnotes are also a good way of allowing the text in the body to flow naturally for those who understand the topic while providing an on-the-page explanation for those who don't catch every nuance of every word or term. My personal preference is to keep the body's language understandable enough for as wide a selection of an English speaking audience as we can, but sometimes that's not always easy without dumbing down and annoying a large proportion of readers, so some flexibility in the MOS, the writing and the readers is required, although it's doubtful you'll ever manage to please anything but one of those groups at any point. - SchroCat (talk) 15:44, 20 January 2024 (UTC)

Agreed, though too many of those can be disruptive too -- especially if I'm reading a topic I am somewhat knowledgeable about, I don't want to be called to footnotes to repeatedly find they tell me things I already know. Jens/UC, can we use the language I mentioned from an earlier discussion? if knowledgeable readers feel that the flow is being broken up too much by inline explanations, non-knowledgeable readers should accept that, and be willing to accept links instead, or, if absolutely necessary, an explanatory note. Ideally the test would be to always have a neutral and knowledgeable reviewer who can assess if the article could be expressed more simply. If we don't have that reviewer available I don't think we should be insisting that the article be fully understandable without following links to whoever is the most knowledgeable reviewer who shows up, no matter how far from knowledgeable they may be in practice. (This is part of the broader problem at FAC of lack of subject-matter expert reviews.) Mike Christie (talk - contribs - library) 16:30, 20 January 2024 (UTC)

How about Do not unnecessarily make a reader chase links. If a technical term can be explained without disrupting the flow of the article for a knowledgeable reader, do so? Mike Christie (talk - contribs - library) 16:49, 20 January 2024 (UTC)

I like it in principle, except for that explanations will always disrupt the flow to some extent (some editors even feel that inline citation used within sentences disrupt flow). It has to be a compromise. Maybe write "[…] without unduly disrupting the flow […]"?

Regarding the language from the other discussion: Do you suggest to combine it with the NOFORCELINK statement? I personally feel that this speaks to the readers ("readers should accept …"), which is awkward as they don't have a choice; we should only speak to authors. Jens Lallensack (talk) 17:57, 20 January 2024 (UTC)

I was thinking that the two sentences I suggested should replace the entire existing NOFORCELINK wording. Not sure about "unduly" -- given we're in the realm of editorial judgement anyway I'd be inclined to omit adverbs as unlikely to be helpful. But with or without, do you think the wording acceptable? Mike Christie (talk - contribs - library) 19:01, 20 January 2024 (UTC)

I am wondering if we really need that other sentence ("if knowledgeable readers feel …"). There does not seem to be additional advice/insight in there (?), and shorter/simpler is better imo. I am also wondering if we can do without the "for a knowledgeable reader" in the first sentence; it does not seem to add anything and sounds a bit like "knowledgeable readers" would be prioritized (which is not the case). Instead, we could maybe just add some more specific advice. What about: Do not unnecessarily make a reader chase links. If a technical term can be explained without disrupting the flow of the article, do so. Inline explanation or footnotes can be especially helpful when a technical term is likely to be unknown to many readers and unlikely to be intuited in context; must be understood to understand the sentence in general terms; or is difficult to understand in the context of the sentence by consulting the wiki-linked article. (Wording partly based on what NebY posted above). I am not sure if that second part is needed, but let me know what you think. Jens Lallensack (talk) 20:06, 20 January 2024 (UTC)

Sorry, I wasn't being clear about what I meant. I meant to suggest that we change NOFORCELINK to Do not unnecessarily make a reader chase links. If a technical term can be explained without disrupting the flow of the article for a knowledgeable reader, do so. My hope is that including the point about "the flow of the article for the knowledgeable reader" covers the baseball case but "do so" doesn't prevent us from expanding and explaining as much as possible. It's an attempt to say the same thing as ONEDOWN without requiring the levels implied by ONEDOWN to be defined. Mike Christie (talk - contribs - library) 20:10, 20 January 2024 (UTC)

I am ok with this wording. I still feel that "the knowledgeable reader" is not needed for the intended meaning (after all, it refers to "disrupting the flow", not to any levels). I think that the baseball case would be covered even if we remove it. But it is a minor point. Jens Lallensack (talk) 20:31, 20 January 2024 (UTC)

I would support Mike's wording and replacement as a proposal. Jens' proposal also works: I'd suggest cutting the second part to a more straightforward suggestion that footnotes are an option for this thing: not sure how essential the material after especially helpful would be, but I can see the argument for giving reviewers a line like "I think this term is unlikely to be intuited in context" or similar. UndercoverClassicist ^T·C 20:13, 20 January 2024 (UTC)

I also support Mike's proposed wording. Hawkeye7 (discuss) 20:29, 20 January 2024 (UTC)

Jens, any objections if I start a new section proposing my wording, to see if there's consensus? I do it prefer it to your wording but if you want to discuss further or wait to see if others chime in that's fine with me. Mike Christie (talk - contribs - library) 22:23, 20 January 2024 (UTC)

No objections at all, please go ahead! Jens Lallensack (talk) 22:48, 20 January 2024 (UTC)

In books, I usually find footnotes go into extra detail, providing a higher level of scholarship – is that peculiar to my reading? Many Wikipedia footnotes too are similarly explanatory and expansive, so clicking to a note only to find a dictionary definition can be very frustrating. NebY (talk) 17:08, 20 January 2024 (UTC)

We’re talking about a webpage, not a book - and that’s a critical difference. We have entire articles to go into extra depth. Personally I find it frustrating to hit a wall of techno babble in an area in which I’m not an expert, although I’m also frustrated when in an article on cricket I have to be told what are (for me) basic terms. Footnotes can provide a middle path between the two. I’ll repeat what I said in my first post: “some flexibility in the MOS, the writing and the readers is required, although it's doubtful you'll ever manage to please anything but one of those groups at any point“. - SchroCat (talk) 17:20, 20 January 2024 (UTC)

Proposed wording

There's the beginnings of a consensus above on a proposed wording, so I am pulling it out to make a clear proposed change. I've changed the first sentence of the version discussed above to match NOFORCELINK's existing phrasing, both to make this a minimal change and because the compressed version isn't as clear.

I propose we change NOFORCELINK from

Do not unnecessarily make a reader chase links: if a highly technical term can be simply explained with very few words, do so. Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence. The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links.

to

Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence. If a technical term can be explained without unduly disrupting the flow of the article for a knowledgeable reader, do so.

This is not a formal RfC but if anyone thinks it necessary I can make it one. In any case I'd rather wait to do that until we see if this form of words does have significant support. Mike Christie (talk - contribs - library) 23:03, 20 January 2024 (UTC)

Note: "unduly" added to the proposed wording per a comment below. Mike Christie (talk - contribs - library) 13:01, 23 January 2024 (UTC)

Just to be clear, do you intend to keep the other existing and very similar sentence in MOS:L (Do not unnecessarily make a reader chase links: if a highly technical term can be simply explained with very few words, do so. in addition, or is this going to be replaced, too? Jens Lallensack (talk) 23:24, 20 January 2024 (UTC)

My mistake -- I intended that to be replaced too as I see it as part of NOFORCELINK. I've edited the above to include that text in the "before" wording. Mike Christie (talk - contribs - library) 23:38, 20 January 2024 (UTC)

As above, I'd support this wording at an RFC (and note that I consider the second sentence of the new wording and the first sentence of the old one to be equivalent -- but it's always better to tell people what to do rather than what not to do.) UndercoverClassicist ^T·C 10:04, 21 January 2024 (UTC)

No objections so far, and (counting Jens and Hawkeye7 above) four supports for this version. If there are no objections in the next week or so I will make the change. Mike Christie (talk - contribs - library) 11:41, 22 January 2024 (UTC)

Seems sensible to me. Lee Vilenski ^{(talk • contribs)} 13:50, 22 January 2024 (UTC)

I like Jens Lallensack's earlier suggestion at #Working proposals (above) to add unduly: If a technical term can be explained without unduly disrupting the flow of the article for a knowledgeable reader, do so. It hopefully conveys that some knowledgeable readers might be somewhat disrupted by a "dumbed down" version, but it's for the common goal of making the article more widely accessible.—Bagumba (talk) 16:02, 22 January 2024 (UTC)

I'm concerned that this is the sort of thing that is very subjective, and may be applied inconsistently at FAC, which as has been pointed out, is the only place it really matters. At the very least, I'd like to see some examples given. Wehwalt (talk) 19:15, 22 January 2024 (UTC)

Yes, it's subjective, but so is MOS:OVERLINK. That in itself is not a showstopper. —Bagumba (talk) 07:42, 23 January 2024 (UTC)

True. But MOS:OVERLINK has a long series of examples and other guidance. Wehwalt (talk) 12:28, 23 January 2024 (UTC)

I'm also more sympathetic to Gog's view above - I'd prefer to privilege the non-expert reader. Nikkimaria (talk) 03:14, 23 January 2024 (UTC)

I think everyone agrees that the non-expert reader should be catered to. A sentence such as After Brooklyn was retired in order in the top of the third inning, Oeschger doubled to center field to lead off the home half of the inning, and Powell sacrificed him to third base, from a recently promoted FA, can't be usefully explained to a non-expert reader without ruining the reading experience for a baseball aficionado. The current version of NOFORCELINK, in my view, makes no allowance for this limitation, and the revised wording is intended to address that -- to promote inline explanations (with the "do so" at the end of the revised wording) but acknowledge that this simplification has to be limited to avoid making the article unfit for expert readers.

Wehwalt, would the sentence I just quoted to Nikki serve as the example you're looking for? And I'd argue that NOFORCELINK is less subjective and more absolutist in its wording and that's a bad thing. You had to argue past the current wording of NOFORCELINK in the FAC for the baseball article. Wouldn't it be better to have a version that acknowledged the role of editor judgement? Mike Christie (talk - contribs - library) 11:46, 23 January 2024 (UTC)

Yes, that would be a good example. Wehwalt (talk) 12:31, 23 January 2024 (UTC)

I have to agree with Wehwalt's point on subjectivity, though. Don't we have double standards here? It is apparently ok for a sports article to not explain any term, but articles on other topics are supposed to. But what exactly sets the sport articles apart from the others? For my dinosaur articles, I could argue that explanations destroy the flow for dinosaur aficionados, and therefore not explain anything. Does the new wording mean that I can get away with that? Jens Lallensack (talk) 12:51, 23 January 2024 (UTC)

There's nothing in the new wording about sports; I would expect it to apply to all articles. No, I don't think one could just "not explain anything" -- the proposed wording says "If a technical term can be explained without unduly disrupting the flow of the article for a knowledgeable reader, do so". A reviewer might ask for further explanations and the line at which the resulting flow is "unduly disrupted" is what editors would have to agree on. Yes, it's subjective, but I don't think we've come up with anything better than this. Mike Christie (talk - contribs - library) 13:01, 23 January 2024 (UTC)

I suspect in a lot of areas, the matter under discussion is just not capable of being explained in a few words to those who know nothing about dinosaurs, or baseball, or mathematics. Therefore, I confess to being still a little perturbed at even having to post a defense to a reviewer who tells me to explain the infield fly rule when it's mentioned in passing in a baseball article, it should be understood that some articles are not basic-knowledge level in their field and require some level of knowledge before coming to the article. Wehwalt (talk) 13:13, 23 January 2024 (UTC)

I suspect in a lot of areas, the matter under discussion is just not capable of being explained in a few words to those who know nothing about dinosaurs, or baseball, or mathematics: I see the frustration of having to respond to comments that we feel are unwise or ill-judged, but would it be so much of a hardship to write something like "yes, this bit's a little specialist, but there isn't really a good way to explain all of this without disrupting the flow (see MOS:NOFORCELINK), and the details are only really of interest to people who already know the basics"? It strikes me that the proposed wording, by having the word unduly, gives a very clear route to explain why an inline explanation has not been offered in a specific case. I'd hope that reviewers would consider their own sense of how disruptive an explanation would be before offering such a comment -- therefore, that if they did ask for an explanation, they would do so believing that it could be done without causing a major problem. UndercoverClassicist ^T·C 13:21, 23 January 2024 (UTC)

@Wehwalt: Sure, we have to require some level of knowledge. But, if I interpret the new wording of NOFORCELINK correctly, that still means we should explain at least some terms (those for which an explanation makes the most sense, especially when they are less widely known but important for the sentence). However, the example baseball article here does not make any attempt to explain any term as far as I can see. How does this not violate the new wording of NOFORCELINK? Jens Lallensack (talk) 13:29, 23 January 2024 (UTC)

I do remain nervous about "as far as possible". A harsh reviewer might insist that it's obviously possible and that this takes precedence – and was recently reviewed too! Maybe a little reshuffling and rephrasing would work: Use a link when appropriate, but if a technical term can be explained without unduly disrupting the flow of the article for a knowledgeable reader, do so. Try not to force a reader to use the link to understand the sentence. "Try not to" may be too weak but a bald "Avoid" might be too strong; is there something suitable in between? NebY (talk) 14:00, 23 January 2024 (UTC)

The article does not attempt to discuss baseball terms because the accepted way of helping the reader there was to provide links. Baseball, a constructed game with fixed and not always intuitive rules, is difficult to discuss and its terms difficult to define if you are trying to discuss them or define them without any reference to baseball whatsoever, something that the hypothetical reader without knowledge of baseball would presumably need. Wehwalt (talk) 14:14, 23 January 2024 (UTC)

I can't think that any reviewer (or co-ordinator) would disagree that explaining the infield fly rule from first principles is unduly disrupting the text -- I don't think any MoS change can avoid stubborn reviewers! But then the coordinators are also empowered to disregard objections which are not felt reasonable. UndercoverClassicist ^T·C 14:29, 23 January 2024 (UTC)

I agree that those terms cannot be explained to a reader without knowledge, and without any reference to baseball. That is not my point: There are, I assume, many readers with basic knowledge of baseball, who know terms such as "inning", but may struggle with some terms that are more specialized. My interpretation of the new NOFORCELINK wording (also based on Mike's explanation above) would be that the article should attempt to explain those more specialized terms where they matter whenever possible (using more basic baseball terminology). So consequently, a baseball article will have to provide some explanations that improve the accessibility of the article in order to comply with the new wording of NOFORCELINK. Or do I misunderstand something? Jens Lallensack (talk) 14:32, 23 January 2024 (UTC)

I don't know. Nothing extraordinary happened in the game other than it went on for a long time, which was the extraordinary thing that made it notable. If one knows enough about baseball to follow a newspaper account or a television broadcast, one should be fine. That way, of course, lies a can of worms with implications for many articles, if the test is that if one has casual acquaintance with the subject matter, every technical term should be explained inline. Wehwalt (talk) 14:47, 23 January 2024 (UTC)

I like the idea with giving examples. However, I think that the examples should be entire articles, not single sentences. Only articles can find the balance between explanations and reading flow that we are looking for; we can't tell from a single sentence which explanations are helpful or disruptive in the given context. The baseball example sentence suggested above is misleading in my opinion: Most of those terms were mentioned earlier in the article already, and for this reason alone should never be explained in this particular sentence. I think that the context is more important than the sentence itself; entire articles are therefore much more helpful as examples. Jens Lallensack (talk) 14:20, 23 January 2024 (UTC)

On reflection I agree that entire articles are better examples than individual sentences, for the reason you give -- at least to demonstrate cases where NOFORCELINK should not apply. The baseball article, Brooklyn Dodgers 1, Boston Braves 1 (26 innings), seems like it could work as an example. Wehwalt, I take your point that that article uses links as the way to help readers, not inline explanations. I think the question here is whether the current or proposed wording of NOFORCELINK are in sync with that approach. (Or if a better wording can be found than the current proposal.). I think the comments you received at the FAC would have been easier to respond to with the proposed wording of NOFORCELINK, because any knowledgeable reader would be annoyed by almost any inline explanations in the game paragraphs. There's an expectation in descriptions of baseball gameplay that the reader can follow along.

I think that means we need two examples: one to show when NOFORCELINK does not apply but also one to show when it does. How about radiocarbon dating for the latter? It explains terms like "anticoincidence counter" inline, and gives details about how accelerator mass spectrometry works, but does no more than link terms like tephra and varve that are peripheral to the core subject. Mike Christie (talk - contribs - library) 12:06, 24 January 2024 (UTC)

As discussed above, I am not convinced that NOFORCELINK does not apply to Brooklyn Dodgers 1, Boston Braves 1 (26 innings). The article contains terms that are not even mentioned in the basic article Baseball (such as "spiked" and "wild pitch"). Above, Whewalt noted that "if one knows enough about baseball to follow a newspaper account or a television broadcast, one should be fine", but NOFORCELINK asks for a bit more: Each sentence should be understandable if possible, not only the article in general.

If we need another alternative, I could offer Bajadasaurus. The NOFORCELINK issues of this very technical and specialised article have been extensively discussed during the FAC, and the result is a good compromise (I hope). The article explains numerous terms, often in a gloss, sometimes several in one sentence. I think that it has the maximum of inline explanations that is possible without unduly disrupting flow, and could therefore be an example for the "upper bound" (which, I think, is not reached by the other two examples). Jens Lallensack (talk) 14:29, 24 January 2024 (UTC)

A wild pitch is an ordinary baseball play that occurs in most baseball games, and is appropriately linked. Spiking, these days, is rarer but not unknown and is appropriately linked. They would be within the knowledge of anyone with sufficient knowledge to follow a baseball article. And the baseball article went though a TFA, the acid test of an article, without any adverse comment as to terminology.

Regarding the dinosaur article being proposed: Without too much effort, I found undefined technical terms in that article, that are not linked such as one finds with "wild pitch" and "spiking". "Margin" and "brittle deformation" to start with.

I should note that dinosaur articles at least have the advantage of describing anatomical features that are analogous to those familiar to humans. A skull is still a skull, a fundamental thing that has remained as time goes by. The reader, having such an object themselves, understands it intuitively. That's a very different situation from baseball, which is an artificial sport with idiosyncratic terminology. So I don't know if we're going to reach common ground here. Wehwalt (talk) 14:55, 24 January 2024 (UTC)

More difficult baseball terms can be explained using basic baseball terminology, so I cannot quite follow the problem with the "idiosyncratic terminology". That people with a basic understanding of baseball will know all these terms as you say – I don't know. But I very much doubt that these terms are all on the same difficulty level – there will be some that are more difficult than others, and those are the candidates that might warrant explanations. This is what ONEDOWN asks for: Take the subject matter down to a lower level. And I would even argue that every article could be written "one level down", so I am not sure if there can possibly be an article for which NOFORCELINK "does not apply". Jens Lallensack (talk) 15:41, 24 January 2024 (UTC)

ONEDOWN works well for topics with a single, clearly identifiable "level". What about articles that aren't that? For example, to be a "knowledgeable reader" for the entirety of the article on Elvis Presley would require an understanding of music, film, and to some extent military and general history as well. It's also an article that is likely to attract a very broad general readership. How does the ONEDOWN principle apply to this? Nikkimaria (talk) 06:18, 25 January 2024 (UTC)

I think ONEDOWN was written with technical topics in mind and is hard to apply to articles like Elvis Presley. That's why I was hoping "knowledgeable reader" would suffice as a way of defining who is being written for; it doesn't depend on levels. I had a look through the Presley article to see what is explained inline (I.e. what could be considered to be because of NOFORCELINK). There's not much: acetate disc is linked but not explained, for example, but discarded X-ray plates might be considered an inline explanation for "ribs" in that sense.

The reason I wanted to rewrite NOFORCELINK was not because I don't want to explain things inline in all cases, but because I think its wording is too absolute. I would like wording that can be used to say editorial judgement has to be involved in deciding how far to go in explaining. "Knowledgeable reader" is an attempt to define that, but if even less defined wording were acceptable I could go along with it. Something like Use a link when appropriate. If it is possible to explain technical terms inline, do so, but use editorial judgement as to whether this can be done without unduly disrupting the flow of the article.. I think Wehwalt made a judgement call (for the baseball article) that almost any inline explanations would be disruptive, and I agree. I don't see how the current wording of NOFORCELINK permits that and I think that should be fixed. Mike Christie (talk - contribs - library) 08:11, 25 January 2024 (UTC)

I think that's ended up as a tautology: unduly is, by definition, a matter of judging what is [due]. How would one assess that if not by us[ing] editorial judgement? UndercoverClassicist ^T·C 08:53, 25 January 2024 (UTC)

Fair point. Is there a wording that invokes editorial judgement that you could support? Mike Christie (talk - contribs - library) 09:12, 25 January 2024 (UTC)

Honestly, I wouldn't oppose this wording -- the perfect is the enemy of the good, and all that. To me, there are plenty of terms -- appropriate, unduly -- that already call for judgement, but I can see the value in explicitly invoking it. However, I can see the value in reinforcing the point that this is a particularly subjective "rule". UndercoverClassicist ^T·C 10:07, 25 January 2024 (UTC)

That's more encouraging than I expected. Nikki, how about you? You indicated you agreed with Gog that we should privilege the non-expert reader. This wording does that less than the existing wording, by placing that exhortation under editorial judgement. Would you oppose this wording? Mike Christie (talk - contribs - library) 11:38, 25 January 2024 (UTC)

The proposed wording overtly privileges the knowledgeable reader over the non-knowledgeable, which seems contrary to Wikipedia's key values. (In passing I continue to believe that such a fundamental change needs a widely advertised RfC.) Would there be an issue in deleting "for a knowledgeable reader" from the proposed wording? This would seem to address the perceived problem without overtly making comprehension for a non-aficionado optional. Gog the Mild (talk) 12:52, 25 January 2024 (UTC)

Agree re an RfC. I don't want to start one unless we have at least some agreement here, though. To your point: how about the wording I suggested to Nikki above: Use a link when appropriate. If it is possible to explain technical terms inline, do so, but use editorial judgement as to whether this can be done without unduly disrupting the flow of the article? Mike Christie (talk - contribs - library) 13:31, 25 January 2024 (UTC)

I disagree with the contention that it is contrary to Wikipedia's values, given our educational mission. Hawkeye7 (discuss) 00:22, 30 January 2024 (UTC)

I will think on't, but my first thought is that this abdicates responsibility. This is meant to be policy, and that wording seems to barely even be guidance. I mean, given a disagreement and both parties turn to the policy to settle matters: that is not going to help a lot. The first version was clear, even though I am opposed to it.

Having thought a bit, this wording seems even worse than that originally proposed. It is effectively saying "So long as you have a link it doesn't matter whether the prose makes sense to a non-expert". The original at least preserved a fig leaf of writing for a general audience. Gog the Mild (talk) 13:54, 25 January 2024 (UTC)

Yeah, I think we're heading in the wrong direction. Nikkimaria (talk) 00:00, 26 January 2024 (UTC)

I'm going to stop trying to find a form of words that can get general support. I still think the existing wording does not reflect actual practice, and it would be better to find wording that reflects what we really do: we do try to improve readability for non-experts, but the reasons we don't or can't always move very far in that direction are not acknowledged in the current wording. However, the MoS is a guideline, not policy, and at FAC a nominator can always say they think the application of a MoS rule doesn't make sense for a given article. Mike Christie (talk - contribs - library) 06:47, 26 January 2024 (UTC)

Example

I'm reviewing Beulé Gate by UndercoverClassicist right now. The following sentence reminded me of this discussion:

The area above the central doorway is decorated in the Doric order, and consists of an architrave in Pentelic marble, topped with marble metopes and triglyphs and made from a variety of limestone known as poros stone. Above the metopes and triglyphs is a geison with mutules, itself topped with an attic

There's nine different linked terms there and I don't konw what any of them means. Yet, the sentence makes complete sense and I know how to click to get more detail on any of them if I want. If this sentence was rewritten with parenthetical explanations for each of those terms, it would be crazy complicated and distinctly less readable. — Preceding unsigned comment added by RoySmith (talk • contribs) 00:22, 30 January 2024 (UTC)

Under the current wording, if this were to be quibbled in the review, I'd plead "as far as possible": as you say, it isn't possible to include inline explanations for all of these without breaking the MoS and policy in other ways (by creating an unreadable sentence). If the guideline were changed to something like Use a link when appropriate, but if a technical term can be explained without unduly disrupting the flow of the article for a knowledgeable reader, do so., I'd give this as precisely the reason unduly is included: we're talking about architectural minutiae, so the details here are pretty immaterial to most readers: the value of the inline explanations is outweighed by the cost of doing so. Incidentally: thank you for raising this here -- it's helped me spot a couple of mistakes! UndercoverClassicist ^T·C 07:27, 30 January 2024 (UTC)

My point above makes sense here. Do we need to know what the Doric order is to understand the context? This piece explains what "poros stone" is (limestone), and "pendalic marble" does pretty much stand out that its a type of marble. There are some more confusing items, such as triglyphs and mutules, but I have no idea how you'd explain them other than being architectual terms. Lee Vilenski ^{(talk • contribs)} 09:19, 30 January 2024 (UTC)

On the triglyphs and geison at least, there's also a photograph immediately to the right with a caption that makes them (hopefully) fairly obvious: I'd suggest that that also would play some kind of role in the level of possible confusion and therefore the overall discussion as to how necessary/valuable an inline explanation would be. As with most things MoS, it's a cost–benefit analysis. UndercoverClassicist ^T·C 09:46, 30 January 2024 (UTC)

I'd start of the second month. 2A00:23C7:4F01:1201:894B:E257:1DF6:C83E (talk) 21:52, 11 February 2024 (UTC)

NOPIPE, piped links, and VisualEditor

Editors interested in MOS:NOPIPE, and the use, creation, and modification of piped links in Visual Editor may be interested in the discussion going on at WP:VPT#Piped links with VisualEditor. Thanks, Mathglot (talk) 23:40, 3 February 2024 (UTC)

Section level and duplink

Since we've changed the duplink policy to be links may or may not be suitable for the first time in a section, I've had users change this for all section headers (so even for level four headers, they have a new link). Can I confirm that when we say the first usage per section, we mean the first use per level 2 header? Lee Vilenski ^{(talk • contribs)} 15:39, 4 February 2024 (UTC)

The MOS was since tweaked to "major section"[2] —Bagumba (talk) 04:00, 25 February 2024 (UTC)

Ok, but what does "major" mean? Level 2 only? Level 3? I think past level 3 wouldn't qualify, but I can see arguments for 3. SMcCandlish you added in "major" to this wording. What was your intent? - Favre1fan93 (talk) 17:54, 26 February 2024 (UTC)

I was unsure what the MOS meant and started this discussion over at WT:SNOOKER, regarding an article I was working on (2024 German Masters). The consensus was to limit to level 2 for snooker tournament articles. I think it's worth a discussion for further clarifying the broader MOS though, not just for snooker articles. Specifying level 2, 3, etc., and perhaps have different criteria for articles of different topics. AmethystZhou (talk) 18:05, 26 February 2024 (UTC)

"Major" is level 2 (== ... ==). Gawaon (talk) 18:12, 26 February 2024 (UTC)

Rather, "major" is descriptive of the depth and importance of the content. If "level 2" was meant, then "level 2" is how it would read. There are innumerable cases of L2 headings (usually toward the end of an article) that contain nothing but a sentence or two of material that is or verges on trivia. Meanwhile, some articles have various L3 subsections that contain the majority of the actual content, each of them longer than most L2 sections in most other articles.  — SMcCandlish ☏ ¢ 😼  19:05, 26 February 2024 (UTC)

My intent was to curtail the sort of excessive link repetition that Lee Vilenski reports (which is obviously contrary to the intent of the change the community approved in the RfC about linking more than once per article), but without imposing or implying a mathematically rigid cut-off (we should always leave to editorial judgement that which can be left to it). Various very long and detailed articles are divided into a few sections which each consist of several subsections are that are the "main" or "major" content, with the level-2 headings just acting as grouping frames. In most cases, though, articles are divided mostly or even only into level-2 headings, with most of the content being directly under them. (And there's also of course the fact that a term/name might appear first at level-2 then be repeated 1000s of words later in another section's level-3 or level-4 subsection; it would still qualify as having reappeared within another major section, just also withing a lower-level subsection of said major section.) One size rarely fits all when it comes to article structure matters. If we think some explanation of "major" is needed (or some term it is replaced by) this can be put into a footnote instead of making the MoS line-item about this more verbose itself. It's also important to remember that consensus actually mostly lives in discussion. Someone cannot drum-beat their preferred but wrong interpretation of something in a guideline is the talk archive about implementing it in the first place contradicts them. So both the original RfC and this discussion will remain evidentiarily pertinent in any interpretation dispute.

It's normal and expected for editorial consensus to be reached on an per-article basis; we treat all of MoS this way with regard to a guideline line-item that has interpretational wiggle-room, and this is by design. (Remember that MoS is not a policy, and is intended to produce consistent and useful content for readers, and secondarily to settle inter-editor disputes about style, broadly defined.) While wikiprojects coming to a "local consensus" on such a matter across a category of articles can sometimes be problematic per WP:CONLEVEL policy (namely, when those editors' preference is against a site-wide consensus, or conflicts with equally principled preferences of editors who are not part of that in-crowd; see, e.g., WP:ARBINFOBOX), in a case like this there is no issue, because all the articles in the affected group are structurally the same, so a page-by-page re-discussion of the same question would be a redundant waste of editorial time.  — SMcCandlish ☏ ¢ 😼  19:05, 26 February 2024 (UTC)

I agree that we shouldn't be too prescriptive, but perhaps a small addition that clarifies this intention would help? i.e. "Major sections will generally be detailed sections with a level 2 heading, but local consensus could determine that a lower level section is 'major'.". - adamstom97 (talk) 19:45, 26 February 2024 (UTC)

I agree that some kind of clarification be good to have. I obviously misunderstood what's meant by "major section", and I suspect I'm not the only one. Though I could also live with just changing it to "level 2 section", which would simplify things. Gawaon (talk) 20:33, 26 February 2024 (UTC)

Put a foonote in, though one that tries to more directly address some of the RfC rationale in addition to what was said above. A major point in the RfC was people arriving directly at [sub]sections by redirects and prominent links from other articles. While we can never "prevent" someone linking to, say, an obscure level-5 heading for some reason, this isn't common and the average reader is going to understand that they may have to scroll up a bit to make complete sense of the material. However, if a subsection is thematically devoted to a discrete subtopic, with various redirects and frequent mentions in other articles, that section being rather stand-alone is a benefit to readers (especially on mobile).  — SMcCandlish ☏ ¢ 😼  21:21, 26 February 2024 (UTC)

• Indeed, SMcCandlish. This was a very bad change to the rules promoting considered linking only. When people get into these debates it's as if a reader can't type a target into the search box. Takes seven or eight seconds. Tony (talk) 04:37, 28 February 2024 (UTC)

Discussion about MOS:FORCELINK in infoboxes

There is currently a discussion about MOS:FORCELINK's application in infoboxes. Any feedback from knowledgeable editors would be greatly appreciated. Thanks! Nemov (talk) 21:21, 5 March 2024 (UTC)

Wiktionary links and overlinking

In articles about CJK (Chinese, Japanese, and Korean) cultures, tons of Wiktionary links have been added to non-English terms (they usually use Template:Linktext). Is this overlinking or not? I started to think that they are overlinking, but it does not seem that MOS:OVERLINK directly says something about this. 172.56.232.211 (talk) 05:56, 6 March 2024 (UTC)

"In articles" is not helpful. Specific examples? -- Michael Bednarek (talk) 07:13, 6 March 2024 (UTC)

Here are cases in Korean. Some people have been adding Wiktionary links to tons of Korean terms. Isn't this overlinking? Wikipedia does not have to provide a link for every single non-English lexical item. 172.56.232.211 (talk) 03:21, 7 March 2024 (UTC)

Thanks for the link. IMO the Wiktionary links can be useful and provide further information, although I would prefer in-text translations. Where those are already there, the Wiktionary links seem unnecessary. Whether those links contravene MOS:OVERLINK, I can't say. OTOH they're not harmful. -- Michael Bednarek (talk) 04:49, 7 March 2024 (UTC)

Linking aside, MOS:FOREIGN advises:

Non-English terms should be used sparingly.

The essay Wikipedia:Writing better articles § Use other languages sparingly says:

It is fine to include foreign terms as extra information, but avoid writing articles that can only be understood if the reader understands the foreign terms.

Foreign words that are not that common in English, when used, should have a MOS:SIMPLEGLOSS.—Bagumba (talk) 07:21, 6 March 2024 (UTC)

I'd be wary of making this common practice for such articles. Tony (talk) 06:44, 7 March 2024 (UTC)

Piped links through redirects

This topic is about whether it is ever preferable to use a redirect link in a pipe.

Joy and I are in a minor editorial dispute over my post-move activities after the close of an RM resulting in the move of Bojana (river) to Buna (Adriatic Sea). I have made various edits to articles that link to the resulting "Bojana (river)" redirect, and have been cleaning up the piped links when encountering the following typical scenarios:

1. [[Bojana (river)|Buna]]
2. [[Bojana (river)|Bojana]]

Irrespective of whether the term after the pipe is Buna or Bojana, I have been changing the link (before the pipe) to "Buna (Adriatic Sea)" with the rationale that the link in a piped link should always be the direct link, producing:

1. [[Buna (Adriatic Sea)|Buna]]
2. [[Buna (Adriatic Sea)|Bojana]]

Joy on the other hand has suggested on my talk page that if the term presented to the reader is "Bojana", the piped link markup should remain as follows:

• [[Bojana (river)|Bojana]]

... and that changing the piped link in this case to [[Buna (Adriatic Sea)|Bojana]] is a "pointless activity" that should not be done and is worthy of being reverted.

It appears that she has not contested changing [[Bojana (river)|Buna]] to [[Buna (Adriatic Sea)|Buna]].

I am of the opinion that in no case do we maintain piping through redirects as a good practice, and that it is completely irrelevant whether the term after the pipe is "Buna" or "Bojana"; the term before the pipe should always be the direct link, not a redirect link. This is because we don't want to introduce the reader to the name of the redirect which they hadn't previously seen, because it's hidden in the piped link markup, and it's preferable to link directly whenever possible, and not through a redirect. Joy, on the other hand suggests that piping through a redirect that is similar to the term visible to the reader, which produces the redirection notification at the destination article, is useful.

Should the MOS be clearer that piped links and redirect links are different techniques that should not be mixed, and that only direct links should be used before the pipe, and not redirect links?

MOS:DABPIPE says that Piping and redirects are two different mechanisms and WP:PIPE says Do not confuse piped links and redirects. But should MOS:PIPE also say something about this? Something like:

When piping, the reader should be led to the destination article directly, and not through a redirect.

—Alalch E. 23:53, 5 April 2024 (UTC)

Joy is correct. The MOS says nowhere "that only direct links should be used before the pipe", and for a good reason. A very common use of pipe markup is simply to remove the disambiguator in parentheses, and write e.g. [[Bojana (river)|]] (with nothing after the pipe). On storing the page, our software autoconverts such links to [[Bojana (river)|Bojana]]. Such autogenerated piped links are fine, very common (in fact the most frequent kind of piped link, I would suspect) and thanks to our redirect mechanism, they'll continue to work as before if a page was moved. So why should you change the invisible URL to use "Buna" if you leave the visible word ("Bojana") intact? There is really no reason to so do. Gawaon (talk) 06:35, 6 April 2024 (UTC)

I agree with Joy and Gawaon. I don't understand "we don't want to introduce the reader to the name of the redirect which they hadn't previously seen". As far as I can see, the only names which the user sees are the one didplayed by the pipe, and the one displayed in the target article to which the link takes them: whether they are taken there directly or via a redirect mskes no difference whatever to what names we "introduce the reader to". Or have I misunderstood what "we don't want to introduce the reader to the name of the redirect" means? Also, there are several good reasons why links via redirects can be desirable, such as the fact that the link will remain valid if the redirect is retargetted or turned into an article, and I fail to see why anyone would think such reasons become less valid just because the way the link is didplayed in the article is different, which is all that piping is about. The difference between a piped link and an unpiped link is only a matter of what text is shown for the link in the article containing it, snd I see no reason why the mechanism whereby the reader is taken to the target article should depend on how the text is displyed. "The link in a piped link should always be the direct link" makes no sense, unless we also have "the link in an unpiped link should always be the direct link"; why treat the two cases differently? JBW (talk) 13:43, 12 April 2024 (UTC)

I agree. As WP:NOTBROKEN advises, there are many cases where it's preferable to link to a redirect. Especially if there's a retarget or an article is written, as you mention, it's much easier for everyone if the backlinks are all already going to the right place, rather than someone having to tease out which backlinks should be retargeted. (I did this a while ago with a few hundred pages referencing school segregation that should have been linking to school segregation in the United States, and eventually burned out.) The exception would be for unprintworthy redirects like typos and nonstandard disambiguation schemes, which we shouldn't deliberately drive traffic to. -- Tamzin^{[cetacean needed]} (they|xe) 04:02, 18 April 2024 (UTC)

Ambiguity in GEOLINK examples

MOS:GEOLINK gives two examples: Sydney, Australia; and Buffalo, New York, United States. This creates an ambiguity, which Pi.1415926535 and I agreed to raise here after it came up in a GAN: Is the point of the two examples that the link should span all words except the country name, or do they describe two alternate approaches, meaning that one can equally write "Buffalo, New York, United States"? For that matter, could one write "Sydney, Australia"?

I think clarity on this would be helpful. I don't hugely care about what answer is settled on, although as I've said at the GAN, I do think that there's a moderate accessibility benefit to the linked text spanning only the city name: I have difficulty distinguishing black from blue in small quantities, and, if I hadn't modified my common.css to address that, "Buffalo, New York" and "Buffalo, New York" would look almost identical to me, making it unclear, when I click on "New York" there, where I'm going to be taken. -- Tamzin^{[cetacean needed]} (they|xe) 03:42, 18 April 2024 (UTC)

My reading of it has been that the link should generally match the article name (i.e, Buffalo, New York as a single link). However, that does get complicated for mononymic articles like Sydney in areas where other cities (c.f. Campbelltown, New South Wales) have the larger unit in the article name. I definitely agree that only a single link should be used regardless of the style. Pi.1415926535 (talk) 04:50, 18 April 2024 (UTC)

I don't see any ambiguity in MOS:GEOLINK. Link what must be linked, don't link what need not be linked, avoid pipes. -- Michael Bednarek (talk) 06:20, 18 April 2024 (UTC)

But in the case of Buffalo, isn't it only "Buffalo" that must be linked? ", New York" is a disambiguator included in the article title, not actually part of the common name of the place, which is just "Buffalo", just as the common name of Sydney is "Sydney". I can't think of any other place where, in deciding what text to link, we care about how the relevant article is titled. -- Tamzin^{[cetacean needed]} (they|xe) 14:49, 18 April 2024 (UTC)

No, since the article title is Buffalo, New York, just link that completely. Writing that as [[Buffalo, New York|Buffalo]], New York would just be needlessly convoluted. Gawaon (talk) 15:30, 18 April 2024 (UTC)

I don't see what's convoluted about that. It's clear to our readers where the link will take them, and that's much more important than a few extra bytes of wikimarkup. It also provides consistency in a case where articles have inconsistent disambiguation due to the peculiarities of the article title policy. Otherwise we wind up with things like "the distance from Toronto, Ontario, Canada, to Niagara Falls, New York, United States". Anyways, if it really is the case that this guideline is supposed to defer to the article title policy in determining what words to link—which, again, seems strange, but whatever—that should be clarified, for my sake and the sake of 206 other usages of "Buffalo, New York" alone (and 137 of "Phoenix, Arizona", and so on and so forth.). -- Tamzin^{[cetacean needed]} (they|xe) 16:15, 18 April 2024 (UTC)

I don't see anything bad about your example. Niagara Falls is a smaller city than Toronto so it's not particularly surprising. I guess if you prefer to write it in a more complicated manner, nobody will trout you for it, though I'd certainly simplify any case of [[Buffalo, New York|Buffalo]], New York I encounter in an article I edit to [[Buffalo, New York]] without any pang of bad conscience. (Though I would be too lazy to chase it through articles I don't otherwise edit.) Gawaon (talk) 17:42, 18 April 2024 (UTC)

Niagara Falls is a smaller city than Toronto so it's not particularly surprising ← Is that intuitive to readers, though? It just looks unbalanced. If I saw that as a lay reader I would think, why does one link only the city and one link also the next level? I don't necessarily think the approach you advocate should be forbidden, but it seems reasonable to allow either as long as it's consistent within an article. -- Tamzin^{[cetacean needed]} (they|xe) 17:46, 18 April 2024 (UTC)

Bluelink, comma, blacktext models generally do not link the larger unit; I'd be sorry to see it changed to blue, comma, blue. NebY (talk) 17:57, 18 April 2024 (UTC)

Further to that, what’s the rule if there are three entities, progressively larger? For example: Hrubieszów, Lublin Voivodeship, Poland. Is that how we should do it? — Biruitorul ^Talk 21:13, 18 April 2024 (UTC)

Usually only the first (smallest) entity is linked. Gawaon (talk) 21:59, 18 April 2024 (UTC)

Why should our readers be expected to know where (or what) Lublin Voivodeship is? Seems extremely arbitrary -- and decided with little input from the community. Dahn (talk) 05:57, 19 April 2024 (UTC)

MOS:GEOLINK say "generally do not link the larger unit". It's not a strict prohibition, just a general recommendation. Common sense applies, as always. Also, I suppose the idea is that if readers want to know more, they'll follow the link to Hrubieszów, where they'll easily find another link to Lublin Voivodeship (in the lead sentence, in fact). Gawaon (talk) 06:22, 19 April 2024 (UTC)

Also, the general rule from which this logically follows is: "When possible, do not place links next to each other, to avoid appearing like a single link", as that will tend to confuse our readers. True enough, and it applies in this case just as well as in others. Gawaon (talk) 06:29, 19 April 2024 (UTC)

"MOS: OVERLINKING" listed at Redirects for discussion

The redirect MOS: OVERLINKING 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 April 25 § MOS: OVERLINKING until a consensus is reached. Utopes _{(talk / cont)} 22:15, 25 April 2024 (UTC)

Multiple links and touchscreen navigation

I'm not sure how much of an appetite there is for addressing accessibility issues that aren't related to vision, but one thing that came up in a recent discussion of a densely linked DYK hook is that our MOS doesn't seem to say much about how multiple links in one section of text can actually impede navigation for people with dexterity/coordination challenges. Because inline links are exceptions to minimum tap target settings, navigating a bunch of links in close proximity on a touchscreen can be kind of a nightmare. Rather than boldly pissing people off by editing directly, I thought I'd propose adding something like the following to the end of the overlink section:

Links may be excessive even if they are informative. For example, because inline links present relatively small tap targets on touchscreen devices, placing several separate inline links close together within a section of text can make navigation more difficult for readers with limited dexterity or coordination. Editors should balance considerations of readability, information, and accessibility when adding multiple links in one section of text.

So, not a hard and fast rule or anything, just some language making people aware that links are things that people touch, not just read. I didn't see much discussion of this in the archives for this page, but if you have institutional knowledge about prior discussion that would be particularly welcome. Or maybe it's already handled elsewhere. But I thought I'd raise the issue. Indignant Flamingo (talk) 22:15, 23 May 2024 (UTC)

I understand what you are saying, as I sometimes touch the wrong link on my Watchlist several times a day. However, aside from too-close links on the same line, which are already discouraged, the relative placement of links on adjacent lines will vary from one device to another, depending on the screen width. I don't see a way around that. Donald Albury 00:00, 24 May 2024 (UTC)

A number of times I've seen MOS:SEAOFBLUE-correcting edits reverted, with edit summaries to the effect of "it's not that much blue". I think there's sometimes a nonchalant sense of "big deal, just press "back" and click the right link, [silly]", and that SOB is purely a cosmetic (and arbitrary) MOS. It would be good to have at least an explanatory footnote so the rationale can be referenced as a teaching point. —Bagumba (talk) 00:37, 24 May 2024 (UTC)

It's an important point (that accessibility isn't just about vision), worth mentioning. The draft language looks good to me. Thanks for raising this issue and putting together a draft. Levivich (talk) 16:39, 24 May 2024 (UTC)

I've added the proposed text with a slight change to match the imperative mood of the surrounding guideline text. I appreciate the feedback and any changes are of course welcome. I think we should address touchscreen accessibility, but I don't have super strong feelings about main text vs. footnote vs. whatever. Indignant Flamingo (talk) 18:14, 30 May 2024 (UTC)

Linking to geographic places

For geographic places specified with the name of the larger territorial unit following a comma, generally do not link the larger unit.

This is such a stupid rule. What does Green Bay, United States mean to the readers? For geographic places, the only thing we should aviod linking is notable countries (i.e. Paris, France). If we were linking a small city, we should link both the city and state (i.e. Birmingham, Alabama), especially for cities in a huge country such as the United States or China. 120.16.11.84 (talk) 21:24, 17 June 2024 (UTC)

Note that Green Bay is a disambiguation page, and you should not be linking to it in an article. In general, for places in the United States, you should be using the state or territory the place is in, as in [[:Green Bay, Wisconsin|Green Bay]], Wisconsin, and not using "United States". Donald Albury 00:07, 18 June 2024 (UTC)

Well, Wisconsin is not a well-known state like California or Texas, I reckon the link should be "[[Green Bay, Wisconsin|Green Bay]], [[Wisconsin]]" instead. 120.16.11.84 (talk) 09:46, 18 June 2024 (UTC)

No, Green Bay, Wisconsin is just fine. Anyone who actually wants to read up on the state just needs to click one or two times more – no big deal, and it's much less confusing and less likely to lead to misclicks this way. Gawaon (talk) 10:17, 18 June 2024 (UTC)

Anytime I come across a disambiguated geographical term that's been piped and doubled up like proposed here ([[Qianxi, Guizhou|Qianxi]], [[Guizhou]]), I'll just copyedit it down to link the disambiguated title in full for cleanliness and simplicity (Qianxi, Guizhou). I expect many others do similarly. Folly Mox (talk) 10:44, 18 June 2024 (UTC)

Links provide context that might be necessary for an uninformed reader, but we do not link to presumed knowledge or general knowledge. So in most contexts, we don't link to apple, or bridge or plant. Where necessary, we link one level up, so on the Granny Smith article, we should link to apple, but we do not link to fruit or plant, which are more steps away.

Geographically, this is the same. So in, say, Alfred Lawson, we have “He founded the Lawson Aircraft Company in Green Bay, Wisconsin, to build military training aircraft…”. If a reader does not understand Green Bay, Wisconsin, they can click through to find out more about the place, and the place article should give the entire context that any reader needs to understand the geography as it relates to Lawson. States and high-level geographic entities are presumed knowledge, and the state (in this case) is not something that connects directly to the topic at hand. — HTGS (talk) 05:39, 20 June 2024 (UTC)

Unusual situation regarding linking userspace from mainspace

So I was over at Comprised of just now after sassing on some grammar in an unrelated thread elsewhere. This is an article that discusses for an entire level 2 subheading an on-Wiki process from the perspective of reliable sources: Comprised of § Removal from Wikipedia.

At the bottom of the article, in § External links, we link an essay by the editor who made it his job to expunge this phrase from mainspace: User:Giraffedata/comprised of. (Incidentally, WP:COMPRISEDOF redirects to the same essay.) It occurred to me that this isn't really an external link.

The guidance this talk page is attached to states In articles, do not link to pages outside the article namespace, except in articles about Wikipedia itself (at anchor MOS:DRAFTNOLINK). I'm wondering if this case is about Wikipedia itself enough to link User:Giraffedata's essay in the article body. I was thinking a section hatnote like {{see also}}, but I wanted to ask here to see what people think. Folly Mox (talk) 12:18, 30 June 2024 (UTC)

If that section remains, it is about Wikipedia itself. (I would argue that it shouldn't remain). Nikkimaria (talk) 15:52, 30 June 2024 (UTC)

Firstly this is significant and verifiable, so it's valid for inclusion. Secondly, it is fine to link to project pages in the very rare cases where they can be considered both appropriate and reliable sources. It might be a best to link to a specific version (if that hasn't been done) and include an archive link. All the best: Rich Farmbrough 21:05, 23 July 2024 (UTC).

The foundational principle is that, when covering ourselves on the encyclopedia, to maintain neutrality we want to treat Wikipedia like any other source. Part of that is treating links to content on this site outside of mainspace the same as we would treat any other external link. Sdkb ^talk 05:52, 26 July 2024 (UTC)

Clarity and Specificity in the requiem example

The Link Clarity section discourages "Previn conducted Mozart's [[Requiem (Mozart)|Requiem]]" and then the Specificity section says that it's preferred over just [[Requiem]]. There seems to be a hierarchy of preference, which makes sense, but it's left implicit and took me a while to work out what it was saying. Is there any scope/need to make the hierarchy more explicit? --Northernhenge (talk) 05:42, 5 August 2024 (UTC)

Overlinking guidance in ITN

A question for watchers of this talk page: does linking to Prime Minister of Bangladesh and Tehran in Template:In the News go against the spirit of WP:OVERLINK's bullet points on politicians and settlements? My read is that they do, as prime ministers are a common occupation and Tehran is a well-known capital city, but I'd like a sanity check before potentially starting a discussion. Thank you! Ed ^{[talk] [OMT]} 15:06, 8 August 2024 (UTC)

I'd say no to both. Prime Minister of Bangladesh is a specific article with useful information, a link to the generic prime minister article would be a different matter. Not all of our readers will have been in Tehran already or be intimately acquainted with that city, so I'd say that link is surely useful too. Gawaon (talk) 15:14, 8 August 2024 (UTC)

Thanks Gawaon! I appreciate the thoughts. Ed ^{[talk] [OMT]} 02:16, 10 August 2024 (UTC)

The prime minister link is excessive when the bolded link is Sheikh Hasina. Readers generally know what a prime minister is, and can go to her bio for more related links, such as Prime Minister of Bangladesh. —Bagumba (talk) 02:55, 10 August 2024 (UTC)

"MOS: OVERLINKING" listed at Redirects for discussion

The redirect MOS: OVERLINKING 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 August 8 § MOS: OVERLINKING until a consensus is reached. Queen of Hearts ^talk 20:34, 8 August 2024 (UTC)

A big ol' table: which phrases to turn into links

Originally created for Full-URL_wiktionary_link/doc#Alternatives but probably belongs somewhere on MOS:LINKING.

Some ways to work a Wiktionary link into prose:

Tone	Type	Example
Semi-encyclopedic	Full statement	"Trucking" means .... Therefore, ...
Encyclopedic	Noun phrase (specific)	According to the definition of "hot sauce" on Wiktionary ...
Encyclopedic	Noun phrase (slightly vague)	I read the definition of "wand" and learned ...
Encyclopedic	Words-as-words (more blue)	The word uncle can mean ...
Encyclopedic	Words-as-words (less blue)	The word "uncle" can mean ...
Semi-encyclopedic	Verb phrase (informational)	Wiktionary defines "footwork" as ...
Semi-encyclopedic	Verb phrase (instructional)	The word "downtime" can refer to either relaxation or outages (at least in American English; see Wiktionary).
Talk pages only	Prepositional phrase	The word "downtime" can refer to either relaxation or outages. Well, at least in American English.
Encyclopedic	Parenthetical disambiguation	See moonlight (Wiktionary).
Semi-encyclopedic	Qualifier	According to Wiktionary, a "mush room" is ...
Talk pages only	Qualifier in aside	A cantaloupe is a type of melon (at least according to Wiktionary).
Talk pages only	Verb phrase (narrative)	I looked up "cyber" and OMG, ...
Talk pages only	Snide remark	Are you sure that's a good source to cite in our paper? Wiktionary can be weird sometimes

Notes

— Jruderman (talk) 06:04, 11 August 2024 (UTC) Jruderman (talk) 06:04, 11 August 2024 (UTC)

I don't think I agree that this belongs in the MOS. Also why are you using a full URL to link Wiktionary instead of the interwiki link [[:wikt:]], or {{linktext}} or one of the other templates listed at {{Wiktionary templates common doc}}? Folly Mox (talk) 14:14, 11 August 2024 (UTC)

What's your favorite existing "subtle hint" template for linking to Wiktionary?

Do you want to help me change my template so it takes a slug & anchor rather than a full URL?

— Jruderman (talk) 16:31, 11 August 2024 (UTC)

Ah, I understand now that one primary purpose of your template is the smol icon. To use a slug and anchor rather than full URL (which sounds easier, and follows the typical presentation for interwiki links), all you'd need to do is to change your first line from {{Plain link|1={{{1}}}|2={{{2}}} to [[:wikt:{{{1}}}|{{{2}}}]] (with the File:Wiktionary small.svg bit retained, of course). I'm not sure of the use cases for using a full URL and figured you might have some.

As to my initial comment about whether the above table belongs in the MOS, I just see it as offering a broad variety of usage rather than describing a best practice. I'm not sure if there exists a best practice for linking Wiktionary.

My first comment in this thread reads as really grumpy now that I'm seeing it again. Please accept my apologies about that. My intended tone was curiosity with a splash of confusion.

For the remaining question, my favourite subtle hint is the URL of the link target. I don't practice signposting different projects within the Wikimedia ecosystem, but many editors do, which I have no quarrel about. Best wishes, Folly Mox (talk) 20:30, 11 August 2024 (UTC)

Websites and social media platforms

My edit on Miranda Sings was reverted when I added a link to the Instagram article because the editor though it was a violation of MOS:OVERLINK. Recognizable websites and social media platforms should generally not be linked, so editors could follow the aformentioned guideline. Sparkbean (talk) 16:04, 11 August 2024 (UTC)

But now you added the statement that major websites should not be linked to MOS:OVERLINK? Do you really think so? Personally I don't – I'd rather say editors should be fine to add these links if they find them useful. A point to consider here is that major examples of websites and such tend to became outdated much quicker than (say) major countries or cities, like who remembers MySpace or Altavista anymore? Gawaon (talk) 17:06, 11 August 2024 (UTC)

@Sparkbean: For the record, I reverted your addition for the time being. Let's first see whether we can find consensus for it here. Like I said, personally I don't think it should be there. Gawaon (talk) 17:11, 11 August 2024 (UTC)

Some editors think that everyone knows Instagram, but I agree with your reply. Sparkbean (talk) 17:39, 11 August 2024 (UTC)

RfC: GEOLINK examples

It remains unclear to many editors how MOS:GEOLINK should be interpreted in relation to sequences such as Sydney, New South Wales, Australia. Should this edit be restored? Khiikiat (talk) 23:45, 11 August 2024 (UTC)

• Comment. This is not really about MOS:GEOLINK, but about whether the state should be mentioned when referring to a major city like Sydney, right? Gawaon (talk) 06:27, 12 August 2024 (UTC)

  No, it is about MOS:GEOLINK. The current examples are not clear. Many editors look at the examples and conclude that it is only the country that should not be linked. Khiikiat (talk) 07:14, 12 August 2024 (UTC)

  The Buffalo, New York example shows clear enough that, instead of three possible links (in the bad version) only one should be made (in the good version). Gawaon (talk) 07:50, 12 August 2024 (UTC)

  I don't think it is clear enough, because people are still confused. For example, see Wikipedia talk:Manual of Style/Linking#MOS:GEOLINK above. The Doom Patrol wrote: WP:GEOLINK specifies larger unit, not unit(s). This pertains to the country, as demonstrated by the accompanying examples. In fact, this guideline only discusses the case where two geographical units are separated by a comma, with the second unit being specifically a country. Khiikiat (talk) 09:01, 12 August 2024 (UTC)

• Comment What was the reason to change from the "Buffalo, New York" example to "London, Ontario"?—Bagumba (talk) 07:30, 12 August 2024 (UTC)

  I think it is clearer. [[New York (state)|New York]] just adds to the confusion. Khiikiat (talk) 09:00, 12 August 2024 (UTC)

• Comment. Perhaps the guidance should be changed to something like this: For a geographical location expressed as a sequence of two or more territorial units, link only the first unit. Khiikiat (talk) 09:02, 12 August 2024 (UTC)

  Sounds good to me. We could also add a third example of the form city/town/village, state, country or similarly, with only the first name linked, but I don't think it should be a huge city like Sydney, where one would usually omit the state. Maybe Quothquan, South Lanarkshire, Scotland? BTW, I don't think we need an RfC for this. For one thing, it's not really controversial, and moreover, there are no reasonable options defined. Gawaon (talk) 10:41, 12 August 2024 (UTC)

  I have reworded the guidance, added the Quothquan example, and ended the RfC. If anyone objects, the changes can be reverted and discussed again. Khiikiat (talk) 10:46, 13 August 2024 (UTC)

  @Khiikiat: This still doesn't address the issue I raised above in § Ambiguity in GEOLINK examples: It remains unclear whether MoS is telling people they must include ", New York" in the displayed text of the link, or whether it is permissible to have the link only span the word "Buffalo", with ", New York" unlinked. The former, I maintain, would be a bizarre intrusion of our article title disambiguation rules into MoS rules for prose, and is less accessible given that only the collar of the comma clarifies where clicking "New York" will take you. -- Tamzin^{[cetacean needed]} (they|xe) 05:39, 14 October 2024 (UTC)

  I think the guidance, as it stands, is fairly clear: [[Buffalo, New York]], United States is preferred over [[Buffalo, New York|Buffalo]], New York, United States. The guidance could be changed, but I suspect most editors would support [[Buffalo, New York]], United States for the sake of simplicity. Khiikiat (talk) 22:13, 14 October 2024 (UTC)

  Indeed. Gawaon (talk) 22:15, 14 October 2024 (UTC)

  If that's what the guidance is, then the guidance should say that. At the moment it takes several inferences to get there, and we can see from this talkpage that not everyone interprets the current wording the same way. Perhaps an RfC is needed at this point. -- Tamzin^{[cetacean needed]} (they|xe) 01:52, 16 October 2024 (UTC)

  Or somebody could just change the page to make it clearer. Gawaon (talk) 07:10, 16 October 2024 (UTC)

  That would require a consensus that that is the intended meaning, which I don't think has been established. -- Tamzin^{[cetacean needed]} (they|xe) 08:35, 16 October 2024 (UTC)

  Well, being WP:BOLD and seeing whether one is reverted is usually the easiest way to find out whether there is consensus. Gawaon (talk) 16:47, 16 October 2024 (UTC)

  I mean, I'll save the time: I would revert it, because there is no consensus for it. -- Tamzin^{[cetacean needed]} (they|xe) 17:31, 16 October 2024 (UTC)

  Why then not add the clarification which you think would be consensual? As far as I can see, nothing in this discussion suggests a lack of consensus. Gawaon (talk) 17:57, 16 October 2024 (UTC)

  If I were changing this to reflect my understanding of how this guideline is generally applied, it would be to add a footnote saying "Both linking all of 'Buffalo, New York' and piping only 'Buffalo' are appropriate. The same approach should be taken consistently throughout an article." Anything else would be overstating consensus in either direction. -- Tamzin^{[cetacean needed]} (they|xe) 18:40, 16 October 2024 (UTC)

  That's indeed not consensual, I'd say. Sure, writing "Buffalo" is fine if that's all the text you want, but what would be the point of writing "Buffalo, New York" instead of simply "Buffalo, New York"? Gawaon (talk) 17:43, 17 October 2024 (UTC)

  As I've explained before, it is both more consistent (e.g. alongside "Atlanta, Georgia") and more accessible ("Buffalo, New York" is hard to distinguish from "Buffalo, New York"). Whether you agree or disagree with that, it's clear to me that the current policy does not adequately explain what the correct approach is here. I'll start an RfC. -- Tamzin^{[cetacean needed]} (they|xe) 20:21, 17 October 2024 (UTC)

Erratic shortcuts

On a mobile phone, use of the shortcuts MOS:UL and MOS:OL both take one towards the end of the relevant subsection, such that it isn't easy to see what is being linked to. In the latter case, in fact, it appears as if the shortcut links to the following subsection (MOS: CIRCULAR). I'm not sure if this behaviour is particular to my mobile phone, or is common to mobile devices in general. If the latter is the case, does anyone know if it would be possible to do something about this?

(Edwin of Northumbria (talk) 00:14, 24 September 2024 (UTC))

Just chiming in to say I can reproduce the problem. Not sure what's causing it. Both redirects are targeting section titles, so I don't think it's anything to do with anchors or Template:Shortcut. No issue on desktop. Firefangledfeathers (talk / contribs) 00:38, 24 September 2024 (UTC)

I get this somewhat frequently on projectspace pages with lots of subsection shortcuts (MOS:PINYIN does this too). I kinda always assumed it had something to do with the browser figuring out where to focus before everything above it finished expanding. I'm on Firefox on Android. Folly Mox (talk) 01:51, 24 September 2024 (UTC)

To remove or not remove underscores in wikilinks ?

What is the preferred styles ? Robertiki (talk) 15:37, 28 September 2024 (UTC)

Typically I remove and see others remove them, though I don't know whether there's a functional reason for that, or whether it's just to increase readability. DonIago (talk) 22:50, 28 September 2024 (UTC)

For talk pages, they should be removed, and I usually do. I am less good for edit summaries, though. Usually cup/paste over the article title works. Gah4 (talk) 08:38, 30 September 2024 (UTC)

unlinking New York City in in an infobox?

I noticed @UrielAcosta was unlinking NYC in an infobox because the MOS said to do so. Surely, the MOS wasn't talking about infobox, but article text? And why would you want New York (state) to be linked without NYC being linked? If someone actually wanted more info about where Abraham Joshua Heschel resided, wouldn't the city be more useful than the larger and less specific state? Andre🚐 05:16, 8 October 2024 (UTC)

If something is to be linked, link the city per MOS:GEOLINK, and never separately link larger units like state, country, etc. —Bagumba (talk) 05:22, 8 October 2024 (UTC)

Moreso than prose, infoboxes are subject to drive-by editors who want "uniformity" across articles. The amount of churn on the supposed MOS:OVERLINK of NYC and other "major" cities is not worth it for this. I'd support an exemption for infoboxes.—Bagumba (talk) 05:28, 8 October 2024 (UTC)

Aren't the vast majority of literate English language readers already familiar with London, Paris, Rome, Athens, Cairo, Moscow, Madrid, New York City, Mexico City, Delhi, Jerusalem, Los Angeles, Beijing, Tokyo, Sydney, Hong Kong, Lagos, Rio de Janeiro, Stockholm, Havana and the like? Plus Sacramento and San Francisco closer to where I live? Cullen328 (talk) 05:31, 8 October 2024 (UTC)

That aside, unregistered and new editors constantly fix the seemingly "missing" link. These types of edits are almost always in infoboxes. Enforcing this just creates churn, as it will endlessly go back and forth. I understand OVERLINK, but I'd compromise for the endless infobox traffic; the downside is minor.—Bagumba (talk) 05:38, 8 October 2024 (UTC)

I'd say as written the MOS doesn't seem to be considering infoboxes. It seems like infoboxes are very often the first thing that people look at when they open a page. So I'd say the infobox should list the major things and link them for ease of use. The other guidance about not linking it should apply to the article body. Andre🚐 06:07, 8 October 2024 (UTC)

I agree, it would be better to exempt infoboxes from OVERLINK, for consistency and simplicity if nothing else. Personally I find the "don't link major examples" rule of OVERLINK fairly illogical and inconsistent anyway. Why should Belgium be linked, but not France? Or are both to be linked, or none? I couldn't really say, tend to link when in doubt, and think Wikipedia would lose nothing by dropping this rule altogether. Gawaon (talk) 07:51, 8 October 2024 (UTC)

Not only are New York and London "commonly understood terms", but they are also unique capital city names? (Perhaps there's a technical means of preventing linking those two in any infobox? How about administering a small electric shock when anyone attempts? They'll soon learn! Martinevans123 (talk) 13:26, 8 October 2024 (UTC)

OVERLINK's examples include everyday words, common occupations, major countries and languages, and more. Should we now start linking doctor in infoboxes or even – if I understand your last sentence correctly – drop this rule altogether and link it in article text? NebY (talk) 13:29, 8 October 2024 (UTC)

I'm talking about geographical entities like countries and cities, not necessarily about anything else. Gawaon (talk) 20:27, 8 October 2024 (UTC)

Didn't we just have this discussion last year? At Wikipedia talk:Manual of Style/Linking/Archive 21 § Linking New York City? Folly Mox (talk) 13:16, 8 October 2024 (UTC)

The discussion here is specifically about infoboxes. —Bagumba (talk) 13:39, 8 October 2024 (UTC)

• I see no difference in principle between linking an item in an infobox or elsewhere. New York City is too well known and too vague to link almost anywhere. Tony (talk) 02:24, 1 November 2024 (UTC)

MOS:GEOLINK for former countries/entities

I believe it would be useful to form consensus and guide editors on the application of MOS:GEOLINK to historical countries and/or entities. For example, a disagreement came up about it over at Talk:Josip Broz Tito § Infobox arrangement, where editors believe it is necessary to include and link the subnational entity to which the place belonged, and otherwise the historical country, like so:

• Kumrovec, Austria-Hungary
• Lubljana, SR Slovenia, Yugoslavia

I'm citing the original proposer's (@Thedarkknightli) arguments: "For Kumrovec's case, Austria-Hungary, you know, no longer exists; I mean, none of the examples in MOS:GEOLINK include a country that no longer exists. For Ljubljana's case, I don't think most readers know it's a part of Slovenia; also, you know, it wasn't Yugoslavia's capital or largest city, unlike Belgrade." –Vipz (talk) 20:15, 8 October 2024 (UTC)

Wouldn’t including a sub-entity for the first one be the following?:

Kumrovec, Kingdom of Croatia-Slavonia, Austria-Hungary OyMosby (talk) 12:46, 9 October 2024 (UTC)

@Vipz: I agree that guidance should be added in relation to this issue. In my opinion, MOS:GEOLINK should also apply to a sequence of historical territorial units in order to prevent a sea of blue. In Tito's case, each territorial unit is linked in the body of the article so applying MOS:GEOLINK to the infobox does not present a problem. Khiikiat (talk) 18:41, 9 October 2024 (UTC)

The primary question, as in all things linking, should be whether the link gives the reader helpful information. One consideration when it comes to multiple successive links is whether one would adequately lead readers to the other. For instance, even if someone is unfamiliar with what Alberta and Canada are, "Calgary, Alberta, Canada" is fine, because Calgary links to Alberta from its lede, and that in turn links to Canada. However, an article on an extant city may not link as prominently to a country it was once a part of. A formulation like "Kumrovec, Austria-Hungary" is reasonable, because the Kumrovec article doesn't readily explain what Austria-Hungary was (in fact, it doesn't mention it once). But something like "Syria Palaestina, Roman Empire" would be unnecessary, as Syria Palaestina only existed as part of the Roman Empire. -- Tamzin^{[cetacean needed]} (they|xe) 22:58, 9 October 2024 (UTC)

@Tamzin: I understand your point. But, if linking each territorial unit is important, the sequence can be broken up. This is what has been done in the article about Tito: Josip Broz was born on 7 May 1892 in Kumrovec, a village in the northern Croatian region of Zagorje. At the time it was part of the Kingdom of Croatia-Slavonia within the Austro-Hungarian Empire. If the units are linked in the body, then there is no need to link them in the infobox as well. Making an exemption for a sequence of historical territorial units opens the door to edits of this sort. Normantas Bataitis has made hundreds and hundreds of edits like this. I don't see how they benefit the reader. The infobox is meant to be a concise summary of the basic facts. Khiikiat (talk) 09:31, 10 October 2024 (UTC)

I link historical territorial units only if historical country is federal. In my opinion, federal historical territorial units should be pointed out, so the reader would understand about composition of historal countries. Normantas Bataitis (talk) 11:12, 10 October 2024 (UTC)

I agree that more spaced-out phrasing in prose is often preferable, sure. But in infoboxen, it's not an option, and I don't really buy the SEAOFBLUE argument there, at least not when separated by punctuation. Text in infoboxen is surrounded by whitespace. There's no aesthetic or reading comprehension issue caused by having two links separated by a comma.

Now, as to the diff, the Second Spanish Republic is a bit more complicated a case, because historiographically that's considered one iteration of a continuous Spain. Something similar actually came up at GAN for Capri-Sun, where Guerillero and I disagreed on how to characterize Germany in 1931 (Germany, the iteration therein called the German Reich, or the sub-iteration therein called the Weimar Republic). The exact way we describe iterations of countries is something it would be good for MoS to be clearer on, but in the context of this discussion a bit of a red herring I think. Although for what it's worth, I disagree with [[Second Spanish Republic|Spain]] in that diff. It should be either linked clearly or not linked at all. -- Tamzin^{[cetacean needed]} (they|xe) 18:01, 10 October 2024 (UTC)

I agree with the last point. It's an EGG, and we prefer to avoid those for good reasons. Gawaon (talk) 18:34, 10 October 2024 (UTC)

I routinely unlink per MOS:GEOLINK (and often rephrase things to avoid seas of blue), but have always taken it for granted that GEOLINK doesn't apply to ex-nations, which can't automatically be reached in a click or so from the linked toponym, so I don't unlink them. I also assume that if there are two linked toponyms in a row, the visual similarity (despite the unlinked comma between them) to a sea of blue is a necessary evil. I would support making these points explicit in the GEOLINK guidelines.

UrielAcosta (talk) 00:38, 11 October 2024 (UTC)

Maybe a sub-bullet under GEOLINK saying "Exception: If the smallest unit is an extant place, but the largest is not, it is acceptable to link both, as in Kumrovec, Austria-Hungary. However, it is preferable to space the links out when feasible, e.g. Kumrovec, then part of Austria-Hungary." -- Tamzin^{[cetacean needed]} (they|xe) 05:35, 14 October 2024 (UTC)

Perhaps the nuance is best left to prose, which currently reads Tito was born to a Croat father and a Slovene mother in Kumrovec in what was then Austria-Hungary, providing proper context in explicit wording instead of consecutive links. —Bagumba (talk) 02:36, 10 October 2024 (UTC)

I agree with Tamzin. A sub-bullet is needed for former territorial units, but I'm not sure it is necessary to include every cascading territorial sub-unit, ie the particular kingdom of Austria-Hungary or republic of Yugoslavia, for example. Peacemaker67 (click to talk to me) 22:11, 31 October 2024 (UTC)

RfC: Linking of three-part place names

There are two common ways to link to a place name with an "A, B, C" format where the article is titled [[A, B]]. Both can be read as fair interpretations of the guidance to "link only the first unit".

1. Have the link span only the smallest unit, using piping if necessary

   Buffalo, New York, United States

2. Have the displayed text match the title of the linked article

   Buffalo, New York, United States

Which style(s) is/are acceptable? If both, is one preferable to the other?

Note: See previous discussion above and above. This is not a question about whether "New York" should be linked to New York (state) in this example; basically everyone agrees that it should not be. 20:57, 17 October 2024 (UTC)

Discussion re RfC: Linking of three-part place names

Pings to past participants @Gawaon, Khiikiat, Pi.1415926535, Michael Bednarek, NebY, Biruitorul, and Dahn. Cross-posted to WT:MOSACCESS. -- Tamzin^{[cetacean needed]} (they|xe) 20:57, 17 October 2024 (UTC)

• Both acceptable, approach 1 preferable. Approach 2 is, no doubt, more common, but both approaches are used in good and featured articles without issue. As a matter of MOS:RETAIN I'll stop short of saying approach 2 should be proscribed, but I think approach 1 is preferable for two reasons:
  • Consistency: Having a prose guideline turn on the title of the article being linked to would be strange, given that the article title policy is informed by various considerations that do not apply to prose, such as disambiguation and the semi-arbitrary rule that is WP:USPLACE. To a reader seeing "Buffalo, New York, United States", next to "Boston, Massachusetts, United States", it is not at all obvious why the two are handled differently. It is cleaner and simpler to have the link span the exact place being referenced, not attached disambiguators like ", New York".
  • Accessibility: The only difference between "Buffalo, New York" and "Buffalo, New York" is the color of the comma. For anyone who, like me, struggles to distinguish between blue and black in small quantities, it looks like clicking on "New York" in the first example will take you to New York (state).
• The main argument made in the opposite direction is simplicity of markup, but that's usually the lowest priority in MoS decisions, certainly lower than accessibility. We should not make our articles more confusing to readers just for the sake of slightly shorter source code. -- Tamzin^{[cetacean needed]} (they|xe) 20:57, 17 October 2024 (UTC)
• None -- I struggle to understand why it wouldn't be necessary to link the first-level administrative division, in most cases outside the US (and even the US as well, but let's assume that Buffalo, New York is an accepted practice in that context). Who could be expected to consider Ialomița County or Simeulue Regency instantly recognizable terms across the vast expanse of the world? and if we're not linking unfamiliar terms, what is the point of having internal links at all? Seems like someone was peeved by having two links next to each other, and came up with this atrocious moratorium on having necessary links where they appear side by side (though neatly separated by a comma); this bewildering approach should not have been tried out at all, ever. Dahn (talk) 21:10, 17 October 2024 (UTC)

  The normal argument against linking the second-level entity is that it can be easily clicked from the first-level, if some wants. As discussed above, exceptions may apply when the first-level entity's article doesn't prominently discuss the second-level one, mostly in the case of former countries. -- Tamzin^{[cetacean needed]} (they|xe) 21:17, 17 October 2024 (UTC)

  The exceptions are in fact the norm -- most subdivisions would be unfamiliar to anyone outside that country. Which is why "Buffalo, New York" is a misleading example, the sort of which has prompted some overzealous users to delete links to Olt County and Wallachia, thus leading to the absurd suggestion that Olt County has the same notoriety as New York, and Wallachia is a notion similar to the US. "It can be easily clicked from [somewhere else]" can be said about each and every bluelink out there, so I don't see why that was ever accepted as a valid argument in any debate. Dahn (talk) 21:32, 17 October 2024 (UTC)

• Option 2 per MOS:SPECIFICLINK. It's also a normal unpiped link, without superfluous text: compare [[Buffalo, New York]], United States (five words) with [[Buffalo, New York|Buffalo]], New York, United States (eight words). --Redrose64 🌹 (talk) 22:13, 17 October 2024 (UTC)
• Comment — there are plenty of situations where linking place, subdivision and country is appropriate, and I think the guideline should do more to encourage that. Examples: 1) Bogdana, Tutova County, Moldavia; 2) Haraklány, Szilágy County, Kingdom of Hungary. It’s more than likely the average reader will have no idea where any of these places are/were, so why not link them all? — Biruitorul ^Talk 05:59, 18 October 2024 (UTC)
• Option 2 because it's shorter to write and leads to linked text and linked page title being in agreement. Later addition: Also per WP:NOPIPE, as pointed out below by Bagumba – don't use piped links when you don't have to, and here you very clearly don't have to. Gawaon (talk) 08:55, 18 October 2024 (UTC), edited 07:55, 19 October 2024 (UTC)
• Both acceptable, do not specify preference for either. I personally prefer Option 2, which cuts down on redundant text that looks extremely silly in the editor and in diffs. I suppose it also matches linktext with article titles, which I care less about. I don't think we should enshrine a preference for best practice here. Agree with others above that in many cases it may be helpful to link multiple administrative subdivisions: not long ago I had reason to mention Yao Mangshan Ethnic Township (莽山瑶族乡), Yizhang County, Chenzhou, Hunan. Leaving out the container state, that's still four subdivisions. I left Hunan unlinked since it appears in User:Ohconfucius/script/Common Terms, but there are probably editors who would argue for linking that as well. Folly Mox (talk) 09:52, 18 October 2024 (UTC)
• Link only the most specific item—especially when the other two are so well known. Tony (talk) 10:25, 18 October 2024 (UTC)
• Option 2 Makes no sense to pipe and hide "New York", just to type it again and display it. Per WP:NOPIPE:

  Unnecessary piping makes the wikitext harder to read.

  —Bagumba (talk) 10:54, 18 October 2024 (UTC)
• Option 2 don't find any specific reason to leave out the state from the muncipality, as it is kind of self explanatory. Also creates redundant piping per Bagumba. Takipoint123 (talk) 02:20, 19 October 2024 (UTC)
• Option 2 In this specific format, it seems more intuitive to match the title of the article. I will also add that including the non-linked country at the end may be somewhat out of place/redundant in either option. Symphony Regalia (talk) 14:38, 19 October 2024 (UTC)
• No preference. MOS should state this. I fully agree with Folly Mox here and would go one step further to say the style guide should be explicit in stating there is no dictated preference. It should list some things to consider, provide examples, and otherwise defer to editorial judgment. Things to consider might include MOS:NOPIPE and other rules or guidelines. A lot of this will come down to context-specific factors and personal judgment or consensus within an article. In nearly all cases it matters too little to mandate a single standard and doing so will likely result in more appeals for exceptions and workarounds. MYCETEAE 🍄‍🟫— talk 22:03, 19 October 2024 (UTC)
• Option 1, but both acceptable, per Tamzin and link intuitiveness. I don’t want people clicking “New York” and being confused at being sent to Buffalo. I also think all arguments based on what looks best in wikitext or is easier to type for the editor are wrong. Style decisions are not made for the wikitext editor’s benefit. — HTGS (talk) 00:50, 23 October 2024 (UTC)

  I don’t want people clicking “New York” and being confused at being sent to Buffalo: But that is exactly why we avoid consecutive links to begin with i.e. SOB. It is a single link to <city, state>, not consecutive links <city>, <state>. —Bagumba (talk) 04:37, 24 October 2024 (UTC)

  And avoiding links that span two page-level topics is another step we can take towards making links clearer. — HTGS (talk) 02:06, 25 October 2024 (UTC)

  Right. Readers have no reason to expect that "New York" won't link to New York there: They don't know that MoS says it shouldn't, and in practice countless articles would link to New York there. Using a different state because the NYC/NYS ambiguity complicates things, there are 11,030 articles containing either [[Boston]], [[Massachusetts]] or [[<someplace>, Massachusetts|<someplace>]], [[Massachusetts]]. These links are distinguished from e.g. [[Boston, Massachusetts]] by the color of a character that is less than a millimeter wide at standard zoom. -- Tamzin^{[cetacean needed]} (they|xe) 00:20, 27 October 2024 (UTC)

  Regardless of the outcome of this RfC, the standalone link to Massachusetts should be unlinked per MOS:GEOLINK in all these cases. MOS:GEOLINK is already very clear on this and it's not something that will change. Gawaon (talk) 08:39, 27 October 2024 (UTC)

• Single link In almost every case the purpose of the link is to take you to the article of a single, unambiguous, location. The link should be written in it's natural format (no piping). The larger regions are merely so that a printed form will lead you to the same place but we don't really expect the reader to want to go directly to the articles for the larger regions - ie, we are listing a city for a reason, the larger regions are just to make it unambiguous and are not a target in their own right. So, we give the link to the city in its natural format (without piping), and then add whatever else is needed in plain text. If it turns out that some cities in a list have the link encompass different portions of the hierarchy (eg Paris, France vs Paris, Ontario, Canada) then that is okay.  Stepho  talk  01:21, 23 October 2024 (UTC)

  Ooh, I really disagree with that last point. I’d rather a list be consistent regardless the choice between these two options. — HTGS (talk) 03:01, 23 October 2024 (UTC)

  How would you list those 2 cities?  Stepho  talk  03:10, 23 October 2024 (UTC)

  Assuming it’s a normal prose sentence, I would have something like: “However in 1894, the government of Paris, France decided to implement the change, while the mayor of Paris, Ontario forced the city to withhold …” But honestly I would still rather the opposite (… Paris, France decided to implement the change, while the mayor of Paris, Ontario did not…”) to the split styling you suggested. — HTGS (talk) 21:40, 24 October 2024 (UTC)

  And for most lists, the same (with disambiguation pages being the exception). — HTGS (talk) 21:42, 24 October 2024 (UTC)

  I agree, but note that what you describe is in fact exactly Option 2 ("Have the displayed text match the title of the linked article"), so you're effectively voting for that. Gawaon (talk) 07:23, 23 October 2024 (UTC)

  the larger regions are just to make it unambiguous and are not a target in their own right: I'm not sure if "unambiguous" is the right word. For a large country, most people have never heard of most non-major cities, so a larger region is mentioned to provide context, whether or not the same city name exists in another region.—Bagumba (talk) 04:48, 24 October 2024 (UTC)

• Definitely Option 2. No pipe gymnastics needed, and the blue the reader sees tells him unambiguously where clicking will take him. EEng 00:33, 27 October 2024 (UTC)
• Link "Buffalo" alone. Tony (talk) 02:25, 1 November 2024 (UTC)

  As in Buffalo, New York, United States? -- Michael Bednarek (talk) 03:01, 1 November 2024 (UTC)

• Comment: Hi folks. I came here to raise a closely related point, then I saw this discussion and the previous ones. I think the examples should be changed to allow or encourage this type of thing:

Three very nice cities are:

• Madison, Wisconsin, US
• Terre Haute, Indiana, US
• Chicago, Illinois, US

That is, in many cases it's preferable to be consistent with how the links are presented, and in my view it's *not* necessary to have the visible linked text exactly match the article titles. So in this example I've coded [[Chicago|Chicago, Illinois]] to achieve that. Although coding [[Chicago, Illinois]] would achieve more or less the same thing, because "Chicago, Illinois" is a redirect to "Chicago". Edited to add: This suggestion does not match either option 1 or option 2. — Mudwater ^(Talk) 01:55, 26 November 2024 (UTC)

Is MOS:SOB just a stylesheet problem?

The page currently has MOS:SEAOFBLUE, which reads, in part:

When possible, do not place links next to each other, to avoid appearing like a single link, as in chess tournament (chess tournament)

Which makes sense to me. But is this just a stylesheet issue with wikipedia? HTML hyperlinks are conventionally displayed in blue and underlined, disambiguating chess tournament from chess tournament (in wikipedia it seems they're only underlined on hover, for whatever reason), which would largely resolve the issue. Or would it? Dingolover6969 (talk) 11:20, 19 October 2024 (UTC)

The difference is still very hard to detect, so I'd say it's definitively not just a stylesheet problem. Gawaon (talk) 11:33, 19 October 2024 (UTC)

Hovering isn't an option on mobile devices. But there's already a navigation concern, even if they're not back-to-back links. Per MOS:OVERLINK:

For example, because inline links present relatively small tap targets on touchscreen devices, placing several separate inline links close together within a section of text can make navigation more difficult for readers, especially if they have limited dexterity or coordination.

This is only worse when it is SOB.—Bagumba (talk) 11:57, 19 October 2024 (UTC)

Although most browsers will underline clickable links in the absence of any instruction to the contrary, many websites nowadays do supply such instruction - for example, https://www.legislation.gov.uk/ where the links are blue, and only become underlined when hovered. Our Cologne Blue skin still underlines links. --Redrose64 🌹 (talk) 14:34, 19 October 2024 (UTC)

Somewhat orthogonal, but I think “chess tournament” is a poor example, as that is a problem primarily about using two links instead of the more appropriate one: “chess tournament”. And beyond that, most SOB problems tend to be more about overlinking than about the actual SOB. When there is an SOB, and the links are all appropriate, the possibility of rewriting is often ignored, and sometimes even reverted. — HTGS (talk) 21:54, 24 October 2024 (UTC)

the possibility of rewriting is often ignored, and sometimes even reverted: Seemingly without fail, someone will be proud of the compact wording—counter to MOS:SOB's Instead, consider rephrasing the sentence (tournament of chess) ...—and will argue that any extra words are "unneceesary". —Bagumba (talk) 09:22, 1 November 2024 (UTC)

Noteworthy exceptions to SOB

I notice that the considerations of a MOS:LEADSENTENCE typically override those described here and think it would be helpful to point that out as follows:

• Exceptions are typically made for opening sentences, where the amount of parent topics may be allowed to exceed navigational concerns out of necessity. An artistically significant film, for example, may need to name a wide range of genres in a single sentence without any possibility of splitting them up:

Oppenheimer is a 2023 epic biographical thriller drama film written, directed, and produced by Christopher Nolan.

Orchastrattor (talk) 18:24, 23 October 2024 (UTC)

These are not exceptions, these are among the most egregious and most visible violations. They are particularly wrong, even more than the examples cited in the policy itself.Remsense ‥ 论 18:27, 23 October 2024 (UTC)

If anything, doubly wrong, because the links do not significantly help the readers' understanding, and the list of genres is not the most important thing about the film, so it also violates MOS:FIRST. IMO a lede sentence for a film should mention between zero and one genres. -- Tamzin^{[cetacean needed]} (they|xe) 00:34, 24 October 2024 (UTC)

What a horrible opening sentence....... A sea of blue Moxy🍁 00:55, 24 October 2024 (UTC)

Would you say that you are become Death, the Destroyer of Worlds, or? Remsense ‥ 论 01:00, 24 October 2024 (UTC)

Lol ....keep it simple [3] Moxy🍁 01:08, 24 October 2024 (UTC)

Yes, specifically there is MOS:LEADCLUTTER:

Do not overload the first sentence by describing everything notable about the subject. Instead, spread the relevant information out over the entire lead.

—Bagumba (talk) 14:44, 25 October 2024 (UTC)

There is indeed often a conflict between these two guidelines.

I have to wonder if the reactions so far above are a local consensus. Orchastrattor is correct that tons of film article lead sentences, and other lead sentences, are written in this manner. And my impression is that the folks who frequent this talk page care more about SOB violations, whereas many other editors are more willing to overlook them if it helps provide useful links.

I disagree with @Tamzin that genres aren't important — they're defining aspects of a film, as evidenced by the fact we have categories for them. A sentence like the one above provides no good options — the SOB isn't optimal, but resolving it by removing the links would take out useful info, and any rewrite to avoid them would be extremely clunky. I think a strong case could be made that the SOB is the lesser evil in this situation. Sdkb ^talk 02:57, 24 October 2024 (UTC)

Point! I never really like to pile on as such: I have strong opinions but they read as uncomfortably strong when flanked by others who feel similarly. Remsense ‥ 论 04:06, 24 October 2024 (UTC)

Our best pop culture articles would deal with this type of sea of blue listing genres by moving these to the infobox with bullets to make each link clear Pink Floyd, House (TV series).... Template:Infobox film is an oddball for this that leads to this problem as it omits genres. Not all projects have accessibility in mind. Moxy🍁 04:31, 24 October 2024 (UTC)

Lots of things are defining and important but don't go in the lede sentence. This is just bad writing. Compare

Oppenheimer is a 2023 biographical film written, directed, and produced by Christopher Nolan. An epic with aspects of a thriller, it follows the life of J. Robert Oppenheimer, the American theoretical physicist who helped develop the first nuclear weapons during World War II.

If there were more in the lede about the structure of the film (which there isn't, because, like most film ledes, it's top-heavy with production and box-office info), the epic/thriller bit could be moved there instead of the second sentence. Drama film doesn't need to be linked because all three other genres are subgenres of it. Note also that the SOB links here hide sourcing issues: The body of the article only quotes people comparing it to a thriller, and the word "epic" only appears in source titles. The former is addressed in my suggested rewrite above; the latter would need changes to the body to fix. -- Tamzin^{[cetacean needed]} (they|xe) 15:31, 24 October 2024 (UTC)

I do actually like that rewrite quite a lot! I'm not sure it'd work for all similar situations, but for this one it resolves the issue nicely, so I stand corrected there. Sdkb ^talk 15:42, 24 October 2024 (UTC)

As much as I do think genres are typically important and should be mentioned early, there is no need to pile them into the very first sentence, and WP:DEFINING (about categories) should not be taken to imply what the first sentence should look like. — HTGS (talk) 21:46, 24 October 2024 (UTC)

The Oppenheimer instance is downright offensive, as no reliable source has ever called the film "epic biographical thriller drama", much less collectively, and goes against WP:FILMLEAD. I've nuked it. Erik (talk | contrib) ^{(ping me)} 13:48, 25 October 2024 (UTC)

Not really a fan of the "epic with aspects of a thriller," re-write. "aspects of a thriller" is vague. What aspects? is it a thriller or not? If anything, this detailed approach confuses readers more than it helps them and is us to clarify something and ten different people would come back with ten different interpretations of. Definitely with Erik on this one. Even if we find a group of sources applying genres, suggesting any hybrid of the form that is not following our standards of genre is misleading. If the genre is truly an important aspect or something this complicated, this will need to be clarified in the prose. Something like The_Lighthouse_(2019_film)#Genre. That said, I generlly skip over genres that would be explained already by the general plot stucture. If the opening sentence says it's about the the real life figure J. Robert Oppenheimer, than we already know it's going to be biographical film. Andrzejbanas (talk) 13:54, 4 November 2024 (UTC)

I'm pretty sure I've half-seriously suggested that we'd be best off eliminating genres from the lead entirely and letting readers draw their own conclusions based on the plot summary and whatever was provided in the Reception section. DonIago (talk) 13:57, 7 November 2024 (UTC)

While I'd agree as a sort of knee-jerk quick-yes to that, So often we have genres, even in good and features articles that are not even mentioned in any prose within articles. While not on the MOS and nobody seems to want to discuss it, I've generally either kept the genre general or tried to apply the WP:WEIGHT standards. Unlike more technical credits which can be more easily solved, genre is so fluid and changing, it is something that requires special intention and ignoring it due to it's complexity within an open encyclopedia is also a bit more work than most people want to get involved with. Andrzejbanas (talk) 20:58, 8 November 2024 (UTC)

Honestly I think Doniago's half-serious suggestion is a good one.

[Removed: five paragraphs of philosophical ramblings on the assignment and usefulness of genera, and the description and subjectivity of artistic characteristics]

In concrete terms I feel that genre can be a valuable addition to an infobox but has no place in the lead paragraph, excepting cases where the genre itself contributes to the significance of the subject per MOS:LEAD. Folly Mox (talk) 15:48, 9 November 2024 (UTC)

I wouldn't support that. Genres are important pieces of information, and no more subjective than some other things we commonly include in the lead. Sdkb ^talk 16:01, 9 November 2024 (UTC)

Given the number of times I've had to request sources for good-faith but unsupported genre changes, I don't think I agree that genre is relatively uncontentious, but I don't know which "some other things" you're referring to. DonIago (talk) 16:07, 9 November 2024 (UTC)

I said "subjective," not "uncontentious" — there are certainly plenty of contentious things that we include in leads all the time, and it would go against WP:NEUTRAL not to include them. Regarding examples of subjective information in leads, WP:REPUTATION is one example that comes to mind. Sdkb ^talk 19:07, 9 November 2024 (UTC)

Editor reverting my unlinking of plain years

Two reversions by User:LightNightLights: what to do? Tony (talk) 00:50, 30 October 2024 (UTC)

Funny, looks like I'm the one who added those, but no longer have that article watchlisted, so didn't see this dispute till you posted here. Unsurprisingly, I agree with LightNightLights. The years are linked in hatnotes, which are navigational aids, not part of the prose content of an article. It would be completely pointless to say "not to be confused with 1776" and not link 1776. -- Tamzin^{[cetacean needed]} (they|xe) 04:16, 30 October 2024 (UTC)

Clarification regarding MOS:REPEATLINK dispute

See this talk page discussion for further information. An editor has removed links at W. S. Gilbert citing MOS:REPEATLINK, however is this incorrect per MOS as this is the first occurrence of these links in its section and MOS:REPEATLINK states to link a term at most once per major section, at first occurence, describing a major section as generally being a level-2 heading. Happily888 (talk) 06:49, 30 October 2024 (UTC)

Do what is best for readers..... if it's a huge article with multiple sections there is no real harm in linking it a few times to facilitate navigation especially for those who don't read whole articles and just go to specific sections through the table of contents. Moxy🍁 02:29, 10 November 2024 (UTC)

Depends on how useless the link is in the first place. Tony (talk) 08:50, 10 November 2024 (UTC)