Misplaced Pages

talk:Manual of Style/Linking: Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages talk:Manual of Style Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 00:44, 24 August 2009 editPiano non troppo (talk | contribs)Rollbackers53,873 editsm Strong disagreement with encouragement to repeat-link← Previous edit Latest revision as of 05:44, 3 January 2025 edit undoBagumba (talk | contribs)Autopatrolled, Administrators174,647 edits Notification: listing of MOS:WINGSUIT at WP:Redirects for discussion.Tag: Twinkle 
Line 1: Line 1:
{{Talk header|shortcut=WT:MOSLINKS}}
{{Contentious topics/talk notice|mos}}
{{WikiProject banner shell|
{{WikiProject Manual of Style}}
}}
{{User:MiszaBot/config {{User:MiszaBot/config
|archiveheader = {{talkarchivenav|noredlinks=y}} |archiveheader = {{talkarchivenav|noredlinks=y}}
|maxarchivesize = 128K |maxarchivesize = 950K
|counter = 6 |counter = 21
|minthreadsleft = 4
|algo = old(20d)
|archive = Misplaced Pages talk:Linking/Archive %(counter)d |algo = old(1y)
|archive = Misplaced Pages talk:Manual of Style/Linking/Archive %(counter)d
}}
}}{{Shortcut|WT:MOSLINK}}
{{archive box|search=yes|
{{WPMOS}}
{{WikiProject Policy}}
{{archive box|
'''WP:CONTEXT archives''' '''WP:CONTEXT archives'''
*] *]
Line 27: Line 31:
*] Sep 2006 – Jan 2009 *] Sep 2006 – Jan 2009
*] Jan 2009 – May 2009 *] Jan 2009 – May 2009
*] May 2009 – present *] May 2009 – Jun 2009
*] Jul 2009 – Aug 2009
*] Sep 2009 – Feb 2010
*] Feb 2010 – Jun 2010
*] Apr 2010 – Sep 2010
*] Sep 2010 – Nov 2010
*] Nov 2010 – May 2011
*] May 2011 – Oct 2011
*] Oct 2011 – Apr 2012
*] May 2012 – Nov 2012
*] Nov 2012 – Sep 2013
*] Sep 2013 – Feb 2015
*] Jan 2015 – Jul 2015
*] Jun 2015 – Sep 2016
*] Sep 2016 – Nov 2019
*] Nov 2019 – Apr 2021
*] May 2021 –
}} }}


== Redirection to another article in an infobox ==
== Inconsistency ==


{{Infobox person
The "Plurals and possessives" bullet seems to suggest that <code><nowiki>]s</nowiki></code> is more readable than <code><nowiki>]</nowiki>, but <code><nowiki>]</nowiki></code> is more readable than <code><nowiki>]'s</nowiki></code>. Does "more readable text and ''source''" means something other than the obvious thing, is it a mistake, or am I missing something? --<span style="background: white; color: blue; font-family: monospace">] di&nbsp;M.</span> 20:46, 6 August 2009 (UTC)
| name = Gioachino Rossini
| image = Composer Rossini G 1865 by Carjat - Restoration.jpg
| alt = Rossini wears a vest and overcoat, holding a cane and looking out of frame
| caption = Rossini in 1865, photo by ]
| birth_date = {{birth date|1792|2|29|df=y}}
| birth_place = ], Italy
| death_date = {{death date and age|1868|11|13|1792|2|29|df=y}}
| death_place = ], Paris, France
| works = ]
}}


Two days ago, I opened a discussion at ] to debate the addition of an infobox. For those who may be unaware, WikiProject Composers has an age-old <s>policy</s> 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.
: The point here is that in "]'s", the apostrophe is parsed as a word delimiter, which means the "'s" is outside of the link. Could be better worded, though. &mdash; ] 21:57, 6 August 2009 (UTC)


To the right is the infobox I proposed, similar in style to ], ], ], ], ], etc. The inclusion of the article link to "List of compositions" in the works parameter has been the subject of debate. @] and I state that the inclusion is justified because the link shows that Rossini was notable for composing and this is the standard on ]. @] countered that ], which is part of Misplaced Pages: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 Misplaced Pages 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 it so readers could only understand the oeuvre of the article subject by following a link, which is what NOFORCELINK exists to combat".
== "Link density" et al. ==


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? ] (]) <small>(])</small> <small style="font-size:66%;">(])</small> <small style="font-size:45%;">(])</small> 00:18, 4 October 2023 (UTC)
*The title "Overlinking and underlinking" is quite different from the replacement "Link density". The density can be high without overlinking, and low without underlinking. I suggest the pre-existing title be reinstated.
*"consider linking "]" and "]" only if these common words have technical dimensions that are specifically relevant to the topic (but since many "single dictionary word"-titled pages are disambiguation pages, make sure that the links are directed to the correct articles);". This is not a good change: if an item is worth linking, it's normally no longer a "dictionary" word, but has technical dimensions in the context.
*The example of a "specific" link, to "film actor" rather than "film" "actor" is not helpful: these two items should not be jammed together in the first place, so the guideline now mixes issues. "Film actor", "film", and "actor" are highly likely to be common terms that should not be linked. In fact, they are misused in many many articles, where the guideline says already not to link professions, normally. This example needs a rethink.
*"If no such page exists, then you need to link to a more general article". What, so if no article on "Religion in Australia" exists, just bung in a link to "Australia"? No. This is bad advice that countenances trivial, general linking, and should be rephrased.
*"If there is any chance that the topic might become an article in the future, create a redirect page to the article as described in section {{sectionlink|Redirects}}." I'm not sure I entirely like the encouragement to fill an article, especially a new one, with red links. Can it be toned down a little? "Any chance"?
*"Pound sign" is known as "hash sign" outside North America.
*"Let's assume for example you needed a link"—This is too informal a tone for this guideline. It's more like a transcript of a chat or talk.


This is all happening rather fast and without specific discussion. ] ] 07:33, 7 August 2009 (UTC) :As noted, ] is also relevant: "key facts at a glance", without having to chase links. ] (]) 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 ] 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. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">]</span><small>}&#125;</small></span> <sup>]</sup> 00:58, 4 October 2023 (UTC)
:I agree and would have reverted the changes on the project page but found the "Revision history" too confusing. --] (]) 07:58, 7 August 2009 (UTC)
:::Also, this is a very widely adopted practice, used in FAs like ], so disallowing it would be a significant change. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">]</span><small>}&#125;</small></span> <sup>]</sup> 01:02, 4 October 2023 (UTC)
::i concur - can we please back up and discuss the changes being proposed? thanks ] (]) 08:19, 7 August 2009 (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. - ] (]) 09:53, 9 November 2023 (UTC)
:::Agree – also, this is getting too technical. Remember, this is a style guideline, not a help page. ] (]) 13:47, 7 August 2009 (UTC)
::::I believe what @] 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 ] FAC? Because these links are simply helpful, and that's what editors truly care about. ] (]) <small>(])</small> <small style="font-size:66%;">(])</small> <small style="font-size:45%;">(])</small> 12:00, 9 November 2023 (UTC)
:::: Please feel free to revert my changes. There are obviously enough people here who deeply care about this page, so I'm not needed here. See also my talk page. &mdash; ] 06:27, 8 August 2009 (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 Misplaced Pages 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 ] cannot overrule policy. - ] (]) 12:05, 9 November 2023 (UTC)
::::::That is solvable if we created a new parameter for a list page link ({{para|list_of_works}})) and set the data row class in the infobox code to <code>class="noprint"</code>. From what I understand from the <code>noprint</code> class it will remove that piece of text from pinted versions. ] does it with its episode list link. ] (]) 12:09, 9 November 2023 (UTC)
:::::::Not for re-users of our freely available product it doesn't, or for those that read offline. - ] (]) 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%. ] (]) 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. - ] (]) 12:49, 9 November 2023 (UTC)
::::::::::When you say "policy", do you mean this piece of text: {{tq|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 Misplaced Pages content may be encountered in republished form, often without links.}}? If so, that is a guideline, not a policy. Also, it says {{tq|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. ] (]) 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. - ] (]) 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. ] (]) 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 ] says in part that he {{tq|gained fame for his 39 operas}}, so we already know he's notable for composing. And of course the link to ] is already in the article, under "Music" in a {{t|see also}}, so it's not something you'd have to hunt to find.{{pb}}<del>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".</del> {{ins|Struck speculation not reflected in past events 15:28, 4 October 2023 (UTC)}}{{pb}}As to whether it's an MOS violation, I'd say that it doesn't comply with ] as noted. It's not a quick essential fact about the subject that Misplaced Pages has a list article about his compositions. ] (]) 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.{{pb}}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. ] (]) 01:03, 4 October 2023 (UTC)
::Quick thought: would something like ] be sufficiently factual, or fall foul of ] or other good practice? ] (]) 12:57, 4 October 2023 (UTC)
:::I'm not really an MOS regular like ] 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 ], I feel like although just a bare link to another article doesn't fully comply with ], it does serve the reader.{{pb}}Having said that, for this case there is an additional issue in that ] has already been split from ], which links it as a "see also" in its first lvl2 subheading. If the lead sentence of the article says Rossini {{tq|"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. ] (]) 15:26, 4 October 2023 (UTC)
{{od}}
{{Infobox person
| name = Gioachino Rossini
| image = Composer Rossini G 1865 by Carjat - Restoration.jpg
| caption = Rossini in 1865, photo by ]
| alt = Rossini wears a vest and overcoat, holding a cane and looking out of frame
| birth_date = {{birth date|1792|2|29|df=y}}
| birth_place = ], Italy
| death_date = {{death date and age|1868|11|13|1792|2|29|df=y}}
| death_place = ], Paris, France
| works = {{hlist|]|]}}
}}
@], 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? ] (]) <small>(])</small> <small style="font-size:66%;">(])</small> <small style="font-size:45%;">(])</small> 20:53, 4 October 2023 (UTC)


:Maybe it should be "Operas" and "Other compositions", however? After all, operas are compositions too. ] (]) 21:45, 4 October 2023 (UTC)
:I've changed the example from "film actor" to "]". (I have actually seen "Icelandic ]" in an article.) As for the "more general article", I think it's supposed to address cases such as linking ] if you have the text "electron neutrino" (one of the three flavours of neutrinos) and there is no article specifically about electron neutrinos. If you want to make that clearer, do that (I can't find a way right now), but the point itself is valid. In the {{xt|since many "single dictionary word"-titled pages are disambiguation pages, make sure that the links are directed to the correct articles}} part, I meant that pages such as ] are likely to be disambiguations, so before saving an article containing such a link, one should actually check it goes to the right place (e.g. ]). I'm going to change it to {{xt|many pages whose title is spelled identically as a common dictionary word}}. I'm trying to address the point about "any chance". --<span style="background: white; color: blue; font-family: monospace">] di&nbsp;M.</span> 16:43, 7 August 2009 (UTC)
::That makes more sense, thank you- updated accordingly. ] (]) <small>(])</small> <small style="font-size:66%;">(])</small> <small style="font-size:45%;">(])</small> 21:49, 4 October 2023 (UTC)
::Much better example there, ADM (can we call you that? what do you prefer?) I'm still a little uneasy about "specific ''enough''" for a context. It seems vaguer than the previous wording. ] ] 17:48, 7 August 2009 (UTC)
:::Perhaps ] or some such, on the ] principle that ] would normally be expected to link to ], and to make the magnitude clear even without clicking on the link? ] (]) 08:06, 5 October 2023 (UTC)
::::Well, in the aforementioned ] 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? ] (]) <small>(])</small> <small style="font-size:66%;">(])</small> <small style="font-size:45%;">(])</small> 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. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">]</span><small>}&#125;</small></span> <sup>]</sup> 14:23, 5 October 2023 (UTC)
::::::Very good point, I agree- updated ] (]) <small>(])</small> <small style="font-size:66%;">(])</small> <small style="font-size:45%;">(])</small> 15:25, 5 October 2023 (UTC)
::::::: The idea of naming the link "Thirty-nine operas" elegantly realizes ]'s principle "key facts at a glance". It may be worth inclusion here, or at least at ], so I suggested it there. ◅&nbsp;]&nbsp;] 11:52, 23 October 2023 (UTC)
::::::::Many thanks- I'll likely open an RfC at Rossini once the discussion over there is concluded. ] (]) <small>(])</small> <small style="font-size:66%;">(])</small> <small style="font-size:45%;">(])</small> 15:29, 23 October 2023 (UTC)
:::::::::{{fyi}} Participants of this discussion may be interested in this RfC on the same topic: ]. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 03:31, 8 March 2024 (UTC)


== Section links from citations ==
:::yeah, the Icelandic alphabet is great! i'm puzzled by some of what's now listed under "Link specificity", though - those second and third numbered options are not examples of cases where "no such page exists"; they're examples of when a page does indeed exist but using a piped link or a "see also" parenthetical works better than a plain link. ] (]) 08:19, 8 August 2009 (UTC)
:::maybe something like this?
::::Always link to a topic that is specifically relevant to the context from which you link. Examples: Link to "]" instead of "] ]". In the article about Mozart, link to "]" instead of "]". (This second example uses a piped link - see below.)
::::Check to see if a page for the specific topic already exists - this is often the case. For example, link to "the ]" instead of "the ] of ]".
::::If no such page exists, the most appropriate link may be to a particular section of a more general article: ''' egs/instructions'''. Alternatively, you can consider creating a red link, a redirect or adding a parenthetic "for more information, see ]".
:::and (to me) the part about "consider moving links to the see also section" doesn't have anything to do with "Link specificity", so i'd move that point elsewhere. ] (]) 08:42, 8 August 2009 (UTC)
::::Indeed, I didn't understand what points 2. and 3. were doing there, either, so I removed them.
(<<=====) This bugs me.
{| class="wikitable" border="1"
|Always link to the article on the most specific topic appropriate to the context from which you link: it will generally contain more focused information, as well as links to more general topics. For example, link to "Icelandic alphabet" instead of "Icelandic alphabet": it will contain more detailed information about the Icelandic alphabet, as well as links to the articles "Icelandic language" and "Alphabet". Likewise, use "the flag of Tokelau" rather than "the flag of Tokelau"; in the article about Mozart, link to "<nowiki>]</nowiki>" instead of "<nowiki>]</nowiki>".
|}
link to "Icelandic alphabet" instead of "Icelandic alphabet"
Likewise, use "the flag of Tokelau" rather than "the flag of Tokelau";
Huh? What's the difference?<br />


