Wikipedia talk:Manual of Style/Linking

RfC: Linking of three-part place names

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

  1. Have the link span only the smallest unit, using piping if necessary
    Buffalo, New York, United States
  2. Have the displayed text match the title of the linked article
    Buffalo, New York, United States

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

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

Discussion re RfC: Linking of three-part place names

  • Both acceptable, approach 1 preferable. Approach 2 is, no doubt, more common, but both approaches are used in good and featured articles without issue. As a matter of MOS:RETAIN I'll stop short of saying approach 2 should be proscribed, but I think approach 1 is preferable for two reasons:
    • Consistency: Having a prose guideline turn on the title of the article being linked to would be strange, given that the article title policy is informed by various considerations that do not apply to prose, such as disambiguation and the semi-arbitrary rule that is WP:USPLACE. To a reader seeing "Buffalo, New York, United States", next to "Boston, Massachusetts, United States", it is not at all obvious why the two are handled differently. It is cleaner and simpler to have the link span the exact place being referenced, not attached disambiguators like ", New York".
    • Accessibility: The only difference between "Buffalo, New York" and "Buffalo, New York" is the color of the comma. For anyone who, like me, struggles to distinguish between blue and black in small quantities, it looks like clicking on "New York" in the first example will take you to New York (state).
  • The main argument made in the opposite direction is simplicity of markup, but that's usually the lowest priority in MoS decisions, certainly lower than accessibility. We should not make our articles more confusing to readers just for the sake of slightly shorter source code. -- Tamzin[cetacean needed] (they|xe) 20:57, 17 October 2024 (UTC)[reply]
  • None -- I struggle to understand why it wouldn't be necessary to link the first-level administrative division, in most cases outside the US (and even the US as well, but let's assume that Buffalo, New York is an accepted practice in that context). Who could be expected to consider Ialomița County or Simeulue Regency instantly recognizable terms across the vast expanse of the world? and if we're not linking unfamiliar terms, what is the point of having internal links at all? Seems like someone was peeved by having two links next to each other, and came up with this atrocious moratorium on having necessary links where they appear side by side (though neatly separated by a comma); this bewildering approach should not have been tried out at all, ever. Dahn (talk) 21:10, 17 October 2024 (UTC)[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 discussed above, exceptions may apply when the first-level entity's article doesn't prominently discuss the second-level one, mostly in the case of former countries. -- Tamzin[cetacean needed] (they|xe) 21:17, 17 October 2024 (UTC)[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 to Olt County and Wallachia, thus leading to the absurd suggestion that Olt County has the same notoriety as New York, and Wallachia is a notion similar to the US. "It can be easily clicked from [somewhere else]" can be said about each and every bluelink out there, so I don't see why that was ever accepted as a valid argument in any debate. Dahn (talk) 21:32, 17 October 2024 (UTC)[reply]
  • Option 2 per MOS:SPECIFICLINK. It's also a normal unpiped link, without superfluous text: compare [[Buffalo, New York]], United States (five words) with [[Buffalo, New York|Buffalo]], New York, United States (eight words). --Redrose64 🌹 (talk) 22:13, 17 October 2024 (UTC)[reply]
  • Comment — there are plenty of situations where linking place, subdivision and country is appropriate, and I think the guideline should do more to encourage that. Examples: 1) Bogdana, Tutova County, Moldavia; 2) Haraklány, Szilágy County, Kingdom of Hungary. It’s more than likely the average reader will have no idea where any of these places are/were, so why not link them all? — Biruitorul Talk 05:59, 18 October 2024 (UTC)[reply]
  • Option 2 because it's shorter to write and leads to linked text and linked page title being in agreement. Later addition: Also per WP:NOPIPE, as pointed out below by Bagumba – don't use piped links when you don't have to, and here you very clearly don't have to. Gawaon (talk) 08:55, 18 October 2024 (UTC), edited 07:55, 19 October 2024 (UTC)[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 mention Yao Mangshan Ethnic Township (莽山瑶族乡), Yizhang County, Chenzhou, Hunan. Leaving out the container state, that's still four subdivisions. I left Hunan unlinked since it appears in User:Ohconfucius/script/Common Terms, but there are probably editors who would argue for linking that as well. Folly Mox (talk) 09:52, 18 October 2024 (UTC)[reply]
  • Link only the most specific item—especially when the other two are so well known. Tony (talk) 10:25, 18 October 2024 (UTC)[reply]
  • Option 2 Makes no sense to pipe and hide "New York", just to type it again and display it. Per WP:NOPIPE:

    Unnecessary piping makes the wikitext harder to read.

    —Bagumba (talk) 10:54, 18 October 2024 (UTC)[reply]
  • Option 2 don't find any specific reason to leave out the state from the muncipality, as it is kind of self explanatory. Also creates redundant piping per Bagumba. Takipoint123 (talk) 02:20, 19 October 2024 (UTC)[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 Mox here and would go one step further to say the style guide should be explicit in stating there is no dictated preference. It should list some things to consider, provide examples, and otherwise defer to editorial judgment. Things to consider might include MOS:NOPIPE and other rules or guidelines. A lot of this will come down to context-specific factors and personal judgment or consensus within an article. In nearly all cases it matters too little to mandate a single standard and doing so will likely result in more appeals for exceptions and workarounds. MYCETEAE 🍄‍🟫— talk 22:03, 19 October 2024 (UTC)[reply]
  • Option 1, but both acceptable, per Tamzin and link intuitiveness. I don’t want people clicking “New York” and being confused at being sent to Buffalo. I also think all arguments based on what looks best in wikitext or is easier to type for the editor are wrong. Style decisions are not made for the wikitext editor’s benefit. — HTGS (talk) 00:50, 23 October 2024 (UTC)[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]
    And avoiding links that span two page-level topics is another step we can take towards making links clearer. — HTGS (talk) 02:06, 25 October 2024 (UTC)[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 articles would link to New York there. Using a different state because the NYC/NYS ambiguity complicates things, there are 11,030 articles containing either [[Boston]], [[Massachusetts]] or [[<someplace>, Massachusetts|<someplace>]], [[Massachusetts]]. These links are distinguished from e.g. [[Boston, Massachusetts]] by the color of a character that is less than a millimeter wide at standard zoom. -- Tamzin[cetacean needed] (they|xe) 00:20, 27 October 2024 (UTC)[reply]
    Regardless of the outcome of this RfC, the standalone link to Massachusetts should be unlinked per MOS:GEOLINK in all these cases. MOS:GEOLINK is already very clear on this and it's not something that will change. Gawaon (talk) 08:39, 27 October 2024 (UTC)[reply]
  • Single link In almost every case the purpose of the link is to take you to the article of a single, unambiguous, location. The link should be written in it's natural format (no piping). The larger regions are merely so that a printed form will lead you to the same place but we don't really expect the reader to want to go directly to the articles for the larger regions - ie, we are listing a city for a reason, the larger regions are just to make it unambiguous and are not a target in their own right. So, we give the link to the city in its natural format (without piping), and then add whatever else is needed in plain text. If it turns out that some cities in a list have the link encompass different portions of the hierarchy (eg Paris, France vs Paris, Ontario, Canada) then that is okay.  Stepho  talk  01:21, 23 October 2024 (UTC)[reply]
    Ooh, I really disagree with that last point. I’d rather a list be consistent regardless the choice between these two options. — HTGS (talk) 03:01, 23 October 2024 (UTC)[reply]
    How would you list those 2 cities?  Stepho  talk  03:10, 23 October 2024 (UTC)[reply]
    Assuming it’s a normal prose sentence, I would have something like: “However in 1894, the government of Paris, France decided to implement the change, while the mayor of Paris, Ontario forced the city to withhold …” But honestly I would still rather the opposite (… Paris, France decided to implement the change, while the mayor of Paris, Ontario did not…”) to the split styling you suggested. — HTGS (talk) 21:40, 24 October 2024 (UTC)[reply]
    And for most lists, the same (with disambiguation pages being the exception). — HTGS (talk) 21:42, 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]
  • Definitely Option 2. No pipe gymnastics needed, and the blue the reader sees tells him unambiguously where clicking will take him. EEng 00:33, 27 October 2024 (UTC)[reply]
  • Link "Buffalo" alone. Tony (talk) 02:25, 1 November 2024 (UTC)[reply]
    As in Buffalo, New York, United States? -- Michael Bednarek (talk) 03:01, 1 November 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:

Three very nice cities are:

That is, in many cases it's preferable to be consistent with how the links are presented, and in my view it's *not* necessary to have the visible linked text exactly match the article titles. So in this example I've coded [[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 is false to say "Both can be read as fair interpretations of the guidance to 'link only the first unit'." In the string "Buffalo, New York, United States", there are clearly three units, and the first of those three units is "Buffalo". If we're going to say that "Buffalo, New York, United States" ([[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 to MOS:USPLACE for the conventional form of US location descriptions). —⁠ ⁠BarrelProof (talk) 01:06, 3 January 2025 (UTC)[reply]
  • Comment: In most cases no 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).
There are 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 a WP: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: Rich Farmbrough 20: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]

Meta-discussion

Should "United Kingdom" be linked in the infobox of the article about Palestine Action? I removed the link per MOS:OVERLINK, but it was reinstated by Genabab with this edit. Khiikiat (talk) 07:32, 15 July 2025 (UTC)[reply]

In my view, it's reasonable to link it (and unreasonable to edit-war over this), since the country is central to the article. It would be something different if it was just mentioned in passing. Gawaon (talk) 08:44, 15 July 2025 (UTC)[reply]
@Gawaon: In my view, if MOS:OVERLINK is to be followed, then "United Kingdom" ought not to be linked, as it is clearly a major example of a country. However, if it is to be linked, shouldn't we link its first occurrence in the infobox (in |region=) per WP:LINKFIRST? Khiikiat (talk) 22:49, 15 July 2025 (UTC)[reply]
Yes, if it's linked, the first occurrence in the infobox should be linked, and the first occurrence in the main article text should be linked too. And yes, I know that a literal reading of MOS:OVERLINK allows the conclusion that it shouldn't be linked, but then the same literal reading would result in terms like United Kingdom being orphans (never linked), which surely cannot be the intent. Plus there's the word "generally" in the guideline, which suggests exceptions, but doesn't clarify when they are to be made. I therefore favour a reading according to the spirit rather than the letter of the rule, which is to avoid linking such terms when they are mentioned in passing, but to link them whenever they are of major important for the article in question, which is clearly the case here. Gawaon (talk) 07:56, 16 July 2025 (UTC)[reply]
Plus there's the word "generally" in the guideline, which suggests exceptions, but doesn't clarify when they are to be made. → This is the problem. We all have our own interpretation. For me, an example of appropriate linking to the United Kingdom would be the article about the United Kingdom of Great Britain and Ireland, where linking helps to resolve any confusion. Khiikiat (talk) 12:58, 16 July 2025 (UTC)[reply]
The word "generally" means there are exceptions and it is a judgement call as to whether or not a link to the other article adds value in understanding more about the article it is linked from. Basically would you understand this topic better, or gain some additional insight to the topic, by reading the linked article. If the country name is linked solely for definition purposes that is overlinking as we assume everyone knows what the United Kingdom is. If there is a reason beyond mere definition, a link may be appropriate. Only people familiar with the topic can make that judgement. Geraldo Perez (talk) 19:22, 16 July 2025 (UTC)[reply]
What you say about unlinked articles (and potential orphans) might be true were it not for the fact that, for a major topic – one that has intrinsic importance – such as the UK, there will always be germane links to be made from other articles. People also often arrive from outside WP, and they will also type in the search bar from any page.  Ohc revolution of our times 15:50, 20 July 2025 (UTC)[reply]
I would also support it being linked given as you say it's central to the article GothicGolem29 (talk) 20:04, 17 July 2025 (UTC)[reply]
I would certainly delink UK, but not if it were Soviet Union for example. Anyone reading that particular article would be sufficiently aware of geopolitics, United Kingdom would be on the opposite end of germane and would not be of interest. Although there's a certainly a risk of a sea of blue appearing, I wouldn't dwell on it or war over it, though. Chances are that someone who's aware of best practices will come along and delink it again in pretty short order.  Ohc revolution of our times 15:40, 20 July 2025 (UTC)[reply]
I'm not sure I'd link "germane"—you're meant to be able to read English if you consult en.WP. Tony (talk) 05:17, 27 July 2025 (UTC)[reply]
All readers would know that the United Kingdom exists as a country, so a link in the infobox isn't required. If a link is to be included then a more appropriate place for that would be the first mention within the main prose. It is best practice not to link the name of a country as per WP:OVERLINK and WP:GEOLINK. Qwerty123M (talk) 08:00, 3 August 2025 (UTC)[reply]

Discussion at Wikipedia talk:Growth Team features: "Add a link" experiment and next steps

 You are invited to join the discussion at Wikipedia talk:Growth Team features § "Add a link" experiment and next steps. Sdkb-WMF (talk) 17:50, 28 July 2025 (UTC)[reply]

Does linking 'skyline' to a list of buildings constitute a violation of the guidelines on linking?

Here is the edit for context [1]

Personally I do not see how any reader could expect a link to skyline to go to a list of buildings (some of which do not make up the skyline, nor is a skyline a made up solely of the tallest buildings) and not an article on the skyline itself. Traumnovelle (talk) 06:08, 8 August 2025 (UTC)[reply]

As per WP:EASTEREGG, I would expect a link "skyline" to go to the article explaining the general idea of a skyline. If they really want to link to List of tallest buildings in Auckland then they would be better to use the pipe link with the text "Skyline of Auckland CBD". Personally, I think it was better without any link for skyline becuase there may be other features that affect the skyline (shorter buildings, the waterline, etc).  Stepho  talk  06:34, 8 August 2025 (UTC)[reply]
I agree with Stepho. Linking "skyline" would be quite meaningless in the context, and [[List of tallest buildings in Auckland|Skyline]] of [[Auckland CBD]] is linking for the sake of creating wikilinks.  Ohc revolution of our times 11:03, 8 August 2025 (UTC)[reply]

 Please see the series of related discussions at WP:RfD where this question has been raised: For possessives in article space in running text, should the 's be included inside wikilinks, either via redirects or piped links, e.g. [[China|China's]] (China's), or outside the wiki markup, producing China's. This has come up in a series of related discussions at WP:RfD (if you click the first one and scroll down you can read all three as they appear in order):

This does not appear to be addressed here nor at MOS:'S. --MYCETEAE 🍄‍🟫—talk 22:27, 12 August 2025 (UTC)[reply]

It's addressed in H:WIKILINK, which says: "Punctuation breaks display text agglutination. This is often helpful for possessives: for example, [[Batman]]'s gives Batman's." The wording used to be bit stronger than that, even more clearly suggesting that writing [[Batman|Batman's]] is wrong. Gawaon (talk) 07:02, 13 August 2025 (UTC)[reply]
Thanks. WP:NOPIPE also covers my China's example, I realize. Neither NOPIPE nor HLINK cover a situation where the possessive is a redirect, e.g. Canada's, from a style perspective. I read the current wording at HLINk as merely explaining the wikilink behavior and being silent on the style question. For example, the opening sentence of Theatre Museum Canada is:

Canada's Theatre Museum (formerly Theatre Museum Canada) was founded by Herbert Whittaker in 1982, for the purpose of preserving and celebrating Canada's theatrical cultural heritage.

I can't find anything that says whether Canada's theatrical cultural heritage (with 's outside thew wikilink) would be better. I don't expect nor want the MOS to cover everything, and style is not the only relevant factor in the RfD discussions, but I raised it here because it is the sort of thing MOS might cover. --MYCETEAE 🍄‍🟫—talk 17:56, 13 August 2025 (UTC)[reply]
It seems wrong to link Canada's (possibly referring to whatever belongs to Canada?) when the article is actually about Canada itself. So I think these redirects were merely created for people accidentally making bad links, just as there are redirects for common typos. The best course of action would be get rid of both the redirect and of the erroneous links. (I know that not everybody seems to agree with this, though I can't say I understand the reasons for this.) Gawaon (talk) 20:55, 13 August 2025 (UTC)[reply]
This was also discussed here recently at #Possessives. Firefangledfeathers (talk / contribs) 18:17, 13 August 2025 (UTC)[reply]
Thanks! I read these discussions as largely inconclusive on the style question. --MYCETEAE 🍄‍🟫—talk 19:12, 13 August 2025 (UTC)[reply]

Description lists

