Wikipedia talk:Manual of Style/Linking

In § Duplicate and repeat links, what constitutes a duplicate link? Specifically, are two references to the same article, differing by a pipe, e.g., [[foo]] a paragraph after [[foo|bar]], duplicate links? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:07, 5 November 2025 (UTC)

They sure are. Once something is linked, it doesn't need to be linked again (in the same section). Gawaon (talk) 15:12, 5 November 2025 (UTC)

In general, it's frowned upon to link to the same destination using what appears to be two different WP:EXAMPLE links (that example is silly in all the ways but you get my meaning, two links look different but lead to the same place). In some cases it can be considered justified, such as where WP:ASTONISH trumps MOS:DUPLINK - when a discussed topic is well known by and established through two different names, you might prefer to just link both even though the resulting article is the same (and I'm not talking cases where one link is direct and the other is a link to a destination that redirects to the first place), since that's better than having the reader go "but why is there only an article on X but not Y?". — Preceding unsigned comment added by CapnZapp (talk • contribs) 11:05, 5 November 2025 (UTC)

I think your first sentence is too strong. In the visible text, one should always use the word or phrase that makes sense in the context of the article. If the word or phrase is likely to be unfamiliar to the reader and we have an article on the topic, one should link to it. If that results in two different words linking to the same article, that's perfectly fine. It also does not violate MOS:DUPLINK, which says "Link a term at most once per major section...". If you have two different terms that happen to link to the same article, that is not a violation.--Srleffler (talk) 02:47, 6 November 2025 (UTC)

Maybe I'm just high, but for the reader's sake, why are we referring to foo by two different words in the same section? Should we not be clear enough in our writing for the reader to know we are talking about the same thing in both instances by just calling foo foo both times? Thus, not needing to duplicate a wl. - Adolphus79 (talk) 04:24, 6 November 2025 (UTC)

I'm concerned with the case that the two phrases are *NOT* synonyms. As an example IBM wrote two different job entry subsystems for MVS, JES2 and JES3, both terms having redirects to Job Entry Subsystem 2/3. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:34, 6 November 2025 (UTC) -- Revised 14:19, 6 November 2025 (UTC)

So linking them both in the same section without further comment or explanation would be confusing and should certainly be avoided. Gawaon (talk) 11:15, 6 November 2025 (UTC)

A clearer solution would be something like two variants of the Job Entry Subsystem, JES2 and JES3 – that'll work as expected and avoid confusion. Gawaon (talk) 11:18, 6 November 2025 (UTC)

That'll work if their in the same sentence, but ot if they're significantly separated. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:51, 6 November 2025 (UTC)

Re calling foo foo both times: exact repetition's boring and largely avoided in many languages. Today's FA Sieges of Berwick (1355 and 1356) includes background on Berwick which mentions the "stone walls", the "town's and castle's defences", and the "town walls", linking to Berwick town walls only once. Any more than that wouldn't be helpful, giving the reader the impression that there were multiple locations ... that can increase readers' understanding of the topic at hand. NebY (talk) 12:21, 6 November 2025 (UTC)

I'm concerned with the case that the two phrases are *NOT* synonyms. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:19, 6 November 2025 (UTC)

OK, so Aldolphus79's question and my response to it weren't directly relevant to your concern. I don't know if there is an easily expressed universal rule for that, but one thing I'd consider when (un)linking would be that risk of giving the reader the impression that there were multiple locations ... that can increase readers' understanding of the topic at hand. As a reader, I have occasionally found it annoying to be sent off to the same place twice. NebY (talk) 15:44, 6 November 2025 (UTC)

How? Your one example of two redirects linking to the same page above was easily remedied by Gawaon. If they are not synonyms, then they shouldn't be linking to the same page. - Adolphus79 (talk) 15:46, 6 November 2025 (UTC)

No, they are *NOT* "easily remedied by Gawaon", because they are not in the same sentence, and they *should* be linking to the same page, because that page describes both. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:58, 6 November 2025 (UTC)

OK, give us an example? - Adolphus79 (talk) 16:23, 6 November 2025 (UTC)

In OS/360 and successors § OS/VS2 SVS and MVS, JES2 and JES3 occur in different sentences: Initially MVS was supplied with a job queue manager called JES2 (Job Entry Subsystem 2), which was descended from HASP (Houston Automatic Spooling Priority) and also supported Remote Job Entry from workstations located elsewhere. JES2 can only manage jobs for one CPU (which might be a tightly coupled multiprocessor system). In 1976 IBM provided another option, JES3 (Job Entry Subsystem 3), a descendant of ASP (Attached Support Processor), which allows one CPU to manage a single job queue feeding work to several physically distinct CPUs, and therefore allows one operator's console to manage the work of all those CPUs.^[1] Note: JES1 was the job queue manager for OS/VS1 (see above). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:35, 6 November 2025 (UTC)

Considering that Job Entry Subsystem 2/3 doesn't even have separate sections on the two, the distinction is merely a mention in the lede, and the body includes the statement "In 1973, IBM rewrote ASP and renamed it JES3", it appears that not only is the JES3 link in your example definitely overlinking, but the (unsourced) description of JES3 in your quote is also incorrect. It should be re-worded to say "In 1976, IBM provided another option, ASP, later renamed JES3, which allows..." without a link at all (as supported by the sourced statement on Job Entry Subsystem 2/3). I see absolutely no reason to link JES2 and JES3 to the same page in the same paragraph. - Adolphus79 (talk) 18:12, 6 November 2025 (UTC)

JES3 is not a renamed ASP; a massive amount of code has been replaced. Your suggested text is erroneous. However, I see that the linked article is missing a lot of important information and I have marked it as a stub. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:27, 6 November 2025 (UTC)

Also, why are the JES abbreviations linked when the other abbreviations in that same paragraph are not (HASP and ASP)? You should also move the link to the "Job Entry Subsystem 2" in the parentheses instead of the JES2 abbreviation, which would further quell any confusion or overlinking. - Adolphus79 (talk) 18:26, 6 November 2025 (UTC)

The full names are linked. However, it would be better stle to have the abbreviations in the parentheses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:27, 6 November 2025 (UTC)

The full names are NOT linked. I just checked again, and the article has links on "JES2" and "JES3", instead of "Job Entry Subsystem 2" like the other abbreviations in that same paragraph (and in your quote of it above). - Adolphus79 (talk) 19:59, 6 November 2025 (UTC)

You mentioned HASP and ASP; in both cases the full name is linked. I agree that the style should be consistent, and my preference is full name linked, abbreviation in parentheses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:11, 7 November 2025 (UTC)

With respect, the JES2/JES3 discussion appears to be a side-track. There are many examples where an article discusses several concepts that just happen to link to the same destination article. Of course these could (at least in theory) be rewritten to only require a single link while still not add confusion or astonishment to the reading experience, but the question is... Should they have to? I am inclined to say "no, having more than one link (in the same great section) is not exactly a great crime against Wikipedia. If it makes sense to retain more than one link, do so!" because... common sense? Not adding rules that mostly add administration? Example: Paul Decauville started a company called Decauville and invented a portable narrow-gauge railway system, the Decauville system. Should the minor fact this system doesn't currently have its own article, and is discussed at the company article, mean editors are prohibited from linking both in close proximity, as I just did? I'm sure there are hundreds of examples where we don't need to delve into arcane differences between old mainframe operating subsystems... :) The point is that one link doesn't obviously have information for readers interested in the other topic and vice versa, so separate links are easily understandable as the first choice when writing new material into Wikipedia. Regards, CapnZapp (talk) 14:53, 7 November 2025 (UTC)

