Wikipedia talk:Manual of Style/Linking

message: The link in the edit summary for this edit should have been to wp:FIXTHEPROBLEM. Sorry about that. - Butwhatdoiknow (talk) 20:07, 25 June 2023 (UTC)
thread_title:  Editing note 

message: When linking to sections, but not piping the link(such as in see also sections or disambiguation pages), is   preferred over Article#section? I ask this because there was a concern raised at my talk page. Ca talk to me! 07:20, 16 September 2023 (UTC)
replies: text: Per MOS:SECTLINK and by example in the MOS itself, the § format is preferred. Whether or not you use the  template is different, although I don't see why you wouldn't. But I do agree that the guidance could be more direct. Orange Suede Sofa (talk) 07:28, 16 September 2023 (UTC)

text: Pinging @Valjean Ca talk to me! 07:33, 16 September 2023 (UTC)
thread_title:  Section links 

message: Two days ago, I opened a discussion at Talk:Gioachino Rossini to debate the addition of an infobox. For those who may be unaware, WikiProject Composers has an age-old policy guideline that disallows infoboxes in composer biographies, but this has been changed in recent years. This question isn't about that; rather, this is about the inclusion of something within a possible Rossini infobox.
To the right is the infobox I proposed, similar in style to Mozart, Beethoven, Chopin, Shostakovich, Prokofiev, etc. The inclusion of the article link to "List of compositions" in the works parameter has been the subject of debate. @Gerda Arendt and I state that the inclusion is justified because the link shows that Rossini was notable for composing and this is the standard on many other composer articles. @Nikkimaria countered that MOS:FORCELINK, which is part of Wikipedia:Manual of Style/Linking, disallows these kinds of links per the words, "The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links." I argued that the very bullet point Nikki quoted also says, "Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence." (emphasis added) Infoboxes are certainly not sentences, but Nikki found this to still apply, since it "mak[es] it so readers could only understand the oeuvre of the article subject by following a link, which is what NOFORCELINK exists to combat".
So, now I am here. I understand the point Nikki is making and understand how it may apply to the infobox, but I want the input of people who frequent the MoS and deduce the sometime vague phrasing. Is the inclusion of the "List of compositions" link under the works parameter a violation of the MoS? MyCatIsAChonk (talk) (not me) (also not me) (still no) 00:18, 4 October 2023 (UTC)
replies: text: 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)
replies: text: 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.  talk 00:58, 4 October 2023 (UTC)
replies: text: Also, this is a very widely adopted practice, used in FAs like Taylor Swift, so disallowing it would be a significant change.  talk 01:02, 4 October 2023 (UTC)

text: 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)
replies: text: 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)
replies: text: The rest of the sentence in question seems to have been conveniently forgotten: "The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links." Given the output without links is "Works	   List of compositions", I fail to see how that non-linking text fulfils the policy requirements. In other words, while some people will be able to use the link, a large number will not, and our policy is that it should not be allowed. Feel free to remove the non-compliant entry in Taylor Swift if you prefer, but WP:LOCALCONSENSUS cannot overrule policy. - SchroCat (talk) 12:05, 9 November 2023 (UTC)
replies: text: That is solvable if we created a new parameter for a list page link ()) 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: When you say "policy", do you mean this piece of text: ? If so, that is a guideline, not a policy. Also, it says , 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)
replies: text: 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)
replies: text: 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)

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

text: 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)
replies: text: 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 , 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)

text: Maybe it should be "Operas" and "Other compositions", however? After all, operas are compositions too. Gawaon (talk) 21:45, 4 October 2023 (UTC)
replies: text: That makes more sense, thank you- updated accordingly. MyCatIsAChonk (talk) (not me) (also not me) (still no) 21:49, 4 October 2023 (UTC)
replies: text: 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)
replies: text: 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)
replies: text: 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.  talk 14:23, 5 October 2023 (UTC)
replies: text: Very good point, I agree- updated MyCatIsAChonk (talk) (not me) (also not me) (still no) 15:25, 5 October 2023 (UTC)
replies: text:  The idea of naming the link "Thirty-nine operas" elegantly realizes MOS:INFOBOXPURPOSE's principle "key facts at a glance". It may be worth inclusion here, or at least at Wikipedia:Manual_of_Style/Infoboxes, so I suggested it there. ◅ Sebastian Helm 🗨 11:52, 23 October 2023 (UTC)
replies: text: 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)
replies: text:  Participants of this discussion may be interested in this RfC on the same topic: Wikipedia_talk:Manual_of_Style/Infoboxes#MOS:INFOBOXPURPOSE_and_links_to_related_articles. Sdkb talk 03:31, 8 March 2024 (UTC)
thread_title:  Redirection to another article in an infobox 