@Remsense, you wrote:

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, or Template:Citation needed § Example 2.

Could you redo the edit please?

— W.andrea (talk) 17:35, 25 August 2025 (UTC)[reply]

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 in wikitext create HTML 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
name 1
value a
value b
name 2
name 3
value c
Remsense 🌈 论 17:43, 25 August 2025 (UTC)[reply]
I'm aware of all that already, and I didn't take your message as obtuse... but regardless, I changed the formatting a different way that we should both be happy with, using {{block indent}}. — W.andrea (talk) 18:09, 25 August 2025 (UTC)[reply]
Thank you very much for your patience. Remsense 🌈 论 18:14, 25 August 2025 (UTC)[reply]

Plural pipestyle

MOS:PIPESTYLE says

  • Plurals and other derived names. [[apple]]s displays as apples, and this is simpler and clearer than [[apple|apples]].

But I see edits that convert [[apple]]s to [[apples]] or vice versa. Both apples and apples work. Which is preferred? Can we spell that out in the MOS section please? Johnjbarton (talk) 16:29, 10 September 2025 (UTC)[reply]

In such cases, [[apple]]s of course, since it doesn't make an unnecessary redirect. Gawaon (talk) 16:43, 10 September 2025 (UTC)[reply]
In ApplesApples, you can read This 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 (see WP:NOTBROKEN). As far as I understand, the second sentence is motivated by MOS:VAR that applies when the change is the only object of the edit. D.Lazard (talk) 17:01, 10 September 2025 (UTC)[reply]
As I remember it, at one time the software automatically redirected titles with an appended 's', but that was deprecated a long time ago. Donald Albury 17:03, 10 September 2025 (UTC)[reply]
I added some text, please check. Johnjbarton (talk) 18:05, 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]
I think that it what the text says now after my edits and those of Gawaon. Johnjbarton (talk) 02:20, 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 to Aztecs. 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]
I have now added a sentence explaining this; feel free to improve or (if necessary) revert. Gawaon (talk) 07:27, 11 September 2025 (UTC)[reply]
I did say "generally". The exceptions are at WP:PLURAL.--Srleffler (talk) 05:15, 13 September 2025 (UTC)[reply]

LINKONCE?

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]

Opinions depend upon context. If you want another opinion, post the article name. Johnjbarton (talk) 21:43, 13 October 2025 (UTC)[reply]
Sure, thanks.. Agent Carter (TV series), also the discussion is on the talk page there. Tduk (talk) 22:08, 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]
That's a good point, thanks; this was the closest MOS entry that I could find, is there a more relevant one? Tduk (talk) 19:05, 14 October 2025 (UTC)[reply]
I'd say it's not a MOS issue; just try to resolve on the talk page itself whatever issues there are no resolve. Gawaon (talk) 21:13, 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]
That is your inference, not my implication. NebY (talk) 15:03, 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 that Template: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]
Comment: See also /Archive 8#Address hyperlink-era usage patterns in "Repeated links" section – Mullafacation『talk』 17:20, 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?

WP:ANCHORSUBST explains that inside section headers, {{Anchor}} should always be substituted (and not a number of alternative approaches).

I asked at that page, and was directed here. Which is probably for the best since that page is an "ordinary" help page and can't prescribe policy anyway.

Could anyone point me to the discussion that is the basis for this recommendation? Thank you CapnZapp (talk) 21:19, 18 October 2025 (UTC)[reply]

The rationale is already given in WP:ANCHORSUBST, which discusses each possible alternative in detail, explaining its problems. Gawaon (talk) 07:17, 19 October 2025 (UTC)[reply]
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]
Template:Anchor/doc was amended after this discussion; I can't say if that's the only or most relevant one for your investigation. NebY (talk) 11:02, 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 heading before 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 is awful for editors:
=== <span class="anchor" id="Administrator"></span><span class="anchor" id="Admin"></span><span class="anchor" id="Sysop"></span><span class="anchor" id="sysop"></span><span class="anchor" id="admin"></span>Administrators and bureaucrats ===
We should consider banning section anchors altogether and having a bot fix links to outdated section headings. --Srleffler (talk) 14:12, 19 October 2025 (UTC)[reply]
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. Cheers CapnZapp (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 that already 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:
FaviFake (talk) 14:20, 19 October 2025 (UTC)[reply]
The guidance to substitute the template if it was in the heading has been well established. What I haven't seen yet is the origin of the mandate that it must be substed in the heading before 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.
Looking at those pages:
  • MOS:RENAMESECTION was edited by you in August, referencing WP:TARGET
  • WP:TARGET said to put the anchor after the section name until it was edited 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 of Template 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.
  • You also edited MOS:SECTIONANCHOR that same day in August
So, it appears that this change did not come from a consensus or from the MOS but rather was boldly inserted into both the MOS and WP: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]
Yes, I did boldly edit the recommendation a while back, based on the recommendation in this comment.