Maybe it's not a great crime, just a little one. Nobody will be blocked from editing for linking both terms in such cases, but if the section can be rewritten in such a way that the duplicate link is eliminated, I'd still consider it an improvement, especially as it will reduce the risk of reader confusion. (Hadn't I read this before? How come I ended up here again?? That's not what I had expected!!!) Gawaon (talk) 21:40, 7 November 2025 (UTC)

Just to clarify: I respect your opinion and in fact share it. But wWhat we're discussing here is possibly tweaking the actual policy. Specifically, should we clarify that what we discuss here is a valid case of "contextually important" (per the existing Do not re-link in other sections if not contextually important there. exemption from MOS:LINKONCE.) Thanks CapnZapp (talk) 12:29, 8 November 2025 (UTC)

Possibly tweaking the actual policy or the actual guideline? Butwhatdoiknow (talk) 15:44, 8 November 2025 (UTC)

I'd me more inclined to duplicate links if the redirect falls under {{R with possibilities}}. Ideally, other articles should not need to be re-written (e.g. adding link(s)) because a new page is created later. Otherwise, it is annoying to a reader unfamiliar with a domain if links unknowingly take them back excessively to the same page, esp. if there is no dedicated section or little distinguishing information. —Bagumba (talk) 17:00, 8 November 2025 (UTC)

• This whole business of linking to the same anchor multiple times in an article was never a good idea. If a reader really wants to divert to another article after following a section link, they can so easily cast their eyes up to a previous link (readers hit links much less often than people here seem to assume, and we certainly shouldn't be catering to the supposed link-hoppers who treat WP like some kind of board game). Or, perish the thought, a reader could type a word into the search box. And on no account should a subsequent link have a different pipe: that would be very irritating if perchance someone did hit both. Recall WP:EASTEREGG? Tony (talk) 10:22, 9 November 2025 (UTC)

I could be wrong, but you appear to discuss as if the issue was "we want to be able to give the same link over and over!" It's not. The discussion revolves around the occasional need to link to two different concepts that just happen to be discussed by the same page. Readers may cast their eyes wherever they want but the premise here is that no matter how hard they look, they cannot be expected to understand that concept Y is discussed at article X. Without adding a link to Y that redirects to X (or perhaps directly using "[[X|Y]]") as a second link to X. If I am wrong, please disregard. Constructively speaking, as I see it, we probably should explicitly explain this to be an allowed case of the "conceptually important" exception of MOS:DL. Regards CapnZapp (talk) 10:56, 10 November 2025 (UTC)

I still think it would be confusing and so certainly shouldn't be explicitly allowed as "this is fine". If it happens, it happens, but usually (I'll still uphold) there'll be better solutions. Gawaon (talk) 11:01, 10 November 2025 (UTC)

MOS:DL's exception is "contextually important", not "conceptually". Even if it were "conceptually", to a great extent they're not entirely separate concepts if they're aspects of the same topic. In the example above, the reader can be expected to fully understand and accept that Job Entry Subsystem 2 and Job Entry Subsystem 3 are both discussed at Job Entry Subsystem 2/3. NebY (talk) 12:03, 10 November 2025 (UTC)

I agree about the Job Entry Subsystem. I also think it is a very poor example. CapnZapp (talk) 12:29, 10 November 2025 (UTC)

DL begins with "Link a term at most once per major section," not "Link to an article or anchor at most once per major section." Thus, the second sentence means "Do not re-link a term in other sections if not contextually important there." It doesn't - and shouldn't - have a limit on how many times an article/anchor is linked to if that article/anchor helps the reader understand different terms. - Butwhatdoiknow (talk) 15:43, 10 November 2025 (UTC)

If the MoS isn't talking about duplicate and repeat links in general in this section, despite the name of the subheader, that is, if we already allow several links to the same page provided the links are to different terms on that page, then this really needs to be said in a more clear and direct fashion. (This is not me disagreeing. In fact, it would solve my issue. But it really isn't immediately obvious this is what we're meaning). CapnZapp (talk) 17:23, 10 November 2025 (UTC)

Note: I was under the impression that it is good practice to repeat a link in the body if it appears in the lead. I've recently been told by experienced editors that they don't do this, likely based on the length of the article. For example, if the article is somewhat short, one link in the lead is good enough for them, and no link in the body is needed. Any thoughts? Viriditas (talk) 23:44, 15 November 2025 (UTC)

That is indeed good practice, in my view. Tony (talk) 00:11, 16 November 2025 (UTC)

Which? Viriditas (talk) 00:36, 16 November 2025 (UTC)

Sorry, my bad: it's good practice not to repeat a link in the body, in my view. The guideline says you may, not you must, and it was never a good idea anyway. Tony (talk) 04:39, 16 November 2025 (UTC)

What's "somewhat short", though? It seems a very vague term. When in doubt, say if the article has at least two body sections of more than a few paragraphs, I'd tend to relink each relevant term at least once in the body, even if it was already linked in the lead. Gawaon (talk) 08:06, 16 November 2025 (UTC)

So we agree the MoS actually does not discourage/prohibit duplicate links... as long as the links are for different terms/concepts explained on the destination page? CapnZapp (talk) 12:06, 16 November 2025 (UTC)

There are all sorts of reasons I think it's a good idea to repeat links in the article - accessibility being the main one. What are the reasons not to? Tduk (talk) 12:25, 16 November 2025 (UTC)

I generally link once in the lead and once in the body. Several highly experienced users who write hundreds of articles have told me that they don’t do that unless the distance between the two links is greater than x number of words, implying length. This reminded me of another argument I had heard about the same thing in the past: if the distance between the two links is greater than one or two screens of paging down then repeat the link. Even then, I have users telling me they still don’t want to link again. Viriditas (talk) 19:41, 16 November 2025 (UTC)

What is the harm of linking again? Especially considering the accessibility benefits. Really, I don't know why we don't _always_ link when it makes sense and let a user-side filter un-blue them. This also decouples the sections for future ease of use. Tduk (talk) 19:58, 16 November 2025 (UTC)

Our MoS deals with the way Wikipedia works now, and that's without a user-side filter that allows readers to choose whether or not to see duplicate links. Such filters and automations are an immense challenge; we don't have automatic date reformatting, units selection or spelling localisation either. NebY (talk) 20:21, 16 November 2025 (UTC)