message: Editors in the taxonomy space use redlinks across entire lists like this. Is this acceptable? The taxonomy folks in the WikipProject Tree of Life seem to prefer it this way, but from a non-expert reader's point of view, it seems a bit ugly and seems to violate the MOS guideline here:  Pyrrho the Skipper (talk) 14:50, 9 October 2023 (UTC)
thread_title:  Redlinked taxonomy lists 

message: In many articles, the first sentence is more blue than black. Example: Z-transform.  If that's indeed what we want, we should mention it here. ◅ Sebastian Helm 🗨 10:06, 23 October 2023 (UTC)
replies: text: You'll need to be more specific about the "that" principles to which you are referring to. For reference, MOS:LEADLINK reads:  —Bagumba (talk) 23:17, 23 October 2023 (UTC)
replies: text: It's not that the first sentence is totally exempt, but for the first sentence MOS:CONTEXTLINK applies.  talk 00:07, 24 October 2023 (UTC)
replies: text:  Thanks for the good answers; I'll close this discussion now. ◅ Sebastian Helm 🗨 09:03, 9 November 2023 (UTC)
thread_title:  MOS:OVERLINK: First sentence exempt? 

message: is written from an absolute point of view: It stipulates a selection of links that is the same for every article, by using only such criteria as “everyday words” and “countries”. But does that really make sense for an article about a specialized topic? Example: The article Z-transform currently links such articles as multiplication, real number and numerator. What is the use case for these? In other words: Do we really think such a specialized article will be read by people who will need to look these up? ◅ Sebastian Helm 🗨 10:32, 23 October 2023 (UTC)
replies: text: Do we really think such a specialized article will be read by people who will need to look these up? Yes. Wikipedia is for everyone. WP:TECHNICAL provides a more comprehensive guideline on highly technical subjects. 2A02:A44A:5C96:1:ECBF:6E49:898B:49CB (talk) 22:35, 23 October 2023 (UTC)
replies: text:  Interesting interpretation of “Wikipedia is for everyone”. Yes, Wikipedia is open for people who have never heard of such things as multiplication. But that doesn't mean that we have to dumb down each and every article to that level, thereby making it harder for the expected audience. If anyone who doesn't know what “multiplication” means wants to read the article Z-transform,   is free to do so, and  is free to enter “multiplication” in the search box. In conclusion: Wikipedia already is for everyone, no need to double these efforts in each and every article. ◅ Sebastian Helm 🗨 09:46, 9 November 2023 (UTC)

text: It is a case by case basis following the consensus policy. But I would think that "multiplication" does not need to be linked in every math article and I wouldn't link it to Z-transform, my first impression without delving deeper in the context. Regards, Thinker78 (talk) 20:56, 25 October 2023 (UTC)

text: Just a heads up that there is an algorithm that already has ideas about this, and is anticipated to be informing placement of wikilinks around the beginning of next year. Folly Mox (talk) 12:25, 23 October 2023 (UTC)
replies: text:  Thanks. So it looks like we can put this question on the back burner for now. Please ping me when there is anything new. ◅ Sebastian Helm 🗨 09:46, 9 November 2023 (UTC)
thread_title:  MOS:OVERLINK: Absolute or relative level? 

message: Greetings and felicitations.  This topic isn't mentioned in the project page, and a brief search of this talk page's archives (not including the those in the sidebar) did not turn up anything relevant.  In my opinion it is best to start with Wikimedia project links, followed by official links (edit: and then everything else), but is there any consensus on this? —DocWatson42 (talk) 06:27, 6 November 2023 (UTC)
replies: text: WP:ELORDER Moxy- 13:19, 6 November 2023 (UTC)
replies: text: WP:ELORDER covers where in the article the external links section goes. The only thing it has to say about the order of the links within it is that an link to an official site should go first. However, the next section, WP:ELTEMP, says to put templates containing external links (such as for Wikipedia projects) after the external links section (or, equivalently, at the bottom of it). Largoplazo (talk) 16:48, 6 November 2023 (UTC)
replies: text: Thank you both—that was what I was (fruitlessly) looking for, in the wrong places. ^_^ —DocWatson42 (talk) 04:52, 12 November 2023 (UTC)
thread_title:  Order of links in an "External links" section? 

message: The redirect MOS: LINK has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at  until a consensus is reached.  Utopes (talk / cont) 04:03, 5 December 2023 (UTC)
thread_title:  "[[:MOS: LINK]]" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: The redirect MOS: NOPIPE has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at  until a consensus is reached.  Utopes (talk / cont) 04:04, 5 December 2023 (UTC)
thread_title:  "[[:MOS: NOPIPE]]" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: The redirect MOS: OL has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at  until a consensus is reached.  Utopes (talk / cont) 04:04, 5 December 2023 (UTC)
thread_title:  "[[:MOS: OL]]" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: After the Wikipedia talk:Manual of Style/Linking/Archive_21#DL,_sections,_and_mobile_readers RFC, which demonstrated overwhelming consensus in support of relaxing the "once per article" rule for links to "once per section", RFC closer  made  to the page, altering the introduction of MOS:DUPLINK like so:
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:
 FeRDNYC (talk) 15:47, 21 December 2023 (UTC)