I've said it before, and I'll say it again: accessibility. Users of screen 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 that banning 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 is exactly 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. Regards CapnZapp (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: Rich Farmbrough 11: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 at WP: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 at WP: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.

FaviFake (talk) 16:43, 20 October 2025 (UTC)[reply]
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 like really 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]
Maybe you don't care, but I for one would sure hate to lose that convenience, trivial or not. Gawaon (talk) 08:14, 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.
    Anomie⚔ 15:13, 21 October 2025 (UTC)[reply]
    Thanks for the summary. With prompting, I do remember the accessibility point. I favor the status quo here. Let's maximize functionality. Firefangledfeathers (talk / contribs) 15:23, 21 October 2025 (UTC)[reply]
    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 of Wikipedia:Substitution. - Butwhatdoiknow (talk) 20:53, 21 October 2025 (UTC)[reply]
    Seems to me it's about both "always subst" and "within the section header". Anomie⚔ 21:58, 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 was a 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 to always subst the anchor template within 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]
    All bold edits are made without consensus. That's the point of WP:BOLD... FaviFake (talk) 15:50, 22 October 2025 (UTC)[reply]
    Yes, and note WP: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 is new, and not something that has been discussed before. --Srleffler (talk) 06:09, 24 October 2025 (UTC)[reply]
    My understanding is that it was the result of a previous discussion (if maybe not a very long one). Gawaon (talk) 07:20, 24 October 2025 (UTC)[reply]
    Yes, in a way. The change was supported by at least one other editor at the time of my bold edit. FaviFake (talk) 14:20, 24 October 2025 (UTC)[reply]
    Pinging @Redrose64 in case they wish to expand their previous comment around the accessibility of subst'ed anchors. Or partecipate in the discussion in general. FaviFake (talk) 15:48, 21 October 2025 (UTC)[reply]

Comment: While I prefer another recommendation, I consider FaviFake'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

Please edit this post freely and discuss below.

Edit: The location of the anchor gets a separate discussion; below. CapnZapp (talk) 14:43, 22 October 2025 (UTC)[reply] 

 ============
Advantages of Transclusion:
  • Cleaner section headings when editing.
Disadvantages of Transclusion:
  • Adds anchor template(s) text to edit summary link.
  • Breaks edit summary link to edited section.
Advantages of Substitution:
  • Preserves edit summary link.
Disadvantages of Substitution:
  • Adds ""HTML gobbledigook" to section headings when editing.
 ============ - Butwhatdoiknow (talk) 14:46, 21 October 2025 (UTC)[reply]
That doesn't really sum up the issue. Anomie had it better, above:
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.

--Srleffler (talk) 04:17, 22 October 2025 (UTC)[reply]

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 of H: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 or Srleffler? 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. Cheers CapnZapp (talk) 15:33, 22 October 2025 (UTC)[reply]
(edit conflict) Allow me to repost Srleffler's example from above. I wholeheartedly agree the following is awful for (new) editors, and I sincerely hope we can prioritize the new editor experience over some convenience shortcuts:
=== <span class="anchor" id="Administrator"></span><span class="anchor" id="Admin"></span><span class="anchor" id="Sysop"></span><span class="anchor" id="sysop"></span><span class="anchor" id="admin"></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 class="anchor" id="Reviewer"></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 to User: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 anchors everywhere (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 exact placement 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 anchors in general are used in the main space, that's why we have guidelines about using anchors.
And, as Gawaon said, the assertion that I made [the current guideline] [...] [tell] people to subst to subst anchors everywhere 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 anchors if 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 in WP: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.
— Template:Anchor/doc § Not transcluded FaviFake (talk) 14:32, 23 October 2025 (UTC)[reply]

Location of anchors placed in or near headings

Please edit this post freely and discuss below. 

 ============
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.
Inside the heading, after the text
Pro: Somewhat less ugly wikitext. Con: Screen readers don't read the heading text.
After the heading
Pro: Sensible wikitext. Cons: Link puts the heading off the top of the screen. Screen readers don't read the heading.
 ============ - CapnZapp (talk) 14:43, 22 October 2025 (UTC)[reply]
Why you do repeat what was already said by Srleffler above? That just pointlessly forks the discussion. Gawaon (talk) 15:16, 22 October 2025 (UTC)[reply]
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]
I do not understand the point of yet another subsection? FaviFake (talk) 15:51, 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 placed outside 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 decision won't be made without taking the question of substitution vs. transclusion into account. Gawaon (talk) 07:19, 23 October 2025 (UTC)[reply]

I created an RfC at Wikipedia:Village pump (proposals)#RfC: Should links to the redirect Search Engine Land be restored? where this guideline is mentioned. Cunard (talk) 09:30, 20 October 2025 (UTC)[reply]

Linking to new names

There is a program that was originally written in conjunction with CP-67 and was called Cambridge Monitor System (CMS). In VM/370, the System/370 replacement for CP-67, IBM renamed CMS to Conversational Monitor System, retaining the initialism. There is a redirect from the old name to the new name.

The article CMS EXEC links to the new name in the first sentence and mentions both the old name and the new name in the second sentence. Should the reference to the old name be wikilinked even though it points to the same page as the new name? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:11, 22 October 2025 (UTC)[reply]

If one of the two links doesn't redirect to a section, then only one link should be kept. FaviFake (talk) 19:07, 22 October 2025 (UTC)[reply]
I disagree. The purpose of links is to explain unfamiliar concepts to the reader. Both Conversational Monitor System and Cambridge 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]
Don't forget the case where, as @Srleffler suggested, eventually the two have different targets. Tduk (talk) 13:41, 27 October 2025 (UTC)[reply]
Yup, this seems th ebetter solution. Two links in two sentences usually means two different things. FaviFake (talk) 16:05, 27 October 2025 (UTC)[reply]

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