The harm is that it dilutes the linking system and can create a sea of blue, which looks messy and unprofessional. Nothing stops a reader from typing a word into the search box (hopefully when they've finished the article, not as a diversion). Tony (talk) 00:35, 17 November 2025 (UTC)

We don't agree on that. The issue is just too exotic to be explicitly addressed in the MOS. Gawaon (talk) 16:04, 16 November 2025 (UTC)

Doesn't agreeing on it mean that it isn't addressed explicitly in the MOS? What am I missing here? Tduk (talk) 17:14, 16 November 2025 (UTC)

In the case it is me you're disagreeing with, Gawaon: When I entered this discussion it was with the firm belief the MoS prohibited exactly the kind of sort-of-but-not-really duplicate links. I have been in several discussions where editors point here to argue it is policy to never allow duplicate links to the same article even when each link is for a separate concept. Because there's far too little to indicate this distinction is important. Now I have been informed we were wrong. I find this highly unclear and if you oppose me clarifying this you need to argue why this isn't the natural spot to explain all of this. Regards CapnZapp (talk) 17:36, 16 November 2025 (UTC)

It is definitely confusing. My take is that we should not duplicate links in the same section, but there are times where this is permissible. The examples provided up above discuss this. I have seen this happen quite a few times, particularly when a larger topic contains a smaller but substantial subtopic. If both of these are discussed in a single section, and the topics are only found on that one page, then duplicate links (using different names, often one to the main topic and the other to the subtopic) are allowed. Others may disagree. Viriditas (talk) 21:06, 16 November 2025 (UTC)

"but there are times where this is permissible"—I strongly disagree. We're trying to avoid the dreaded sea of blue and the dilution of the linking system. Used sparingly it gives readers a reliable selection of links that on rare occasions they might follow (readers don't follow links much). Tony (talk) 00:32, 17 November 2025 (UTC)

I believe it is permissible to link once to the same concept in the lead and the body. I realize that others disagree. Viriditas (talk) 00:38, 17 November 2025 (UTC)

That's not what this discussion is about. Repeating a link in a different section had been allowed for quite a while. This it about whether multiple links to the same article in the same section should be allowed in certain cases. I'm not happy with the idea and not convinced there's a good use case for it, but others disagree. Gawaon (talk) 09:05, 17 November 2025 (UTC)

Apologies for confusing you. I know what this discussion is about. However, it has recently come up in several different reviews that some editors do not believe in linking articles in different sections, which is why I raised it in this discussion. I think we are all able to handle multiple ideas at once. Viriditas (talk) 09:07, 17 November 2025 (UTC)

Sigh. This is quickly turning into one of those cases where everybody can read what they want into the current phrasing, so we end up with the bad ending where we keep the confusing and unclear phrasing simply because any rewording that would benefit the great majority of readers would force the issue, and while that would be great for Wikipedia, it is less great for the editors on one side. I know better than to engage in such unwinnable fights, so please ping me if and when you do arrive at a consensus, and honestly, please only do that if that consensus is in favor of allowing two links in the same section to the same article (as long as each link is for a different concept, and that those concepts are only really discussed by the same destination). While I now know I can add such links - and defend them using the existing MoS, since you might disagree but you can't argue the current wording excludes the interpretation that would allow them - I would have preferred if this discussion resulted in actual improvements to the page, such as avoiding language that only appears to be prescriptive but really allows both ways. CapnZapp (talk) 12:57, 18 November 2025 (UTC)

The bio on Fernand Léger currently contains a 92 word (707 character) "sea of blue" link section. This is not conducive to readability, nor is it all that unusual; lots of bios use this horrible style. What's the solution? Viriditas (talk) 23:41, 15 November 2025 (UTC)

Listify the list of pupils? -- Michael Bednarek (talk) 02:13, 16 November 2025 (UTC)

I agree with this. The lack of readability is, imo, not related to the fact that any of the text is blue. Comma separated lists like this are a poor idea I think. Tduk (talk) 12:31, 16 November 2025 (UTC)

Given the source for the list is a ledger at a museum and not a secondary source, this screams that third-party secondary sources should be found to identify the most significant individuals on that list rather than retain them all. Masem (t) 02:17, 16 November 2025 (UTC)

Create a category - say Category:Pupils of Fernand Léger - and add all of the listed articles to it. Then trim the list to the four or five, six maximum, that are most significant. --Redrose64 🌹 (talk) 08:13, 16 November 2025 (UTC)

Will do! Viriditas (talk) 21:07, 16 November 2025 (UTC)

Hello! I have been in a discussion about the fact that it has become standard practice in {{Infobox legislature}} to write down "Government" with a link to a specific cabinet (e.g. Schoof cabinet), so it becomes Government (See House of Representatives (Netherlands) for the specific example). I consider this a MOS:EASTEREGG, because I expect to be taken to a page like Executive (government). I have proposed to more explicitly mention the cabinet (see rev), but others have reverted these edits because it is against standard practice. Which is true, because many other legislature pages do this. Although there are some examples which make it even more confusing (House of Representatives (Egypt) also links opposition to general opposition article. And House of Representatives (Japan) links to confidence and supply).

I'm curious what the consensus is about this practice versus the guideline. Dajasj (talk) 12:17, 21 November 2025 (UTC)

• Not only is that the standard practice, it is also the information that the template calls for. But I see your point. It seems to me that the problem is the word "Government," which would require a change to the template. Maybe come up with what you think is a better label ("In Power"? "In Government"? "Controlling"?) and start a conversation on the template's talk page with that proposal? ("In Government" may not be the best, but it is probably the easiest to sell.) - Butwhatdoiknow (talk) 17:23, 21 November 2025 (UTC) Strikethrough erroneous text. - Butwhatdoiknow (talk) 23:35, 21 November 2025 (UTC) Strikethrough erroneous text #2 (this is embarrassing, or would be if I had any shame). - Butwhatdoiknow (talk) 17:37, 22 November 2025 (UTC)

I might be missing something, but where does the template call for this practice specifically? I only see that you can list the political groups in Parliament, not even a suggestion that it should be split out by government vs opposition. Dajasj (talk) 20:42, 21 November 2025 (UTC)

(I have also notified the template talk page of this discussion btw) Dajasj (talk) 20:43, 21 November 2025 (UTC)

I thought your issue is that the word "Government" made the reader think that the link would lead to a generic article regarding the institution, not the name of the governing body/party. Now it seems you are opposed to identifying the party/coalition in control at all.

I think that boat has sailed. The template has two "political_groups" lines, one for "list of the political parties/groups represented in house1" and one for "list of the political parties/groups represented in house2." It seems likely to me that the original purpose of the house2 line was for use in articles covering both houses of a bicameral legislature, for example Parliament of the United Kingdom, meaning it was not intended to have anything in articles about a single house. But, nature abhors a vacuum and, over time, it has been used in single house articles to identify parties out of power, suggesting that editors have found it beneficial to include that information. - Butwhatdoiknow (talk) 23:35, 21 November 2025 (UTC)

My issue is only with the link behind the genetic term "Government". The split itself is not a problem (which is often done within political_groups1). Sorry if that wasn't clear. My question was, where does the template imply that there should be the word government with a link to a specific cabinet? That's what I understood from your first comment but couldn't find. Dajasj (talk) 07:38, 22 November 2025 (UTC)

My bad. Sorry to send you on a wild goose chase. It looks like "Government" comes from taking taking the HM out of "HM Government" (where it makes sense as a term of art). I still think the solution is to change the word "Government" to something else. Here's a fourth alternative: "Governing." - Butwhatdoiknow (talk) 17:37, 22 November 2025 (UTC)

No problem ;) 'Governing' would be better, but I still think it would be best to be more explicit about the link. Dajasj (talk) 11:45, 24 November 2025 (UTC)

• It's an example of a highly misleading easter egg, and should not be used. Tony (talk) 09:54, 22 November 2025 (UTC)
• Government is the conventional term used, even in parliamentary republics. Glide08 (talk) 10:05, 18 January 2026 (UTC)

