This page falls within the scope of theWikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across theManual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style
This page may fall under thecontentious topics procedure and be given additional attention, as it may be closely associated to thearticle titles policy andcapitalisation. Both areas are subjects of debate. Contributors are urged to review theawareness criteria carefully and exercise caution when editing.
There are two common ways to link to a place name with an "A, B, C" format where the article is titled [[A, B]]. Both can be read as fair interpretations of the guidance to "link only the first unit".
Have the link span only the smallest unit, using piping if necessary
Which style(s) is/are acceptable? If both, is one preferable to the other?
Note: See previous discussionabove andabove. This isnot a question about whether "New York" should be linked toNew York (state) in this example; basically everyone agrees that it should not be. 20:57, 17 October 2024 (UTC)
Discussion re RfC: Linking of three-part place names
Both acceptable, approach 1 preferable. Approach 2 is, no doubt, more common, but both approaches are used in good and featured articles without issue. As a matter ofMOS:RETAIN I'll stop short of saying approach 2 should be proscribed, but I think approach 1 is preferable for two reasons:
Consistency: Having a prose guideline turn on the title of the article being linked to would be strange, given that the article title policy is informed by various considerations that do not apply to prose, such as disambiguation and the semi-arbitrary rule that isWP:USPLACE. To a reader seeing "Buffalo, New York, United States", next to "Boston, Massachusetts, United States", it is not at all obvious why the two are handled differently. It is cleaner and simpler to have the link span the exact place being referenced, not attached disambiguators like ", New York".
Accessibility: The only difference between "Buffalo, New York" and "Buffalo,New York" is the color of the comma. For anyone who, like me, struggles to distinguish between blue and black in small quantities, it looks like clicking on "New York" in the first example will take you toNew York (state).
The main argument made in the opposite direction is simplicity of markup, but that's usually the lowest priority in MoS decisions, certainly lower than accessibility. We should not make our articles more confusing to readers just for the sake of slightly shorter source code. --Tamzin[cetacean needed](they|xe)20:57, 17 October 2024 (UTC)[reply]
None -- I struggle to understand why itwouldn't be necessary to link the first-level administrative division, in most cases outside the US (and even the US as well, but let's assume thatBuffalo, New York is an accepted practice in that context).Who could be expected to considerIalomița County orSimeulue Regency instantly recognizable terms across the vast expanse of the world? and if we're not linking unfamiliar terms, what is the point of having internal links at all? Seems like someone was peeved by having two links next to each other, and came up with this atrocious moratorium on having necessary links where they appear side by side (though neatly separated by a comma); this bewildering approach should not have been tried outat all,ever.Dahn (talk)21:10, 17 October 2024 (UTC)[reply]
The normal argument against linking the second-level entity is that it can be easily clicked from the first-level, if some wants. As discussedabove, exceptions may apply when the first-level entity's article doesn't prominently discuss the second-level one, mostly in the case of former countries. --Tamzin[cetacean needed](they|xe)21:17, 17 October 2024 (UTC)[reply]
The exceptions are in fact the norm -- most subdivisions would be unfamiliar to anyone outside that country. Which is why "Buffalo, New York" is a misleading example, the sort of which has prompted some overzealous users to delete links toOlt County andWallachia, thus leading to the absurd suggestion that Olt County has the same notoriety as New York, and Wallachia is a notion similar to the US. "It can be easily clicked from [somewhere else]" can be said about each and every bluelink out there, so I don't see why that was ever accepted as a valid argument in any debate.Dahn (talk)21:32, 17 October 2024 (UTC)[reply]
Option 2 perMOS:SPECIFICLINK. It's also a normal unpiped link, without superfluous text: compare[[Buffalo, New York]], United States (five words) with[[Buffalo, New York|Buffalo]], New York, United States (eight words). --Redrose64 🌹 (talk)22:13, 17 October 2024 (UTC)[reply]
Option 2 because it's shorter to write and leads to linked text and linked page title being in agreement.Later addition: Also perWP:NOPIPE, as pointed out below byBagumba – don't use piped links when you don't have to, and here you very clearly don't have to.Gawaon (talk)08:55, 18 October 2024 (UTC),edited 07:55, 19 October 2024 (UTC)[reply]
Both acceptable, do not specify preference for either. I personally prefer Option 2, which cuts down on redundant text that looks extremely silly in the editor and in diffs. I suppose it also matches linktext with article titles, which I care less about. I don't think we should enshrine a preference for best practice here. Agree with others above that in many cases it may be helpful to link multiple administrative subdivisions: not long ago I had reason to mentionYao Mangshan Ethnic Township (莽山瑶族乡),Yizhang County,Chenzhou, Hunan. Leaving out the container state, that's still four subdivisions. I leftHunan unlinked since it appears inUser:Ohconfucius/script/Common Terms, but there are probably editors who would argue for linking that as well.Folly Mox (talk)09:52, 18 October 2024 (UTC)[reply]
Option 2 In this specific format, it seems more intuitive to match the title of the article. I will also add that including the non-linked country at the end may be somewhat out of place/redundant in either option.Symphony Regalia (talk)14:38, 19 October 2024 (UTC)[reply]
No preference. MOS should state this. I fully agree with Folly Moxhere and would go one step further to say the style guide should be explicit in stating there is no dictated preference. It should list some things to consider, provide examples, and otherwise defer to editorial judgment. Things to consider might includeMOS:NOPIPE and other rules or guidelines. A lot of this will come down to context-specific factors and personal judgment or consensus within an article. In nearly all cases it matters too little to mandate a single standard and doing so will likely result in more appeals for exceptions and workarounds.MYCETEAE 🍄🟫—talk22:03, 19 October 2024 (UTC)[reply]
Option 1, but both acceptable, per Tamzin andlink intuitiveness. I don’t want people clicking “New York” and being confused at being sent to Buffalo. I also think all arguments based on what looks best in wikitext or is easier to type for the editor are wrong. Style decisions are not made for the wikitext editor’s benefit.— HTGS (talk)00:50, 23 October 2024 (UTC)[reply]
I don’t want people clicking “New York” and being confused at being sent to Buffalo: But that is exactly why we avoid consecutive links to begin with i.e. SOB. It is a single link to <city, state>, not consecutive links <city>, <state>. —Bagumba (talk)04:37, 24 October 2024 (UTC)[reply]
Right. Readers have no reason to expect that "New York" won't link to New York there: They don't know that MoS says it shouldn't, and in practice countless articleswould link to New York there. Using a different state because the NYC/NYS ambiguity complicates things, there are11,030 articles containing either[[Boston]], [[Massachusetts]] or[[<someplace>, Massachusetts|<someplace>]], [[Massachusetts]]. These links are distinguished from e.g.[[Boston, Massachusetts]] by the color of a character that is less than a millimeter wide at standard zoom. --Tamzin[cetacean needed](they|xe)00:20, 27 October 2024 (UTC)[reply]
Single linkIn almost every case the purpose of the link is to take you to the article of a single, unambiguous, location. The link should be written in it's natural format (no piping). The larger regions are merely so that a printed form will lead you to the same place but we don't really expect the reader to want to go directly to the articles for the larger regions - ie, we are listing a city for a reason, the larger regions are just to make it unambiguous and are not a target in their own right. So, we give the link to the city in its natural format (without piping), and then add whatever else is needed in plain text. If it turns out that some cities in a list have the link encompass different portions of the hierarchy (egParis, France vsParis, Ontario, Canada) then that is okay. Stepho talk01:21, 23 October 2024 (UTC)[reply]
Ooh, Ireally disagree with that last point. I’d rather a list be consistent regardless the choice between these two options.— HTGS (talk)03:01, 23 October 2024 (UTC)[reply]
Assuming it’s a normal prose sentence, I would have something like:“However in 1894, the government ofParis, France decided to implement the change, while the mayor ofParis, Ontario forced the city to withhold …” But honestly I would still rather the opposite (…Paris, France decided to implement the change, while the mayor ofParis, Ontario did not…”) to the split styling you suggested.— HTGS (talk)21:40, 24 October 2024 (UTC)[reply]
I agree, but note that what you describe is in fact exactly Option 2 ("Have the displayed text match the title of the linked article"), so you're effectively voting for that.Gawaon (talk)07:23, 23 October 2024 (UTC)[reply]
the larger regions are just to make it unambiguous and are not a target in their own right: I'm not sure if "unambiguous" is the right word. For a large country, most people have never heard of most non-major cities, so a larger region is mentioned to provide context, whether or not the same city name exists in another region.—Bagumba (talk)04:48, 24 October 2024 (UTC)[reply]
DefinitelyOption 2. No pipe gymnastics needed, and the blue the reader sees tells him unambiguously where clicking will take him.EEng00:33, 27 October 2024 (UTC)[reply]
Comment: Hi folks. I came here to raise a closely related point, then I saw this discussion and the previous ones. I think the examples should be changed to allow or encourage this type of thing:
That is, in many cases it's preferable to be consistent with how the links are presented, and in my view it's *not* necessary to have the visible linked text exactly match the article titles. So in this example I've coded[[Chicago|Chicago, Illinois]] to achieve that. Although coding[[Chicago, Illinois]] would achieve more or less the same thing, because "Chicago, Illinois" is a redirect to "Chicago". Edited to add: This suggestion does not match either option 1 or option 2.—Mudwater (Talk)01:55, 26 November 2024 (UTC)[reply]
At least correct the description of what is recommended: To me, it isfalse to say "Both can be read as fair interpretations of the guidance to 'link only the first unit'." In the string "Buffalo, New York, United States", there are clearly three units, and the first of those three units is "Buffalo". If we're going to say that "Buffalo, New York, United States" ([[Buffalo, New York]], United States) is the preferred format, we need a different characterization than saying that for "a sequence of two or more territorial units, link only the first unit". For example, we could say to "link only as much of the name as is used in the corresponding article title" or "link only the initial parts of the name that form its conventional identification". (We might also need to refer the reader toMOS:USPLACE for the conventional form of US location descriptions). — BarrelProof (talk)01:06, 3 January 2025 (UTC)[reply]
Comment: In most casesno one is ever going to link to "Terre Haute", as suggested above, just because the subject was born there. Who cares? (Unless that town had significant bearing on the notability of the subject.) So often we are faced with the logic of not linking because of insufficient relevance, or because the location is internationally known: the smaller and least consequential "village" ("Terre Haute") vs the too-well-known larger location ("Chicago"). In that case, nothing seems to need linking. Another example: "suburb of London, London, UK"—link nothing, unless the suburb has sufficient relevance to the subject (unlikely).
Thereare cases that could be linked as a matter of logic. Let's say the formative years were spent in the village of birth:Adalaj, Gujarat, India. Here, the article on Adalaj will reasonably contain a link to Gujarat, if the reader really wants to know more about the state. Remember that the one in 10,000 readers who really do want to know more, in situ, can spend 10 seconds typing a target into the search box. Otherwise we have systemic bunching, which MOSLINK discourages for good reason.Tony(talk)23:42, 17 January 2025 (UTC)[reply]
I'm fairly sure we have decided in the past to only visibly link to the smallest unit. The reason being that the difference between a link to the smallest unit and it's next superunit, and two links is merely the colour of the comma between the two place names. People will click on the superunit expecting to be taken there, and get aWP:Easter egg. I have done this myself. The priority needs to go to the reader, not the editor here. If you prefer less typing, go ahead, but don't oppose others improving it. All the best:RichFarmbrough20:34, 1 March 2025 (UTC).[reply]
"I'm fairly sure we have decided in the past" is very much a weasel phrase. Assuming we did, supposedly there would be a rule somewhere that says so?Gawaon (talk)12:52, 2 March 2025 (UTC)[reply]
I might leave it for at least a few days, as the discussion seems to be picking up a bit. But if it quickly dies down, probably.Graham11 (talk)03:55, 5 July 2025 (UTC)[reply]
unfortunately there's no way i can parse these semantics as [...] "an association list consisting of zero or more name-value groups (a description list)."
I know, but<dd> is used on project pages since it's the best way to apply this kind of formatting. I can't remember where that's documented, but there are plenty of examples, like on this page itself under§ Syntax, orTemplate:Citation needed § Example 2.
Sorry, I see how my attempt to just copy-paste directly from the HTML standard intending to be clear came off as obtuse. These colons inwikitext createHTML description lists (<dl>...</dl>) – with line-beginning semicolons generating the names and line-beginning colons generating the values for said names – famously, we already naughtily ignore the intended semantics of said lists for our threaded discussions, but e.g.MOS:BADINDENT makes it clear how using them merely for their visual effect of horizontal indentation is incorrect.Remsense 🌈 论17:39, 25 August 2025 (UTC)[reply]
The intended use is somewhat familiar to editors, and looks like
InApplesApples, you can readThis redirect link is used for convenience; it is often preferable to add the plural directly after the link (for example,[[link]]s). However, do not replace these redirected links with a simpler link unless the page is updated for another reason (seeWP:NOTBROKEN). As far as I understand, the second sentence is motivated byMOS:VAR that applies when the change is the only object of the edit.D.Lazard (talk)17:01, 10 September 2025 (UTC)[reply]
Link targets should generally be singular nouns, noun phrases, or gerunds. It's bad form to link to plural nouns, adjectives, etc. (Regardless of redirects.)--Srleffler (talk)01:58, 11 September 2025 (UTC)[reply]
However, we also have the situation where the article title is plural and the singular redirects, e.g.Aztec redirects toAztecs. In such cases, both[[Aztec]] and[[Aztecs]] are fine, but writing[[Aztec]]s would be a bit odd. I think it makes sense to point this out, but am not sure how to do so in a concise way.Gawaon (talk)07:19, 11 September 2025 (UTC)[reply]
There is an article on which someone posted on the talk page that a (brief) level 2 section is confusing because not only do many of the previously mentioned names have links to their articles, many leave out the given name as well, requiring a good deal of effort on the editor's part to figure out what is going on. This comment has been receiving a good deal of resistance on the talk page; I happen to agree with the OP and think "Link a term at most once per major section (Major sections are generally detailed sections with a level-2 heading...) , at first occurrence." suggests that they are not incorrect, but I would like clarification here if any can be offered. Thanks...Tduk (talk)18:42, 13 October 2025 (UTC)[reply]
The core issues on that page are unrelated to LINKONCE. For example, "Ryan" isn't even linked once elsewhere in the article because that person isn't even notable.Johnjbarton (talk)16:50, 14 October 2025 (UTC)[reply]
Linking once in each level-2 section is explicitly allowed by our current policy even if the same article was already linked in earlier sections, so I don't understand what's the issue here?Gawaon (talk)07:40, 14 October 2025 (UTC)[reply]
The issue was that the section did NOT link once, and did not include the full names of the people involved, so it was very confusing if one is looking only to read that section. If this is the expected norm, where do I raise an issue with this - because not only is it difficult for those readers, it creates some accessibility issues, requiring the reader to do more work than I think is necessary.Tduk (talk)13:19, 14 October 2025 (UTC)[reply]
MOS:LINKONCE doesn't say that all terms should or must be linked in every major section in which they appear, nor is that our practice, nor do we privilege that hypothetical reader who dives into the middle of an article, expects everything to be made clear there and then, and is unwilling to scroll up even if fully understanding some later part of an aricle would be helped by reading an earlier part.NebY (talk)14:00, 14 October 2025 (UTC)[reply]
Are there use case studies to back up your implication that most people who read wikipedia read the entire article in one sitting? Setting aside the accessibility issues for now.Tduk (talk)14:53, 14 October 2025 (UTC)[reply]
What is your implication from "nor do we privilege that hypothetical reader who dives into the middle of an article, expects everything to be made clear there and then, and is unwilling to scroll up even if fully understanding some later part of an aricle would be helped by reading an earlier part."?Tduk (talk)15:27, 14 October 2025 (UTC)[reply]
@NebY: We literally have architecture to force a reader to dive into a particular part of a section and skip over the rest of the article:{{Anchor}}. The culture of linking to specific parts of a page has gotten so bad thatTemplate:ATA shortcut notice had to be made for our own internal policies to remind people to read the start. If you want a case study, just look at how we can't even get editors who should know better to read the start of pages and somehow we're expecting this of our readers? Without even any tooltip that we've dumped them in the middle of an unfamiliar land? I think that's unfair. –Mullafacation『talk』17:11, 15 January 2026 (UTC)[reply]
Since the MOS allows, but doesn't not require wikilinks to be repeated once per major section, this doesn't seem a MOS issue at all.Gawaon (talk)15:40, 14 October 2025 (UTC)[reply]
Always subst the anchor template within a section header?
Sure, but that's not what I'm asking for,Gawaon. I'm asking for the discussion or discussions where the current consensus was hashed out, where - I imagine - each approach's disadvantages (and advantages) were weighed against each other, before the current prescribed approach was selected.CapnZapp (talk)09:23, 19 October 2025 (UTC)[reply]
The consensus in that discussion seems to be against substitution of the anchor template within the section heading. The discussion also doesn't include contemplation of putting the substituted span in the headingbefore the heading itself.
I'm starting to wonder if we walked step by terrible step into an awful solution without ever having a discussion and arriving at a consensus. The current recommendation may work well technically and for readers, but isawful for editors:
=== <span></span><span></span><span></span><span></span><span></span>Administrators and bureaucrats ===
Just to quickly say that at the very least, let us discuss this proposal separately. Personally I find the ability to safeguard incoming section links so they keep working even if well-meaning editors rename sections is crucial. But again, please let us have that discussion separately. CheersCapnZapp (talk)11:07, 20 October 2025 (UTC)[reply]
That discussion was about editing the documentation of a template, which isn't a guideline, to align it with a guideline thatalready existed. The actual consensus was likely formed on the various policy pages which recommended the practice of subst'ing the template even before that discussion took place. These are the ones I could find:
The guidance to substitute the templateif it was in the heading has been well established. What I haven't seen yet is the origin of the mandate that itmust be substed in the headingbefore the text of the heading. In the discussion linked above, nobody was discussing that as an option, and there was clearly not agreement on mandating it having to be in the heading at all.
WP:TARGET said to put the anchorafter the section name until it wasedited by you, again in August, as a "Bold edit inspired by User:Redrose64's comment on {{Anchor}}'s talk page"
The relevant comment appears to be at the end ofTemplate talk:Anchor, in the section "Are we sure WP:ANCHORSUBST is a good idea?" Other editors in that discussion favored options other than including the anchor in the heading; there was no consensus there for Redrose64's suggestion.
So, it appears that this change didnot come from a consensus or from the MOS but rather was boldly inserted into both the MOS andWP:TARGET by you based on one editor's comment. I know you meant well here, but it's time to stop and look at where we ended up and decide whether we took a wrong turn. --Srleffler (talk)02:44, 20 October 2025 (UTC)[reply]
I've said it before, and I'll say it again: accessibility. Users ofscreen readers rely on anchors to be at the point from which reading should commence. Consider a section heading: if the anchor is after the heading, or even within the heading but after the heading text, the screen reader softare will not read out the heading text, but will begin with the text that follows the heading. Therefore, the anchor must be inside the heading and also before the heading text, so that the latter is read out.
A wider discussion on this may be needed but I think thatbanning section anchors altogether is a tad bit too extreme. I would fully support a bot that would do this though!FaviFake (talk)15:37, 20 October 2025 (UTC)[reply]
I'm starting to wonder if we walked step by terrible step into an awful solution without ever having a discussion and arriving at a consensus. This isexactly why I asked for previous discussions as my first step...! :-)CapnZapp (talk)10:48, 20 October 2025 (UTC)[reply]
I fully agree that the current recommendation/prescription is awful for readers. I fully understand how the current recommendations could have come to be; editors active in these discussions definitely lean towards the tech savvy (and tech tolerant) side of things, I know, because I am one myself. However, what cannot be taken for granted is technical experts' ability to accurately judge what regular people will accept when it comes to jargon or code. It is a complete disservice to readers, simply put. My first instinct, before realizing how we might have gotten here, was to simply (and boldly) replace the current recommendation, recommending transclusion instead of substitution because the only reason given against it, "it messes up edit summaries", to me appears much much more tolerable to the average reader (but crucially looks ugly to tech-savvy editors). After all, regular web users are able to replace the prefilled contents of the edit summary text box if they don't like it. For instance, the prefilled contents of the edit summary for THIS post is long: "/* Consensus for the current recommendation to always subst the anchor template within a section header */" I do not believe it is nearly as confusing for a reader to just mark that text before writing their edit summary - replacing the existing text altogether - to avoid it being so long. (If you look at the edit summary of this post it will read simply "my own view" just to demonstrate). In contrast, asking average readers to tolerate HTML comments and to know enough to disregard them without worrying you've done something wrong, is just not a reasonable ask of the average Wikipedia reader. RegardsCapnZapp (talk)11:03, 20 October 2025 (UTC)[reply]
Just for the record, it seems like bad advice to me. We should avoid having any more html or css in articles than absolutely necessary. All the best:RichFarmbrough11:39, 20 October 2025 (UTC).[reply]
I think we can all agree the current method isn't great. The question is, what should it be changed to? Or rather, which of tradeoffs listed atWP:ANCHORSUBST should we accept just to have better wikicode readability?FaviFake (talk)16:45, 20 October 2025 (UTC)[reply]
Not commenting on the rest, but the problem listed atWP:ANCHORSUBST isn't that "it looks ugly". It's more functional:
If it is not manually removed every time, the browser may not return the user to the section and the section link of that edit in the history page will be broken.
I don't actually understand why I should care about that. Being automatically returned to the section you just edited and having a link to the section in the history seem likereally trivial conveniences to me; hardly worth worrying about. Having headers that start with a line or two of HTML gobbledigook seems like a much bigger problem. --Srleffler (talk)04:49, 21 October 2025 (UTC)[reply]
"having a link to the section in the history" Is not just about convenience, it's also about telling folks who view the history what part of the article was changed (without them having to open up the edit to see). That is a non-trivial time-saver for history-viewing editors. -Butwhatdoiknow (talk)12:58, 21 October 2025 (UTC)[reply]
I don't think that's relevant. Even if the anchor is transcluded, the edit summary will still accurately describe what section was edited. It just won't provide a functional link to it. A minor inconvenience, but not a loss of information about what part of the article was changed.--Srleffler (talk)04:00, 22 October 2025 (UTC)[reply]
If someone edits multiple single sections of an article, it would be more annoying if the software sent them to the top of the page every time they clicked publish rather than if they took 1 more second to read the name of the section. In my opinion, at least.FaviFake (talk)15:54, 21 October 2025 (UTC)[reply]
In my experience, using section links from my watchlist or a history page is something that happens multiple times every day. I would prefer to keep that functional. I very rarely edit section headings—maybe once a month or so—and I've probably only edited a heading that includes the gobbledygook a dozen or so times ever. We generally prefer to simplify wikitext where possible, but functionality is more important. I hadn't thought before about whether anchors should come before or after the current heading, but it seems like after would be more editor friendly. I'm sorry if I've missed the reasons for preferring it the other way around.Firefangledfeathers (talk /contribs)15:04, 21 October 2025 (UTC)[reply]
Sounds like the summary regarding location is:
Before the heading: Pros: Links to a good place. Mostly sensible wikitext. Cons: Doesn't open the collapsed section on mobile. Not visible in section editing.
Inside the heading, before the text: Pro: Most functional for screen readers and mobile. Con: Ugly wikitext. If not substed, breaks auto-summary links.
Inside the heading, after the text: Pro: Somewhat less ugly wikitext. Con: Screen readers don't read the heading text. If not substed, breaks auto-summary links.
After the heading: Pro: Sensible wikitext. Cons: Link puts the heading off the top of the screen. Screen readers don't read the heading.
I don't think this discussion relates to location. Rather, is is about whether anchors placed inside the heading should be transcluded or substituted. To learn about the difference, see the first two paragraphs ofWikipedia:Substitution. -Butwhatdoiknow (talk)20:53, 21 October 2025 (UTC)[reply]
It's more than both those things. It's about "always subst"and "within the section heading"and "at the start of the header". What triggered this discussion wasa change made without consensus from "always subst within the heading,at the end of the heading" to "always subst within the heading,at the start of the heading". This change has negative consequences and was pushed out to multiple MOS and guidance pages by one editor in one day, with no discussion. So, location is very definitely a key part of this discussion. --Srleffler (talk)04:11, 22 October 2025 (UTC)[reply]
Yes, those are issues raised by the original edit, but are they issues pertinent to this particular discussion?
This section begins with the following sentence: "WP:ANCHORSUBST explains that inside section headers,{{Anchor}} should always be substituted (and not a number of alternative approaches)." The discussion that follows talks about transclusion vs. substitution when Anchor is placed inside a heading.
To avoid this already long discussion from dealing with too many issues at once, please raise other issues separately, perhaps by starting subsections from Transclusion vs. substitution. -Butwhatdoiknow (talk)06:12, 22 October 2025 (UTC)[reply]
The title of this section says (emphasis added) "for the current recommendation toalways subst the anchor templatewithin a section header". The "(and not a number of alternative approaches)" you quote encompasses the other positionings. Attempting to artificially limit the discussion isn't going to help.Anomie⚔12:59, 22 October 2025 (UTC)[reply]
Yes, and noteWP:BRD. Bold edits are often summarily reverted. I have not done that, preferring to bring this issue to a discussion first. I have emphasized that this was a bold edit, made without consensus, because I want it to be clear that the mandate to put the substed anchor at the start of the heading isnew, and not something that has been discussed before. --Srleffler (talk)06:09, 24 October 2025 (UTC)[reply]
Comment: While I prefer another recommendation, I considerFaviFake's change to be a perfectly reasonable bold edit. He hardly edited "without consensus." For whatever this is worth, I consider us to be in the BRD cycle, except without the R step (now that we're discussing).CapnZapp (talk)14:47, 22 October 2025 (UTC)[reply]
Transclusion v. Substitution for anchors placed in headings
Anomie's summary covers multiple issues. I have amended the heading of this subsection to clarify that it only deals with Anomie's "If not substed, breaks auto-summary links" issue (which, as my summary shows, is not a complete statement of that issue). -Butwhatdoiknow (talk)06:18, 22 October 2025 (UTC)[reply]
Thanks for this summary of the various options. Based on it, it seems clear to me that the recommended status quo (substed at start of heading) is indeed the best solution. It has one downside (ugly and hard-to-understand wikitext) but that one's less severe than the downsides of the alternatives, which would all entail loss of important functionality for either editors or readers, especially readers relying on screen readers.Gawaon (talk)06:39, 22 October 2025 (UTC)[reply]
Hold on, is that really a genuine representation of the situation. You are, if I'm understanding you correctly, making the following claims. Let's discuss each one separately:
Location inside and at the start of heading. I have no issues with this. It is the best (or least worst) location option.
The downside isn't merely "ugly and hard-to-understand wikitext". For starters, it isn't regular wikitext (H:MARKUP), it's pure CSS code (part ofH:HTML)! Presenting editors (including newbies) with straight up programming code is in my view not an acceptable downside. It is the reason I'm starting this entire discussion. Experienced editors and coders (like the majority of you participating in this discussion?) very likely severely underestimates how user-hostile this really is.
You aren't actually enumerating the downsides of the alternatives, which I really wished you would. If there's one I am forgetting about, you know why.
As for screen readers, the downside there appears to be related to the location of the anchor, not whether it's substed or not. Please don't argue for the status quo based on conflated arguments.
The downside that you're not taken directly to a section from page history or your watchlist (breaking edit summary links): While I don't use these links myself, I do acknowledge the usefulness of such a function, but I think sacrificing newbies for the convenience of experienced editors is the wrong way to go. (As an aside, edit summary links aren't even colored blue in the watchlist, meaning there is no visual indicator the edit summary contains a link unless you hover over it. This makes me suspect it isn't meant to be core functionality but more of an editor perk. We can live without editor perks, at least when it significantly decreases user hostility.)
All in all, I must confess I find your summary to have an unfortunate (and hopefully unintended) appearance of being geared towards making readers inclined to agree with it, rather than examining every aspect equally and neutrally. With respect,CapnZapp (talk)15:18, 22 October 2025 (UTC)[reply]
Are you addressing me orSrleffler? I was merely drawing my own conclusion from Srleffler's summary, which I'd consider fair and adequate. If one can get others to agree, that is, of course, always a welcome side-effect of expressing one's opinion (so certainly not "unfortunate" nor "unintended").Gawaon (talk)15:29, 22 October 2025 (UTC)[reply]
I indeed addressed you,Gawaon. If you have any objections to what I wrote, you are welcome to tell me about it (here or at my talk, whatever you feel is appropriate). Sorry about the indentation, our edits conflicted. CheersCapnZapp (talk)15:33, 22 October 2025 (UTC)[reply]
(edit conflict) Allow me to repost Srleffler's example from above. I wholeheartedly agree the following isawful for (new) editors, and I sincerely hope we can prioritize the new editor experience over some convenience shortcuts:
=== <span></span><span></span><span></span><span></span><span></span>Administrators and bureaucrats ===
I genuinely ask everybody to consider the choice we're about to make here not as a coder or experienced wikipedian, but as way to warmly greet new arrivals to Wikipedia. Best,CapnZapp (talk)15:31, 22 October 2025 (UTC)[reply]
This is indeed unpleasant to read, but having five anchors for the same section will in any case be very rare. Also I imagine that newbies using the source-code editor will fairly quickly learn to ignore the HTML stuff and focus on wiki-formatted content instead. There are other situations, such as tables with CSS styling, where the situation is the same.Gawaon (talk)17:24, 22 October 2025 (UTC)[reply]
Having 2+ anchors in the same section doesn't seem that rare to me though, and results in ugly, verbose, and unclear wikitext.Example.{{Anchor}} is very clear.<span></span> is unclear to most people that this is there to be an anchor, unless you're a web programmer or very familiar with how anchors work. –Novem Linguae(talk)17:40, 22 October 2025 (UTC)[reply]
A large number of anchors is only common on projectspace afaik. We shouldn't base our project-wide policies on issues affecting mostly projectspace pages.FaviFake (talk)18:55, 22 October 2025 (UTC)[reply]
Yes, tables are hard, but headers usually aren't. Bizarre code in them is perturbing even to moderately experienced editors like me; we might be deterred from rewording a section header - if we can even find it in all that - or we might even assume that we're looking at some weird glitch, clean away the entire mess and return the header to normal.NebY (talk)18:12, 22 October 2025 (UTC)[reply]
Yeah. In a way it also helps newer editors, as the VE hides old anchor HTML tags but displays templates. I think the status quo is the best option we have, but I agree it's not great.FaviFake (talk)19:01, 22 October 2025 (UTC)[reply]
I tried using VE to reword a header that had (invisibly to VE) an HTML anchor embedded between "==" and the wording. Doing that deleted the anchor. I tried it twice, once with anchor HTML code added directly and once with substititution, but I might have done something wrong; perhaps someone could check if that's repeatable.NebY (talk)19:51, 22 October 2025 (UTC)[reply]
Another reply toUser:Gawaon: "Because other things exist" is not a compelling argument. You focusing on the example being extreme is also not compelling; even a single substed anchor is one too many.CapnZapp (talk)09:55, 23 October 2025 (UTC)[reply]
User:FaviFake: If substed anchors only appeared in project space you might have a point, and I would indeed be willing to let the issue slide, since editing guidelines or help pages (etc) isn't critical to the new user experience. But it isn't - I'm here because our current guideline tells people to subst anchorseverywhere (you would know, because you made it say that). This definitely includes article space, where new editors will trip up on it.CapnZapp (talk)09:56, 23 October 2025 (UTC)[reply]
That remark is hardly fair, since the guidelines already said the same thing before FaviFake's edits (which were only about the exactplacement of the subst'ed anchors).Gawaon (talk)10:17, 23 October 2025 (UTC)[reply]
@CapnZapp I don't what you're replying to. I said[a] large number of anchors is only common on projectspace and you aren't talking about large numbers of anchors being common outside projectspace. Of course anchorsin general are used in the main space, that's why we have guidelines about using anchors.And, as Gawaon said, the assertion that Imade [the current guideline] [...] [tell] people to subst to subst anchorseverywhere is simply untrue. (emphasis in original)FaviFake (talk)14:18, 23 October 2025 (UTC)[reply]
CapnZapp: "even a single substed anchor is one too many" is your opinion, but an opinion isn't an argument either. I'd agree that it would in principle be better to avoid subst'ed anchorsif there was a good way of doing so, but considering the downsides of the possible alternatives, it seems to be the least bad alternative. Not ideal, but sometimes that's all one will get.Gawaon (talk)10:20, 23 October 2025 (UTC)[reply]
I wasn't trying to pass off my opinion as argument. I was pointing out that your reply to me repeating Srleffer's example focused solely on how it substed more than one template, not the basic fact substing leaves programming code in the edit window of regular editors. It doesn't need to be said, but you are obviously entitled to have and share your opinion. However, can I ask what you mean by "downsides"? That is, in plural? To the best of my knowledge, the sole argument so far for writing the guideline to exclude any alternative to substing is that section links (from watchlists and page histories) aren't broken.CapnZapp (talk)10:47, 23 October 2025 (UTC)[reply]
can I ask what you mean by "downsides"? That is, in plural? There are multiple, I've ce'd the section inWP:ANCHORSUBST to distinguish them:
[This is visual clutter. It annoys people who are browsing the edit history] The template call will appear in the edit summary each time the section is edited, like this:/* {{anchor|Transcluded anchor}} Basic format */.
[This is what you're saying] In watchlists and history pages, the clickable link to the section will fail to bring the user to the correct section, unless the template call is manually removed before the edit is published.
[This also affects functionality] After editors save an edit to a section, they are taken to the top of the page instead of to the section they just edited.
The forking of the discussion was made by Butwhatdoiknow when he started the subsection to discuss "subst or transclude?" specifically. To me, having also a separate place to discuss the other aspect (excluded from that section) makes things more clear, not less. Regards,CapnZapp (talk)15:22, 22 October 2025 (UTC)[reply]
There are two separate issues: (1) Where to place the anchor. (2) Whether, when an anchor is placed within a heading, it should be transcluded or substituted. Hence, there are two separate subsections. -Butwhatdoiknow (talk)05:26, 23 October 2025 (UTC)[reply]
As it would make no sense to substitute if the anchor is placedoutside the header, I don't think there's a point in discussing those separately. Discussing whether or not to subst only makes sense if one already has decided that placement within the header is best. But realistically that decisionwon't be made without taking the question of substitution vs. transclusion into account.Gawaon (talk)07:19, 23 October 2025 (UTC)[reply]
There is a program that was originally written in conjunction withCP-67 and was called Cambridge Monitor System (CMS). InVM/370, theSystem/370 replacement for CP-67, IBM renamed CMS toConversational Monitor System, retaining the initialism. There is a redirect from the old name to the new name.
I disagree. The purpose of links is to explain unfamiliar concepts to the reader. BothConversational Monitor System andCambridge Monitor System are terms that may be unfamiliar to the reader, and it is not obvious that they refer to the same thing. It's not even obvious that the two terms will always link to the same article, although they do at present. Both terms should be linked in this case, unless the article text makes it clear that they are two terms for the same thing.--Srleffler (talk)23:39, 26 October 2025 (UTC)[reply]
I'd rather suggest to tweak the text in such a way that it's obvious that both names refer to the same thing, removing any need for a second link.Gawaon (talk)08:36, 27 October 2025 (UTC)[reply]
I agree insomuch that if you can reword the text to remove the need for two links (that lead to the same place), that is indeed preferable. However, if you can't or won't do that, linking both terms is much better than linking only once (relying on the reader understanding that both terms are explained wherever the single link leads to). That is, don't remove links just because our guidelines might say so - making thinks easy to understand for readers is and should be our top priority, even if at the expense of a couple of technically superfluous links.CapnZapp (talk)10:32, 27 October 2025 (UTC)[reply]
In general, it's frowned upon to link to the same destination using what appears to betwo differentWP: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 itcan 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?".— Precedingunsigned comment added byCapnZapp (talk •contribs)11:05, 5 November 2025 (UTC)[reply]
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 aterm 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)[reply]
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)[reply]
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)[reply]
Recalling foo foo both times: exact repetition's boring and largely avoided in many languages. Today's FASieges 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 toBerwick town walls only once. Any more than that wouldn't be helpful, giving the reader the impression that there were multiplelocations ... that can increase readers' understanding of the topic at hand.NebY (talk)12:21, 6 November 2025 (UTC)[reply]
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 multiplelocations ... 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)[reply]
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)[reply]
Considering thatJob 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 onJob 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)[reply]
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)[reply]
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)[reply]
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 calledDecauville and invented a portable narrow-gauge railway system, theDecauville 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)[reply]
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)[reply]
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 existingDo not re-link in other sections if not contextually important there. exemption fromMOS:LINKONCE.) ThanksCapnZapp (talk)12:29, 8 November 2025 (UTC)[reply]
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)[reply]
This whole business of linking to the same anchor multiple times in an article was never a good idea. If a readerreally 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. RecallWP:EASTEREGG?Tony(talk)10:22, 9 November 2025 (UTC)[reply]
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 ofMOS:DL. RegardsCapnZapp (talk)10:56, 10 November 2025 (UTC)[reply]
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)[reply]
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 atJob Entry Subsystem 2/3.NebY (talk)12:03, 10 November 2025 (UTC)[reply]
DL begins with "Linka term at most once per major section," not "Linkto an article or anchor at most once per major section." Thus, the second sentence means "Do not re-linka 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)[reply]
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 thisreally needs to be said in a more clear and direct fashion. (This is not me disagreeing. In fact, it would solve my issue. But itreally isn't immediately obvious this is what we're meaning).CapnZapp (talk)17:23, 10 November 2025 (UTC)[reply]
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)[reply]
Sorry, my bad: it's good practicenot 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)[reply]
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)[reply]
So we agree the MoS actually doesnot 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
In the case it is me you're disagreeing with, Gawaon: When Ientered 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 thishighly unclear and if you oppose me clarifying this you need to argue why this isn't the natural spot to explain all of this. RegardsCapnZapp (talk)17:36, 16 November 2025 (UTC)[reply]
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)[reply]
"but there are times where this is permissible"—I strongly disagree. We're trying to avoid the dreaded sea of blueand 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)[reply]
That's not what this discussion is about. Repeating a link in adifferent section had been allowed for quite a while. This it about whether multiple links to the same article in thesame 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)[reply]
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)[reply]
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)[reply]
The bio onFernand 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)[reply]
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)[reply]
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)[reply]
Not only is that the standard practice, it is also the information thatthe template calls for. ButI 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)[reply]
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)[reply]
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 exampleParliament 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)[reply]
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)[reply]
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)[reply]
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 alsoWikipedia:Make_technical_articles_understandable#Lead_sectionNote: 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 atGovernment. -— Precedingunsigned comment added byButwhatdoiknow (talk •contribs)22:00, 18 January 2026 (UTC)[reply]
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)[reply]
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)[reply]
Don't forget there's an easy alternative: create a "See also" section after the main text. Then the readers will see what they're getting, and clicking the link is more likely.Tony(talk)23:17, 22 January 2026 (UTC)[reply]
I don’t like that as much for a page likeHouse of Representatives (Netherlands), where the article is agnostic to which government is in power. And I think there’s a good chance that that will get forgotten at the bottom of the page, or (worse), people will add every ministry that has ever held power.— HTGS (talk)23:48, 22 January 2026 (UTC)[reply]
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, andCharlemagne should. The article even gives its own examples, such as that most countries shouldn't.Wikieditor662 (talk)02:53, 23 November 2025 (UTC)[reply]
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)[reply]
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 linkequestrian statue, possiblybust, 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)[reply]
"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.
(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.
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)[reply]
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)[reply]
Something, yes, but it would be random and useless. Moreover, whether to link a term in a given contextalways 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)[reply]
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)[reply]
I first posted about this atWP: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)[reply]
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)[reply]
This post presents a perceived problem and two possible solutions.
There have been many disagreements and interpretations of the currentWP:MOS policy onWP: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 aMOS: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), andwhose experience the current balance put in place favors and how.
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 2solution is? It seems more like a statement.Nikkimaria (talk)01:26, 29 November 2025 (UTC)[reply]
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)[reply]
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)[reply]
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 atTalk: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)[reply]
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)[reply]
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)[reply]
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)[reply]
There has beena lot of discussion onMOS:GEOLINK on this page. Mostly about something likeBuffalo, New York, versusBuffalo, 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 articleNovoye 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 linkParfyonovskoye Rural Settlement and keep the link toVelikoustyugsky District (while getting rid of the link that had been toVologda 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)[reply]
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)[reply]
MOS:SL statesSection-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 likeWikipedia 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 isnot 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 toremain 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 updateH:SECTIONLINK but realized I should first divine your collective will.
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)[reply]
@CapnZapp: Now I'm a bit confused by your lateredit since as it currently stands the MOS doesnot "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 isnot silence, though it's a fairly quiet (easy to overhear) way of speaking.Gawaon (talk)16:17, 4 January 2026 (UTC)[reply]
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 forit seems to effectively forbid unpiped links that's exactly the conundrum - I would argue it quiteineffectively 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)[reply]
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 achange 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)[reply]
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)[reply]
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)[reply]
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 surementions 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)[reply]
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)[reply]
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)[reply]
H:SECTIONLINK doesn't start with how to make araw 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)[reply]
(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)[reply]
I agree with your wish for further clarification and I know that the section doesn'tsay such a thing. But the point remains that it doesn't show how to make unpiped section links either. People can easyguess 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
The following discussion is closed.Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Yes,MOS:GEOLINK says that consecutive comma-separated names should not all be linked, just the first one. It also advises against combining extant and non-extant names without a qualifying statement in between, which in this case would be something like "Tallinn, then part of Estonian SSR, USSR", or better, "Tallinn, Estonia, then occupied by USSR".Indrek (talk)06:48, 14 January 2026 (UTC)[reply]
No, it didn't have consensus. There merely was a small majority of votes. The close was invalid. And the whole RFC was ill-advised. One problem was that the proposed options violatedMOS:GEOLINK. —Chrisahn (talk)07:57, 14 January 2026 (UTC)[reply]
I'm aware of that RFC, butlocal consensus (such as achieved in an RFC about a limited set of articles) cannot override a Wikipedia-wide policy or guideline (such as the Manual of Style). Now MOS:GEOLINK is not exactly adamant about qualifying statements between extant and non-extant names, instead recommending them "when feasible", so I'm not saying that the format used in Baltic person infoboxes currently errs against that particular guideline (though I'm also notnot saying that). But since there is now debate about using the same format in article bodies, where there is definitely room for more verbosity, the guideline should be kept in mind.Indrek (talk)08:02, 14 January 2026 (UTC)[reply]
If I understandBeland’s messagehere correctly, the close did not determine the linking pattern or the exact form "City, SSR, Soviet Union," only that the SSR and the Soviet Union be mentioned. Beland, please correct me if I have misunderstood you.Jähmefyysikko (talk)13:19, 14 January 2026 (UTC)[reply]
Yeah, after checking the RfC, it seems to be only about theform of the entry, without explicitly covering linking at all. So theform should be "Tallinn, Estonian SSR, Soviet Union" in agreement with the RfC, but how many of those are to be linked was not really its topic.Gawaon (talk)14:44, 14 January 2026 (UTC)[reply]
I read Beland's comment as suggesting that the inclusion of "then part of" is not contrary to the consensus established at the RFC, and can still be discussed.Jähmefyysikko (talk)15:01, 14 January 2026 (UTC)[reply]
Yeah, while the "then part of" was not explicitly discussed by the RfC, I don't think that its outcome explicitly rules this variant out. The outcome mostly says that both the SSR and the Soviet Union should be mentioned.Gawaon (talk)15:14, 14 January 2026 (UTC)[reply]
Correct. No one mentionedMOS:GEOLINK, so we didn't take that into consideration, and there wasn't much discussion about linking. So I'd say it's fair to interpret that RFC as saying the SSR and Soviet Union should be mentioned, but not how it should be linked or if there should be a footnote or if "then part of" should be included. --Beland (talk)18:53, 14 January 2026 (UTC)[reply]
MOS:GEOLINK states:For a geographical location expressed as a consecutive comma-separated sequence of two or more territorial units, link only the first unit. See the article for examples. Regards,Danbloch (talk)07:09, 14 January 2026 (UTC)[reply]
MOS:GEOLINK also says something which is directly relevant in this case:
If the smallest unit is an extant place, but the largest is not, it is preferable to space the links out when feasible, e.g.Kumrovec, then part ofAustria-Hungary ([[Kumrovec]], then part of[[Austria-Hungary]]).
If this thread can come to agreement on this question, there is no need to have another RFC about linking.
"Tallinn, Estonia, then occupied by USSR" was proposed byIndrek, but this does not link the largest polity, which I think is required byMOS:GEOLINK because the USSR no longer exists. (And our article isSoviet Union, not USSR; I think someone objected to USSR?) It also does not conform to the RFC outcome, which specified "SSR" in the country name.
"Tallinn, Estonian SSR, Soviet Union" was proposed byGoodDay, but this does not link the largest polity as required byMOS:GEOLINK and does not include the recommended separating text.
The Nikkimaria option is the only one so far that seems to comply withMOS:GEOLINK. Are people OK with adopting that, or would following the policy more literally with "Tallinn, then part of Estonian SSR,Soviet Union" be better, or some other option not yet mentioned? --Beland (talk)01:09, 15 January 2026 (UTC)[reply]
I proposed the first option because I think "then occupied by" presents a moreneutral summary of the situation than "then part of". Note also that MOS:GEOLINK does not say ithas to be "then part of", it's only used as an example, so we shouldn't automatically exclude other phrasings. The first option also makes it more clear who occupied who, whereas the third could be read as implying that the Estonian SSR took the city of Tallinn from some other entity, which is of course wrong.
Regarding the largest entity, I didn't link it because I'm not aware of a guideline that says it must be, but I'm not opposed to it. And yes, according toMOS:PLACE, it should be "Soviet Union", not "USSR".
In light of this, I would change the first option to "Tallinn, Estonia, then occupied bySoviet Union". I am not, however, strongly opposed to the third option (which, with minor differences, I also proposed myself earlier), since it does conform to the RFC outcome better, plus linking the SSR is probably more useful than linking "Soviet Union".Indrek (talk)07:02, 15 January 2026 (UTC)[reply]
"then occupied by" seems to have serious POV issues that are avoided by a footnote that addresses these issues more carefully. But that's really a different discussion that doesn't belong here, I'd say.Gawaon (talk)11:32, 15 January 2026 (UTC)[reply]
I don't think any phrase short enough for an infobox would be completely free of POV issues on such a complex subject. A footnote, such as the one being discussed atTalk:Kaja Kallas, would be the best way to address those issues, agreed. The choice of phrase then boils down to which entities (besides the first one, of course) should be linked, which is the core of this discussion.Indrek (talk)12:20, 15 January 2026 (UTC)[reply]
What about "Tallinn, then administered as part ofEstonian SSR, Soviet Union"? We often used "administered by" to describe de facto control in a neutral way. Or "then administered by" if it needs to be shorter? --Beland (talk)17:57, 15 January 2026 (UTC)[reply]
Apart from being a bit more verbose than the other options, that does sound fairly neutral. Another possible option might be "governed by".Indrek (talk)19:33, 15 January 2026 (UTC)[reply]
FWIW, Danbloch, the aforementiond RFC result - does not call for any additional wording. But, that's not what this discussion here at MOSLINK is about. I only wanted clarity on linkage. I wasn't attempting to alter an RFC decision.GoodDay (talk)15:24, 15 January 2026 (UTC)[reply]
I'm genuinely curious,@GoodDay: did the information provided in this thread not sufficiently answer your question, that you felt the need to start another discussion elsewhere? All the talk about qualifying/separating phrases aside, MOS:GEOLINK is very clear about how consecutive comma-separated names (which is what that new RFC is about) should be linked. Or are you intending for the guideline to be amended?Indrek (talk)21:03, 15 January 2026 (UTC)[reply]
That RFC was closed in December 2025, therefore 'not' concurrent with the one I just opened. As for 'here'? this talkpage is for either amending MOS:GEOLINK or seeking clarification on MOS:GEOLINK. I could've came here asking a question concerning the United States or Yugoslavia, makes no difference.GoodDay (talk)21:14, 15 January 2026 (UTC)[reply]
this talkpage is for either amending MOS:GEOLINK or seeking clarification on MOS:GEOLINK. Right. And you already did the latter and got an answer. So why are you doing it all over again atWP:VP?Indrek (talk)21:20, 15 January 2026 (UTC)[reply]
Aren't you? Your initial question here, in this thread (WT:MOSLINKS § A question) was about how to link consecutive comma-separated place names. Multiple users, myself included, explained to you how MOS:GEOLINK answers that question. Now you have opened an RFC (WP:VPM § RFC: Baltic bios infoboxes question) where the question is essentially the same, two of the options mirror the ones you used here, and you even explicitly mention MOS:GEOLINK. Both of these threads are, in your own words, "about linkage" ([1],[2]).
The discussion above is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
SEAOFBLUE example: "chess tournament" -> "tournament of chess"
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 aschess" would be possible too and may be quite sound advice.Gawaon (talk)08:24, 24 January 2026 (UTC)[reply]
... adding a suggestion like 'or link just the term that's most relevant in the given context, such aschess': 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)[reply]
The following discussion is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi there, MOS. We over at RfD/WikiProject Redirect have had a heck of a time with this and we need some help.
So, as of now, there is no guidance atMOS:Linking regarding possessives-- i.e. Canada's or George Washington's-- and how to properly link them to, as an example,Canada orGeorge Washington. There's been three main schools of thought--
1.[[Foobar|Foobar's]] >Foobar's.WP:NOPIPE does imply that this shouldn't be done as it impacts wikitext readability.
3.[[Foobar's]] >Foobar's, then create a redirect titledFoobar's and target it atFoobar. This has happened a SHOCKING amount of times, with discussion atWikipedia talk:WikiProject Redirect turning up a stunning4961 redirects that end in 's (although a good majority of them are instead redirects likeAldi's or1960's or the like that aren't possessives.)
The consensus at RfD over this isall over the place, split into two camps-- the camp that is convinced that 2 is preferred, 3 is wrong, and the redirects created to support 3 should be deleted, and the camp that is convinced that 3 is either preferred or Fine (including at least one VERY vocal user who is convinced 2 is Dead Wrong because "the 's is part of the word") and the redirects created to support it are helpful. The lack of solid guidance on the MOS page is Not Helping Matters, and the discussions about what to do can get really heated. (I will note that at least from myWP:INVOLVED stance, the former camp seems to be the majority while the latter camp is a vocal minority, but as I just stated I am extremelyWP:INVOLVED and quite vocal myself that the former camp is correct, so I'm pretty sure I can't pass judgement re: what consensus actually is)
Thus, we come to you. Can you please help us re: setting down in the MOS page what we're meant to do here?
(Pinging a bunch of editors who've been in the related recent discussions at Wikipedia talk:WikiProject Redirect and Wikipedia talk:Speedy Deletion:)
Option 2 is hands down the best choice. You can just use things like "George Washington's military service" for a possessive use that links to Washington. It's completely pointless to duplicate his name for these instances when a possessive comes into play. You can also use "dogs" without having a pipe replicate the word before turning the singular form into a plural, and for that matter such pipes also aren't needed for turning an upper case letter at the start of words into lower case. See WP:NOPIPE and the already linked threads supporting this stance for more.SNUGGUMS (talk /edits)20:11, 25 January 2026 (UTC)[reply]
Option 2. We had this discussion at Wiktionary a long, long time ago, where we do include plurals, but it was decided that possessives did not fall within the scope of "all words in all languages" unless they fell into the rare exception of being complete concepts in themselves, likeWikt:confectioner's. The possessive formFoo's merely signifies ownership or possession by Foo, and does not make sense to link unless we would similarly linkbelonging to Foo.BD2412T20:14, 25 January 2026 (UTC)[reply]
ClearlyOption 2, as it requires no redirect and no piping, and is moreover the cleanest grammatically, linking just that which is meant to be linked (the name/term in question). For comparison: If we were to replace[[Foobar]]'s House withthe House of [[Foobar]], we certainly wouldn't include the "of" in the link – indicating that the"'s", which has the same function, shouldn't be included either. And, as OP already pointed out,Help:Link § Illustrative examples of display text agglutination also marks this as the preferred option, if in a somewhat subtle way.Gawaon (talk)21:05, 25 January 2026 (UTC)[reply]
3 or 1 look more natural to me. Maybe that's because I have my links underlined instead of the default to only change color, which is barely visible to me. —Cryptic21:10, 25 January 2026 (UTC)[reply]
Option 2. This maps with current accepted practice and also allows for an important semantic distinction. Compare "There are many cultures in the world, likeAustralia's" to "There are many cultures in the world, likeAustralia's.J947 ‡edits21:39, 25 January 2026 (UTC)[reply]
Option 2. This is most correct semantically and grammatically. The subject ofBatman's car isBatmobile, notBatman, so including the possessive marker in the link is incorrect. As redirects, these are a burden to maintain and verify, and this type of linking should be avoided in article prose regardless of how it is produced. Such links are prone to creatingWP:EGG,MOS:EGG andWP:RSURPRISE problems. —Myceteae🍄🟫 (talk)22:00, 25 January 2026 (UTC)[reply]
Option 2's better – Since this is literally the third ongoing discussion about the same exact thing, I'll copy-paste my comment from one of the other two:
I didn't even know linking only the word and not the's was controversial. Links should only include the"'s" if that's related to the content linked. For exampleJacob's would link to things that belong to Jacob, whileJacob's would link to Jacob as a person. I've always fixed these errors in articles.
And besides, even we decided that the"'s" should be linked in both cases, redirects shouldn't be kept solely for this reason. Nobody's searching for "Wikipedia's", piping is enough (and should only be done in the cases I described).
Option 2, by a long shot. I will note that I originally proposed Option 1, but I can see how it would cause issues. Option 3 seems wildly unnecessary in my opinion.thetechie@enwiki:~$she/they |talk22:31, 25 January 2026 (UTC)[reply]
Option 1 or 2. Do Ireally care? No, not at all. But if we as a community don't decide something here, this extremely pointless series of arguments will continue on forever, and surely there are better things editors could spend their time on. I prefer option 2 because it looks like we can get a consensus for that, but I think option 1 is also find because what wikitext looks like doesn't really matter, and it's probably not worth our time chasing down and yelling at every new editor who does this as the most natural option in the Visual Editor. (FWIW Tavix is probably correct that the 's is part of the word, but I don't think that justifies the creation of thousands, potentially millions, of mostly-useless redirects that the community doesn't want.)Toadspike[Talk]00:06, 26 January 2026 (UTC)[reply]
I'm neutral on this issue, more interested in helping a process to go along, because the redirects associated with option 3 cause quite a stir over at RfD.
I'd like to point out that the "thousands of redirects" bit may be a bit inaccurate. That was based off of a query provided by Cryptic, which returned 4961 redirects that end in 's. However, there were alot of false positives in that list. Out of a random spot-check sample of 20 of those redirects, I only find 2 to be clearly problematic:Physician's assistant's →Physician assistant andGrateful Dead's →Grateful Dead. The other 18 were justified, linking something likeLive At Grimey's →Live at Grimey's (fixing the capitalization) orSir Kensington’s →Sir Kensington's (an R from move fixing the wrong apostrophe type). Based on that, I would assume that the true number of problematic redirects is closer to around 500.MEN KISSING(she/they)T -C -Email me!01:02, 26 January 2026 (UTC)[reply]
I don't care what the preferred style is (that's completely irrelevant to the entire discussion and coming here isWP:FORUMSHOPPING), What I care about is that links made in any of the above styles shouldwork. That means that whether someone writes [[Foobar]]'s, [[Foobar|Foobar's]] or [[Foobar's]] the output should be identical: a blue link toFoobar (assumingFoobar andFoobar's are not distinct topics). Why do I think this? It's the most inclusive and has by far the lowest barrier to entry. We gain nothing by making it harder for editors and readers to find our articles, we lose non-trivial amounts by making people search unnecessarily (and remember that search results may or may not contain the correct target, and may be up to sever clicks/taps away) and we definitely lose when duplicate articles are created.Thryduulf (talk)01:23, 26 January 2026 (UTC)[reply]
I very much was not aware of the CSD discussion until well after both the Wikiproject Redirect discussion had been made by meand the CSD discussion had already been made byuser:voorts; I also did not make this discussion until someone else (also voorts) opined that we needed to get a judgement re: MOSbefore the redirect side of the discussion was handled. I also had not been made aware ofWP:MULTI until after the MOS thread had been made; if I had, not only would I have closed the discussion at Wikiproject Redirect before making the MOS discussion, I would've also requested to Voorts that he close the CSD discussion until after we determine if the Redirect side of the discussion evenwanted to delete the redirects.I'd also like to point out that FORUMSHOPPING really only takes into account what happens when the first discussioncloses in one direction and a user takes it to a different forum in order to try and geta different opinion. This is not that; the CSD and Wikiproject Redirect discussionshadn't closed before the MOS discussion started, and when they did close, the CSD one closed as withdrawn, and the WPRD one closed as procedural, neither of which are actual judgements re: where consensus fell. (I'd also point out that while the discussions had gotten REALLY long, tangled, and messy, it feels to me that if they'd closed with a judgement it would've been in favor of deletion; that said, as stated above, I'mWP:INVOLVED and shouldn't be trusted to make judgements on where things were swinging.)Anyways, as for why I was convinced by voort's comment to come here in the first place, it was for two reasons: 1. I'd much rather whatever consensus we came up with actually be acted on by MORE than just RFD, and that means teaching editors which method is preferred. 2. Whichever way this swings is going to massively impact consensus when we DO head to RFD, because quite obviously if we end up with MOS deciding that we should go with 3 than we're gonna need to keep the 's redirects in order to support that, meanwhile if MOS decides on 2, the argument that we should keep gets notably weaker.𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 (talk)02:12, 26 January 2026 (UTC)[reply]
Yeah, this ain't forum shopping. Having three concurrent discussions was certainly undesirable but the other two closed without a firm decision about what to do with these redirects and the suggestion to address the MOS issue separately (and first) arose out of one of those discussion (and has been suggested before). Additionally, Lunamann has repeatedly tagged participants in prior/concurrent discussions and made good-faith efforts to post links to the latest discussion in other relevant venues. —Myceteae🍄🟫 (talk)20:08, 26 January 2026 (UTC)[reply]
Option 2. This should've been an actual RFC with a neutral opening summary (WP:RFCNEUTRAL) and linked atWP:CENT to get broader community attention, but I wouldn't particularly mind if Option 2, which I personally think is the clearest, was standardized. However, such standardization is not determinative of whether the redirects should be deleted, since linking isn't the only function of redirects. MOS has existed for a very long time, non-MOS compliant edits have existed for just as long, and not adhering to MOS isn't a reason to delete redirects that users have deliberately created, presumably because of their usefulness, which is an explicit reason to keep redirects (WP:R#K5). --Patar knight -chat/contributions06:10, 26 January 2026 (UTC)[reply]
I'd like to note that one of the biggest arguments for the redirects created by Option 3 being kept at RfD has, historically, been to point at their "usefulness for editors for this exact purpose"; so... bit of a chicken-and-egg thing going on there. Also, as I was trying to point out up there in my comment to Thryduulf, RfD deciding to delete these redirects would be a bit of a bad idea if MOS decided they were How Things Were Meant To Be Done, right?As for the first bit-- This should've been an actual RfC with a neutral opening summary (WP:RFCNEUTRAL) and linked at WP:CENT to get broader community attentionRegardingThis should've been an actual RfC, back when I first started up the Wikiproject Redirect discussion, I actually went to RfC first, and my eyes landed onWP:RFCBEFORE. It directed me to, as an alternative before making a full RfC, ask at a relevant Wikiproject-- which is why the first discussion venue I chose was Wikiproject Redirect. As for what else happened, see my reply to Thryduulf above. I did not realize back then the sheer scope of what was at question, and if I should've flouted RFCBEFORE and made it a full RFC, my apologies. (Unfortunately it's too late to swap the discussion over to an RfC, I've already got people getting onto me forWP:MULTI and someone tossing aWP:FORUMSHOPPING accusation at me, so let's stay here for now?)Regardingwith a neutral opening summary (WP:RFCNEUTRAL) I did my best to make it as neutral as possible, while including all relevant information, while also not making it too overly long. If there's ways to make it more neutral, then in the spirit ofWP:RFCNEUTRAL I'd like to ask for help on that.Regardinglinked at WP:CENT, I'd like to bring up A: that this is actually the first time I'veheard of CENT lol, and B: there's noWP:DEADLINE for anything; we can definitely still put up a notification there -- in fact, I'm doing that now. (Also is there some reason there's four Ss in "Discusssion" on that page??)𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 (talk)06:43, 26 January 2026 (UTC)[reply]
As a neat way of solving this conundrum, a short question could be added before your exposition, which would functionally be the first comment, and thus comply withWP:RFCNEUTRAL (meaning it could additionally be tagged as an RfC, as I figure it wouldn't affect the existing responses).ChaoticEnby (talk ·contribs)10:14, 26 January 2026 (UTC)[reply]
Am still waking up but went ahead with a simple initial idea of just shunting everything said after the initial three option question (which contained most of the exposition) over to its own comment; is this sufficient or will more need to be done? (if the latter, I definitely need some wake up time and coffee first lol)𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 (talk)12:03, 26 January 2026 (UTC)[reply]
I would personally make it even more concise, something like this:
That argument exists because despite what MOS may say,linguistic prescriptivism always has to eventually deal with how language actually functions. There are endless redirects that would not be MOS compliant links, but are good redirects. I think Option 2 is the preferred style, which most Wikipedia editors are used to and prefer, but it's also a fact that many good faith editors have shown arevealed preference to simply link the full word in the style of Option 3 by deliberately creating these over the years. The arguments for keeping such redirects provided there's no other reason for deletion has been hashed out extensively and I won't repeat them here since they're not relevant.
RfD deciding to delete these redirects would be a bit of a bad idea if MOS decided they were How Things Were Meant To Be Done, right is true, but a red herring in the context of RFD, since "Option 2" is the predominant linking style.
In respect to the RFC stuff, adding it to CENT is good, and I think following what Chaotic Enby suggested in terms of splitting the actual question to be discussed and your own thoughts would be fine; this is a standard solution toWP:RFCNEUTRAL violations. This discussion already sort of presupposes that there should be guidance (e.g. instead ofMOS:VAR applying]]). If I had started the RFC, I probably would've had it as a two-parter (should be there be one official guidance, then what that be). Cat's already out of the bag though. For what it's worth, I don't think this is forum shopping, but just confusion from someone relatively new to these processes.
As for neutrality, the proposed split above should be fine, but describing one option using all-caps "SHOCKING", "stunning" and bit text formatting, describing one of its supporters as "VERY vocal" and that he thinks something is "Dead Wrong" when not capitalizing that phrase would be fine) will obviously prime readers to be biased against that. I don't know your writing style, but it comes of aspush polling.
The biggest issue though is you've elided two separate positions: "Option 3 style linking is fine or even preferable" and "Option 3 style redirects should probably not be deleted absent aWP:R#DELETE" into a third position (i.e. "Option 3" liking should be the standardized guidance and then hundreds of thousands if not millions of "Option 3" redirects should be created en masse) that no one actually holds, because the position has mainly just been they're fine or ever preferable and shouldn't be deleted. Several !votes opposing Option 3 have already cited the a floodgates argument for opposing it. --Patar knight -chat/contributions05:32, 27 January 2026 (UTC)[reply]
If it's pushpolling it's very much not intentional, and probably my own biases leaking through. I'm once again going to thank ChaoticEnby and yourself (and also MEN KISSING) for help with this, and... yeah, I'll admit that maybe I shouldn't have been the one to pull the trigger on this, and I apologize for screwing it up this badly. But I guess on the flip side,ifnobody does it, it never gets done, right...?𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 (talk)12:23, 27 January 2026 (UTC)[reply]
This should've been an actual RFC RfCs are for contentious discussions and this is almost ready for a SNOW close in my opinion. So definitely not RfC-worthy.FaviFake (talk)16:31, 26 January 2026 (UTC)[reply]
While that's what RFCs are often used for, that's not inWikipedia:Requests for comment#What an RfC is. For changes that affect things widely like how to link one of the most common grammatical forms, making it an RFC and/or advertising at CENT, even if it is eventually SNOWed, makes the outcome much safer against being overturned. That way no one can say that the change was just aWP:LOCALCONSENSUS of editors who already argued over a bunch of pages and were hyperaware of the discussion, but aren't representative of the wider community. --Patar knight -chat/contributions04:50, 28 January 2026 (UTC)[reply]
The MOS question is central to the usefulness of these redirects and whether we should keep or delete them. Most RFD participants have agreed that these should be deleted but a vocal minority objects on the grounds that they are useful for linking in articles and that they are useful because some editors create them for use in articles. If consensus is that such links should not appear in articles and the MOS is updated to reflect this, that negates the main arguments for keeping these. I will agree that the MOS question is not entirely determinative of whether or not these should be deleted. We keep certain redirects from misspellings, alternative (incorrect) capitalization, and non-neutral names that should not appear in articles but that are retained as navigational aids. We typically do delete other redirects with additional punctuation, likeFoo. or"Foo", although these do not have the same semantic problems asFoo's. Consensus has generally been thatFoo's is no more plausible as a search term or error than the likes ofFoo. and"Foo". Settling the MOS question is a critical first step to resolving the recurring question atWP:RFD and directly addresses the primary 'keep' reasons that have been put forward. —Myceteae🍄🟫 (talk)16:37, 26 January 2026 (UTC)[reply]
If consensus is that such links should not appear in articles and the MOS is updated to reflect this, that negates the main arguments for keeping these. It does no such thing. For the sake of brevity, I shall refrain from repeating the arguments myself and others have made other times this has been brought up, but they are easy to find if anyone has an open mind and isn't already familiar with them.Thryduulf (talk)17:23, 26 January 2026 (UTC)[reply]
If using these links in articles violates the MOS, that absolutely removes the "useful for linking in articles" argument. I maintain that this is the main argument that has been put forward for keeping these redirects. The "plausible search term" notionhas been rejected as a basis for assessing these redirects by at least one editor who otherwise supports the maintenance and creation of possessive redirects. I agree that any redirect-specific considerations that don't concern the MOS question are beyond the scope of this discussion and don't bear repeating here. But I maintain that the MOS question is imminently relevant to the recurringWP:RFD discussion and that a definitive outcome here will inform futureWP:RFD discussions although it may not be entirelydeterminative because there are other considerations. —Myceteae🍄🟫 (talk)19:33, 26 January 2026 (UTC)[reply]
If the MOS advising not to do something meant that editors never did that thing then you might have a point, however that is trivially obviously not true. They remain useful so that when an editordoes use this sort of link (which they will continue to do, regardless of what the MOS says) then both they and the reader who finds the article before someone changes it will have a working link to the article, which is significnatly better for absolutely everybody than a redlink.Thryduulf (talk)19:37, 26 January 2026 (UTC)[reply]
And folks are free to raise that issue, which has appeared rarely in actual RFD discussions. I have previously suggested other courses of action if we treat these like misspellings. I'm happy to revisit this down the line pending the outcome here. —Myceteae🍄🟫 (talk)19:57, 26 January 2026 (UTC)[reply]
The plan here is once thisWT:MOS discussion gets wrapped up, we can go back toWT:RE and try and come up with a solution for what to do with the redirects (if anything) as informed here. Maybe the redirects can be kept as cheap, maybe they can be deleted as costly. For implementation, maybe a temporary criteria for speedy deletion could be created, or a new entry could be added toWP:RFDO.
I've remained fairly unopinionated on the redirects themselves, except that what I really want to see more than anything else issome sort of consensus that can decide what to do with them. RfD cannot handle ~500 contentious redirects on it's own. I'm really opposed to this view that this MOS discussion shouldn't hold any weight for the next stage of this process, that's just standing in the way of building consensus.MEN KISSING(she/they)T -C -Email me!19:48, 26 January 2026 (UTC)[reply]
The plan here is once thisWT:MOS discussion gets wrapped up, we can go back toWT:RE and try and come up with a solution for what to do with the redirects (if anything) as informed here And also clarify the MOS to help prevent or inform future disputes :)FaviFake (talk)20:04, 26 January 2026 (UTC)[reply]
I think you've done a good job with the summary in regards to neutrality. Also, I personally don't think I would have added an entry toWP:CENT, the discussion feels a bit niche for there, but the wider coverage from folks beyondWT:RE/WT:SD discussions could certainly make things run a bit faster. Also also I see a hanging}} at the end of one of your signatures below, I think you may have messed up the formatting of some template?MEN KISSING(she/they)T -C -Email me!07:19, 26 January 2026 (UTC)[reply]
Option 2 as the cleanest overall – I figure there's a reason why 's isn't automatically appended to a link like regular strings of letters are. As a second choice,option 1 to avoid the proliferation of redirects.ChaoticEnby (talk ·contribs)10:13, 26 January 2026 (UTC)[reply]
Option 2. Ideally, if the subjectFoobar's X exists, we would link there perMOS:SPECIFICLINK. In its absence, we should stillkeep links as simple as possible (WP:NOPIPE) andkeep piped links as intuitive as possible (MOS:EGG), both of which are achieved by option 2. Ioppose both other options as they make a crucial mistake:Foobar's is not the same asFoobar. In this construction, the former is apossessive determiner, so it makes no grammatical sense to link the "'s" in any case without also linking the noun it modifies.UpTheOctave! • 8va?10:36, 26 January 2026 (UTC)[reply]
While I agree on the substance, I'm not sure about that last point: the possessive determiner is, functionally, a noun marked for the genitive case through a clitic. I'm not sure how Wikipedias in languages with a stronger case system do it, but I presume that they link the whole word rather than only the root. In the English case, where the genitive is carried through a clitic rather than a more usual affix, the question is really whether we take it a separate-ish word or as a purely grammatical case marker.ChaoticEnby (talk ·contribs)10:48, 26 January 2026 (UTC)[reply]
I know it's not exactly the same, but the German guidelines have a section on linking parts of compound words atde:Wikipedia:Verlinken § Verlinkung von Teilwörtern that seems to advocate for partial linking as a solution to a similar problem.
In both cases of your cases, it will usually make sense to link either the head or the overall noun phrase (NP). In the second, linking the clitic on its own would not usually be expected per common sense. That just leaves the noun phrase functioning as a possessive determiner (PDNP) and the PDNP without its clitic. If we consider it aseparate-ish word then we need to look at the NP as a whole, which is not complete without the head. This means all proposed linking methods are invalid except linking the head or the NP, as the PDNP is considered an indivisable(ish) unit dependant on the head. If we consider it apurely grammatical case marker thenipso facto the PDNP shouldn't be linked for the same reason we wouldn't link only the clitic. This means that, as we're considering the PDNP as divisable, linking the PDNP without its clitic, the head, or the NP is valid. I see "'s" as phrasal clitic, so don't see the PDNP as indivisable. Therefore, the only forms of linking I would support are linking the head, the overall NP, or the PDNP without its clitic.
This is why I oppose both other options as, regardless of how you consider the construction, I can't see how linking only the PDNP is valid. Thanks for the intellectual stimulation!UpTheOctave! • 8va?13:02, 26 January 2026 (UTC)[reply]
I think Option 2 is best as well, but in cases where you wouldn't want to link the overall noun phrase because it doesn't have an article, but would want to link the proper noun which does (e.g. "Batman's decision to X" or "Napoleon's arrival in Y"), I think it's just as simple as some editors wanting to just link the whole word since different word forms are a very common type of redirect. --Patar knight -chat/contributions14:24, 26 January 2026 (UTC)[reply]
Absolutely: I might've verged on being too technical above. My usual school of thought on trivial cases like these is that if something is not codified, then it's generally not worth the trouble standardising unless needed. However, now that we are here, I'd rather get down into the details.UpTheOctave! • 8va?16:36, 26 January 2026 (UTC)[reply]
Option 2: the 's is not an integral part of the word, as can be seen from examples such asJacob's vsJacob's. Furthermore, option 3 would open aWP:PANDORA's box, requiring us to create potentially millions of redirects; delete's quite rightly been the most common outcome for possessive redirects in recent RFDs.Rosbif73 (talk)13:04, 26 January 2026 (UTC)[reply]
Just to note for those unfamilar with RFD,WP:PANDORA is not something that enjoys consensus - on the contrary it is an actively misleading combination of nonsense and discredited arguments - seeWP:BACKINBOX. None of the options here would require the creation or deletion of any redirects.Thryduulf (talk)17:26, 26 January 2026 (UTC)[reply]
Option 3 would allow or recommend creating redirects when there is desire to link a possessive. It would not require creating millions of redirects in advance - not that creating that many redirects would be at all problematic if they go to the correct target (such redirects are, after all, useful and it is not any sort of problem to create useful redirects).Thryduulf (talk)18:25, 26 January 2026 (UTC)[reply]
WP:PANDORA (which is indeed part of an essay and thus neither universally accepted nor universally applicable) talks about encouraging user expectations. In the case at hand, do we really want to be encouraging the expectation that a link to[[Foobar's]] will just work, and thus (given that it won't, unless someone has already created it), encouraging an expectation that it is normal to have to create additional redirects to just "make it work"?
As to the counter-argument ofWP:BACKINBOX, also an essay, I note that it concludes by saying thata good redirect will catch common searches. Since it ishighly unlikely that a human being would type a string of characters ending in an's into a search box, the correspondingredirect is pretty useless and should probably be deleted or not created in the first place.Rosbif73 (talk)13:29, 27 January 2026 (UTC)[reply]
Option 2 is the best choice here. No piping or extra redirect creation involved. A reader would know exactly where they are going if they were to click onJohn Doe andJohn Doe's.John Doe's would be more unclear - is it about John Doe or something owned by John Doe?Schützenpanzer(Talk)00:45, 27 January 2026 (UTC)[reply]
It's only unclear in the abstract. When used in the context of the sentence it is entirely clear - if it isn't the sentence needs to be reworded for reasons unrelated to the link.Thryduulf (talk)01:24, 27 January 2026 (UTC)[reply]
Comment. I don't have a strong preference, but whatever the outcome is, it should also apply to plural possessives (e.g., dogs'), and the MOS guidance should make that clear.FactOrOpinion (talk)02:00, 27 January 2026 (UTC)[reply]
In essence, but in practice pluralized words typically are or should be linked to go to the actual article, which will likely use the singular form, hence[[dog]]s', rendered asdogs'.Gawaon (talk)08:32, 27 January 2026 (UTC)[reply]
Option 2 best satisfies theprinciple of least astonishment by making clear the scope of what is being linked to, as well as avoidingWP:SEAOFBLUE in certain sentence structures. See also the examples from people like Michael Bednarek and Rosbif, who identify cases where the presence/absence of the's suffix can distinguish notable topics. Oppose Option 3; readers are never going to search "George Washington's" in order to findGeorge Washington, so such redirects are only useful for people who are trying to write out "George Washington's" as a redirect in wikitext. In other words, making Option 3 into guidance creates a navigational problem just for the sake of being able to solve it, whereas using Option 2 effectively just sidesteps the problem entirely.ModernDayTrilobite (talk •contribs)15:36, 27 January 2026 (UTC)[reply]
Option 2 per above, but as Toadspike notes, please be kind to Visual Editor users who generate Option 1-style possessive wikilinks without knowing it.ViridianPenguin🐧 (💬)18:36, 27 January 2026 (UTC)[reply]
Question/Comment What is the prescribed method for linking a plural of a word that ends in y - pipe, or redirect? For such words, we cannot simply add an s after the link, because the plural ending isies and notys. So if one wanted to linkpuppies, would the prescribed markup be[[Puppy|puppies]] or[[puppies]] redirected toPuppy? My understanding is that it should be the former, but that a redirect atpuppies should also exist? Therefore, this RFC seems to not ask the right question, since nobody ever suggested option 3 should beprescribed - the controversy was only ever about whether these redirects should be MASS DELETED!
It should also be noted, the 's not appearing as part of the wikilink was a consequence of the limitations of the Audra, not because of some fundamental principle that the 's in English possessive nouns are somehow "not part of the word". They absolutely are part of the word: the apostrophe's only function is to differentiate a possesive from a plural.
So, my position would beall should be permissible, per Thryduulf, andredirects of alternate word forms,including possesives, should not be deleted.~2026-59608-1 (talk)21:25, 27 January 2026 (UTC)[reply]
Therefore, this RFC seems to not ask the right question, since nobody ever suggested option 3 should beprescribed- the controversy was only ever about whether these redirects should be MASS DELETED! The issue originated with deletion discussions atWP:RFD and the MOS question rose out of these discussions naturally (on multiple occasions). As for plurals,puppiespuppies is a perfectly acceptable{{R from plural}}, as isdogsdogs, even though the latter can be accomplished with agglutination and piping can be used for both. Technical limitations aside, plurals and possessives are quite different so it is reasonable for the MOS to recommend different approaches. —Myceteae🍄🟫 (talk)23:14, 27 January 2026 (UTC)[reply]
A directive for "...redirects of alternate word forms,including possesives, should not be deleted..." is both not the scope of this discussion (though it may have been partially the cause) and not enforceable across the board since discussion would have to be performed for each individual redirect, given that a "do not delete any of these ever"-type of directive is not compatible with the basis of Wikipedia's consensus-based functionality.Steel1943 (talk)23:18, 27 January 2026 (UTC)[reply]
Nor would such a directive be desirable - there are some possessives, etc that should be deleted (e.g.Octopodes's). However simply being a possessive should not be seen as a valid rationale for deletion in the same way that simply being a misspelling alone is not sufficient reason to delete. By consensus there needs to be some indication of why a specific misspelling redirect is harmful or implausible in a way that misspellings generally are not. The same could and should be true for possessives - some indication of why a specific example of such is harmful or implausible in a way that possessives generally are not.Thryduulf (talk)01:06, 28 January 2026 (UTC)[reply]
The discussion above is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There's an RfC for a related question ongoing atWikipedia:Village pump (miscellaneous)#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)[reply]
A whole subsection would surely be overkill. One option might be to add it as a new list item toMOS: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)[reply]
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)[reply]
My thoughts as well, and was about to also bring up an example like:
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 useFoobar's is clear. Also I can't find that example in the current version ofWikipedia:Piped link using Cmd+F. But if there are random examples there or on other pages (likeHelp: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 withWashington's. —Myceteae🍄🟫 (talk)22:38, 28 January 2026 (UTC)[reply]
*Possessives.[[apple]]'s should be used in preference to[[apple's]] (which would require a redirect to be created atApple'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.
Done: see diff[4]. 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)[reply]
Just a query now, but if needed perhapsMOS: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.SounderBruce07:12, 5 February 2026 (UTC)[reply]
Why would you link thesuburb, 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)[reply]
Wouldn't you normally use a connecting word such as "in" in such cases ("Banc of California Stadium inLos Angeles, California, United States")? GEOLINK only applies to comma-separated sequences, hence it will only applyafter 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)[reply]
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)[reply]
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 toLos 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)[reply]
It's fine to link both the venue and city in infoboxes and tables. Seeing something likeIntuit 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)[reply]
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)[reply]
That is a fine solution, and I'll bring it up atWT:FOOTBALL. Definitely prefer to have both the venue and city linked, but without "in", which would be out of place in an infobox row.SounderBruce03:24, 10 February 2026 (UTC)[reply]
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)[reply]
Remsense 🌈 论18:14, 25 August 2025 (UTC)[reply]
Agree —Myceteae🍄🟫 (talk)23:23, 27 January 2026 (UTC)[reply]
Done: see diff[3]. Feel free to further refine the wording if necessary.Rosbif73 (talk)12:38, 29 January 2026 (UTC)[reply]