They sure are. Once something is linked, it doesn't need to be linked again (in the same section). Gawaon (talk) 15:12, 5 November 2025 (UTC)[reply]
In general, it's frowned upon to link to the same destination using what appears to be two different WP:EXAMPLE links (that example is silly in all the ways but you get my meaning, two links look different but lead to the same place). In some cases it can be considered justified, such as where WP:ASTONISH trumps MOS:DUPLINK - when a discussed topic is well known by and established through two different names, you might prefer to just link both even though the resulting article is the same (and I'm not talking cases where one link is direct and the other is a link to a destination that redirects to the first place), since that's better than having the reader go "but why is there only an article on X but not Y?". — Preceding unsigned comment added by CapnZapp (talk • contribs) 11:05, 5 November 2025 (UTC)[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 a term at most once per major section...". If you have two different terms that happen to link to the same article, that is not a violation.--Srleffler (talk) 02:47, 6 November 2025 (UTC)[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]
I'm concerned with the case that the two phrases are *NOT* synonyms. As an example IBM wrote two different job entry subsystems for MVS, JES2 and JES3, both terms having redirects to Job Entry Subsystem 2/3. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:34, 6 November 2025 (UTC) -- Revised 14:19, 6 November 2025 (UTC)[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]
A clearer solution would be something like two variants of the Job Entry Subsystem, JES2 and JES3 – that'll work as expected and avoid confusion. Gawaon (talk) 11:18, 6 November 2025 (UTC)[reply]
That'll work if their in the same sentence, but ot if they're significantly separated. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:51, 6 November 2025 (UTC)[reply]
Re calling foo foo both times: exact repetition's boring and largely avoided in many languages. Today's FA Sieges of Berwick (1355 and 1356) includes background on Berwick which mentions the "stone walls", the "town's and castle's defences", and the "town walls", linking to Berwick town walls only once. Any more than that wouldn't be helpful, giving the reader the impression that there were multiple locations ... that can increase readers' understanding of the topic at hand. NebY (talk) 12:21, 6 November 2025 (UTC)[reply]
I'm concerned with the case that the two phrases are *NOT* synonyms. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:19, 6 November 2025 (UTC)[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 multiple locations ... that can increase readers' understanding of the topic at hand. As a reader, I have occasionally found it annoying to be sent off to the same place twice. NebY (talk) 15:44, 6 November 2025 (UTC)[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]
No, they are *NOT* "easily remedied by Gawaon", because they are not in the same sentence, and they *should* be linking to the same page, because that page describes both. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:58, 6 November 2025 (UTC)[reply]
OK, give us an example? - Adolphus79 (talk) 16:23, 6 November 2025 (UTC)[reply]
In OS/360 and successors § OS/VS2 SVS and MVS, JES2 and JES3 occur in different sentences: Initially MVS was supplied with a job queue manager called JES2 (Job Entry Subsystem 2), which was descended from HASP (Houston Automatic Spooling Priority) and also supported Remote Job Entry from workstations located elsewhere. JES2 can only manage jobs for one CPU (which might be a tightly coupled multiprocessor system). In 1976 IBM provided another option, JES3 (Job Entry Subsystem 3), a descendant of ASP (Attached Support Processor), which allows one CPU to manage a single job queue feeding work to several physically distinct CPUs, and therefore allows one operator's console to manage the work of all those CPUs.[1] Note: JES1 was the job queue manager for OS/VS1 (see above). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:35, 6 November 2025 (UTC)[reply]
Considering that Job Entry Subsystem 2/3 doesn't even have separate sections on the two, the distinction is merely a mention in the lede, and the body includes the statement "In 1973, IBM rewrote ASP and renamed it JES3", it appears that not only is the JES3 link in your example definitely overlinking, but the (unsourced) description of JES3 in your quote is also incorrect. It should be re-worded to say "In 1976, IBM provided another option, ASP, later renamed JES3, which allows..." without a link at all (as supported by the sourced statement on Job Entry Subsystem 2/3). I see absolutely no reason to link JES2 and JES3 to the same page in the same paragraph. - Adolphus79 (talk) 18:12, 6 November 2025 (UTC)[reply]
JES3 is not a renamed ASP; a massive amount of code has been replaced. Your suggested text is erroneous. However, I see that the linked article is missing a lot of important information and I have marked it as a stub. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:27, 6 November 2025 (UTC)[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 linked. However, it would be better stle to have the abbreviations in the parentheses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:27, 6 November 2025 (UTC)[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]
You mentioned HASP and ASP; in both cases the full name is linked. I agree that the style should be consistent, and my preference is full name linked, abbreviation in parentheses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:11, 7 November 2025 (UTC)[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 called Decauville and invented a portable narrow-gauge railway system, the Decauville system. Should the minor fact this system doesn't currently have its own article, and is discussed at the company article, mean editors are prohibited from linking both in close proximity, as I just did? I'm sure there are hundreds of examples where we don't need to delve into arcane differences between old mainframe operating subsystems... :) The point is that one link doesn't obviously have information for readers interested in the other topic and vice versa, so separate links are easily understandable as the first choice when writing new material into Wikipedia. Regards, CapnZapp (talk) 14:53, 7 November 2025 (UTC)[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 existing Do not re-link in other sections if not contextually important there. exemption from MOS:LINKONCE.) Thanks CapnZapp (talk) 12:29, 8 November 2025 (UTC)[reply]
Possibly tweaking the actual policy or the actual guideline? Butwhatdoiknow (talk) 15:44, 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 reader really wants to divert to another article after following a section link, they can so easily cast their eyes up to a previous link (readers hit links much less often than people here seem to assume, and we certainly shouldn't be catering to the supposed link-hoppers who treat WP like some kind of board game). Or, perish the thought, a reader could type a word into the search box. And on no account should a subsequent link have a different pipe: that would be very irritating if perchance someone did hit both. Recall WP:EASTEREGG? Tony (talk) 10:22, 9 November 2025 (UTC)[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 of MOS:DL. Regards CapnZapp (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 at Job Entry Subsystem 2/3. NebY (talk) 12:03, 10 November 2025 (UTC)[reply]
I agree about the Job Entry Subsystem. I also think it is a very poor example. CapnZapp (talk) 12:29, 10 November 2025 (UTC)[reply]

DL begins with "Link a term at most once per major section," not "Link to an article or anchor at most once per major section." Thus, the second sentence means "Do not re-link a term in other sections if not contextually important there." It doesn't - and shouldn't - have a limit on how many times an article/anchor is linked to if that article/anchor helps the reader understand different terms. - Butwhatdoiknow (talk) 15:43, 10 November 2025 (UTC)[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 this really needs to be said in a more clear and direct fashion. (This is not me disagreeing. In fact, it would solve my issue. But it really isn't immediately obvious this is what we're meaning). CapnZapp (talk) 17:23, 10 November 2025 (UTC)[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]
That is indeed good practice, in my view. Tony (talk) 00:11, 16 November 2025 (UTC)[reply]
Which? Viriditas (talk) 00:36, 16 November 2025 (UTC)[reply]
Sorry, my bad: it's good practice not to repeat a link in the body, in my view. The guideline says you may, not you must, and it was never a good idea anyway. Tony (talk) 04:39, 16 November 2025 (UTC)[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 does not discourage/prohibit duplicate links... as long as the links are for different terms/concepts explained on the destination page? CapnZapp (talk) 12:06, 16 November 2025 (UTC)[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]
We don't agree on that. The issue is just too exotic to be explicitly addressed in the MOS. Gawaon (talk) 16:04, 16 November 2025 (UTC)[reply]
Doesn't agreeing on it mean that it isn't addressed explicitly in the MOS? What am I missing here? Tduk (talk) 17:14, 16 November 2025 (UTC)[reply]
In the case it is me you're disagreeing with, Gawaon: When I entered this discussion it was with the firm belief the MoS prohibited exactly the kind of sort-of-but-not-really duplicate links. I have been in several discussions where editors point here to argue it is policy to never allow duplicate links to the same article even when each link is for a separate concept. Because there's far too little to indicate this distinction is important. Now I have been informed we were wrong. I find this highly unclear and if you oppose me clarifying this you need to argue why this isn't the natural spot to explain all of this. Regards CapnZapp (talk) 17:36, 16 November 2025 (UTC)[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 blue and the dilution of the linking system. Used sparingly it gives readers a reliable selection of links that on rare occasions they might follow (readers don't follow links much). Tony (talk) 00:32, 17 November 2025 (UTC)[reply]
I believe it is permissible to link once to the same concept in the lead and the body. I realize that others disagree. Viriditas (talk) 00:38, 17 November 2025 (UTC)[reply]
That's not what this discussion is about. Repeating a link in a different section had been allowed for quite a while. This it about whether multiple links to the same article in the same section should be allowed in certain cases. I'm not happy with the idea and not convinced there's a good use case for it, but others disagree. Gawaon (talk) 09:05, 17 November 2025 (UTC)[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]

References

MOS:SEAOFBLUE

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

Listify the list of pupils? -- Michael Bednarek (talk) 02:13, 16 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]
Create a category - say Category:Pupils of Fernand Léger - and add all of the listed articles to it. Then trim the list to the four or five, six maximum, that are most significant. --Redrose64 🌹 (talk) 08:13, 16 November 2025 (UTC)[reply]
Will do! Viriditas (talk) 21:07, 16 November 2025 (UTC)[reply]

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

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

  • Not only is that the standard practice, it is also the information that the template calls for. But I see your point. It seems to me that the problem is the word "Government," which would require a change to the template. Maybe come up with what you think is a better label ("In Power"? "In Government"? "Controlling"?) and start a conversation on the template's talk page with that proposal? ("In Government" may not be the best, but it is probably the easiest to sell.) - Butwhatdoiknow (talk) 17:23, 21 November 2025 (UTC) Strikethrough erroneous text. - Butwhatdoiknow (talk) 23:35, 21 November 2025 (UTC) Strikethrough erroneous text #2 (this is embarrassing, or would be if I had any shame). - Butwhatdoiknow (talk) 17:37, 22 November 2025 (UTC)[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 have also notified the template talk page of this discussion btw) Dajasj (talk) 20:43, 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 example Parliament of the United Kingdom, meaning it was not intended to have anything in articles about a single house. But, nature abhors a vacuum and, over time, it has been used in single house articles to identify parties out of power, suggesting that editors have found it beneficial to include that information. - Butwhatdoiknow (talk) 23:35, 21 November 2025 (UTC)[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]
No problem ;) 'Governing' would be better, but I still think it would be best to be more explicit about the link. Dajasj (talk) 11:45, 24 November 2025 (UTC)[reply]
The problem is that "government" has multiple meanings. According to the Wikipedia government article: "In the case of its broad associative definition, government normally consists of legislature, executive, and judiciary." I suggest that most readers would assume that meaning. - Butwhatdoiknow (talk) 13:14, 18 January 2026 (UTC)[reply]
I get the impression that "Government" is the common term used to refer to the coalition in power in various parliamentary systems where multiple parties have to form a coalition for anyone to be able govern (i.e. definition 6 at wikt:government#Noun, and maybe also definition 5). In these infoboxes, the "Government" header is introducing the list of parties making up the coalition, and additionally is linking to the article about the coalition itself. The US doesn't have anything directly comparable, as its system selects the Executive separately and the two-party system means no coalitions are needed in the Legislative anyway. The UK seems to specifically qualify it as "HM Government" which makes it distinct from the plain word "government", but that wouldn't work so well for countries without a monarch or ones that separate the monarch from government more than the UK does. It's not clear to me that inventing our own terminology for the general cases would really make things more clear if English-language sources use "Government". Anomie⚔ 15:48, 18 January 2026 (UTC)[reply]
  • Seconded. Glide08 (talk) 18:02, 18 January 2026 (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 also Wikipedia:Make_technical_articles_understandable#Lead_section
    Note: This issue wouldn't be all that important if the word was not linked to governing coalitions articles. But it is, and when the uninitiated see "government" they expect land at Government. - — Preceding unsigned comment added by Butwhatdoiknow (talk • contribs) 22:00, 18 January 2026 (UTC)[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]

List of words

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

Not that I know of. A lot depends on context. - Butwhatdoiknow (talk) 22:05, 22 November 2025 (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, and Charlemagne should. The article even gives its own examples, such as that most countries shouldn't. Wikieditor662 (talk) 02:53, 23 November 2025 (UTC)[reply]
What problem would this solve? - Butwhatdoiknow (talk) 06:11, 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 link equestrian statue, possibly bust, and many occurrences of the others might be better with adding the specific road, stadium, or army, and linking that appropriately. Johnbod (talk) 11:33, 23 November 2025 (UTC)[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.
And, oh my, the debates that will take place regarding whether words should or should not be on the list. I shudder to think about it. - Butwhatdoiknow (talk) 15:57, 23 November 2025 (UTC)[reply]
It might also help to have more than two tiers, for example:
  • Should almost always not be linked (eg the words "the" or "a")
  • Should usually not be linked (eg countries)
  • Should sometimes be linked (eg bust, death)
  • Should usually be linked (eg cancer)
  • Should almost always be linked (eg obscure words)
(the list/examples aren't perfect and there could be fewer categories but you get the idea)
As for the overlinkers not reading it, perhaps it could still be benefitial: someone who sees an article overlinked can refer the overlinker to the list. Plenty of other people could benefit from this, such as myself.
Also, if we did decide to make such a list, would we need to use external resources to find out how common a word is, or do the editors' consensus determine how commonly a word should be linked? If you want I can start working on such page.
Wikieditor662 (talk) 14:54, 24 November 2025 (UTC)[reply]
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, the idea is that people wouldn't read the entire list, but look for specific words that they're not sure if they should link from that page. Wikieditor662 (talk) 15:35, 24 November 2025 (UTC)[reply]
If you aren't sure, use common sense. The lists you ask for would be way too long to be usable and maintainable. Gawaon (talk) 09:11, 25 November 2025 (UTC)[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 context always depends on the context in which it is mentioned (is it sufficiently relevant here to be linked or what that be just a distraction?), so such a list is not only impractical, but also impossible for conceptual reasons. Gawaon (talk) 03:26, 26 November 2025 (UTC)[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 at WP:Village Pump (technical) and was told that it was "not a technical question and you should ask on the relevant MOS talk page" so here I am. This is my original post from VP (technical):
I came across an article where another editor had changed various geographical wikilinks from complete wikilinks to piped wikilinks, for example:

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

The editor cited WP:GEOLINK as the reason. I know that Geolink states "For a geographical location expressed as a consecutive comma-separated sequence of two or more territorial units, link only the first unit." but the changes just look like a lot of unnecessary piping to me... - Shearonink (talk) 18:33, 27 November 2025 (UTC)[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]
Why is it a mistake? It avoids link bunching. See MOSLINK. Tony (talk) 02:36, 28 November 2025 (UTC)[reply]
What's link bunching? MOS:LINK doesn't mention it. Gawaon (talk) 03:04, 28 November 2025 (UTC)[reply]
Moved from Wikipedia talk:Manual of Style/Accessibility § Linking strategy

This post presents a perceived problem and two possible solutions.

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

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

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

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

1 solves your perceived problem for editors only. But the vast majority of readers are not editors, and so cannot set preferences. They could only be served by 2, and I'm not really sure what your 2 solution is? It seems more like a statement. Nikkimaria (talk) 01:26, 29 November 2025 (UTC)[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]
Presumably default settings for 1 would reflect... whatever 2 ends up being. Nikkimaria (talk) 01:37, 29 November 2025 (UTC)[reply]
readers are not editors, and so cannot set preferences Not if they have no account. Paradoctor (talk) 15:24, 30 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 at Talk:Agent Carter (TV series), although somewhat circuitously; it was this talk page that got me thinking about this. I don't think Nikkimaria pointed out that (1) won't work; rather, it will work but may require looking into (2), or encouraging use of preferences. People I have spoken to/seen discuss it sometimes do complain that the linking policy is outdated, especially for those who aren't on good systems or who have difficulty navigating/typing for various reasons, but there is a perception that if anyone brings it up, it will get a negative reaction, so typically no one does since that kind of change is not easy here. However, I've already said my point of view, and I'm not interested in trying to convince people of it; as I've said, if they are around, they will comment here if they want to. Tduk (talk) 03:44, 29 November 2025 (UTC)[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 been a lot of discussion on MOS:GEOLINK on this page. Mostly about something like Buffalo, New York, versus Buffalo, New York. I think both are fine. My question though, is what if the first location does not have an article on it yet? For example, with the article Novoye Rozhkovo, it describes a place in Parfyonovskoye Rural Settlement, Velikoustyugsky District, Vologda Oblast, Russia. There currently isn't an article on the Parfyonovskoye Rural Settlement. My solution was to red link Parfyonovskoye Rural Settlement and keep the link to Velikoustyugsky District (while getting rid of the link that had been to Vologda Oblast). However, I encountered a lot of articles like this for different rural settlements in Russia, and I'd wager it's probably occasionally relevant elsewhere too, so I figured I'd see what y'all think. The way I see it there's three options:

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

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

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

I think 2 and 3 are probably both fine. I'm curious if I'm missing some policy on this tho, or if there will be a clear community consensus. I'm not starting an RfC, because I don't think this warrants one, and I'm not even actually sure how to, but apologies if this would have been better posted elsewhere. Ezra Fox🦊 • (talk) 01:51, 15 December 2025 (UTC)[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]
Don't avoid red links.
WP:REDLINK: Red links help Wikipedia grow.
See WP:REDYES for more. Paradoctor (talk) 11:07, 15 December 2025 (UTC)[reply]


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

Some of them, especially the academic degrees (Master of Science etc.), seem unnecessarily linked. Gawaon (talk) 09:31, 16 December 2025 (UTC)[reply]
Please note: what you talk about is WP:OVERLINK, not WP:SEAOFBLUE. Different things. SEAOFBLUE is about adjacent links that look like one, which can happen with entirely appropriate links. Paradoctor (talk) 12:08, 16 December 2025 (UTC)[reply]
fixed. Graywalls (talk) 18:18, 16 December 2025 (UTC)[reply]

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

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

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

Section-linking options are links (piped or otherwise), redirects, and the {{Section link}} template, which also generates the paragraph (§) character.
(if you want our MOS to remain be open to hash marks in article space section links)

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

Section-linking options are piped links, redirects, and the {{Section link}} template, which also generates the paragraph (§) character. Avoid unpiped links which display the hash (#) character.
(if you want our MOS to be clear about discouraging hash marks in article space section links)

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

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

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

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]
Support first version. Nikkimaria (talk) 14:13, 4 January 2026 (UTC)[reply]
@CapnZapp: Now I'm a bit confused by your later edit since as it currently stands the MOS does not "remain silent on the issue", rather it seems to effectively forbid unpiped links, by mentioning only piped ones among the valid/recommended options. So keeping the status quo is not silence, though it's a fairly quiet (easy to overhear) way of speaking. Gawaon (talk) 16:17, 4 January 2026 (UTC)[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 for it seems to effectively forbid unpiped links that's exactly the conundrum - I would argue it quite ineffectively forbids them, by being far too obscure. The prohibition is so "hidden" that I'm almost questioning the intent. Which is exactly what this talk section is about. Don't prohibit things by omission - if you want something barred, spell it out!
Sorry if my later edit made it appear I was less direct than I intended to be, I keep standing by my opening statement: "I cannot interpret this as anything else than a discouragement (or outright prohibition) on section links whose hash character isn't [replaced or omitted]". I just had to read the sentence more than once to see this, which is effectively what I want improved here. CapnZapp (talk) 11:29, 5 January 2026 (UTC)[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 a change rather than preserving status quo. Can I ask if you agree or oppose this train of thought? It would help clarify what you meant by your sentiment. Regards, CapnZapp (talk) 11:33, 5 January 2026 (UTC)[reply]
I don't agree that there is currently a disallowance, and prefer wording that makes that clear. Nikkimaria (talk) 00:19, 6 January 2026 (UTC)[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]
Why are we holding a parallel discussion? Please see Wikipedia talk:Manual of Style/Layout#RFC: Piped links in "See also" sections, or at the very least, Wikipedia talk:Manual of Style/Layout#c-Redrose64-20251207121500-Beland-20251207013900. --Redrose64 🦌 (talk) 18:05, 5 January 2026 (UTC)[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 sure mentions the hash tag vs the slink template, but I can't see how it clearly answers what I'm asking here. Posters do implicitly assume things about styles and such, but I am no expert on Wikipedia MOS history... which is why I am asking a direct question here and now. Why or how do you feel this discussion you linked is more than adjacent to a point where it is directly relevant to ours? (Are you even saying this discussion should not happen here, because it is happening there...? Maybe I'm misunderstanding your question?)
The second link is directly to a post of yours: Wikipedia uses that syntax for linking to sections because it's being used for exactly its design purpose. I obviously know HTML syntax. Do note that it does not necessarily follow that just because HTML does something a certain way, we should blindly assume Wikipedia does it the same way. It does appear you are saying you prefer our MOS allow hash marks in section links - is this correct? (Pro tip: you could just have said so rather than to link to a, to me, chiefly unrelated discussion thus forcing me to parse that entire context) Back to the point, Redrose64: are you saying you agree the wording currently does not seem to allow it? And do you then prefer we change our wording to explicitly allow it? Your clarity and directness would be welcomed. CapnZapp (talk) 12:02, 6 January 2026 (UTC)[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 a raw section link, but with how to make a piped section link – admittedly you see that only thanks to the example, but then, examples always an important part of our instructions. Gawaon (talk) 12:18, 6 January 2026 (UTC)[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't say such a thing. But the point remains that it doesn't show how to make unpiped section links either. People can easy guess that that works too, as indeed it does – but for all you know after reading just that section, if you omit the |Displayed text part, an "error: unpiped section link" message could appear. Gawaon (talk) 14:26, 6 January 2026 (UTC)[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]
Given we seem to be heavily leaning in that direction, I've gone ahead and put the second version into the guideline. -- Beland (talk) 08:27, 9 January 2026 (UTC)[reply]
Thanks. I should note I stumbled upon Wikipedia:Manual of Style/Linking#Piped links to sections which was much more clear already. I've updated H:SECTIONLINK accordingly. Regards, CapnZapp (talk) 15:48, 9 January 2026 (UTC)[reply]

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

I'd use the former, it looks cleaner to me. And it has the advantage of not needing a piped link. Gawaon (talk) 14:54, 8 January 2026 (UTC)[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 former (w/o abbrev). MOS:MORELINKWORDS doesn't apply here. —Bagumba (talk) 19:03, 8 January 2026 (UTC)[reply]

A question

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.
Discussion continues at an RFC at WP:VPM § RFC: Baltic bios infoboxes question. — Jähmefyysikko (talk) 17:11, 16 January 2026 (UTC)[reply]

In the infobox of Kaja Kallas, under birthplace. How should it be linked? -

GoodDay (talk) 03:06, 14 January 2026 (UTC)[reply]

The latter. Nikkimaria (talk) 03:08, 14 January 2026 (UTC)[reply]
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]
The 2025 RFC on Baltic bios infoboxes, has consensus for (in this case) "Tallinn, Estonian SSR, Soviet Union", fwiw. Thus my question, about linkage. GoodDay (talk) 06:53, 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 violated MOS:GEOLINK. — Chrisahn (talk) 07:57, 14 January 2026 (UTC)[reply]
If you want to challenege the RFC decision? go to WP:AN. GoodDay (talk) 12:56, 14 January 2026 (UTC)[reply]
I'm aware of that RFC, but local 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 not not 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]
So it's "Tallinn, Estonian SSR, Soviet Union". GoodDay (talk) 12:56, 14 January 2026 (UTC)[reply]
If I understand Beland’s message here 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 the form of the entry, without explicitly covering linking at all. So the form 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]
That was not an option in the RFC-in-question. GoodDay (talk) 15:07, 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 mentioned MOS: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]
There was a simultaneous conversation at Wikipedia talk:Manual of Style/Infoboxes#Baltic birth places and linking, which I just closed to continue the conversation here. -- Beland (talk) 18:52, 14 January 2026 (UTC)[reply]

There's inconsistencies on this matter, across Wikipedia. GoodDay (talk) 03:13, 14 January 2026 (UTC)[reply]

I don't disagree that there are inconsistencies, but the guideline is pretty clear (MOS:GEOLINK). Danbloch (talk) 06:27, 14 January 2026 (UTC)[reply]
Clarify, please. As no link to Estonian SSR in the infobox, makes a reader's search, tougher. GoodDay (talk) 06:34, 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]
"Tallinn, Estonian SRR, Soviet Union" - thanks @Danbloch: for your answer. GoodDay (talk) 18:19, 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 of Austria-Hungary ([[Kumrovec]], then part of [[Austria-Hungary]]).
-- Beland (talk) 00:28, 15 January 2026 (UTC)[reply]
That would likely be an option in a future RFC on this matter, for the Baltics. GoodDay (talk) 00:44, 15 January 2026 (UTC)[reply]
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 by Indrek, but this does not link the largest polity, which I think is required by MOS:GEOLINK because the USSR no longer exists. (And our article is Soviet 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 by GoodDay, but this does not link the largest polity as required by MOS:GEOLINK and does not include the recommended separating text.
  • "Tallinn, then part of Estonian SSR, Soviet Union" was proposed by Nikkimaria
The Nikkimaria option is the only one so far that seems to comply with MOS: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]
The latter two are acceptible options. The first option is cumbersome. GoodDay (talk) 01:13, 15 January 2026 (UTC)[reply]
There still seems to be some confusion here. MOS:GEOLINK does not require linking the largest polity. Danbloch (talk) 01:29, 15 January 2026 (UTC)[reply]
Woul you please show us, using our examples? GoodDay (talk) 01:32, 15 January 2026 (UTC)[reply]
Any of the three suggestions above ("Tallinn, Estonia, then occupied by USSR", "Tallinn, Estonian SSR, Soviet Union", or "Tallinn, then part of Estonian SSR, Soviet Union") are in accord with MOS:GEOLINK. Per MOS:GEOLINK's Kumrovic example, the last of these is probably preferred. Danbloch (talk) 02:57, 15 January 2026 (UTC)[reply]
Yes, the last one seems fine. Its only disadvantage is that it's a bit long. Gawaon (talk) 03:01, 15 January 2026 (UTC)[reply]
Thanks, Danbloch. The last two are viable options, concerning my reason for having come here. GoodDay (talk) 03:06, 15 January 2026 (UTC)[reply]
I proposed the first option because I think "then occupied by" presents a more neutral summary of the situation than "then part of". Note also that MOS:GEOLINK does not say it has 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 to MOS:PLACE, it should be "Soviet Union", not "USSR".
In light of this, I would change the first option to "Tallinn, Estonia, then occupied by Soviet 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 at Talk: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]
OK, but on that point we are already settled. Gawaon (talk) 14:21, 15 January 2026 (UTC)[reply]
What about "Tallinn, then administered as part of Estonian 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]

GoodDay has opened a parallel RFC at Wikipedia:Village pump (miscellaneous)#RFC: Baltic bios infoboxes question. Jähmefyysikko (talk) 20:53, 15 January 2026 (UTC)[reply]
A "parallel RFC" means two (or more) RFC concurrently running. That's not the case, here. GoodDay (talk) 20:56, 15 January 2026 (UTC)[reply]
Sure, but it is certainly a discussion parallel to this one. This is also not the first restart of the discussion you've done, as Wikipedia talk:Manual of Style/Infoboxes#Baltic birth places and linking was running when you decided to open this one here. I do consider this inappropriate. Jähmefyysikko (talk) 21:02, 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 at WP:VP? Indrek (talk) 21:20, 15 January 2026 (UTC)[reply]
I'm not. GoodDay (talk) 21:25, 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" ([2], [3]).
I agree with Jähmefyysikko's observation that this is starting to look like forum shopping. Indrek (talk) 21:41, 15 January 2026 (UTC)[reply]
It's not forum shopping & I'm willing to add options to the RFC, if given clearance there. GoodDay (talk) 21:45, 15 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.
allikas: https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style_(links)