The problem is that "government" has multiple meanings. According to the Wikipedia government article: "In the case of its broad associative definition, government normally consists of legislature, executive, and judiciary." I suggest that most readers would assume that meaning. - Butwhatdoiknow (talk) 13:14, 18 January 2026 (UTC)

I get the impression that "Government" is the common term used to refer to the coalition in power in various parliamentary systems where multiple parties have to form a coalition for anyone to be able govern (i.e. definition 6 at wikt:government#Noun, and maybe also definition 5). In these infoboxes, the "Government" header is introducing the list of parties making up the coalition, and additionally is linking to the article about the coalition itself. The US doesn't have anything directly comparable, as its system selects the Executive separately and the two-party system means no coalitions are needed in the Legislative anyway. The UK seems to specifically qualify it as "HM Government" which makes it distinct from the plain word "government", but that wouldn't work so well for countries without a monarch or ones that separate the monarch from government more than the UK does. It's not clear to me that inventing our own terminology for the general cases would really make things more clear if English-language sources use "Government". Anomie⚔ 15:48, 18 January 2026 (UTC)

• Seconded. Glide08 (talk) 18:02, 18 January 2026 (UTC)
• I don't think the issue is "inventing" terminology but, rather, it's that the use of "Government" as a term of art causes sufficient confusion for those unfamiliar with that definition. We should use a more descriptive term that all readers can instantly understand without consulting Wiktionary). See also Wikipedia:Make_technical_articles_understandable#Lead_section
  Note: This issue wouldn't be all that important if the word was not linked to governing coalitions articles. But it is, and when the uninitiated see "government" they expect land at Government. - — Preceding unsigned comment added by Butwhatdoiknow (talk • contribs) 22:00, 18 January 2026 (UTC)

  Any term could be considered a "term of art" for people who're unfamiliar with it. I think what we need here is for someone to do the research to find out what terminology publications actually use, if not "Government", instead of inventing something that you think might be clearer to some hypothetical uninformed reader. Anomie⚔ 23:41, 18 January 2026 (UTC)

  What sort of publications do you have in mind? And would they be local to each particular country or would the survey include international publications? For example, for the UK parliament governing party/coalition would you include US publications? - Butwhatdoiknow (talk) 05:24, 19 January 2026 (UTC)

Is there any list of words that show whether a word should be typically linked or not? Wikieditor662 (talk) 20:52, 22 November 2025 (UTC)

Not that I know of. A lot depends on context. - Butwhatdoiknow (talk) 22:05, 22 November 2025 (UTC)

Well do you think there should be one? And even with context, there are some words that most of the time should or shouldn't be linked... for example, "the" shouldn't, and Charlemagne should. The article even gives its own examples, such as that most countries shouldn't. Wikieditor662 (talk) 02:53, 23 November 2025 (UTC)

What problem would this solve? - Butwhatdoiknow (talk) 06:11, 23 November 2025 (UTC)

It would solve the "sea of blue" problem, which not only disfigures the reading experience but dilutes the linking system: linking should be rationed to anchors that an editor decides are more likely to be followed by readers. It requires editorial skill in the light of each context. But that said, certain words shouldn't be linked, except on rare occasions: road, stadium, statue, nation, army, for example. Readers are supposed to be familiar with English vocabulary. But listing words that shouldn't ever be linked is problematic, I think. Tony (talk) 10:55, 23 November 2025 (UTC)

And difficult, and unlikely to be read or followed by most overlinkers, who are generally very early-stage editors. I'd agree with the short list given, but for example I'd link equestrian statue, possibly bust, and many occurrences of the others might be better with adding the specific road, stadium, or army, and linking that appropriately. Johnbod (talk) 11:33, 23 November 2025 (UTC)

"certain words shouldn't be linked, except on rare occasions" And there you have it. Once you create a list the reality is that nuance will go out the window. There won't be any rare occasions.

And, oh my, the debates that will take place regarding whether words should or should not be on the list. I shudder to think about it. - Butwhatdoiknow (talk) 15:57, 23 November 2025 (UTC)

It might also help to have more than two tiers, for example:

• Should almost always not be linked (eg the words "the" or "a")
• Should usually not be linked (eg countries)
• Should sometimes be linked (eg bust, death)
• Should usually be linked (eg cancer)
• Should almost always be linked (eg obscure words)

(the list/examples aren't perfect and there could be fewer categories but you get the idea)

As for the overlinkers not reading it, perhaps it could still be benefitial: someone who sees an article overlinked can refer the overlinker to the list. Plenty of other people could benefit from this, such as myself.

Also, if we did decide to make such a list, would we need to use external resources to find out how common a word is, or do the editors' consensus determine how commonly a word should be linked? If you want I can start working on such page.

Wikieditor662 (talk) 14:54, 24 November 2025 (UTC)

If we produce extensive lists, almost nobody (neither people adding links, nor people deleting them) will be bothered to read them (TLDNR), making them superfluous. Almost inevitably, the lists will overlook some words, which people will then link and point out that they are not on the list(s), although they would come under the generic description. I would agree to citing a few (3 or 4) more examples in the existing format, but not to extensive lists. - Arjayay (talk) 15:16, 24 November 2025 (UTC)

Well, the idea is that people wouldn't read the entire list, but look for specific words that they're not sure if they should link from that page. Wikieditor662 (talk) 15:35, 24 November 2025 (UTC)

If you aren't sure, use common sense. The lists you ask for would be way too long to be usable and maintainable. Gawaon (talk) 09:11, 25 November 2025 (UTC)

Well, common sense would be easy in simpler cases, but in others it becomes more difficult or more of a gray area. The lists you ask for would be way too long to be usable and maintainable. well for one editor yeah, but if there are thousands, many of which even contribute to one word based on what they think there could be something, no? Wikieditor662 (talk) 16:23, 25 November 2025 (UTC)

Something, yes, but it would be random and useless. Moreover, whether to link a term in a given context always depends on the context in which it is mentioned (is it sufficiently relevant here to be linked or what that be just a distraction?), so such a list is not only impractical, but also impossible for conceptual reasons. Gawaon (talk) 03:26, 26 November 2025 (UTC)

• Johnbod said: "unlikely to be read or followed by most overlinkers, who are generally very early-stage editors". Yeah, actually a high proportion of ridiculous links come from articles translated from other language WPs. Linking is completely undisciplined in most WPs; it's something that sets en.WP aside from them. Tony (talk) 09:33, 26 November 2025 (UTC)

I first posted about this at WP:Village Pump (technical) and was told that it was "not a technical question and you should ask on the relevant MOS talk page" so here I am. This is my original post from VP (technical):
I came across an article where another editor had changed various geographical wikilinks from complete wikilinks to piped wikilinks, for example:

• [[Roanoke, Virginia]] to [[Roanoke, Virginia|Roanoke]],Virginia and
• [[Halifax County, Virginia]] to [[Halifax County, Virginia|Halifax County]], Virginia.

The editor cited WP:GEOLINK as the reason. I know that Geolink states "For a geographical location expressed as a consecutive comma-separated sequence of two or more territorial units, link only the first unit." but the changes just look like a lot of unnecessary piping to me... - Shearonink (talk) 18:33, 27 November 2025 (UTC)

This editor misunderstands [WP:GEOLINK]]. [[Roanoke, Virginia]] and [[Halifax County, Virginia]] are both fine.