When adding the first citation of ]<ref>https://fathomjournal.org/al-wasatia-reviving-the-palestinian-peace-camp-an-interview-with-professor-mohammed-s-dajani-daoudi/</ref>, 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 ] based on the examples of ] but either the article and section titles were italicised or error notices appeared. In the end I left it as a link to ] which redirects to the Centre. Should it be possible to make a direct link from the citation to the section? ] (]) 22:17, 14 November 2023 (UTC)
I made a point of pasting in the above text without the bluelinks that came from Wikimarkup. <br />
:I would say that you ''shouldn't'' link to the section, regardless. If ] wikilinks should be targeted at ], 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 ] is made centrally and by consensus, rather than each individual citation author making their own call. ] (]) 15:55, 21 December 2023 (UTC)
Why? Because I knew that some of you would say, "WELL D'OH, MORON, you just MOUSE OVER the Wikilinks -- they're DIFFERENT!!!" But not all readers may think of that. If they are new, they have enough trouble absorbing and processing all this information, we cannot expect that everyone will think of hovering the mouse to discover that in the first example, the entire phrase is wikilinked and in the second, every component word individually. Suggested fix: show Wikimarkup first, then actual wikilinked result.--] (]) 12:48, 10 August 2009 (UTC)
:(Also, FWIW in the case of ] in particular, I think linking to the overall ] 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.) ] (]) 17:13, 21 December 2023 (UTC)
{{reflist-talk}}


== MOS:DUPLINK rules for repeating links in articles ==
:that's a good point, Goodmorningworld - you've got my vote if you want to go ahead and fix it. ] (]) 14:15, 10 August 2009 (UTC)
::Okay, I went and changed ], I hope y'all like it better now. ] (]) 19:21, 22 August 2009 (UTC)


After the ] RFC, which demonstrated overwhelming consensus in support of relaxing the "once per article" rule for links to "once per section", RFC closer {{u|Mike Christie}} made {{Diff|Misplaced Pages:Manual of Style/Linking|1159921006|1157644530|a perfectly reasonable edit-of-least-disruption}} to the page, altering the introduction of ] like so:
:::very nicely done, Goodmorningworld! ] (]) 20:34, 22 August 2009 (UTC)
{{quote|Generally, a link should appear only {{em|once}} in an article, but it may be repeated if helpful for readers, such as in ], tables, image captions, ], ], and at the first occurrence <del>after the lead</del><ins>in a section</ins>.}}


Reasonable, sure. Least-disruptive, sure. But... accurate?
== the "what generally should be linked" section ==


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.
a lot of the points in this section are really unclear. can we discuss rephrasing it? some of my questions/proposals are:
:1] i don't understand this point - does "references" mean "footnotes", or ... ? and what does the second sentence mean?
::*articles with relevant information, through references (Example: "{{xt|see ] for relevant background}}"). Linking items in a list of examples makes them easier to reference as well.
:2] i'd like to rephrase the point about technical terms to something like:
::*technical terms, unless they are defined in the article - but always consider providing a concise definition instead of or in addition to a link to another article. If a technical term doesn't have its own article, an ] to ] may be the most appropriate.
:3] the next point sounds dubious to me in a number of ways, including: what kinds of "confusing usage" are meant? what does "explicit articles" mean? and why is the point about about ] buried here? it should be one of the "general principles".
::*explicit articles when word usage may be confusing to a non-native speaker (or users of other varieties of English). If the word would not be translated in context with an ordinary foreign-language dictionary, consider linking to an article or Wiktionary entry to help foreign language readers, especially ]. Check the link for ], and link to the specific item.
assistance improving any/all of that will be very well met - thanks ] (]) 08:00, 8 August 2009 (UTC)
:I've fixed the last two as you suggested, and removed the unintelligible part of the first. Maybe someone who understands what it was supposed to mean can suggest a clearer wording, which could then be re-added. --<span style="background: white; color: blue; font-family: monospace">] di&nbsp;M.</span> 12:56, 9 August 2009 (UTC)


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''?
::thanks A di M - the one i numbered 3 remains incomprehensible to me, though. for that one, what i posted up there is not my suggestion - it's what's puzzling me. what kinds of "confusing usage" are meant? what does "explicit articles" mean? and why is the point about about ] buried here? ] (]) 13:10, 9 August 2009 (UTC)
:::I think it refers to when an English word can have several meanings and it'd be very hard for non-native speakers to figure out which one is meant in a given context. One example someone once made is "He was shot in the ]", but I think there probably are better examples than that. I believe that, when possible, the solution is to use a less ambiguous meaning, but maybe sometimes there might be no valid alternative. --<span style="background: white; color: blue; font-family: monospace">] di&nbsp;M.</span> 22:39, 9 August 2009 (UTC)


IMHO we should bite the bullet, embrace the change, and open with something like:
::::thanks for clarifying, A di M - i agree with you that creating links doesn't seem like the best way to address that kind of "confusing usage", so maybe the recommendation should be omitted altogether from this "what generally should be linked" section. but if it's going to stay, it certainly needs to be expressed more clearly than it is now. how about:
::::::*articles that specify which meaning of a word is intended, such as ] (although writing more clearly to begin with is usually a better solution than relying on links to clarify the meaning).
::::something like that? but again: i think omitting it is a better idea. ] (]) 06:55, 10 August 2009 (UTC)


{{quote|<p>Generally, a term should be linked at most {{em|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.)</p><p>Outside of the body text, additional mentions of the same term may be linked if helpful for readers, such as in ], tables, image captions, ], and ].</p>}} ] (]) 15:47, 21 December 2023 (UTC)
*I agree that clarity of linguistic context is preferable. I often point out where readers should not have to hit a link to work out what an item means. The linked article should generally not be necessary to access a basic definition. "RFID" is one example ]. Yes, "temple" should be clear from the context (I've never thought of mine as religious in the least). ] ] 10:46, 10 August 2009 (UTC)
:That sounds reasonable to me, and an accurate summary of what we really do, though it could be considerably compressed: {{tqb|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 ], ], ], ], and ].}} That appears to get the same messages across in much less wording. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 01:52, 18 January 2024 (UTC)
::Sounds good to me. ] (]) 14:25, 24 January 2024 (UTC)
{{outdent|:::}}
Very belatedly <small>(see below)</small> implemented the re-wording provided by {{u|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.
{{Collapse|title=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}} ] (]) 08:51, 22 March 2024 (UTC)


:{{tqqi|someone ... even stuffed an unnecessarily verbose explanation of the precisely-imprecise contextual meaning of "major" into a footnote}} Heh, turns out ''that'' was '''also''' {{u|SMcCandlish}}'s doing! ] (]) 08:56, 22 March 2024 (UTC)
::A di M, hope you don't mind that i've tried to clarify that "confusing usage" point - the "explicit article" wording really isn't clear at all. the more i think about it, though, the more strongly i feel this point doesn't belong in the "what should generally be linked" section. sentences like the example given should be rewritten, not linked. ] (]) 06:51, 11 August 2009 (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 ] for details. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 10:14, 22 March 2024 (UTC)
:::The monk who was shot in the temple. The word is ''not'' going to mean a religious building, by any stretch of the imagination. This should be moved into the "What should ''not'' be linked" section", if retained at all. I think examples will come readily from goming lots of articles—that's how I come across examples for all of my tutorial pages, almost by coincidence. If "temple" is a must, I'd look at the "what links here" for "Temple". ] ] 07:49, 11 August 2009 (UTC)


== MOS:EGG in Template:Infobox company ==
:As currently worded, that point would encourage linking ''all'' words with several meanings, even if all-but-one of them are completely absurd in a context (e.g. I ] open that ] of beer); that's not what we want. I would have retained the point about non-native speakers and ordinary foreign-language dictionaries. For example, without the links a non-native speaker would have no way to understand most of the sentence {{xt|and in "]" his urine test contained "], ], ], ], ], ], ], ], ], ], ], ]" and trace amounts of human urine (but was misread as Homer's test results)}}, no matter how many learners' dictionaries you'd use. (And that's one of the very rare cases where I'd have links within a quotation; after all, that's a quotation of ''spoken'' language, so it'd make no sense to state that "the links were not present in the original".) Another example is the verdict of ], which linked "]" (but this is a bad example, as I was able to correctly guess what that idiom meant; but this could not be the case with more confusing idioms). The "temple" example is a different one: even the most elementary dict will show both meanings, but the other meaning fits the sentence so well that it might not even occur to a non-native speaker about looking it up; given the high number of completely absurd choice of words in Italian translations of English texts (even by professional translators) I find everyday, which I can only make head or tail of if I guess the original English word and which other meaning could it have, it is not unlikely at all that someone might not realize that "temple" could have another meaning in that sentence. (BTW, "explicit articles" mean "articles about the one specific meaning of the word", as opposed to disambiguation pages.) I'd propose something such as: {{xt|words and idioms used in a context where a non-native speaker could be unable to determine their meaning, even using an ordinary foreign-language dictionary; make sure the link goes to an article specifically about the intended meaning (or to a Wikitionary entry), and not to a disambiguation page (which would defeat the purpose of it). However, rewording the sentence to that it is less confusing, if possible, is strongly preferred.}} --] 13:52, 11 August 2009 (UTC)


I've proposed updating ]'s documentation to avoid a potential ] issue. Please give your thoughts ]. ]&nbsp;<sup>]]&nbsp;]]</sup> 01:24, 12 January 2024 (UTC)
::... i understand what you're saying A di M, but i still feel that an invitation to guess what terms non-native speakers might have trouble understanding and to create links to help clarify their meaning is <u>not</u> something that belongs under "what should generally be linked".
::the example with all the drug jargon is a totally different question - plenty of people whose first language is English wouldn't be able to tell you what all of those mean. that kind of jargon/subcultural slang needs to be linked for the same reason as technical terms need to be linked (which could usefully be clarified in the point about technical terms). ] (]) 14:40, 11 August 2009 (UTC)


== Edit request ==
:::'''update''': sorry, i've just elected to transplant the point here until we can work it out, because it truly doesn't seem to be getting better as it goes along out there. here's the last version:

::::*words and idioms used in a context where a non-native speaker could be unable to determine their meaning, even using an ordinary foreign-language dictionary; make sure the link goes to an article specifically about the intended meaning (or to a Wikitionary entry), and not to a disambiguation page (which would defeat the purpose of it).{{example needed}} However, rewording the sentence to that it is less confusing, if possible, is strongly preferred.
add {{textdiff||2={&#123;pp-semi-indef&#124;small=yes}&#125;}} ] (]) 22:32, 14 January 2024 (UTC)
:::and the last-but-one:
:{{done}} ] (]) 01:01, 15 January 2024 (UTC)
::::*articles that specify which meaning of a term is used, although rewording the sentence so that it is unambiguous is preferable. For example, in {{xt|A monk was shot in the ]}}, a non-native speaker unaware of the anatomical meaning of ''temple'' might not even suspect that in that sentence it does not refer to a religious building.

:::i don't feel the MoS needs to prohibit links like this, but i don't think they should be encouraged as "what generally should be linked". ] (]) 14:49, 11 August 2009 (UTC)
== A change to NOFORCELINK ==
*Sorry, ADM, I was being opaque: I really meant that "temple" shouldn't exemplify the "what should", and used the opposite ironically. May I put in a plea that we move slowly on changing this page. I feel that a lot is happening in a very short time. BTW, ADM, your spanking new signature—did you consider making the A and the M white against those dark backgrounds? ] ] 14:55, 11 August 2009 (UTC)