replies: text: That sounds reasonable to me, and an accurate summary of what we really do, though it could be considerably compressed:  That appears to get the same messages across in much less wording.  — SMcCandlish ☏ ¢ 😼  01:52, 18 January 2024 (UTC)
replies: text: Sounds good to me. Gawaon (talk) 14:25, 24 January 2024 (UTC)

text: Heh, turns out that was also 's doing! FeRDNYC (talk) 08:56, 22 March 2024 (UTC)
replies: text: 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)
thread_title:  MOS:DUPLINK rules for repeating links in articles 

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

message: add  103.253.27.33 (talk) 22:32, 14 January 2024 (UTC)
replies: text: Largoplazo (talk) 01:01, 15 January 2024 (UTC)
thread_title:  Edit request 

message: I'm reviewing Beulé Gate by  right now.  The following sentence reminded me of this discussion:  There's nine different linked terms there and I don't konw what any of them means.  Yet, the sentence makes complete sense and I know how to click to get more detail on any of them if I want.  If this sentence was rewritten with parenthetical explanations for each of those terms, it would be crazy complicated and distinctly less readable. — Preceding unsigned comment added by RoySmith (talk • contribs) 00:22, 30 January 2024 (UTC)
replies: text: 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 , 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.  UndercoverClassicist T·C 07:27, 30 January 2024 (UTC)

text: My point above makes sense here. Do we need to know what the Doric order is to understand the context? This piece explains what "poros stone" is (limestone), and "pendalic marble" does pretty much stand out that its a type of marble. There are some more confusing items, such as triglyphs and mutules, but I have no idea how you'd explain them other than being architectual terms. Lee Vilenski (talk • contribs) 09:19, 30 January 2024 (UTC)
replies: text: On the triglyphs and geison at least, there's also a photograph immediately to the right with a caption that makes them (hopefully) fairly obvious: I'd suggest that that also would play some kind of role in the level of possible confusion and therefore the overall discussion as to how necessary/valuable an inline explanation would be. As with most things MoS, it's a cost–benefit analysis.  UndercoverClassicist T·C 09:46, 30 January 2024 (UTC)

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

message: 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)
thread_title:  NOPIPE, piped links, and VisualEditor 

message: Since we've changed the duplink policy to be links may or may not be suitable for the first time in a section, I've had users change this for all section headers (so even for level four headers, they have a new link). Can I confirm that when we say the first usage per section, we mean the first use per level 2 header? Lee Vilenski (talk • contribs) 15:39, 4 February 2024 (UTC)
replies: text: The MOS was since tweaked to "major  section" —Bagumba (talk) 04:00, 25 February 2024 (UTC)
replies: text: 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.  you added in "major" to this wording. What was your intent? - Favre1fan93 (talk) 17:54, 26 February 2024 (UTC)
replies: text: 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)

text: "Major" is level 2 (== ... ==). Gawaon (talk) 18:12, 26 February 2024 (UTC)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)

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

message: 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)
thread_title:  Discussion about [[MOS:FORCELINK]] in infoboxes 

message: 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)
replies: text: "In articles" is not helpful. Specific examples? -- Michael Bednarek (talk) 07:13, 6 March 2024 (UTC)
replies: text: Here are cases in Korean. Some people have been adding Wiktionary links to tons of Korean terms. Isn't this overlinking? Wikipedia does not have to provide a link for every single non-English lexical item. 172.56.232.211 (talk) 03:21, 7 March 2024 (UTC)
replies: text: 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)

text: Linking aside, MOS:FOREIGN advises:  The essay  says:  Foreign words that are not that common in English, when used, should have a MOS:SIMPLEGLOSS.—Bagumba (talk) 07:21, 6 March 2024 (UTC)
replies: text: I'd be wary of making this common practice for such articles. Tony (talk) 06:44, 7 March 2024 (UTC)
thread_title:  Wiktionary links and overlinking 