I can see how someone can make this mistake, but I'm not inclined to change the wording. I can't think of a cleaner way, and the examples make this whole thing pretty clear, e.g., the second [[Buffalo, New York]] one in this case. Danbloch (talk) 20:59, 27 November 2025 (UTC)

Why is it a mistake? It avoids link bunching. See MOSLINK. Tony (talk) 02:36, 28 November 2025 (UTC)

What's link bunching? MOS:LINK doesn't mention it. Gawaon (talk) 03:04, 28 November 2025 (UTC)

Moved from Wikipedia talk:Manual of Style/Accessibility § Linking strategy

This post presents a perceived problem and two possible solutions.

There have been many disagreements and interpretations of the current WP:MOS policy on WP:OVERLINKING. While some argue that overlinking results in an unreadable sea of blue links (which can be worse if you’re using certain assisted reading devices), the counter to that is that _not_ linking things forces a user who to scroll/search back through the article for the first time that link appeared - assuming it’s still there and is not hidden behind a MOS:PIPE - which can be difficult for people on certain systems, or with certain disabilities. It could be said that either of these situations is asking a lot of the reader, unreasonably.

Solution 1 (more work): Rather than have to do a one-or-the-other linking policy, I’d like to suggest something like this : linking is permitted wherever the editor likes it, and is never discouraged. There’s no reason that the problem of overlinking can’t be addressed client-side, filtering out redundant links via a user preference (even allowing users who want to to see several of the same link in the same sentence, if it occurs - though obviously this won’t be the default). This could be toyed with in many ways but I think the basic ideas is sound. I think we’re long past the time where we’re concerned about the extra bytes a blue link takes up, so it really comes down to readability and accessibility. All users will have a default setting which reflects what the consensus on linking should be.

Solution 2 (easier techwise, harder consensus wise): As wikipedia evolved, I don’t think anyone has given thought to the linking policy, what its harms and benefits are to the underlying technology (and how that has changed), and whose experience the current balance put in place favors and how.

Any thoughts on this? Tduk (talk) 00:14, 29 November 2025 (UTC)

1 solves your perceived problem for editors only. But the vast majority of readers are not editors, and so cannot set preferences. They could only be served by 2, and I'm not really sure what your 2 solution is? It seems more like a statement. Nikkimaria (talk) 01:26, 29 November 2025 (UTC)

I'm not in a position to unilaterally provide a solution for 2 (or indeed default settings for 1, which is what you've missed in my proposal, maybe that's my fault). I'd like to see what feelings are on this before making any proposals. Tduk (talk) 01:29, 29 November 2025 (UTC)

Presumably default settings for 1 would reflect... whatever 2 ends up being. Nikkimaria (talk) 01:37, 29 November 2025 (UTC)

readers are not editors, and so cannot set preferences Not if they have no account. Paradoctor (talk) 15:24, 30 November 2025 (UTC)

Solution 1 won't work, as Nikkimaria pointed out, and solution 2 is not a solution at all, as far as I can see. Also I'm not sure what the problem is, and that it really is one. I haven't yet heard any readers complain that we don't link every repeated mention of a linkable term. Gawaon (talk) 02:46, 29 November 2025 (UTC)

I've asked around a good deal in person before posting here and most people I've spoken to do think it's an issue worth considering; and it came up recently at Talk:Agent Carter (TV series), although somewhat circuitously; it was this talk page that got me thinking about this. I don't think Nikkimaria pointed out that (1) won't work; rather, it will work but may require looking into (2), or encouraging use of preferences. People I have spoken to/seen discuss it sometimes do complain that the linking policy is outdated, especially for those who aren't on good systems or who have difficulty navigating/typing for various reasons, but there is a perception that if anyone brings it up, it will get a negative reaction, so typically no one does since that kind of change is not easy here. However, I've already said my point of view, and I'm not interested in trying to convince people of it; as I've said, if they are around, they will comment here if they want to. Tduk (talk) 03:44, 29 November 2025 (UTC)

Tduk: I don't think either solution would work. And let's put an end to this moaning about poor readers and scrolling up ("not linking things forces a user who to scroll/search back through the article for the first time that link appeared"): if you follow a section link there's nothing stopping you from typing an item into the search box—or better, scrolling up to read the earlier part of the article. I don't think WP should cater to readers who don't want to read articles properly. Tony (talk) 10:25, 29 November 2025 (UTC)

Also, we already allow repeating links once per major section. But allowing or requesting them to be repeated even within the same section would needlessly burden editors, while possibly distracting readers with so much blue. Gawaon (talk) 11:12, 29 November 2025 (UTC)

In the discussion I linked to above, people argued that because links are allowed _at most once_ per section, then zero is a reasonable number, and people use the MOS to defend that. Someone just tried to change that text in the MOS, which you rightly reverted, but I think these two cases show that there is some interest. I agree about the too much blue which is why I advocated for solutions 1 above. If you're really interested in trying to figure out what the issue is along with me, I am happy to engage in a dialog here. There may be a third solution that makes more sense, and it may just be making the MOS more assertive in what should be done. Tduk (talk) 12:59, 2 December 2025 (UTC)

There has been a lot of discussion on MOS:GEOLINK on this page. Mostly about something like Buffalo, New York, versus Buffalo, New York. I think both are fine. My question though, is what if the first location does not have an article on it yet? For example, with the article Novoye Rozhkovo, it describes a place in Parfyonovskoye Rural Settlement, Velikoustyugsky District, Vologda Oblast, Russia. There currently isn't an article on the Parfyonovskoye Rural Settlement. My solution was to red link Parfyonovskoye Rural Settlement and keep the link to Velikoustyugsky District (while getting rid of the link that had been to Vologda Oblast). However, I encountered a lot of articles like this for different rural settlements in Russia, and I'd wager it's probably occasionally relevant elsewhere too, so I figured I'd see what y'all think. The way I see it there's three options:

1) Only include a red link. This seems problematic since then a user can't follow the link tree to get to the other places, like Velikoustyugsky District.

2) Include a red link and blue link for the first term which has an article, as I chose.

3) No link for the location without an article, and include a link for the first term that has an article already.

I think 2 and 3 are probably both fine. I'm curious if I'm missing some policy on this tho, or if there will be a clear community consensus. I'm not starting an RfC, because I don't think this warrants one, and I'm not even actually sure how to, but apologies if this would have been better posted elsewhere. Ezra Fox🦊 • (talk) 01:51, 15 December 2025 (UTC)

I'd go with option (3), avoid red links. If the article is created later, people can still add links to it (ideally then removing the link for the second-level unit). Gawaon (talk) 02:32, 15 December 2025 (UTC)

Don't avoid red links.

WP:REDLINK: Red links help Wikipedia grow.

See WP:REDYES for more. Paradoctor (talk) 11:07, 15 December 2025 (UTC)

Would someone take a look at Eric_Gilbertson_(climber) and comment if the amount of wikilink is reasonable? I find the Eric_Gilbertson_(climber)#Early_life_and_academic_career section especially exceedingly heavy in links. I've noted that the recent heavy contributor's other articles are similarly heavy in wikilinks. Graywalls (talk) 06:08, 16 December 2025 (UTC)