I had gotten your point, but I couldn't find a better example than that; however, with Sssoul's wording the point is clear even without examples at all, so that's moot now. (As for the sig, the code for that would exceed 256 chars, but I think this one is fine.) --<span style="color: #4B61D1; font-family: monospace; border: thin solid">]A.&nbsp;di&nbsp;M.</span> 18:23, 11 August 2009 (UTC)
Currently NOFORCELINK says {{tq|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 Misplaced Pages content may be encountered in republished form, often without links.}}. <s>The literal interpretation of this</s> My interpretation of this is that it requires that every word that could be considered specialist ("]", "]", "]", "]", ...) be explained in the text. I believe this is impossible and would be bad writing if it were possible. This ], so I'll ping in everyone who was in that conversation, but what prompted me to post here was seeing a request from {{u|Gog the Mild}} in ] (nominated by {{u|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 {{tq|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 {{u|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 ] point that {{u|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: {{u|J Milburn}}, {{u|Lee Vilenski}}, {{u|Bagumba}}, {{u|Uanfala}}. ] (] - ] - ]) 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 ("]", "]", "]", "]", ...) be explained in the text" - is helpful. ] (]) 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 ], eventually NOFORCELINK becomes actively unhelpful? I'm arguing that we should acknowledge that fact in the wording. ] (] - ] - ]) 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. ] (]) 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 ] already has its "out" and I look forward with interest to seeing what there is to discuss. ] (]) 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."{{tsp}}', have you run this past the accessibility people? Their objection is usually taken to be the end of a discussion. ] (]) 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 {{u|Graham87}} who is always helpful on such questions. Also pinging {{u|David Eppstein}} who I know has contributed to this sort of discussion in the past. ] (] - ] - ]) 00:17, 18 January 2024 (UTC)
:::::::I don't think this has any special accessibility implications for users with disabilities. ] (]) 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 ] 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 ] states: {{tq|A '''prime number''' (or a '''prime''') is a ] greater than 1 that is not a ] 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. —] (]) 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 ]. 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. Strongly recommend restoring the original version: {{tq| Do not unnecessarily make a reader chase links: if a highly technical term can be simply explained with very few words, do so.}} ] ] 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. ] is that rule. —] (]) 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 ] and ] and even ] 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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 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 ] is but not what an ] 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. <p>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. </p> ] (]) 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 {{tq|] made a ] 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 {{tq|the event was played as a ].}} 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 {{tq|players who lost one match would be moved to the "loser's side" of the ] 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 ], a ] or a ] is. '''] <sup>(] • ])</sup>''' 10:00, 18 January 2024 (UTC)
:The key words are {{tq|as far as possible|q=yes}}. Articles are not limited to experts, but it shouldn't be bogged down for people with a bit of familiarity. ] is mentioned by some below.—] (]) 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 {{tq|Users may print articles or read offline, and Misplaced Pages content may be encountered in republished form, often without links}} is an obsolete concept. ] says {{tq|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 ], 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. ] ] 16:54, 25 January 2024 (UTC)
::It would be wonderful if it were obsolete. Unfortunately the - there are millions of users of offline versions of Misplaced Pages. ] (]) 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.
* {{tq|member of the Société Honoraire de Français}} from the FAC for ]. Nominators {{u|Neopeius}} and Hawkeye7; reviewer requesting the explanation {{u|The Rambling Man}}. Current wording in the article: {{tq|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.
* {{tq|possibly because of Jacobite sympathies}} from the FAC for ]. Nominator {{u|Pickersgill-Cunliffe}}; reviewer requesting the explanation Gog the Mild. Current wording in the article: {{tq|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 ], ], and ], in the FAC for ]. Nominator {{u|Jens Lallensack}}; reviewer The Rambling Man. That FAC contains a debate about the usage of NOFORCELINK with comments from multiple reviewers.
* {{tq|137 break}} from the FAC for ]. Nominator Lee Vilenski; reviewer Gog the Mild. I think this is the one that led to the last NOFORCELINK discussion.
* {{tq|frigate}} in the FAC for ]. Nominator {{u|Ykraps}}; reviewer Gog the Mild.
* {{tq|"a metal cast plaque in champlevé (carved) enamel}} in the FAC for ]. Nominator {{u|Ceoil}}; reviewer Gog the Mild. Current wording in the article is simplified rather than expanded: {{tq|in champlevé enamel}}.
* {{tq|"Tribal Hidage"}} in the FAC for ]. Nominator {{u|Usernameunique}}; reviewer {{u|UndercoverClassicist}}.
* {{tq|hero pulp}} and {{tq|weird menace}} in the FAC for ]. Nominator Mike Christie; reviewer UndercoverClassicist.
* {{tq|Chagatai literature}} in the FAC for ]. Nominator {{u|Golden}}; reviewer UndercoverClassicist.
* A reverse usage: in the FAC for ], nominated by {{u|Heartfox}}, reviewer {{u|MaranoFan}} questioned the details of a sentence and Heartfox responded that it was required by NOFORCELINK.
David suggested that ] 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. ] (] - ] - ]) 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 ].
::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. '']'' <sup>]·]</sup> 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 "] 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 ] 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"? --] (]) 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.{{pb}}
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 Misplaced Pages. 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).{{pb}}
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'', '']'' and the others I mentioned ], or '']'', '']'', or '']''). They're still good articles. Misplaced Pages editors shouldn't be told to degrade them to cater for print readers in ways that print publishers can't and don't. ] (]) 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. ] (]) 18:28, 18 January 2024 (UTC)

:In response to ]'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 ] 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. '']'' <sup>]·]</sup> 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?" ] (]) 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. --] (]) 18:56, 18 January 2024 (UTC)
:I agree with the idea of applying ] 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.{{pb}}In ] (created by me), the meaning of '']'' is obvious (more than two levels down), so it goes unlinked and certainly without a lengthy definition. In ] 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 ], which contains distinct, unordered objects"). — ] (''']''') 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. ] also conflicts with NOFORCELINK (as does ]) but I would favour applying the former to links instead of the unenforceable NOFORCELINK. ] ] 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''. '']'' <sup>]·]</sup> 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:
:{{tq|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 Misplaced Pages content may be encountered in republished form, often without links.}}
and ONEDOWN says:
:{{tq|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?
:{{tq|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 ] 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. ] (] - ] - ]) 15:05, 19 January 2024 (UTC)

:I like it '''] <sup>(] • ])</sup>''' 15:40, 19 January 2024 (UTC)
:] is not an essay, but rather part of ], which is an editing guideline. —] (]) 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) '']'' <sup>]·]</sup> 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: {{tq|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.}} ] (]) 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? '']'' <sup>]·]</sup> 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. --] (]) 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. '']'' <sup>]·]</sup> 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 Misplaced Pages readership, or this wording change won't achieve anything. ] (] - ] - ]) 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 Misplaced Pages's very best work", so would not become an FAC nor a TFA and thus the hypothetical example seems moot. ] (]) 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 ] proposes. '']'' <sup>]·]</sup> 18:19, 19 January 2024 (UTC)
:::{{ping|Mike Christie}} You are right that the part about the target readership is not ideal. What about: {{tq|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?). ] (]) 23:40, 19 January 2024 (UTC)
::::Of course it's "reasonable extent" that's going to be hard to define, though. I think ], a recently promoted FA, is a good test case. The nominator was {{u|Wehwalt}}; {{u|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 {{u|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? ] (] - ] - ]) 03:43, 20 January 2024 (UTC)
:::::As I expressed , 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 ]).
:::::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 ] 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. ] (]) 11:42, 20 January 2024 (UTC)
::::::I would assume that inline explanations are covered by ] 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". ] (]) 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 {{cuegloss|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. '''] <sup>(] • ])</sup>''' 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. ] (]) 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. '''] <sup>(] • ])</sup>''' 15:47, 20 January 2024 (UTC)
::::::::::I've mentally invoked ] 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&nbsp;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.{{refn|group=UC|1={{harvnb|Smith|2020}}. For the dates of Justinian's reign, see {{harvnb|Jones|1999}}.}} '']'' <sup>]·]</sup> 06:34, 26 January 2024 (UTC)
::::::::::{{reflist|group=UC}}
::::::::::{{sfn whitelist|CITEREFSmith2020|CITEREFJones1999}} '']'' <sup>]·]</sup> 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 {{tq|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 ] guideline stating {{tq|Misplaced Pages 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. --] (]) 12:15, 20 January 2024 (UTC)
::::::<del>I'm not sure I've understood: are you proposing ''removing'' {{tq|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.</del> 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 ]" 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. '']'' <sup>]·]</sup> 13:06, 20 January 2024 (UTC)
:::::::I was suggesting to remove this part: {{tq|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 Misplaced Pages 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 {{tq|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. ] (]) 13:28, 20 January 2024 (UTC)
:::::::::How about {{tq|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}}? ] (] - ] - ]) 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 {{tq|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. '''']'' <sup>]·]</sup> 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. ] (]) 14:45, 20 January 2024 (UTC)
::::::::::::I think there's a difference in emphasis between {{tq|if a {{em|highly technical}} term}} (formatting mine) -- which suggests that we generally ''don't'' explain, unless the term is ''highly'' technical -- and {{tq|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 (]), 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. '']'' <sup>]·]</sup> 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? ] (]) 14:59, 20 January 2024 (UTC)
::::::::::::::I'm not sure: compare an instruction like:
:::::::::::::::{{tq|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. '']'' <sup>]·]</sup> 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? ] (]) 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:
::::::::::::::::* {{tq|Unjustified changes from one acceptable, consistently-applied style in an article to a different style '''may generally''' be reverted.}}
::::::::::::::::* {{tq|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'''.}}
::::::::::::::::* {{tq|'''Normally''' use nouns or noun phrases: Early life, not In early life}}
::::::::::::::::* {{tq|'''In rare cases''', a hyphen can improve clarity if a rewritten alternative is awkward, but rewording is '''usually''' preferable}}
:::::::::::::::: '']'' <sup>]·]</sup> 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. ] (]) 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. ] (]) 15:36, 20 January 2024 (UTC)
::::::::::{{ping|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. ] (]) 15:32, 20 January 2024 (UTC)
{{od}} 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. - ] (]) 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? {{tq|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.) ] (] - ] - ]) 16:30, 20 January 2024 (UTC)
::How about {{tq|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}}? ] (] - ] - ]) 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. ] (]) 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? ] (] - ] - ]) 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: {{tq|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 ] posted above). I am not sure if that second part is needed, but let me know what you think. ] (]) 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 {{tq|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. ] (] - ] - ]) 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. ] (]) 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. '']'' <sup>]·]</sup> 20:13, 20 January 2024 (UTC)
::::::I also support Mike's proposed wording. ] ] 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. ] (] - ] - ]) 22:23, 20 January 2024 (UTC)
::::::::No objections at all, please go ahead! ] (]) 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 Misplaced Pages footnotes too are similarly explanatory and expansive, so clicking to a note only to find a dictionary definition can be very frustrating. ] (]) 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''“. - ] (]) 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
:{{tq|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 Misplaced Pages content may be encountered in republished form, often without links.}}
to
:{{tq|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. ] (] - ] - ]) 23:03, 20 January 2024 (UTC)
::Note: "unduly" added to the proposed wording per a comment below. ] (] - ] - ]) 13:01, 23 January 2024 (UTC)

:Just to be clear, do you intend to keep the other existing and very similar sentence in ] ({{tq|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? ] (]) 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. ] (] - ] - ]) 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.) '']'' <sup>]·]</sup> 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. ] (] - ] - ]) 11:41, 22 January 2024 (UTC)
:Seems sensible to me. '''] <sup>(] • ])</sup>''' 13:50, 22 January 2024 (UTC)

I like {{u|Jens Lallensack}}'s earlier suggestion at ] (above) to add ''unduly'': {{tq|If a technical term can be explained without <u>unduly</u> 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.—] (]) 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. ] (]) 19:15, 22 January 2024 (UTC)

:Yes, it's subjective, but so is ]. That in itself is not a showstopper. —] (]) 07:42, 23 January 2024 (UTC)
::True. But MOS:OVERLINK has a long series of examples and other guidance. ] (]) 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. ] (]) 03:14, 23 January 2024 (UTC)
:I think everyone agrees that the non-expert reader should be catered to. A sentence such as {{tq|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? ] (] - ] - ]) 11:46, 23 January 2024 (UTC)
::Yes, that would be a good example. ] (]) 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? ] (]) 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. ] (] - ] - ]) 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 ] 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. ] (]) 13:13, 23 January 2024 (UTC)
::::{{tq|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 ]), 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. '']'' <sup>]·]</sup> 13:21, 23 January 2024 (UTC)
::::{{ping|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? ] (]) 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: {{tq|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? ] (]) 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. ] (]) 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. '']'' <sup>]·]</sup> 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? ] (]) 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. ] (]) 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. ] (]) 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, ], 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 ] 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 ] and ] that are peripheral to the core subject. ] (] - ] - ]) 12:06, 24 January 2024 (UTC)
::::As discussed above, I am not convinced that NOFORCELINK does not apply to ]. The article contains terms that are not even mentioned in the basic article ] (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 '']''. 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). ] (]) 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. ] (]) 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". ] (]) 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 ] 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? ] (]) 06:18, 25 January 2024 (UTC)
::::::::I think ONEDOWN was written with technical topics in mind and is hard to apply to articles like ]. 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: ] is linked but not explained, for example, but ] 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 {{tq|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. ] (] - ] - ]) 08:11, 25 January 2024 (UTC)
:::::::::I think that's ended up as a tautology: {{tq|unduly}} is, by definition, a matter of judging what is {{tq|}}. How would one assess that if not by {{tq|us editorial judgement}}? '']'' <sup>]·]</sup> 08:53, 25 January 2024 (UTC)
::::::::::Fair point. Is there a wording that invokes editorial judgement that you could support? ] (] - ] - ]) 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 -- {{tq|appropriate}}, {{tq|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". '']'' <sup>]·]</sup> 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? ] (] - ] - ]) 11:38, 25 January 2024 (UTC)
:::::::::::::The proposed wording overtly privileges the knowledgeable reader over the non-knowledgeable, which seems contrary to Misplaced Pages'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. ] (]) 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: {{tq|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}}? ] (] - ] - ]) 13:31, 25 January 2024 (UTC)
::::::::::::::I disagree with the contention that it is contrary to Misplaced Pages's values, given our educational mission. ] ] 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. ] (]) 13:54, 25 January 2024 (UTC)
::::::::::::::Yeah, I think we're heading in the wrong direction. ] (]) 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. ] (] - ] - ]) 06:47, 26 January 2024 (UTC)

===Example===
I'm reviewing ] by {{u|UndercoverClassicist}} right now. The following sentence reminded me of this discussion: {{quote|The area above the central doorway is decorated in the ], and consists of an ] in ], topped with marble ]s and ] and made from a variety of limestone known as ]. Above the metopes and triglyphs is a {{transl|grc|]}} with ]s, itself topped with an ]}} 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. <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding ] comment added by ] (] • ]) 00:22, 30 January 2024 (UTC)</small>
: 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 {{tq|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. {{small|Incidentally: thank you for raising this here -- it's helped me spot a couple of mistakes!}} '']'' <sup>]·]</sup> 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. '''] <sup>(] • ])</sup>''' 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&ndash;benefit analysis. '']'' <sup>]·]</sup> 09:46, 30 January 2024 (UTC)
::I'd start of the second month. ] (]) 21:52, 11 February 2024 (UTC)

== NOPIPE, piped links, and VisualEditor ==

Editors interested in ], and the use, creation, and modification of piped links in Visual Editor may be interested in the discussion going on at ]. Thanks, ] (]) 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? '''] <sup>(] • ])</sup>''' 15:39, 4 February 2024 (UTC)

:The MOS was since tweaked to "<ins>major </ins> section" —] (]) 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. {{u|SMcCandlish}} you added in "major" to this wording. What was your intent? - ] (]) 17:54, 26 February 2024 (UTC)
:::I was unsure what the MOS meant and started ] over at ], regarding an article I was working on (]). 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. ] (]) 18:05, 26 February 2024 (UTC)
:::"Major" is level 2 (== ... ==). ] (]) 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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 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.<!-- --><p>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 ] 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., ]), 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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 19:05, 26 February 2024 (UTC)</p>
::::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'.". - ] (]) 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. ] (]) 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 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). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 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. ] ] 04:37, 28 February 2024 (UTC)

== Discussion about ] in infoboxes ==

There is currently a ] about MOS:FORCELINK's application in infoboxes. Any feedback from knowledgeable editors would be greatly appreciated. Thanks! ] (]) 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 ]). Is this overlinking or not? I started to think that they are overlinking, but it does not seem that ] directly says something about this. ] (]) 05:56, 6 March 2024 (UTC)
:"In articles" is not helpful. Specific examples? -- ] (]) 07:13, 6 March 2024 (UTC)
:: are cases in Korean. Some people have been adding Wiktionary links to tons of Korean terms. Isn't this overlinking? Misplaced Pages does not have to provide a link for every single non-English lexical item. ] (]) 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. -- ] (]) 04:49, 7 March 2024 (UTC)
:Linking aside, ] advises: {{tq2|Non-English terms should be used sparingly.}} The essay {{section link|Misplaced Pages:Writing_better_articles#Use_other_languages_sparingly}} says: {{tq2|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 ].—] (]) 07:21, 6 March 2024 (UTC)
::I'd be wary of making this common practice for such articles. ] ] 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.{{pb}}{{u|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 ] to ]. 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:
#<nowiki>]</nowiki>
#<nowiki>]</nowiki>
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:
#<nowiki>]</nowiki>
#<nowiki>]</nowiki>
Joy on the other hand has suggested ] that if the term presented to the reader is "Bojana", the piped link markup should remain as follows:
*<nowiki>]</nowiki>
... and that changing the piped link in this case to <nowiki>]</nowiki> is a "pointless activity" that should not be done and is worthy of being reverted.
It appears that she has not contested changing <nowiki>]</nowiki> to <nowiki>]</nowiki>.{{pb}}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.{{pb}}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?{{pb}}] says that {{tq|Piping and redirects are two different mechanisms}} and ] says {{tq|Do not confuse piped links and redirects}}. But should ] also say something about this? Something like:{{blockquote|''When piping, the reader should be led to the destination article directly, and not through a redirect''.}} —] 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. <code><nowiki>]</nowiki></code> (with nothing after the pipe). On storing the page, our software autoconverts such links to <code><nowiki>]</nowiki></code>. 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. ] (]) 06:35, 6 April 2024 (UTC)

: I agree with {{u|Joy}} and {{u|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? ] (]) 13:43, 12 April 2024 (UTC)
::I agree. As ] 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 ] that should have been linking to ], 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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 04:02, 18 April 2024 (UTC)

== Ambiguity in GEOLINK examples ==

] gives two examples: ], Australia; and ], United States. This creates an ambiguity, which ] and I agreed to raise here after it came up in ]: 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 "], New York, United States"? For that matter, could one write "]"?

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, "]" and "], ]" would look almost identical to me, making it unclear, when I click on "New York" there, where I'm going to be taken. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 03:42, 18 April 2024 (UTC)
:My reading of it has been that the link should generally match the article name (i.e, ] as a single link). However, that does get complicated for mononymic articles like Sydney in areas where other cities (c.f. ]) have the larger unit in the article name. I definitely agree that only a single link should be used regardless of the style. ] (]) 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. -- ] (]) 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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 14:49, 18 April 2024 (UTC)
::::No, since the article title is ], just link that completely. Writing that as {{code|], New York}} would just be needlessly convoluted. ] (]) 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 ], Ontario, Canada, to ], 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 of "], New York" alone (and of "], Arizona", and so on and so forth.). <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 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 {{code|], New York}} I encounter in an article I edit to {{code|]}} without any pang of bad conscience. (Though I would be too lazy to chase it through articles I don't otherwise edit.) ] (]) 17:42, 18 April 2024 (UTC)
:::::::{{tqq|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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 17:46, 18 April 2024 (UTC)
:::::::''Bluelink, comma, blacktext'' models {{tq|generally do not link the larger unit}}; I'd be sorry to see it changed to ''blue, comma, blue''. ] (]) 17:57, 18 April 2024 (UTC)

Further to that, what’s the rule if there are three entities, progressively larger? For example: ], ], Poland. Is that how we should do it? — ] <small><sup>]</sup></small> 21:13, 18 April 2024 (UTC)

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

::Why should our readers be expected to know where (or what) ] is? Seems extremely arbitrary -- and decided with little input from the community. ] (]) 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 ], where they'll easily find another link to ] (in the lead sentence, in fact). ] (]) 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. ] (]) 06:29, 19 April 2024 (UTC)
== "]" listed at ] ==
]
The redirect <span class="plainlinks"></span> has been listed at ] to determine whether its use and function meets the ]. Readers of this page are welcome to comment on this redirect at '''{{slink|Misplaced Pages:Redirects for discussion/Log/2024 April 25#MOS: OVERLINKING}}''' until a consensus is reached. <!-- Template:RFDNote --> <span style="background-color: #FFCFBF; font-variant: small-caps">] <sub>(''']''' / ''']''')</sub></span> 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:{{pb}}{{tq|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.}}{{pb}}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. ] (]) 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. ] 00:00, 24 May 2024 (UTC)
:A number of times I've seen ]-correcting edits reverted, with edit summaries to the effect of "it's not <u>that</u> much blue". I think there's sometimes a nonchalant sense of "big deal, just press "back" and click the right link, ", 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. —] (]) 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. ] (]) 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. ] (]) 18:14, 30 May 2024 (UTC)

== Linking to geographic places ==
<blockquote>
''For geographic places specified with the name of the larger territorial unit following a comma, generally do not link the larger unit.''
</blockquote>

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

:Note that ] 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 <nowiki>]</nowiki>, Wisconsin, and not using "United States". ] 00:07, 18 June 2024 (UTC)
::Well, Wisconsin is not a well-known state like California or Texas, I reckon the link should be <nowiki>"], ]"</nowiki> instead. ] (]) 09:46, 18 June 2024 (UTC)
:::No, ] 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. ] (]) 10:17, 18 June 2024 (UTC)
:Anytime I come across a disambiguated geographical term that's been piped and doubled up like proposed here ({{code|{{!((}}Qianxi, Guizhou{{!}}Qianxi{{!))}}, {{!((}}Guizhou{{!))}}}}), I'll just copyedit it down to link the disambiguated title in full for cleanliness and simplicity (]). I expect many others do similarly. ] (]) 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 ], or ] or ]. Where necessary, we link one level up, so on the ] article, we should link to ], but we do not link to ] or ], which are more steps away.
:Geographically, this is the same. So in, say, ], we have {{tq|“He founded the Lawson Aircraft Company in ], to build military training aircraft…”}}. If a reader does not understand ], 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. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">]</span>&nbsp;(])</span> 05:39, 20 June 2024 (UTC)