message: This topic is about whether it is ever preferable to use a redirect link in a pipe. 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:
#Buna
#Bojana
Irrespective of whether the term after the pipe is Buna or Bojana, I have been changing the link (before the pipe) to "Buna (Adriatic Sea)" with the rationale that the link in a piped link should always be the direct link, producing:
#Buna
#Bojana
Joy on the other hand has suggested on my talk page that if the term presented to the reader is "Bojana", the piped link markup should remain as follows:
*Bojana
... and that changing the piped link in this case to Bojana is a "pointless activity" that should not be done and is worthy of being reverted.
It appears that she has not contested changing Buna to Buna.I am of the opinion that in no case do we maintain piping through redirects as a good practice, and that it is completely irrelevant whether the term after the pipe is "Buna" or "Bojana"; the term before the pipe should always be the direct link, not a redirect link. This is because we don't want to introduce the reader to the name of the redirect which they hadn't previously seen, because it's hidden in the piped link markup, and it's preferable to link directly whenever possible, and not through a redirect. Joy, on the other hand suggests that piping through a redirect that is similar to the term visible to the reader, which produces the redirection notification at the destination article, is useful.Should the MOS be clearer that piped links and redirect links are different techniques that should not be mixed, and that only direct links should be used before the pipe, and not redirect links?MOS:DABPIPE says that  and WP:PIPE says . But should MOS:PIPE also say something about this? Something like: —Alalch E. 23:53, 5 April 2024 (UTC)
replies: text: 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 Bojana. Such autogenerated piped links are fine, very common (in fact the most frequent kind of piped link, I would suspect) and thanks to our redirect mechanism, they'll continue to work as before if a page was moved. So why should you change the invisible URL to use "Buna" if you leave the visible word ("Bojana") intact? There is really no reason to so do. Gawaon (talk) 06:35, 6 April 2024 (UTC)

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

message: MOS:GEOLINK gives two examples: Sydney, Australia; and Buffalo, New York, United States. This creates an ambiguity, which Pi.1415926535 and I agreed to raise here after it came up in a GAN: Is the point of the two examples that the link should span all words except the country name, or do they describe two alternate approaches, meaning that one can equally write "Buffalo, New York, United States"? For that matter, could one write "Sydney, Australia"?
I think clarity on this would be helpful. I don't hugely care about what answer is settled on, although as I've said at the GAN, I do think that there's a moderate accessibility benefit to the linked text spanning only the city name: I have difficulty distinguishing black from blue in small quantities, and, if I hadn't modified my common.css to address that, "Buffalo, New York" and "Buffalo, New York" would look almost identical to me, making it unclear, when I click on "New York" there, where I'm going to be taken.  -- Tamzin[cetacean needed] (they|xe) 03:42, 18 April 2024 (UTC)
replies: text: 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)
replies: text: 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)
replies: text: But in the case of Buffalo, isn't it only "Buffalo" that must be linked? ", New York" is a disambiguator included in the article title, not actually part of the common name of the place, which is just "Buffalo", just as the common name of Sydney is "Sydney". I can't think of any other place where, in deciding what text to link, we care about how the relevant article is titled.  -- Tamzin[cetacean needed] (they|xe) 14:49, 18 April 2024 (UTC)
replies: text: No, since the article title is Buffalo, New York, just link that completely. Writing that as  would just be needlessly convoluted. Gawaon (talk) 15:30, 18 April 2024 (UTC)
replies: text: I don't see what's convoluted about that. It's clear to our readers where the link will take them, and that's much more important than a few extra bytes of wikimarkup. It also provides consistency in a case where articles have inconsistent disambiguation due to the peculiarities of the article title policy. Otherwise we wind up with things like "the distance from Toronto, Ontario, Canada, to Niagara Falls, New York, United States". Anyways, if it really is the case that this guideline is supposed to defer to the article title policy in determining what words to link—which, again, seems strange, but whatever—that should be clarified, for my sake and the sake of 206 other usages of "Buffalo, New York" alone (and 137 of "Phoenix, Arizona", and so on and so forth.).  -- Tamzin[cetacean needed] (they|xe) 16:15, 18 April 2024 (UTC)
replies: text: 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  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)
replies: text:  ← Is that intuitive to readers, though? It just looks unbalanced. If I saw that as a lay reader I would think, why does one link only the city and one link also the next level? I don't necessarily think the approach you advocate should be forbidden, but it seems reasonable to allow either as long as it's consistent within an article.  -- Tamzin[cetacean needed] (they|xe) 17:46, 18 April 2024 (UTC)

text: Bluelink, comma, blacktext models ; I'd be sorry to see it changed to blue, comma, blue. NebY (talk) 17:57, 18 April 2024 (UTC)

text: Usually only the first (smallest) entity is linked. Gawaon (talk) 21:59, 18 April 2024 (UTC)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Ambiguity in GEOLINK examples 

message: 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  until a consensus is reached.  Utopes (talk / cont) 22:15, 25 April 2024 (UTC)
thread_title:  "[[:MOS: OVERLINKING]]" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: 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: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)
replies: text: 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)

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

text: 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)
replies: text:  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)
thread_title:  Multiple links and touchscreen navigation