Some of them, especially the academic degrees (Master of Science etc.), seem unnecessarily linked. Gawaon (talk) 09:31, 16 December 2025 (UTC)

Please note: what you talk about is WP:OVERLINK, not WP:SEAOFBLUE. Different things. SEAOFBLUE is about adjacent links that look like one, which can happen with entirely appropriate links. Paradoctor (talk) 12:08, 16 December 2025 (UTC)

fixed. Graywalls (talk) 18:18, 16 December 2025 (UTC)

MOS:SL states Section-linking options are piped links, redirects, and the {{Section link}} template, which also generates the § character.

I note the absence of an "unpiped" link, a link like Wikipedia talk:Manual of Style/Linking#appearance of section links that displays the hash character. I cannot interpret this as anything else than a discouragement (or outright prohibition) on section links whose hash character isn't replaced by the paragraph character of a {{slink}} (or links to sections which don't appear as such, for example a redirect to a section).

If the consensus and intent is not to discourage the hash character (edit: talking chiefly about article space, not talk discussions), I would suggest we tweak the wording to specifically include unpiped section links. This would make it much less likely anyone arrives at the same interpretation I did. Perhaps:

Section-linking options are links (piped or otherwise), redirects, and the {{Section link}} template, which also generates the paragraph (§) character.

(if you want our MOS to remain be open to hash marks in article space section links)

If it is, it wouldn't hurt to spell this out clearly:

Section-linking options are piped links, redirects, and the {{Section link}} template, which also generates the paragraph (§) character. Avoid unpiped links which display the hash (#) character.

(if you want our MOS to be clear about discouraging hash marks in article space section links)

Edit to add: I guess a third option is to prefer MOS to remain silent on the issue. Please then argue why. Also, as I said, I do not believe the current wording can support such a stance, so I would ask you to offer up your own phrasing in that case (or argue why you think my interpretation is not the correct/intended one).

I wanted to update H:SECTIONLINK but realized I should first divine your collective will.

Thoughts? CapnZapp (talk) 11:26, 4 January 2026 (UTC)

I agree it makes sense. Raw # links are fine for discussion pages, but for the article space the cleaner § form is clearly preferable. Gawaon (talk) 11:32, 4 January 2026 (UTC)

Support first version. Nikkimaria (talk) 14:13, 4 January 2026 (UTC)

@CapnZapp: Now I'm a bit confused by your later edit since as it currently stands the MOS does not "remain silent on the issue", rather it seems to effectively forbid unpiped links, by mentioning only piped ones among the valid/recommended options. So keeping the status quo is not silence, though it's a fairly quiet (easy to overhear) way of speaking. Gawaon (talk) 16:17, 4 January 2026 (UTC)

I think I see what your concern is. I replaced "remain open" with "be open" like this: remain be open. Does this answer your query? As for it seems to effectively forbid unpiped links that's exactly the conundrum - I would argue it quite ineffectively forbids them, by being far too obscure. The prohibition is so "hidden" that I'm almost questioning the intent. Which is exactly what this talk section is about. Don't prohibit things by omission - if you want something barred, spell it out!

Sorry if my later edit made it appear I was less direct than I intended to be, I keep standing by my opening statement: "I cannot interpret this as anything else than a discouragement (or outright prohibition) on section links whose hash character isn't [replaced or omitted]". I just had to read the sentence more than once to see this, which is effectively what I want improved here. CapnZapp (talk) 11:29, 5 January 2026 (UTC)

Nikkimaria: as you can read from the above, I wasn't perhaps as clear as I should have been regarding the first option. It appears the current phrasing disallows hash marks in section links, thus option 1 would mean a change rather than preserving status quo. Can I ask if you agree or oppose this train of thought? It would help clarify what you meant by your sentiment. Regards, CapnZapp (talk) 11:33, 5 January 2026 (UTC)

I don't agree that there is currently a disallowance, and prefer wording that makes that clear. Nikkimaria (talk) 00:19, 6 January 2026 (UTC)

Yeah, okay. Like I said, I think the disallowance is already there, though indeed very implicitly, so I fully agree that it should be expressed more clearly and unambiguously. Gawaon (talk) 03:21, 6 January 2026 (UTC)

The hash character is a technical detail of the URL syntax. It should not appear in article space, and the MOS should say so explicitly. (Section links with a hash are fine on talk pages. And most other non-article namespaces, I think. Maybe not in the MOS itself, since it should be an example of good style.) — Chrisahn (talk) 15:44, 5 January 2026 (UTC)

Why are we holding a parallel discussion? Please see Wikipedia talk:Manual of Style/Layout#RFC: Piped links in "See also" sections, or at the very least, Wikipedia talk:Manual of Style/Layout#c-Redrose64-20251207121500-Beland-20251207013900. --Redrose64 🦌 (talk) 18:05, 5 January 2026 (UTC)

Because I had no idea those other discussions existed, User:Redrose64? (For the next time, how would I proceed to find them before starting a new discussion?) Now then, to that discussions: Edit to add: maybe the constructive approach would be to ask you to consider advertising this discussion there? I've gone ahead and added a discussion notice.

The RFC about piped see also links - it sure mentions the hash tag vs the slink template, but I can't see how it clearly answers what I'm asking here. Posters do implicitly assume things about styles and such, but I am no expert on Wikipedia MOS history... which is why I am asking a direct question here and now. Why or how do you feel this discussion you linked is more than adjacent to a point where it is directly relevant to ours? (Are you even saying this discussion should not happen here, because it is happening there...? Maybe I'm misunderstanding your question?)

The second link is directly to a post of yours: Wikipedia uses that syntax for linking to sections because it's being used for exactly its design purpose. I obviously know HTML syntax. Do note that it does not necessarily follow that just because HTML does something a certain way, we should blindly assume Wikipedia does it the same way. It does appear you are saying you prefer our MOS allow hash marks in section links - is this correct? (Pro tip: you could just have said so rather than to link to a, to me, chiefly unrelated discussion thus forcing me to parse that entire context) Back to the point, Redrose64: are you saying you agree the wording currently does not seem to allow it? And do you then prefer we change our wording to explicitly allow it? Your clarity and directness would be welcomed. CapnZapp (talk) 12:02, 6 January 2026 (UTC)

Option 2 is my preferred, regardless of how the current guideline might be interpreted. Templates like {{further}} and {{main}} display §; section links everywhere in articles should be consistent with this for aesthetic reasons and so new readers only have to learn one convention. BTW, "§" is called the "section sign". Paragraph character refers to "¶". The wording should be corrected. -- Beland (talk) 21:51, 6 January 2026 (UTC)

Editors appear to have differing options, but at least we should be able to agree the current wording is sufficiently imprecise to allow different editors to interpret it differently. It thus appears my question was warranted. I should clarify I don't have a strong preference for or against hash mark section links. I wouldn't even mind the MOS leaving it up to local consensus. I do have a strong preference against policies and guidelines worded so vaguely as to be useless. If the MOS is saying something should be allowed or preferred, this should be clear. If the MOS is saying something should be disallowed or discouraged, again this should be clear. Even if the MOS wants to be silent on an issue, it's better to spell this out explicitly and say that the decision is left up to individual editors and/or local consensus.

My impetus for being here is seeing how unpiped links are excluded by our current language (whether intentionally or by accident through the fragmented nature of Wikipedia editing), yet H:SECTIONLINK starts off by explaining how to link to a section using this exact method. The slink template is only mentioned much later. If we were to agree hash marks should be discouraged from section links (which again, I'm not particularly arguing for, other than that the current wording of MOS:SL is difficult to read in any other way) I would like to make the slink method the prominent one, and relegate the HTML section linking URL fragment thingy to secondary importance for use outside article space only. That's really the only concern I have. As long as your consensus provides clarity one way or the other (or the third), I'm content. CapnZapp (talk) 12:13, 6 January 2026 (UTC)

H:SECTIONLINK doesn't start with how to make a raw section link, but with how to make a piped section link – admittedly you see that only thanks to the example, but then, examples always an important part of our instructions. Gawaon (talk) 12:18, 6 January 2026 (UTC)

(edit conflict) Sigh. If this is supposed to say "don't link to a section in another page without piping the link to avoid the ugly # character" please agree this could be said approximatelya gazillion percent more clearly... Is it so unreasonable to think the |Displayed text]] is there mostly "because" and for no particular reason? If you have edited Wikipedia for any length of time, you know it isn't an intrinsic/required part of the link syntax. The "basic syntax" doesn't have it, so it's very hard to see how it's supposed to be a clear requirement. Regards, CapnZapp (talk) 12:25, 6 January 2026 (UTC)

I agree with your wish for further clarification and I know that the section doesn't say such a thing. But the point remains that it doesn't show how to make unpiped section links either. People can easy guess that that works too, as indeed it does – but for all you know after reading just that section, if you omit the |Displayed text part, an "error: unpiped section link" message could appear. Gawaon (talk) 14:26, 6 January 2026 (UTC)

I really don't know where you're going with this, User:Gawaon. How does your point in any way help with the fact that reading that section gives zero solid clues you should avoid hash marked section links?If we can even assume that's intentional That the example casually omits unpiped links could easily be interpreted by many editors (certainly if they have minimal technical proficiency) as just saving some space and not repeated what "people already know works"... CapnZapp (talk) 16:19, 8 January 2026 (UTC)

It sounds like you both agree on option 2, so unless I'm missing some disagreement over the proposed change, it seems unproductive to quibble over the interpretation of a previous version? -- Beland (talk) 19:27, 8 January 2026 (UTC)

My worry was just that CapnZapp may accidentally be weakening his own case by leaving the impression that our help page gives unpiped section links a much more favourable treatment than it actually does, which could be interpreted as EDITCON in favour of keeping that favourable treatment. Hence my little comment to correct that impression – that was all, and I think we can consider it settled now. Gawaon (talk) 02:55, 9 January 2026 (UTC)

Given we seem to be heavily leaning in that direction, I've gone ahead and put the second version into the guideline. -- Beland (talk) 08:27, 9 January 2026 (UTC)

Thanks. I should note I stumbled upon Wikipedia:Manual of Style/Linking#Piped links to sections which was much more clear already. I've updated H:SECTIONLINK accordingly. Regards, CapnZapp (talk) 15:48, 9 January 2026 (UTC)

If I write People's Party for Freedom and Democracy (VVD) somewhere for the first time, is there a guideline specifying whether it should be People's Party for Freedom and Democracy (VVD) or People's Party for Freedom and Democracy (VVD)? I see both used, and I wondered if there were any rules. Dajasj (talk) 14:23, 8 January 2026 (UTC)

I'd use the former, it looks cleaner to me. And it has the advantage of not needing a piped link. Gawaon (talk) 14:54, 8 January 2026 (UTC)

I'd also prefer the former (abbreviation after link), and I'd guess it's more common. But that's just my opinion and gut feeling. I'm not aware of any guideline. — Chrisahn (talk) 16:14, 8 January 2026 (UTC)

Chrisahn provides the answer you're looking for, Dajasj, and that answer is "no": and if there is no such guideline, that means policy leaves it open to you (and other contributors to a particular article or sentence) to agree what works best in each case. CapnZapp (talk) 16:21, 8 January 2026 (UTC)

The former (w/o abbrev). MOS:MORELINKWORDS doesn't apply here. —Bagumba (talk) 19:03, 8 January 2026 (UTC)

This seems a poor example because "tournament of chess" sounds unidiomatic and almost wrong. ~2026-49881-2 (talk) 10:22, 23 January 2026 (UTC)

Yeah, that's terrible phrasing that no one who is actually literate in English would use. oknazevad (talk) 15:33, 23 January 2026 (UTC)

I concur. I don't think I've ever heard that formulation. DonIago (talk) 17:01, 23 January 2026 (UTC)

It's only a possibility to "consider", according to SOB. So, is this discussion going anywhere? Gawaon (talk) 17:09, 23 January 2026 (UTC)

Why are even linking the word tournament? It it was describing what type of tournament (round-robin tournament, double-elimination tournament, single-elimination tournament, etc) sure. Lee Vilenski ^{(talk • contribs)} 17:22, 23 January 2026 (UTC)

It's just an example. If you can think of a better example to use here, just suggest it. Or course, adding a suggestion like "or link just the term that's most relevant in the given context, such as chess" would be possible too and may be quite sound advice. Gawaon (talk) 08:24, 24 January 2026 (UTC)

... adding a suggestion like 'or link just the term that's most relevant in the given context, such as chess': Except we'd still need a replacement example in which adding a word of two is preferable when two or more consecutive terms are important enough to link. —Bagumba (talk) 08:10, 28 January 2026 (UTC)

It's also a bad example 'cause like... chess tournament exists as a page and is what the user should be linking instead of chess + tournament right? 𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 (talk) 10:11, 28 January 2026 (UTC)

Hi, a consensus is needed on whether to de-link "Ukrainian SSR" in Volodymyr Zelenskyy's infobox. Could you guys please share your thoughts at Talk:Volodymyr Zelenskyy#De-linking "Ukrainian SSR" in infobox? Thanks in advance, Thedarkknightli (talk) 19:28, 27 January 2026 (UTC)

There's an RfC for a related question ongoing at Wikipedia:Village pump (miscellaneous)/Archive 87#RFC: Baltic bios infoboxes question. While not explicitly targeting the Ukrainian SSR and other non-Baltic SSRs, its outcome should be relevant for how to present other SSRs in infoboxes too, especially regarding the question of which parts to link. (Its options F and G are inapplicable outside the Baltics, I guess, but the others would generalize smoothly to all SSRs.) Hence you might want to voice your opinion there, share the link to it on the talk page in question, and otherwise wait for its results before tweaking the page accordingly. Gawaon (talk) 21:30, 27 January 2026 (UTC)

Now that Wikipedia_talk:Manual_of_Style/Linking#Possessive_Redirects_vs_Blended/Agglutinated_Links has closed with a definitive preference for [[Foo]]'s, explicit guidance should be added to the MOS. Thoughts on the best way to do this? Perhaps a new subsection under Wikipedia:Manual of Style/Linking § Specific cases? I've played around with simple guidance and I don't really like any wording I've come up with. —Myceteae‍🍄‍🟫 (talk) 21:33, 28 January 2026 (UTC)

And to be clear, someone should feel free to just boldly update this! —Myceteae‍🍄‍🟫 (talk) 21:50, 28 January 2026 (UTC)

A whole subsection would surely be overkill. One option might be to add it as a new list item to MOS:LINK#OTHER. I guess you meant "Specific cases" instead of "Special" ones, but it's not really a specific case, as such possessive links can emerge fairly naturally in normal text and for most kinds of links. Gawaon (talk) 21:52, 28 January 2026 (UTC)

Yes, I meant "Specific" cases. Will fix. —Myceteae‍🍄‍🟫 (talk) 22:00, 28 January 2026 (UTC)

Crud, I just realized that the following example of a WP:PIPEd link was not brought up during the discussion. Is it assumed this is true?

[[Foobar (thing)|Foobar]]'s > [[Foobar (thing)|Foobar's]]