== Unusual situation regarding linking userspace from mainspace ==

So I was over at '']'' 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: {{sectionlink|Comprised of|Removal from Misplaced Pages}}.{{pb}}At the bottom of the article, in {{sectionlink|Comprised of|External links|nopage=y}}, we link an essay by the editor who made it {{their|User:Giraffedata}} job to expunge this phrase from mainspace: ]. (Incidentally, ] redirects to the same essay.) {{blue|It occurred to me that this isn't really an external link.}}{{pb}}The guidance this talk page is attached to states {{xt|In articles, do not link to pages outside the article namespace, except in articles about Misplaced Pages itself}} (at anchor ]). I'm wondering if this case is {{xt|about Misplaced Pages itself}} {{em|enough}} to link ]'s essay in the article body. I was thinking a section hatnote like {{tl|see also}}, but I wanted to ask here to see what people think. ] (]) 12:18, 30 June 2024 (UTC)

:If that section remains, it is about Misplaced Pages itself. (I would argue that it shouldn't remain). ] (]) 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: ''] ]''<small> 21:05, 23 July 2024 (UTC).</small>
:The foundational principle is that, when covering ourselves on the encyclopedia, to maintain neutrality we want to treat Misplaced Pages 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. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 05:52, 26 July 2024 (UTC)
:<br />

== Clarity and Specificity in the requiem example ==

The Link Clarity section discourages "Previn conducted Mozart's <nowiki>]</nowiki>" and then the Specificity section says that it's preferred over just <nowiki>]</nowiki>. 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? --] (]) 05:42, 5 August 2024 (UTC)

== Overlinking guidance in ITN ==

A question for watchers of this talk page: does linking to ] and ] in go against the spirit of ]'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! ]&nbsp;<sup>]]&nbsp;]]</sup> 15:06, 8 August 2024 (UTC)

:I'd say no to both. ] is a specific article with useful information, a link to the generic ] article would be a different matter. Not all of our readers will have been in ] already or be intimately acquainted with that city, so I'd say that link is surely useful too. ] (]) 15:14, 8 August 2024 (UTC)
::Thanks {{u|Gawaon}}! I appreciate the thoughts. ]&nbsp;<sup>]]&nbsp;]]</sup> 02:16, 10 August 2024 (UTC)
:The prime minister link is excessive when the bolded link is ]. Readers generally know what a prime minister is, and can go to her bio for more related links, such as ]. —] (]) 02:55, 10 August 2024 (UTC)

== "]" listed at ] ==
]
The redirect <span class="plainlinks"></span> has been listed at ] to determine whether its use and function meets the ]. Readers of this page are welcome to comment on this redirect at '''{{slink|Misplaced Pages:Redirects for discussion/Log/2024 August 8#MOS: OVERLINKING}}''' until a consensus is reached. <!-- Template:RFDNote --> ]&thinsp;<sup>]</sup> 20:34, 8 August 2024 (UTC)

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

''Originally created for ] but probably belongs somewhere on MOS:LINKING''.

Some ways to work a Wiktionary link into prose:

{| class="wikitable"
! Tone
! Type
! Example
|-
| {{nowrap|Semi-encyclopedic{{efn|Avoid making an entire sentence a link if it will be lengthy}}}}
| Full statement
| ]. Therefore, ...
|-
| Encyclopedic
| Noun phrase (specific)
| According to ] ...
|-
| Encyclopedic
| {{nowrap|Noun phrase (slightly vague)}}
| I read ] and learned ...
|-
| Encyclopedic
| ] (more blue)
| ] can mean ...
|-
| Encyclopedic{{efn|Avoid using italics to mark word-as-words in this case; consider using quote marks instead.}}
| Words-as-words (less blue)
| The word "]" can mean ...
|-
| Semi-encyclopedic
| Verb phrase (informational)
| ] as ...
|-
| Semi-encyclopedic
| Verb phrase (instructional)
| The word "downtime" can refer to either ] or ]s (at least in American English; ]).
|-
| Talk pages only
| Prepositional phrase
| The word "downtime" can refer to either ] or ]s. Well, ].
|-
| Encyclopedic
| {{nowrap|Parenthetical disambiguation}}
| See ].
|-
| Semi-encyclopedic
| Qualifier
| ], a "mush room" is ...
|-
| Talk pages only
| Qualifier in aside
| A cantaloupe is a type of melon (at least ]).
|-
| Talk pages only
| Verb phrase (narrative)
| I ] and OMG, ...
|-
| Talk pages only
| Snide remark
| Are you sure that's a good source to cite in our paper? ]
|}
{{notelist-talk}}


{{mhair}}] (]) 06:04, 11 August 2024 (UTC) ] (]) 06:04, 11 August 2024 (UTC)
== Cross namespace links ==


Any objections to adding "links from article to user namespace links" as something to avoid in general. I recently came across a "see also" which linked to a list developed on the user's subpage. I removed it, citing ] but it might be nice to add that here. Any objections, thoughts or discussion? --] (]) 18:36, 9 August 2009 (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 ] {{code|]}}, or {{tl|linktext}} or one of the other templates listed at {{tl|Wiktionary templates common doc}}? ] (]) 14:14, 11 August 2024 (UTC)
::What's your favorite existing "subtle hint" template for linking to Wiktionary?
:I have ] added it, since there did not seem much discussion here. --] (]) 03:36, 21 August 2009 (UTC)
::Do you want to help me change my template so it takes a slug & anchor rather than a full URL?
::Doh, already in it. My mistake. --] (]) 04:07, 21 August 2009 (UTC)
::{{mhair}}] (]) 16:31, 11 August 2024 (UTC)
:::Ah, I understand now that one primary purpose of your template is the smol <span style="padding-left:.25em; position: relative; bottom: .2em;">]</span> 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 <syntaxhighlight lang= "wikitext" inline= y>{{Plain link|1={{{1}}}|2={{{2}}}</syntaxhighlight> to <syntaxhighlight lang= "wikitext" inline= y>]</syntaxhighlight> (with the ] bit retained, of course). I'm not sure of the use cases for using a full URL and figured you might have some.{{pb}}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.{{pb}}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.{{pb}}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, ] (]) 20:30, 11 August 2024 (UTC)


== Websites and social media platforms ==
== Particle physics ==


My edit on ] was reverted when I added a link to the ] 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. ] (]) 16:04, 11 August 2024 (UTC)
ADM, one or two examples from that area are fine. Pp articles are likely to be more heavily linked because they contain a higher density of very technical terms. They are unusual in that respect. It may not be necessary, but you might consider making the point that articles (and parts of articles) vary in the appropriate density of links ''because'' of their varying technicality. ] ] 02:10, 10 August 2009 (UTC)
:Good point. They were the first ones which occurred to me (due to my background...), but I would not object to replacing them (except the one about Feynman, which is the most spectacular example of how ''not'' to use a piped link I have ever seen in an actual article). In particular, the one about electron neutrinos is not a very good example, because it's not evident to everybody that an article about them could be written. For the example on proton mass, I had thought hard about an example of a topic which could ''not'' have its own article; ] suggests "oak trees in North Carolina", but for the second half of the example I was looking for something more obviously needing linking than ] or ]. --] 20:14, 10 August 2009 (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? ] (]) 17:06, 11 August 2024 (UTC)
== Strong disagreement with encouragement to repeat-link ==
:@]: 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. ] (]) 17:11, 11 August 2024 (UTC)
::Some editors think that everyone knows Instagram, but I agree with your reply. ] (]) 17:39, 11 August 2024 (UTC)


== RfC: GEOLINK examples ==
"(As a rule of thumb, do not repeat a link in the main prose of the article more than once per section.)"—Why are editors now encouraged (that is as it will be taken) to link the same item in successive sections? This seems like a massive invitation to link, link, link, link. If a reader doesn't bother to hit the link on its first occurrence, many editors would say that's too bad, they'll need to catch it as they re-read the article.


It remains unclear to many editors how ] should be interpreted in relation to sequences such as {{tq|Sydney, New South Wales, Australia}}. Should be restored? ] (]) 23:45, 11 August 2024 (UTC)
This needs to be removed. ] ] 23:01, 11 August 2009 (UTC)


:Because people don't always read the article from start to end... --] 00:14, 12 August 2009 (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? ] (]) 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. ] (]) 07:14, 12 August 2024 (UTC)
::Well if they do that, it's too bad. This is not a magic blue-carpet service for readers who want to read only Section 5 and expect to be linked everywhere from just that section. Articles need to stand as whole entities. Why don't we link "the" every time it occurs. Why don't we simply turn the whole article, every single word, into blue links, just to be sure that no one misses out.
::High-value links are diluted by linking items in every section. It's a major change in practice, and must not be allowed to occur.] ] 00:37, 12 August 2009 (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). ] (]) 07:50, 12 August 2024 (UTC)
*:::I don't think it is clear enough, because people are still confused. For example, see ] above. {{U|The Doom Patrol}} wrote: {{tq|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.}} ] (]) 09:01, 12 August 2024 (UTC)
:::You're not making any sense. Someone going to an article about a railroad and reading the history might want more information about a major predecessor. It would be silly to make them find the only place it's linked just because it's mentioned earlier. --] 00:56, 12 August 2009 (UTC)
*'''Comment''' What was the reason to change from the "Buffalo, New York" example to "London, Ontario"?—] (]) 07:30, 12 August 2024 (UTC)
::::I think we should take the middle road on this and encourage linking ''uncommon'' terms twice: once in the lead and once on the first appearance of the term in the body of the article. That way, readers who just want a quick overview of the subject can read the lead and see the link, and readers who want an in-depth understanding of the topic might skip the lead and still find the link. ] (]) 01:15, 12 August 2009 (UTC)
*:I think it is clearer. <code><nowiki>]</nowiki></code> just adds to the confusion. ] (]) 09:00, 12 August 2024 (UTC)
:::::That might be acceptable, dabomb, since the lead functions quite differently to the body of the article (as does the infobox); it is already the practice of a few editors. But really, linking a term in one section and then another is wasting the value of wikilinks. There's a dilutionary cost for every one added; I don't want to puff up the crisis potential of adding a single link—you know what I mean: editors will add links all over the place in an undisciplined way unless they're guided as to the balance between cost and utility. Look at the French and Italian WPs for examples of ruined wikilinking systems. ] ] 02:27, 12 August 2009 (UTC)
::::::Wow... "wasting the value"... "puff up the crisis potential"... "ruined wikilinking systems"... either you're making a dry joke or you need to step back and look at the big picture... --] 02:58, 12 August 2009 (UTC) *'''Comment'''. Perhaps the guidance should be changed to something like this: {{tq|For a geographical location expressed as a sequence of two or more territorial units, link only the first unit.}} ] (]) 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 {{xt|], 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. ] (]) 10:41, 12 August 2024 (UTC)
:::::::Perhaps you didn't see where I was being ironic and where I was not. ] ] 04:03, 12 August 2009 (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. ] (]) 10:46, 13 August 2024 (UTC)
: I concur that this needs to be removed. Please look at it the same way as an acronym. Spell it out at first mention, then use the acronym. If someone reads only one section of an article and finds themselves stymied, they will read back, same as they would do if they need more context about the subject. We don't need "in case you are just joining us" wikilinks. --] ] 04:38, 12 August 2009 (UTC)
*:::@]: This still doesn't address the issue I raised above in {{slink||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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 05:39, 14 October 2024 (UTC)
*::::I think the guidance, as it stands, is fairly clear: <code><nowiki>], United States</nowiki></code> is preferred over <code><nowiki>], New York, United States</nowiki></code>. The guidance could be changed, but I suspect most editors would support <code><nowiki>], United States</nowiki></code> for the sake of simplicity. ] (]) 22:13, 14 October 2024 (UTC)
*:::::Indeed. ] (]) 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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 01:52, 16 October 2024 (UTC)
*::::::Or somebody could just change the page to make it clearer. ] (]) 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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 08:35, 16 October 2024 (UTC)
*::::::::Well, being ] and seeing whether one is reverted is usually the easiest way to find out whether there is consensus. ] (]) 16:47, 16 October 2024 (UTC)
*:::::::::I mean, I'll save the time: I would revert it, because there is no consensus for it. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 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. ] (]) 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 ']' and piping only ']' are appropriate. The same approach should be taken consistently throughout an article." Anything else would be overstating consensus in either direction. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 18:40, 16 October 2024 (UTC)
*::::::::::::That's indeed not consensual, I'd say. Sure, writing "]" is fine if that's all the text you want, but what would be the point of writing "], New York" instead of simply "]"? ] (]) 17:43, 17 October 2024 (UTC)
*:::::::::::::As I've explained before, it is both more consistent (e.g. alongside "], Georgia") and more accessible ("]" is hard to distinguish from "], ]"). 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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 20:21, 17 October 2024 (UTC)


== Erratic shortcuts ==
::i agree that "link once per section" is too frequent, as a rule of thumb. (besides which, having a rule of thumb within another rule of thumb was awkward.) ] (]) 05:05, 12 August 2009 (UTC)


On a mobile phone, use of the shortcuts ] and ] 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?
:I agree that the quoted text needs to be removed. ] 06:17, 12 August 2009 (UTC)
::I was only trying to clarify what "a long way" meant; I was not encouraging anyone to repeat the same link in *every* section of any article. (And I don't believe that having the same link repeated twice in an article is ''always'' useless. Imagine a very technical word used in a minor parenthetical point in section 3 (with a link), and then the same term used in section 17 in a sentence where it's crucial to understand it all. Many readers will have forgotten that they had encountered that term before, so they won't know where to look for the link. Now imagine there is a ''redirect'' to section 17: a reader following it will encounter that unlinked technical term and they won't be able to make head or tail of it ''at all''. --<span style="color: #4B61D1; font-family: monospace; border: thin solid">]A.&nbsp;di&nbsp;M.</span> 10:15, 12 August 2009 (UTC)
::: The language is clear enough as stands. People can use their judgment in cases such as what you mention. --] ] 13:01, 12 August 2009 (UTC)
::::Agree. One problem with the text is that it will green-light the edits by those who merely seek to lift their edit count. Such editors will only have to point at the text and say: "but the guidelines allow me to add all those links". ] 22:57, 12 August 2009 (UTC)
:::::That's circular reasoning: it's bad because it's bad. If linking is good then I would expect editors to add links where apppropriate and applaud such behaviour.--] <sup>]</sup> 07:47, 20 August 2009 (UTC)
:::::What about the editors who seek to lift their edit count by removing repeated links? --] 07:54, 20 August 2009 (UTC)


(] (]) 00:14, 24 September 2024 (UTC))
After thinking about this for a while, I think linking has two fundamental aspects that overlap significantly but have slightly different requirements: Navigational and explanatory. Navigational aspect: When you go to ], you expect to find links to ] and ] in prominent positions. Possibly in the lead, but certainly from the most relevant section. Explanatory aspect: A reader who does not know a term, or aspects of it that are assumed without explanation, they can follow a link to the relevant article.


: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 ]. No issue on desktop. ] (] / ]) 00:38, 24 September 2024 (UTC)
Based on this theory I came up with this rule of thumb: (1) If it's obvious from the table of contents where a certain linkable term will be discussed, link it once from that section. In very long articles occasionally two sections far apart from each other may deserve such a link. (2) If the term first appears in an earlier section, e.g. the lead, link it from there as well.
:I get this somewhat frequently on projectspace pages with lots of subsection shortcuts (] 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. ] (]) 01:51, 24 September 2024 (UTC)


== To remove or not remove underscores in wikilinks ? ==
The formulation also allows for situations where it's better to link the second occurrence in a paragraph. ] ] 13:22, 12 August 2009 (UTC)


What is the preferred styles ? ] (]) 15:37, 28 September 2024 (UTC)
:i understand what A di M means about "a long way" sounding vague - but there are too many different situations for a more specific "one size fits all" solution. ("don't repeat a link more than once per section" <u>does</u> read like an invitation to repeat links once per section.) if we're going to add anything to the "long way" point, i propose a parenthetic to show it's vague on purpose - something like: "(how far 'a long way' is will vary; editors can make their own judgements within individual articles.)" ] (]) 14:33, 12 August 2009 (UTC)
:
:Hans, I agree with the point about two types of links, but I'm not 100% sure I understand what the conclusion has to do with it, as you don't say that the two types of links should be handled differently. (Besides that, links in the lead section will generally be almost all navigational, and links in later sections almost all explanatory.) --<span style="color: #4B61D1; font-family: monospace; border: thin solid">]A.&nbsp;di&nbsp;M.</span> 19:49, 12 August 2009 (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. ] (]) 22:50, 28 September 2024 (UTC)
::''Explanation of the parenthesis above.'' The lead section will be read by people who have just heard about the article topic (via a search result, or following an explanatory link), so we should not assume that the reader will be willing to go read even more articles in order to understand a sentence. That is not to say that no technical terms should ever be used in a lead; but they should be used in a way that the reader will not miss the gist of a sentence if they don't follow any link. Take a look at the lead of ]: a lay reader will likely have never heard of "color confinement" or "hadrons" before, but they will be able to understand the point of that sentence anyway. So you don't want purely explanatory links in the lead. As for navigational links, a reader just visiting the article ] or ] as a stepping stone to ] or ] will want to find those links without scrolling down; so navigational links should all be found in the first screenful of the article.
::
::The rule of thumb I generally use is: include each navigational link as near the top of the article as reasonably possible; repeat the most important ones in a {{tl|seealso}} or {{tl|main}} template before the first paragraph of the relevant section, and/or in navboxes, but not in paragraphs. As for the explanatory links, include each one the first time it occurs; and for specialist terms (ones that most people with a high school diploma have never heard of) repeat them the first time they occur in each sentence, except if they have been linked to in the lead. (This is based on the assumption that almost all readers will read the lead, and then some of then might jump through the TOC to the section they're interested in.) --<span style="color: #4B61D1; font-family: monospace; border: thin solid">]A.&nbsp;di&nbsp;M.</span> 13:35, 13 August 2009 (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. ] (]) 08:38, 30 September 2024 (UTC)


== unlinking ] in in an infobox? ==
I have never understood the aversion folks have to linking, since I do not find it reduces readability; quite the contrary I find it reassuring to read a heavily linked sentence, knowing that I'm only a click away from more details if desired. It's very annoying in the middle of an article to realise that you have to go off on a long hunt for a link, and when you find it and click through you aren't returned automatically to where you where.


I noticed @] 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 ] to be linked without NYC being linked? If someone actually wanted more info about where ] resided, wouldn't the city be more useful than the larger and less specific state? ''']'''<span style="border:2px solid #073642;background:rgb(255,156,0);background:linear-gradient(90deg, rgba(255,156,0,1) 0%, rgba(147,0,255,1) 45%, rgba(4,123,134,1) 87%);">]</span> 05:16, 8 October 2024 (UTC)
The notion expressed above that you have some moral duty to click on the first occurence, and if you missed it, well fuck you, is one of the most unfriendly attitudes I've seen here for awhile. It reduces rhe utility of WP.
--] <sup>]</sup> 23:21, 19 August 2009 (UTC)


:If something is to be linked, link the city per ], and never separately link larger units like state, country, etc. —] (]) 05:22, 8 October 2024 (UTC)
:I agree, I couldn't believe my eyes when I read some of the language used above. I'm appalled by the distain showed here for our readers. Limiting linking to the extent talked about above limits the usefulness for no other reason than it seems to offend some people. The appropriate level of linking will be found just as any other editorial question is settled on Misplaced Pages and not by some (literally) arbitrary set of rules. Editors can (and will) make judgements about linking on an article by article basis. ] (]) 05:05, 20 August 2009 (UTC)
:Moreso than prose, infoboxes are subject to drive-by editors who want "uniformity" across articles. The amount of churn on the supposed ] of NYC and other "major" cities is not worth it for this. I'd support an exemption for infoboxes.—] (]) 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? ] (]) 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.—] (]) 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. ''']'''<span style="border:2px solid #073642;background:rgb(255,156,0);background:linear-gradient(90deg, rgba(255,156,0,1) 0%, rgba(147,0,255,1) 45%, rgba(4,123,134,1) 87%);">]</span> 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 ] be linked, but not ]? Or are both to be linked, or none? I couldn't really say, tend to link when in doubt, and think Misplaced Pages would lose nothing by dropping this rule altogether. ] (]) 07:51, 8 October 2024 (UTC)
:::::Not only are New York and London "commonly understood terms", but they are also unique capital city names? {{small|(Perhaps there's a technical means of preventing linking those two in any infobox? How about administering a small electric shock when anyone attempts? ]!}} ] (]) 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 ] in infoboxes or even – if I understand your last sentence correctly – drop this rule altogether and link it in article text? ] (]) 13:29, 8 October 2024 (UTC)
::::::I'm talking about geographical entities like countries and cities, not necessarily about anything else. ] (]) 20:27, 8 October 2024 (UTC)
:Didn't we just have this discussion last year? At {{sectionlink|Misplaced Pages talk:Manual of Style/Linking/Archive 21|Linking New York City}}? ] (]) 13:16, 8 October 2024 (UTC)
::The discussion here is specifically about infoboxes. —] (]) 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. ] ] 02:24, 1 November 2024 (UTC)


== ] for former countries/entities ==
::MichaelCPrice, please remove your re-insertion of that awkward "rule of thumb within a rule of thumb" about linking no more than once per section. as your edit summary noted, this discussion has not concluded and there is no evidence that consensus supports the inclusion of that statement, and further discussion is appropriate. thanks ] (]) 09:43, 20 August 2009 (UTC)
:::I agree it was awkard, so I've reverted it.
:::I propose that the first sentence be changed from
::::''In general, link only the first occurrence of an item.''
:::to
::::''In general, link the first occurrence of an item in a section or subsection.''
:::The reason is straightforward. Some navigational links, by design, take readers directly to an article's section or subsection. It defeats the purpose and intent of the link to require them to go on a further link hunt.
:::The following exceptions are still valid and do not require updating. E.g. if the (sub)section is very long then further linking may be appropriate. --] <sup>]</sup> 10:19, 20 August 2009 (UTC)


I believe it would be useful to form consensus and guide editors on the application of ] to historical countries and/or entities. For example, a disagreement came up about it over at {{Section link|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:
(outdent) thanks for the self-revert and for continuing the discussion. proposing to "link the first occurrence of an item in a section or subsection" may make sense for some particular items in articles that have very long sections, but it definitely won't make a reasonable general recommendation. i suggest keeping "first occurrence only" rule of thumb and the three exceptions listed, adding a parenthetic to the "long way" point - something like: "(how far 'a long way' is will vary; editors can make their own judgements within individual articles)". ] (]) 10:47, 20 August 2009 (UTC)
* ], ]
:Although it may to necessary to state that "long" is a subjective matter, it doesn't address the issue of readers who are directed to specific sections (regardless of length). Unless the section issue is specifically addressed links will be removed, to the detriment of WP's readability.
* ], ], Yugoslavia
:As it stands the current advice about repeated linking and the ability to link to sections is inconsistent. Misplaced Pages should be consistent. --] <sup>]</sup> 12:28, 20 August 2009 (UTC)
I'm citing the original proposer's (@]) arguments: "{{tq|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.}}" –] (]) 20:15, 8 October 2024 (UTC)
::Would making that "where a later occurrence of an item is a long way from the first, or is found in a section which is directly linked to by another article" be OK? --<span style="color: #4B61D1; font-family: monospace; border: thin solid">]A.&nbsp;di&nbsp;M.</span> 10:25, 21 August 2009 (UTC)
:::No, because that would require that everytime you add a link to a section you would have to check to see if the appropriate terms were all linked. And remove them all when the link was removed. Better to have them in by default.
:::And some readers will come to the sections directly, even without being directed there by links. --] <sup>]</sup> 11:43, 21 August 2009 (UTC)


:Wouldn’t including a sub-entity for the first one be the following?:
:::... is there some efficient way for an editor to ascertain whether or not a particular section is directly linked to from another article? more efficient, i mean, than a reader simply looking at the earlier parts of the article, if s/he wants more information than is in the exact section s/he's looking at? ] (]) 11:38, 21 August 2009 (UTC)
:], ], ] ] (]) 12:46, 9 October 2024 (UTC)
::::There's no way to apply "What links here" directly to sections. When you create a link to a section, you are supposed to add a comment to it (see ]). --<span style="color: #4B61D1; font-family: monospace; border: thin solid">]A.&nbsp;di&nbsp;M.</span> 11:51, 21 August 2009 (UTC)
:{{reply to|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 ]. 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. ] (]) 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, "], Alberta, Canada" is fine, because ] links to ] from its lede, and that in turn links to ]. However, an article on an extant city may not link as prominently to a country it was once a part of. A formulation like "], ]" 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 "], ]" would be unnecessary, as Syria Palaestina only existed as part of the Roman Empire. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 22:58, 9 October 2024 (UTC)
::{{reply to|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: {{tq|Josip Broz was born on 7 May 1892 in ], a village in the northern Croatian region of ]. At the time it was part of the ] within the ].}} 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 . {{U|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. ] (]) 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. ] (]) 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.{{pb}}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 ], where ] and I ] on how to characterize Germany in 1931 (], the iteration therein called the ], or the sub-iteration therein called the ]). 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 <code><nowiki>]</nowiki></code> in that diff. It should be either linked clearly or not linked at all. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 18:01, 10 October 2024 (UTC)
::::I agree with the last point. It's an ], and we prefer to avoid those for good reasons. ] (]) 18:34, 10 October 2024 (UTC)
::I routinely unlink per ] (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.
::] (]) 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 {{xt|], ]}}. However, it is preferable to space the links out when feasible, e.g. {{xt|], then part of ]}}." <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 05:35, 14 October 2024 (UTC)
:Perhaps the nuance is best left to prose, which currently reads {{tq|Tito was born to a Croat father and a Slovene mother in ] in what was then ]|q=yes}}, providing proper context in explicit wording instead of consecutive links. —] (]) 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. ] (]) 22:11, 31 October 2024 (UTC)


== RfC: Linking of three-part place names ==
(outdent) maybe what i'm missing in all this is: what is wrong with considering readers capable of backing up a little to look at other sections of an article, if they want more information? it's not like linking to a particular section <u>confines</u> anyone to that section. ] (]) 11:58, 21 August 2009 (UTC)
:It's a matter of convenience and ease of use, not capability. That's why we have links in the first place, to make finding other articles ''easier''.
:A natural extension of your argument is that we should remove ''all'' links, since any reader is ''capable'' of finding any article, without links.--] <sup>]</sup> 12:35, 21 August 2009 (UTC)
::smile: only in the sense that "a natural extension of *your* argument" is that we should link everything - which isn't a constructive way to discuss this, so let's skip all that, okay? i believe that the guidance now given (linking only first occurrences as a general principle, with exceptions noted) caters quite sufficiently to readers' ease/convenience. ] (]) 12:45, 21 August 2009 (UTC)
:::No, it doesn't. Why would we want to make readers scan a whole page for a link they are interested in, sometimes in sections they haven't read and are not interested in? Why would we make Misplaced Pages harder to use? Why would we not use the capabilities MediaWiki offers to make finding information easier to use? That's the whole point of this project. ] (]) 13:27, 21 August 2009 (UTC)
::::Exactly.
::::--] <sup>]</sup> 14:53, 21 August 2009 (UTC)
BTW, just so we don't reinvent the wheel, --] <sup>]</sup> 04:32, 22 August 2009 (UTC)
:smile: i'm glad the two of you agree, but others don't, so we need to continue the discussion here, not in the guideline itself.
:the wording "in general link only first occurrences with these exceptions" doesn't prohibit anyone from repeating links - even more than once per section, if the sections are large enough to warrant that. the wording you're proposing ("in general, link once per section") would read like an invitation to repeat links in each section even if the sections are only a few sentences long - which is obviously silly. i assume you two are <u>not</u> arguing in favour of something that silly - but these guidelines apply to ALL articles, including short ones, and need to be formulated with that in mind. ] (]) 06:11, 22 August 2009 (UTC)
::And what exactly is silly with links in sections, regardless of length?--] <sup>]</sup> 07:47, 22 August 2009 (UTC)
:::Michael, are you referring to ''repeat'' links within sections? If so, they add no utility for the reader, but each comes at a slight cost. The cost has been detailed and discussed ad nauseum, here and elsewhere, and relates to the psychology of signalling and of reading—a psychology that is readily understandable by all editors. ] ] 09:14, 22 August 2009 (UTC)
::::It is not "readily understood" by ''all'' editors as witness the archives which I linked to above, along with debate ongoing here. Such demonstrably false statements only undermine your stance's credibility.
::::PLease provides diffs or link to source your claim of universal support for your position, e.g. an RfC or whatever. --] <sup>]</sup> 21:01, 22 August 2009 (UTC)
:::::I cannot provide diffs that demonstrate "universal support", since you plainly do not support the notion of more rather than less selective linking. ] ] 07:06, 23 August 2009 (UTC)
::::::Exactly. And not just me, as the archives and this section testify. So, back to my question, "what exactly is silly with links in sections, regardless of length", and please provide evidence, not just unsupported claims of near universal support.--] <sup>]</sup> 09:55, 23 August 2009 (UTC)


<!-- ] 21:01, 21 November 2024 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1732222876}}
Michael, I didn't call frequent repeat-links "silly", did I? I usually prefer to be understated, and I can see where you're coming from, so I respect the internal logic of your position (while believing that the frame is not usefully conceived). Nor have I claimed "near universal support"; if that were the case, en.WP would not have a serious overlinking problem. (I've just found multiple repeat links in the article on Dolly Parton, and worse, many many items like "high school" linked—someone went wild with the square brackets without understanding the skills required to make the system work optimally.) The really valuable links—to her songs, for example, were swamped in this sea of blue. Nor would the other WPs (French and Italian especially, which have no guidelines for wikilinking) be beset by scattergun spray-paint linking that unthinkingly drowns the links you'd want to attract readers to.
There are two common ways to link to a place name with an "A, B, C" format where the article is titled ]. Both can be read as fair interpretations of the guidance to "link only the first unit".


# Have the link span only the smallest unit, using piping if necessary
Now, it really is all a matter of balance: dilution and unprofessional visual appearance on the one hand, versus the utility of links for our readers. The difficulty of establishing that balance is why editors engage in debate (sometimes vigorous); and editors who have put a lot of work into articles they want to see linked (the "orphan" issue) represent a vested interest. IT professionals and enthusiasts are another group of users who tend to perceive the potential utility of wikilinks, and the connective structure on the web, in isolation from their costs. As editors, it is easy to be beguiled by this notion of utility, because we're a little distant from the experience of (most of) the visitors to WP, who we've been told by a number of IT specialists tend not to hit links at all, or if they do, only rarely (see my talk page). Nevertheless, the en.WP has moved significantly towards that need to balance (skilled wikilinking, I'd call it) over the past few years. ] ] 10:19, 23 August 2009 (UTC)
#:{{xt|], New York, United States}}
# Have the displayed text match the title of the linked article
#:{{xt|], United States}}


Which style(s) is/are acceptable? If both, is one preferable to the other?
I am picking up from you that you don't see this need to balance. Is that correct? ] ] 10:19, 23 August 2009 (UTC)


Note: See previous discussion ] and ]. This is <em>not</em> a question about whether "New York" should be linked to ] in this example; basically everyone agrees that it should not be. 20:57, 17 October 2024 (UTC)
:A balanced approach is not indicated by your statement that
::"repeat links within sections .... add no utility for the reader".
:--] <sup>]</sup> 14:37, 23 August 2009 (UTC)


=== Discussion re RfC: Linking of three-part place names ===
*My view on this (as someone that doesn't read articles from top to bottom) is that when I come across a word in an article that I would like to click on, that is not linked, but which I think might be linked earlier, I find it very annoying to hunt back through the article, trying to find where it was linked. It jars my reading experience almost as much as it would to go and type it in a search box, or do Ctl-F (or whatever your search function is). And then I have to go back and try and find where I had stopped reading the article. The point of linking is to make such side-excursions easy, not difficult. As a reader, gliding past a link that maybe shouldn't be there is much easier than stopping to search or look for an earlier link (this is why I favour a conservative approach to tackling over-linking). On the other hand, there are ways around this. The method I now use is a function available in the Mozilla Firefox browser (maybe as an add-on) and maybe in other browsers as well. This function (not sure what it is called) means I can select a word with the mouse cursor (i.e. highlight it), right-click, and select a "search Misplaced Pages for this word" option. This is almost as convenient as clicking a link and much less disruptive than searching up and down a page, or going over to the search box. However, before anyone says this is an argument never to link, remember that useful information on relationships between articles and topics is present in the web of interconnecting links between articles (provided things aren't over-linked), so links are need for reasons other than people clicking on them. My view is that both over-linking and under-linking are things to avoid, and I don't want to see an over-reaction to linking that means we end up with an encyclopedia that is under-linked. In this particular case, for readers that don't have this add-on tool, and who might arrive at a section from a section link, and for those long articles, I would favour repeating links where it might be needed. Rigidly enforcing a "no repeats" rule is not sensible, in my view. There are things that need more urgent attention (such as clicking on existing links and making sure they are correct, and adding links that are missing). ] (]) 14:40, 23 August 2009 (UTC)
{{small div|1=Pings to past participants {{re|Gawaon|Khiikiat|Pi.1415926535|Michael Bednarek|NebY|Biruitorul |Dahn |p=.}} Cross-posted to ]. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 20:57, 17 October 2024 (UTC)}}
:I commented on this earlier, but perhaps it merits repeating. In my opinion, linking a term on ''every'' appearance is excessive, and linking once per section is also borderline unnecessary. However, allowing someone to link only once in the entire article ''may'' be a bit restrictive. So, perhaps we should advocate linking once in the lead, and one or two times in the body, depending on the unfamiliarity of the word (technical terms) and the length of the article. A concrete example:<p> In ], ] is a relevant link that should be linked once in the lead and once in the body, but no more, as it's not overly technical or unfamiliar. On the other hand, ], in addition to being linked in the lead, might be linked two or even three times in the body as a relatively less-known (but important) concept. ] (]) 15:59, 23 August 2009 (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 ] 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 ]. To a reader seeing "], United States", next to "], 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 ",&nbsp;New York".
** ''Accessibility'': The only difference between "]" and "], ]" 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 ].
*<li style="list-style:none;">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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 20:57, 17 October 2024 (UTC)</li><!--{{subst:i*}}-->
*'''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 ] is an accepted practice in that context). ''Who'' could be expected to consider ] or ] 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''. ] (]) 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 ], 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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 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 ] and ], 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 " 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. ] (]) 21:32, 17 October 2024 (UTC)
*'''Option 2''' per ]. It's also a normal unpiped link, without superfluous text: compare <code><nowiki>], United States</nowiki></code> (five words) with <code><nowiki>], New York, United States</nowiki></code> (eight words). --] &#x1f339; (]) 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) ], ], ]; 2) ], ], ]. 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? — ] <small><sup>]</sup></small> 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 ], as pointed out below by {{u|Bagumba}} – don't use piped links when you don't have to, and here you very clearly don't have to. ] (]) 08:55, 18 October 2024 (UTC), {{small|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 {{tq|Yao Mangshan Ethnic Township ({{zhi|莽山瑶族乡}}), ], ], Hunan}}. Leaving out the container state, that's still four subdivisions. I left ] unlinked since it appears in ], but there are probably editors who would argue for linking that as well. ] (]) 09:52, 18 October 2024 (UTC)
*Link only the most specific item—especially when the other two are so well known. ] ] 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 ]: {{tq2|Unnecessary piping makes the wikitext harder to read.|q=yes}} —] (]) 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 {{noping|Bagumba}}. ] (]) 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. ] (]) 14:38, 19 October 2024 (UTC)
*'''No preference. MOS should state this.''' I fully agree with Folly Mox ] 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 ] 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. <span style="font-family: verdana;">] 🍄‍🟫<i>— ]</i> </span> 22:03, 19 October 2024 (UTC)
*'''Option 1''', but both acceptable, per Tamzin and ]. 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. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">]</span>&nbsp;(])</span> 00:50, 23 October 2024 (UTC)
*:{{tq| I don’t want people clicking “New York” and being confused at being sent to Buffalo|q=yes}}: 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>. —] (]) 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. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">]</span>&nbsp;(])</span> 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 <em>would</em> link to New York there. Using a different state because the NYC/NYS ambiguity complicates things, there are containing either <code><nowiki>], ]</nowiki></code> or <code><nowiki>], ]</nowiki></code>. These links are distinguished from e.g. <code><nowiki>]</nowiki></code> by the color of a character that is less than a millimeter wide at standard zoom. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 00:20, 27 October 2024 (UTC)
*::::Regardless of the outcome of this RfC, the standalone link to ] should be unlinked per ] in all these cases. MOS:GEOLINK is already very clear on this and it's not something that will change. ] (]) 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 ], France vs ], Canada) then that is okay. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 01:21, 23 October 2024 (UTC)
*:Ooh, I {{em|really}} disagree with that last point. I’d rather a list be consistent regardless the choice between these two options. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">]</span>&nbsp;(])</span> 03:01, 23 October 2024 (UTC)
*::How would you list those 2 cities? <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 03:10, 23 October 2024 (UTC)
*:::Assuming it’s a normal prose sentence, I would have something like: {{tq|“However in 1894, the government of ], France decided to implement the change, while the mayor of ], Ontario forced the city to withhold …”}} But honestly I would still rather the opposite ({{tq|… ] decided to implement the change, while the mayor of ] did not…”}}) to the split styling you suggested. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">]</span>&nbsp;(])</span> 21:40, 24 October 2024 (UTC)
*:::And for most lists, the same (with disambiguation pages being the exception). <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">]</span>&nbsp;(])</span> 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. ] (]) 07:23, 23 October 2024 (UTC)
*:{{tq|the larger regions are just to make it unambiguous and are not a target in their own right|q=yes}}: 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.—] (]) 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. ]] 00:33, 27 October 2024 (UTC)
*Link "Buffalo" alone. ] ] 02:25, 1 November 2024 (UTC)
*:As in {{tq|], New York, United States}}? -- ] (]) 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:
:Carcharoth's statement above expresses my sentiments pretty closely. The "rule" should neither imply encouragement of a rigid only-link-once-per-article regimen nor any sort of link-every-occurrence mania. Much as with Varieties of English, the guidance should encourage tolerance -- link minimalists should try to appreciate that not everyone shares their aesthetic ideal and link maximalists may need to be reminded that not every possible link adds value to an article and that overlinking can detract from the usefulness of the links. ] ≠ ] 16:22, 23 August 2009 (UTC)
{{tqb|Three very nice cities are:
*], US
*], US
*], 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 <code><nowiki>]</nowiki></code> to achieve that. Although coding <code><nowiki>]</nowiki></code> 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. <span style="font-family: cursive;">— ]<small><sup> (])</sup></small></span> 01:55, 26 November 2024 (UTC)
*'''At least correct the description of what is recommended''': To me, it is {{em|false}} to say "Both can be read as fair interpretations of the guidance to 'link only the first unit'." In the string "Buffalo, New York, United States", there are clearly three units, and the first of those three units is "Buffalo". If we're going to say that "], United States" (<code><nowiki>], United States</nowiki></code>) is the preferred format, we need a different characterization than saying that for "a sequence of two or more territorial units, link only the first unit". For example, we could say to "link only as much of the name as is used in the corresponding article title" or "link only the initial parts of the name that form its conventional identification". (We might also need to refer the reader to ] for the conventional form of US location descriptions). —⁠ ⁠] (]) 01:06, 3 January 2025 (UTC)