...Or do we have to have another discussion? Steel1943 (talk) 22:09, 28 January 2026 (UTC)

No, we won't have another discussion of that, the left one wins now, as a matter of course. That doesn't mean we need to explicitly mention it, on the other hand – it might rather go without saying. Gawaon (talk) 22:13, 28 January 2026 (UTC)

My thoughts as well, and was about to also bring up an example like:

[[George Washington|Washington]]'s > [[George Washington|Washington's]]

...But yeah, my thoughts as well. Steel1943 (talk) 22:17, 28 January 2026 (UTC)

@Gawaon: "mean"? Steel1943 (talk) 22:20, 28 January 2026 (UTC)

(Resolved, nothing to see here...) Steel1943 (talk) 23:15, 28 January 2026 (UTC)

This says that the preference confirmed here is better so I don't see that anything needs to be changed, although I would strengthen it so the consensus to not use Foobar's is clear. Also I can't find that example in the current version of Wikipedia:Piped link using Cmd+F. But if there are random examples there or on other pages (like Help:Link) those should be reviewed and updated to align with the current MOS consensus. The MOS guidance, once updated, and/or the RFC can be referenced in the edit summaries. There's no need for another discussion unless there is a new conflict or question that is not adequately resolved by the just-closed discussion. I do agree it would be good to have a piped example like you have with Washington's. —Myceteae‍🍄‍🟫 (talk) 22:38, 28 January 2026 (UTC)

How about adding a bullet point to MOS:PIPESTYLE:

* Possessives. [[apple]]'s should be used in preference to [[apple's]] (which would require a redirect to be created at Apple's), unless the 's is part of the article title (e.g. Jacob's). This also applies to piped links such as [[George Washington|Washington]]'s.

Rosbif73 (talk) 10:40, 29 January 2026 (UTC)

Sounds good, though actually no piping is involved here, except for the "Washington's" case. Hence it rather add it to MOS:LINK#OTHER. Gawaon (talk) 11:12, 29 January 2026 (UTC)

Also it should be "in preference to [[apple|apple's]]or [[apple's]] (the latter would require ..." Gawaon (talk) 11:15, 29 January 2026 (UTC)

 Done: see diff . Feel free to further refine the wording if necessary. Rosbif73 (talk) 12:38, 29 January 2026 (UTC)

A cross reference from somewhere in MOS:POSSESSIVE / MOS:'S would be useful. Anomie⚔ 12:50, 29 January 2026 (UTC)

 Done: see diff . I realise that this has created two hatnote lines, but (a) it doesn't seem to be possible to use a piped link with {{for-multi}} and (b) there are already MOS sections with two hatnote lines. Rosbif73 (talk) 13:56, 29 January 2026 (UTC)

Looks good! —Myceteae‍🍄‍🟫 (talk) 14:38, 29 January 2026 (UTC)

For what it's worth, a few days ago, I created MOS:POSLINK as a redirect towards an anchor for that new guideline. Steel1943 (talk) 20:34, 1 February 2026 (UTC)

I saw that, thanks for doing this @Steel1943! Sadly for me I noticed this after making several edits and using the less specific shortcut MOS:LINK#OTHER. Happy to have a more direct shortcut moving forward! —Myceteae‍🍄‍🟫 (talk) 20:58, 1 February 2026 (UTC)

Just a query now, but if needed perhaps MOS:GEOLINK needs to be reworded: I have recently seen links to city articles removed from event infoboxes (e.g. MLS Cup 2022) because the stadium/venue is allegedly enough to provide context. In my view it does not, as many stadiums (especially in the U.S.) are in suburbs that are not well-known outside of their immediate area and providing that context would be helpful to readers. There seems to be an interpretation of MOS:GEOLINK that counts a stadium as part of the "consecutive comma-separated sequence of two or more territorial units" despite stadiums not being a geographical/territorial unit. I think we ought to remedy this, as there are thousands of articles that already use the format. SounderBruce 07:12, 5 February 2026 (UTC)

Why would you link the suburb, let alone a well-known city. In any case, a link to the stadium anchor will give the reader all they want. Tony (talk) 09:00, 5 February 2026 (UTC)

Wouldn't you normally use a connecting word such as "in" in such cases ("Banc of California Stadium in Los Angeles, California, United States")? GEOLINK only applies to comma-separated sequences, hence it will only apply after the connecting proposition, as it should. Linking Los Angeles may nevertheless be overlinking in this specific case, but that's unrelated to GEOLINK. Gawaon (talk) 09:22, 5 February 2026 (UTC)

Wouldn't you normally use a connecting word such as 'in' in such cases: The OP was referring to infoboxes (and the same might apply to tables). In sports, some readers might want to know the details of the stadium/venue, while others might just care about the geographic location. That's why some pages choose to present both, and not force the reader to click on the venue just to get to the city. —Bagumba (talk) 06:23, 8 February 2026 (UTC)

Right, in the infobox only the stadium or other actual venue will be linked in such cases, if GEOLINK is strictly followed. Seems fine to me, since people mainly use the infobox to gather facts, not links (I suppose), and since the link to Los Angeles or wherever the event took place can still easily be found in the lead paragraph nearby. Gawaon (talk) 08:52, 8 February 2026 (UTC)

It's fine to link both the venue and city in infoboxes and tables. Seeing something like Intuit Dome (Inglewood, California), a reader can either click on the venue, or just Inglewood if they just wanted to know where geographically the event was without caring about the actual facility. Don't force a double click; thousands of pages already have this format.—Bagumba (talk) 09:27, 8 February 2026 (UTC)

Yeah, that's possible too and in perfect agreement with GEOLINK. Gawaon (talk) 09:56, 8 February 2026 (UTC)

Possible, but a disservice to readers: the Intuit Dome article (far more specific) has ALL of the information you could want about its location. Tony (talk) 10:34, 8 February 2026 (UTC)

That is a fine solution, and I'll bring it up at WT:FOOTBALL. Definitely prefer to have both the venue and city linked, but without "in", which would be out of place in an infobox row. SounderBruce 03:24, 10 February 2026 (UTC)

It's not a fine solution at all, as I've pointed out above. Tony (talk) 06:36, 10 February 2026 (UTC)

And as also pointed out above, some could care less about the facility and just want to figure out where it is, e.g. is it a home or away game? —Bagumba (talk) 08:28, 10 February 2026 (UTC)

Hi, there's an ongoing dispute over whether to link "Russia" in the body of Lena Katina's article. Could you guys please share your thoughts at Talk:Lena Katina#Overlinking? Thanks in advance, Thedarkknightli (talk) 22:07, 19 March 2026 (UTC)