== Is ] just a stylesheet problem? ==
::I've been a webmaster for major companies for some years. Every couple weeks I get a request to "make as many links to and from an article" in a knowledgebase as possible, the assumption being that more people will read the article. In practice, what Webtrends and other analysis tools show is that readers quickly become "saturated" with links on a page, even to the extent that they will ignore a link in bold red in an article "PLEASE READ THIS". In practice the golden number of article links is about ten. Any more, and the number of readers clicking ("click-throughs") doesn't increase significantly, if at all. Therefore the strategy is to pick the best ten links. (The best articles, the most important issues — whatever the criteria may be.) This affects the question of whether there should be repeat links.


The page currently has ], which reads, in part:
::There is another pragmatic issue: how many readers scroll down the screen ("below the fold"). There is debate. (Notice how AOL director misquotes her reference .) At any rate, some substantial number of readers do not scroll past the first screen, and most do not scroll to the bottom. This suggest two things regarding Wikilinking: 1) Links placed toward the top of an article are far more likely to be seen than ones at the bottom. The second inference, I can't provide statistics for, because the knowledgebases which which I have webmaster experience did not generally have a table of contents. However, the implication is: 2) Few readers would jump down pages in an article, without reading at least part of the opening page.
{{quote|When possible, do not place links next to each other, to avoid appearing like a single link, as in chess tournament (] ])}}
Which makes sense to me. But is this just a stylesheet issue with wikipedia? HTML ] are conventionally displayed in blue and underlined, disambiguating <u>chess&nbsp;tournament</u> from <u>chess</u>&nbsp;<u>tournament</u> (in wikipedia it seems they're only underlined on hover, for whatever reason), which would largely resolve the issue. Or would it? ] (]) 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. ] (]) 11:33, 19 October 2024 (UTC)
::Most of the factors above in discussion against multiple linking I would agree with, but not on the basis of my statistical analysis. The statistical case alone for few links outweighs any small gain for a small number of readers. So not to gild the lily, but there are professional guidelines about <i>hardcopy</i> "linking". Readers expect to see the first instance of a term ... defined, footnoted, given an acronym, etc. Duplicates are confusing, because they cause the reader to think, "Wait, didn't I already see that term?" And then they have to stop reading, go back and check. I'm a skimming reader, and stumble over these links constantly. In articles with names of many foreign kings or cities or ingredients, it makes reading extremely difficult — the duplicate link leads me to think that I misunderstood something earlier.
: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 ]: {{tq2|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.—] (]) 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 still underlines links. --] &#x1f339; (]) 14:34, 19 October 2024 (UTC)
:Somewhat orthogonal, but I think “] ]” is a poor example, as that is a problem primarily about using two links instead of the more appropriate one: “]”. And beyond that, most SOB problems tend to be more about ] 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. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">]</span>&nbsp;(])</span> 21:54, 24 October 2024 (UTC)
::{{tq|the possibility of rewriting is often ignored, and sometimes even reverted|q=yes}}: Seemingly without fail, someone will be proud of the compact wording—counter to ]'s {{tq|Instead, consider rephrasing the sentence (] of ]) ...|q=yes}}—and will argue that any extra words are "unneceesary". —] (]) 09:22, 1 November 2024 (UTC)


== Noteworthy exceptions to SOB ==
::In sum. An article in my knowledgebases that got 10% click-throughs to other articles was rare. 1-2% was typical. So multiple links are labor intensive for editors, little-used, contrary to professional hardcopy guidelines, and make articles more difficult to read for the vast majority of readers. I.e., in their current, limited technical form, they are a lose/lose/lose situation. ] (]) 00:32, 24 August 2009 (UTC)


I notice that the considerations of a ] typically override those described here and think it would be helpful to point that out as follows:
== Easter egg question ==


* 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 ]s in a single sentence without any possibility of splitting them up:
I just have a quick question: Do people think I created an easter egg with edit? &mdash; ] 22:39, 17 August 2009 (UTC)
:Maybe not, but I would have kept it as it was before, per the "better safe than sorry" principle. Never underestimate readers' stupidity. --<span style="color: #4B61D1; font-family: monospace; border: thin solid">]A.&nbsp;di&nbsp;M.</span> 09:44, 18 August 2009 (UTC)
:I think it's fine.&mdash;] (]) 12:50, 18 August 2009 (UTC)
::it seems fine to me too ] (]) 13:17, 18 August 2009 (UTC)
::: Thanks for your replies. To A. di M.: I assume you're saying that you wold have kept it, but if you were writing it as a new text, you would leave it out. Such a view makes sense, because the editor who put it in there before probably had a reason for thinking it might be needed. But in this case, that original editor was me, too. So, I weighed both concerns: The principle of least astonishment and the ideal of legibility, and ended up deciding that the latter prevailed in this case. Anyway, this was an interesting borderline case! &mdash; ] 18:16, 18 August 2009 (UTC)
::::Sebastian—Your edit in question is fine, I think; but the article itself is badly overlinked. And I see "Amsterdam" linked in the lead and then 15 seconds later in the first section. This is bad practice, I believe. ] ] 10:04, 21 August 2009 (UTC)
:::::Since sections are linking entry points it looks like good practice to me. --] <sup>]</sup> 10:19, 21 August 2009 (UTC)
::::::Tony1, I cleared up a few examples I considered overlinking. Better?----] (]) 01:32, 22 August 2009 (UTC)
:::::::Occono: nice work. I went through after you and caught "diary" and bad links to institutions; plus the date formats were inconsistent. ] ] 05:26, 22 August 2009 (UTC)
:::::Michael C Price: I think you overestimate the number of readers who will ever hit a link (the rate estimated at 1–2% by an ex-web master, see my talk page. I frankly don't care in the case of the extremely rare case in which someone ignores the lead and starts reading from the first section: they can ''type "Amsterdam" into the search box''. It can be irritating to see "Amsterdam" (of limited utility, anyway) blued out twice in such a short period, and this slightly dilutes the high-value links in the vicinity. What is clear to me and many other editors is that we have to be smart about attracting readers to links. Doubling up is ''not'' a smart way to increase the hit rate, and while it might make some editors feel that they've added to the intricate interconnectedness of the project, in the cold light of day, rationing the links is a better way of making the system work optimally, I put it to you. ] ] 05:08, 22 August 2009 (UTC)
::::::The system works best when our readers can navigate easily around topics they are interested in. Aggressively rationing links hurts this goal and undermines one of the things that makes the MediaWiki platform useful for this purpose. ] (]) 05:40, 22 August 2009 (UTC)
::::::Once again, I can only add my support to RxS's views. Rationing links is the same as rationing utility, since links within sections have utility, despite claims to the contrary. --] <sup>]</sup> 14:51, 23 August 2009 (UTC)


<blockquote>''''']''''' is a 2023 ] ] ] ] written, directed, and produced by ].</blockquote>
== Links to Non-English Misplaced Pages articles ==


] (]) 18:24, 23 October 2024 (UTC)
When should one translate (in summary if neccessary) a foreign language Misplaced Pages article and when should one provide a link to the foreign language? The following case study might help concentrate people's minds:


:These are not exceptions, these are among the most egregious and most visible violations. They are <em>particularly</em> wrong, even more than the examples cited in the policy itself.<span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 18:27, 23 October 2024 (UTC)
The ] (Eleven Cities Journey) is a classic Dutch ice skating event. One of the giants of the event was ] (who won it twice in the 1940's). ] was another winner from the same era. I checked the number of hits for each of these pages during July 2009. They are:
::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 ]. IMO a lede sentence for a film should mention between zero and one genres. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 00:34, 24 October 2024 (UTC)
*Elfstedentocht: Dutch - 3384 hits; English 829 hits
:::What a horrible opening sentence....... ] <span style="font-weight:bold;color:darkblue">]</span>🍁 00:55, 24 October 2024 (UTC)
*Coen de Koning: Dutch - 195 hits; English 158 hits
::::{{midsize|Would you say that you are become Death, the Destroyer of Worlds, or?}} <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 01:00, 24 October 2024 (UTC)
*Piet Keijzer: Dutch - 208 hits (of which 84 were on the first anniversary of his death); English - no Misplaced Pages entry.
:::::Lol ....keep it simple <span style="font-weight:bold;color:darkblue">]</span>🍁 01:08, 24 October 2024 (UTC)
Would is be proper in these circumstances to link Piet Keijzer in the English language version of the race to his biography in the Dutch language section, or to leave it as a "red link"? ] (]) 11:38, 18 August 2009 (UTC)
:::Yes, specifically there is ]: {{tq2| Do not overload the first sentence by describing everything notable about the subject. Instead, spread the relevant information out over the entire lead.}} —] (]) 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 ]. 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 @] that genres aren't important — they're ] 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. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 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. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 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 ], ].... ] is an oddball for this that leads to this problem as it omits genres. Not all projects have accessibility in mind. <span style="font-weight:bold;color:darkblue">]</span>🍁 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<blockquote>'''''Oppenheimer''''' is a 2023 ] written, directed, and produced by ]. An ] with aspects of a ], it follows the life of ], the American ] who helped ] during ].</blockquote>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. ] 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. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 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. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 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 ] (about categories) should {{em|not}} be taken to imply what the first sentence should look like. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">]</span>&nbsp;(])</span> 21:46, 24 October 2024 (UTC)
{{od|:::}} 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 ]. I've nuked it. ]&nbsp;(]&nbsp;&#124;&nbsp;]) <sup>(])</sup> 13:48, 25 October 2024 (UTC)
::::Not really a fan of the "] with aspects of a ]," 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 ]. 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. ] (]) 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. ] (]) 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 ] 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. ] (]) 20:58, 8 November 2024 (UTC)
::::::::I would disagree with leaving readers to guess the genre. Sometimes the plot summary is incapable of indicating the genre, particularly for nearby genres. ], for example, is incomplete (there are now dozens of subgenres, as well as overlapping combinations, e.g., the lady detective historical romantic locked-room mystery), but just guessing between those few won't always be possible from a plot summary. Also, there's no guarantee that a given reader will even know that a particular genre exists. ] (]) 21:21, 30 November 2024 (UTC)
::::::Honestly I think {{u|Doniago}}'s half-serious suggestion is a good one.{{pb}}''''{{pb}}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 ]. ] (]) 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. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 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. ] (]) 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 ] not to include them. Regarding examples of subjective information in leads, ] is one example that comes to mind. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 19:07, 9 November 2024 (UTC)


== Editor reverting my unlinking of plain years ==
:Always leave it as a redlink. --] 05:08, 20 August 2009 (UTC)
::Misplaced Pages Policy ] advocates caution about articles concerning people who are notable only in respect of a single event and that due attention should be paid to the significance of the event concerned. The Elfstedentocht is a major event in the Netherlands, but is a minor event elsewhere - how many column inches is devoted to in in English-language newspapers compared to Dutch-language newspapers? As I see it, the following options exist:
::* Retain red links for ever and hide the fact that a foreign-language text is available.
::* Remove the links completely in the English-language versions of Misplaced Pages and hide the fact that a foreign-language text is available.
::* Create stubs in the English-language versions that automatically redirect to the foreign-language text.
::* Create stubs in the English-language version with a link to the foreign-language text.
::* Provide links to the foreign langauge text until such time as an English language article is wirtten.
::I favour the last of these options.] (]) 07:43, 20 August 2009 (UTC)
:::Notability is not based on the language of the sources. As for your last option, how, exactly, will you find the links to change? There's no "what links here" for interwiki links. --] 07:53, 20 August 2009 (UTC)
::::I agree that notability is not based on the language of the sources, but rather on various cultures. In some cases there is a very strong correlation between the language and the culture, for example the Dutch language Wiki caters mainly for residents of the Netherlands. However the English language Wiki caters for a number of different communities – the International Community who need a common language, the American community, the British Community, the Indian community to mention but a few.
::::Getting back to my original argument, if a particular entry would be notable only within a particular community and that community uses a language other than English, would you favour a stub in the English-language Misplaced Pages which contains the sentence “Please refer to the XXXX language version” and a link in the languages box? ] (]) 11:21, 20 August 2009 (UTC)
:::::If those people pass ], an article about them can be written sooner or later, and you should use redlinks until such articles are written; and when written, the English articles even if initially very stubby will have links to the Dutch ones in the obvious places. If they don't pass WP:N, there's no point in having eternal redlinks, or to create stubs. Links going directly to the Dutch articles can be useful, but make sure the reader knows where they go before following then. --<span style="color: #4B61D1; font-family: monospace; border: thin solid">]A.&nbsp;di&nbsp;M.</span> 12:28, 20 August 2009 (UTC)
::::NE2: the Dutch Misplaced Pages is not bound by the English Misplaced Pages notability guidelines, nor vice versa. It's entirely possible that someone is notable according to the one but not to the other. In particular, the notability guidelines of a Misplaced Pages in a language strongly associated with a regional culture (such as Croatian or Japanese, and as opposed to languages such as English of Spanish) might well favour regional topics. --<span style="color: #4B61D1; font-family: monospace; border: thin solid">]A.&nbsp;di&nbsp;M.</span> 12:28, 20 August 2009 (UTC)


Two by ]: what to do? ] ] 00:50, 30 October 2024 (UTC)
One option might be a footnote referring readers to the foreign-language article. --] (]) 09:45, 22 August 2009 (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 ]. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]&#93;</sup> <small>(])</small> 04:16, 30 October 2024 (UTC)
== Over-linking and under-linking ==


== Clarification regarding ] dispute ==
I've been following the over-linking and under-linking debate on and off for about a year, and my concern here is that changes that will affect the entire encyclopedia are being discussed by a small group. This actually applies to other manual of style discussions, but that should be raised at ]. What I fear is that what happened with date delinking will happen here. That small groups will gain local consensus for ever-more strict changes, and that as more and more people become aware of efforts to de-link or re-link (especially if anyone mentions bots or script automation being used - I don't know if that has ever been considered, or whether script automation is already being done, but that would raise tempers somewhat), that the dispute will snowball. What I propose is that major changes that affect all the articles in the encyclopedia (most MOS changes are not on this scale) should be discussed by much larger groups. And that until such large discussions are set up (there would need to be discussion beforehand on how to present such discussions) that efforts are directed towards gathering data and sources to back up assertions being made. ] (]) 16:01, 23 August 2009 (UTC)


See ] for further information. An editor has ] links at ] citing ], however is this incorrect per MOS as this is the first occurrence of these links in its section and MOS:REPEATLINK states to {{tq|link a term at most once per major section, at first occurence}}, describing a major section as generally being a level-2 heading. ] (]) 06:49, 30 October 2024 (UTC)
:I share your concerns. This needs to go higher up. Perhaps an RfC and some sort of user survey.--] <sup>]</sup> 17:11, 23 August 2009 (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. <span style="font-weight:bold;color:darkblue">]</span>🍁 02:29, 10 November 2024 (UTC)
== Scripts that deal with linking ==
::Depends on how useless the link is in the first place. ] ] 08:50, 10 November 2024 (UTC)
:This appears to be resolved.
:As a point of comparison, most "longer" articles (i.e., the 50% of articles that have more than Misplaced Pages's current median of 13 sentences per article) have about one link for every 20 words, or about four links in every five sentences. Links aren't distributed randomly throughout the article (e.g., there are more in the lead), but if you find yourself thinking that there are the Wrong™ number of links, it might be useful to compare your personal guess against the average numbers. (Shorter articles have a higher density of links, running about two links per sentence.) ] (]) 21:30, 30 November 2024 (UTC)


== Update for ]? ==
Is there a list anywhere of scripts that deal with linking? I've found the following so far:
*]
*]
I believe that Twinkle and Huggle and AWB and other such things also have functions to add and remove links. Could those be summarised here? ] (]) 16:08, 23 August 2009 (UTC)


In addition to years and dates, the Spanish Misplaced Pages guidelines (not sure how to link to it from here, but it's linked there as WP:ENLACESFECHAS) mention not linking other units of time – like centuries and months. This seems like good common sense to me. ] (]) 23:48, 28 December 2024 (UTC)
== Linking, delinking, changing links, and link maintenance exercises ==


== How does ] relate to a phrase like "] ]"?==
I've noticed ], which is a good set of exercises for spotting and removing unnecessary links and improving link syntax (and piping of links). What I think is missing there is exercises that point out when links need to be added, and how to spot and correct incorrect links (I call this link maintenance). Examples are: spotting when a redlink has incorrectly turned blue (when someone creates an article without checking what links to it); spotting when a link has turned into a disambiguation page without the incoming links being disambiguated; spotting when a link has turned red because an article was deleted (OK, that is a trivial example); spotting when a blue link is incorrect (links to the wrong article), and so on. In addition, exercises where a word that should be linked, but hasn't been linked, should also be included. Rather than have separate exercises for tackling overlinking and ones for dealing with underlinking and ones dealing with link maintenance, is it not possible to combine them and edit them collaboratively? ] (]) 16:34, 23 August 2009 (UTC)
See discussion ]. ] (]) 17:20, 2 January 2025 (UTC)
:It's still a work in progress. ] (]) 16:36, 23 August 2009 (UTC)
== "]" listed at ] ==
::Shall I move this discussion to the talk page of the work in progress? ] (]) 16:40, 23 August 2009 (UTC)
]
:::Probably a good idea. ] (]) 16:57, 23 August 2009 (UTC)
The redirect <span class="plainlinks"></span> has been listed at ] to determine whether its use and function meets the ]. Readers of this page are welcome to comment on this redirect at '''{{slink|Misplaced Pages:Redirects for discussion/Log/2025 January 3#MOS:WINGSUIT}}''' until a consensus is reached. <!-- Template:RFDNote --> —] (]) 05:44, 3 January 2025 (UTC)
::::Moved . I'll leave this section open in case anyone wants to comment here on linking exercises in general, as opposed to the one Tony is developing. ] (]) 20:42, 23 August 2009 (UTC)
*Yes, it's a stub, really. Thanks for your suggestions, Carcharoth—I'd already identified the need to write exercises for the correction of underlinking (although I see it as a much smaller problem than overlinking). I'm unsure what material to use for the changed-red-links idea: do you have any suggestions? (I'll put this and subsequent entries at the talk page there.) ] ] 23:25, 23 August 2009 (UTC)

Latest revision as of 05:44, 3 January 2025

This is the talk page for discussing improvements to the Manual of Style/Linking page.
Shortcut
Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21
The contentious topics procedure applies to this page. This page is related to the English Misplaced Pages Manual of Style and article titles policy, which has been designated as a contentious topic.

Editors who repeatedly or seriously fail to adhere to the purpose of Misplaced Pages, any expected standards of behaviour, or any normal editorial process may be blocked or restricted by an administrator. Editors are advised to familiarise themselves with the contentious topics procedures before editing this page.

This project page does not require a rating on Misplaced Pages's content assessment scale.
It is of interest to the following WikiProjects:
WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Misplaced Pages:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Misplaced Pages Manual of Style, and the article titles policy. Both areas are subjects of debate.
Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
Note icon
For information on Misplaced Pages's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Misplaced Pages policies of Misplaced Pages's policy and guideline documents is available, offering valuable insights and recommendations.

Archiving icon
Archives

WP:CONTEXT archives

WP:BUILD archive

WP:MOSLINK archives



This page has archives. Sections may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

Redirection to another article in an infobox

Gioachino Rossini
Rossini wears a vest and overcoat, holding a cane and looking out of frameRossini in 1865, photo by Étienne Carjat
Born(1792-02-29)29 February 1792
Pesaro, Italy
Died13 November 1868(1868-11-13) (aged 76)
Passy, Paris, France
WorksList 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 Misplaced Pages: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 Misplaced Pages 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 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}}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}}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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages 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 wears a vest and overcoat, holding a cane and looking out of frameRossini in 1865, photo by Étienne Carjat
Born(1792-02-29)29 February 1792
Pesaro, Italy
Died13 November 1868(1868-11-13) (aged 76)
Passy, Paris, France
Works

@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}}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 Misplaced Pages: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. Sdkb03:31, 8 March 2024 (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

  1. https://fathomjournal.org/al-wasatia-reviving-the-palestinian-peace-camp-an-interview-with-professor-mohammed-s-dajani-daoudi/

MOS:DUPLINK rules for repeating links in articles

After the Misplaced Pages 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  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 Misplaced Pages 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. 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 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 Misplaced Pages 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 Misplaced Pages. 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 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 Misplaced Pages. 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. Misplaced Pages 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 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 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 Misplaced Pages 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 15:40, 19 January 2024 (UTC)
WP:ONEDOWN is not an essay, but rather part of Misplaced Pages: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 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 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 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 Misplaced Pages 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 Misplaced Pages'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 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 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 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 06:34, 26 January 2024 (UTC)
  1. Smith 2020. For the dates of Justinian's reign, see Jones 1999.
UndercoverClassicist 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 Misplaced Pages 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 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 Misplaced Pages 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 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 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 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.
  • 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 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 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 Misplaced Pages 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 Misplaced Pages 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 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 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 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 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 . How would one assess that if not by us editorial judgement? UndercoverClassicist 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 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 Misplaced Pages'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 Misplaced Pages'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 (talkcontribs) 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 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 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 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 15:39, 4 February 2024 (UTC)

The MOS was since tweaked to "major section"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 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? Misplaced Pages 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 Misplaced Pages: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. ]
  2. ]

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. ]
  2. ]

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:

  • ]

... and that changing the piped link in this case to ] is a "pointless activity" that should not be done and is worthy of being reverted.

It appears that she has not contested changing ] to ].

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. ] (with nothing after the pipe). On storing the page, our software autoconverts such links to ]. 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 (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 (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 (they|xe) 14:49, 18 April 2024 (UTC)
No, since the article title is Buffalo, New York, just link that completely. Writing that as ], 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 (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 ], New York I encounter in an article I edit to ] 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 (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 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 Misplaced Pages: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, ", 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 ], 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 "], ]" 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 (], ]), 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 Misplaced Pages.

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 Misplaced Pages itself (at anchor MOS:DRAFTNOLINK). I'm wondering if this case is about Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages 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. Sdkb05:52, 26 July 2024 (UTC)

Clarity and Specificity in the requiem example

The Link Clarity section discourages "Previn conducted Mozart's ]" and then the Specificity section says that it's preferred over just ]. 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  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  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 Misplaced Pages:Redirects for discussion/Log/2024 August 8 § MOS: OVERLINKING until a consensus is reached. Queen of Hearts20: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

  1. Avoid making an entire sentence a link if it will be lengthy
  2. Avoid using italics to mark word-as-words in this case; consider using quote marks instead.

— 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 ], 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 ] (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 Misplaced Pages 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. ] 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 (they|xe) 05:39, 14 October 2024 (UTC)
    I think the guidance, as it stands, is fairly clear: ], United States is preferred over ], New York, United States. The guidance could be changed, but I suspect most editors would support ], 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 (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 (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 (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 (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 (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 Misplaced Pages 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 Misplaced Pages 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:

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 (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 ] in that diff. It should be either linked clearly or not linked at all. -- Tamzin (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 (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 ]. 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 (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 (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 (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 " 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 ], United States (five words) with ], 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 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 ], ] or ], ]. These links are distinguished from e.g. ] by the color of a character that is less than a millimeter wide at standard zoom. -- Tamzin (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:

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 ] to achieve that. Although coding ] 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 01:55, 26 November 2024 (UTC)
  • At least correct the description of what is recommended: To me, it is false to say "Both can be read as fair interpretations of the guidance to 'link only the first unit'." In the string "Buffalo, New York, United States", there are clearly three units, and the first of those three units is "Buffalo". If we're going to say that "Buffalo, New York, United States" (], United States) is the preferred format, we need a different characterization than saying that for "a sequence of two or more territorial units, link only the first unit". For example, we could say to "link only as much of the name as is used in the corresponding article title" or "link only the initial parts of the name that form its conventional identification". (We might also need to refer the reader to MOS:USPLACE for the conventional form of US location descriptions). —⁠ ⁠BarrelProof (talk) 01:06, 3 January 2025 (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 (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 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. Sdkb02: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 (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. Sdkb15: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) 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)
I would disagree with leaving readers to guess the genre. Sometimes the plot summary is incapable of indicating the genre, particularly for nearby genres. Mystery fiction#Classifications, for example, is incomplete (there are now dozens of subgenres, as well as overlapping combinations, e.g., the lady detective historical romantic locked-room mystery), but just guessing between those few won't always be possible from a plot summary. Also, there's no guarantee that a given reader will even know that a particular genre exists. WhatamIdoing (talk) 21:21, 30 November 2024 (UTC)
Honestly I think Doniago's half-serious suggestion is a good one.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. Sdkb16: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. Sdkb19: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 (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)
This appears to be resolved.
As a point of comparison, most "longer" articles (i.e., the 50% of articles that have more than Misplaced Pages's current median of 13 sentences per article) have about one link for every 20 words, or about four links in every five sentences. Links aren't distributed randomly throughout the article (e.g., there are more in the lead), but if you find yourself thinking that there are the Wrong™ number of links, it might be useful to compare your personal guess against the average numbers. (Shorter articles have a higher density of links, running about two links per sentence.) WhatamIdoing (talk) 21:30, 30 November 2024 (UTC)

Update for MOS:DATELINK?

In addition to years and dates, the Spanish Misplaced Pages guidelines (not sure how to link to it from here, but it's linked there as WP:ENLACESFECHAS) mention not linking other units of time – like centuries and months. This seems like good common sense to me. 1980fast (talk) 23:48, 28 December 2024 (UTC)

How does MOS:SEAOFBLUE relate to a phrase like "football quarterback"?

See discussion here. ~WikiOriginal-9~ (talk) 17:20, 2 January 2025 (UTC)

"MOS:WINGSUIT" listed at Redirects for discussion

The redirect MOS:WINGSUIT 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 Misplaced Pages:Redirects for discussion/Log/2025 January 3 § MOS:WINGSUIT until a consensus is reached. —Bagumba (talk) 05:44, 3 January 2025 (UTC)