Wikipedia talk:Manual of Style/Layout/Archive 13

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Archive 15

Single subsections

FYI

 – Pointer to relevant discussion elsewhere.

There's a rather lengthy ongoing thread at Wikipedia talk:Manual of Style/Film § To be or not to be a subsection

While much of it is mired in fallacious "WP must do exactly what The Chicago Manual of Style says, or else" nonsense, it may be worth discussing in more salient terms whether WP articles should ever use subsections then the section in question does not contain two or more. I'm pretty sure I know what the answer is, but the discussion should still happen, and should have broader input than the 5 or so people currently debating it, especially if a WP:POLICYFORK could possibly result, with MOS:TV diverging from MOS:LAYOUT on a topical basis for no legitimate reason.  — SMcCandlish ☏ ¢ 😼  18:22, 28 June 2018 (UTC)

See also - piped links

Just came across a good example of this, where a useful and logical See Also for the 2018 Amesbury poisonings article would be Poisoning of Sergei and Yulia Skripal. That article is linked within the lead of the 2018 Amesbury article, but only as a piped link (at time of writing, "same kind used in the poisoning of ex-Russian spy"). I would suggest that as the casual reader may not 'get' piped links, and would certainly expect to see the Skripal article referenced, and would want to perhaps go there next, it would be reasonable and user-friendly to have a See Also section that includes a link to the Skripal article. I'd like to propose a modification to WP:SEEALSO, where "As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes." is expanded a little bit to note piped links don't necessarily count as 'appearing' - again, bear in mind we write for the casual reader, not editors. Not hung up on the wording, and people may not think it's a good idea, but I think it's a suggestion worth making. Fish+Karate 12:15, 5 July 2018 (UTC)

I'd oppose that. The problem in your example is thoughtless piping. The construct "same kind used in the poisoning of ex-Russian spy", or similar, would clarify the link. -- Michael Bednarek (talk) 13:27, 5 July 2018 (UTC)

The fuller sentence is "same kind used in the poisoning of ex-Russian spy Sergei Skripal" - piping it in your way would have two blue links next to one another ("same kind used in the poisoning of ex-Russian spy Sergei Skripal") which is a no no (per WP:SEAOFBLUE). Fish+Karate 13:45, 13 July 2018 (UTC)

"same kind used in the poisoning of ex-Russian spy Sergei Skripal" -- Michael Bednarek (talk) 14:49, 13 July 2018 (UTC)

Linking to Commons - now deprecated?

Re [1] and the removal of Commons link boxes.

Has the easily-recognised Commons link box now been deprecated in favour of an indistinct listing in the packed LH sidebar? Presumably this is now populated by some incomprehensible bit of wikidata. Andy Dingley (talk) 20:43, 15 July 2018 (UTC)

Geographic boxes

Hi. I would like to propose that geographic navigation boxes (with links to surrounding neighborhoods, cities, communities, etc.) be allowed within the "Geography" section of any given article. Because of the way these boxes are laid out (showing directions as on a map), they would be helpful for visualizing the general relationship of one place with another. Thank you, and I am looking forward to hearing from you. BeenAroundAWhile (talk) 20:21, 18 August 2018 (UTC)

Can you point to an example, or sandbox one please? EEng 23:05, 18 August 2018 (UTC)

Notice of RfC on single subsections

An issue related to single subsections, which watchers of this page may be interested in, is now up for discussion in an RfC which can be found at Wikipedia talk:Manual of Style#RfC on single subsections. Feel free to come and participate. - adamstom97 (talk) 00:21, 26 August 2018 (UTC)

See also - flag icons

I found a flag icon farm in the "See also" section of Flag of Tuva, which I've removed per WP:ICONDECORATION. Is this something that has been discussed before, and should it be specifically allowed or disallowed? Thanks. - BilCat (talk) 01:32, 29 August 2018 (UTC)

I don't think we've had any discussion regarding flag icons in See also sections. This is a general layout guideline and I'm of the opinion that it shouldn't speak to specifics such as this. Regarding the specifics, doesn't WP:ICONDECORATION already cover this subject? Butwhatdoiknow (talk) 17:24, 31 August 2018 (UTC)

OK, thanks. - BilCat (talk) 23:19, 31 August 2018 (UTC)

Major flaw in WP:NOTSEEALSO

There is a major flaw in the consideration of "See also". This manual of style has a WP:NOTSEEALSO which states that if there is a blue wiki-link then that referred article should not be in the see also.

The end result is that a major, significant "see also" candidate is disqualified but a moderate or minor "see also" candidate appears.

It is easy to miss a wiki-link but the see also section is very prominent. This leads to many fights on Wikipedia. In the recent 2-3 weeks, I have seen fights about the Humboldt Broncos bus crash and Southwest Airlines Flight 1380. (The bus crash was where more than half of the hockey team was killed in a bus crash and a related Broncos team had a fatal bus crash years ago, which was the see also candidate. The Southwest Airlines incident was very similar to another Southwest incident where a fan blade tore through the fuselage and the plane was just a few numbers different in registration number).

In both examples, the see also entries that survived are remotely related but the single example that did not survive the see also debate (because of this MOS cited) was a very similar incident that has been cited many times in news reports.

I propose that if there is a very strongly related incident or article, the WP:NOTSEEALSO does not apply. This would help the reader. Vanguard10 (talk) 19:15, 22 April 2018 (UTC)

• Oppose "See also" sections may display something more prominently but to the same degree demote the importance of what is being displayed. "See also" sections are meant to be brief, limiting how thoroughly connections between related topics can be investigated. In the case of the Humboldt Broncos bus crash, two deadly tragedies are very strongly culturally linked, and much discussion has erupted concerning both of them at once. It is my belief, as well as that of others, that this discussion is significant enough to be covered in the article. However, the most we can do for "See also" is devote a single sentence to a topic; entire paragraphs, naturally, are prohibited down there. Therefore, the increased prominence of a link comes at the cost of further potential coverage or attempts to tie it into the main topic of the article's discussion. WP:NOTSEEALSO is intended to reduce redundancy; if something can be in both places at once, in "See also" and further up, then it can be further up in much greater detail, and deserves to be. In which case it should be prominent enough that a "See also" link is not needed, and would therefore be redundant. In a way, "See also" sections are trying to, as much as possible, eliminate the need for their own existence.This is not me trying to WP:FORUMSHOP or WP:BLUDGEON; I am merely reiterating here to help kick-start the discussion, as well as so people don't have to head back to Talk:Humboldt Broncos bus crash#See also, which was the main impetus for this discussion here. Zeke, the Mad Horrorist ^{(Speak quickly)} _{(Follow my trail)} 05:06, 23 April 2018 (UTC)

The above oppose might really be a support. Zeke seems to not want complete reliance on see also. Rather than only vote, I propose mostly discussion. Zeke seems to suggest that in addition to see also, an important related article should be linked within the body of the article. I agree. That would seem like a "support" to me. Vanguard10 (talk) 03:17, 24 April 2018 (UTC) Stricken by me. Vanguard10 (talk) 05:00, 24 April 2018 (UTC)

First, please take it easy with the indentations. I've fixed them for you.

Second, that is not what I said. I'm saying if it can be in both places, then it should only be in one, and that's not the "See also" section. Zeke, the Mad Horrorist ^{(Speak quickly)} _{(Follow my trail)} 03:27, 24 April 2018 (UTC)

Oh, sorry. I've stricken my comments. If in the text, you mention that it "should be prominent enough". In that case, perhaps WP:NOTSEEALSO should not ban a "see also" list if there is a mere blue link but if there is a blue link and paragraph? In other words, the mention in the text must be blue-link and significant enough, as defined by having a separate paragraph. You see, I brought up the topic for discussion, not a simple support/oppose vote. Thank you for your idea. Vanguard10 (talk) 05:00, 24 April 2018 (UTC)

• Alternative. I think the policy should be changed to say that if the "See also" section contains many instances of a certain category (e.g. other flights that crashed in the same way) then it should include all more significant instances of that category, even if they are also blue-linked in the article. This would avoid the problem of a reader perusing the "See also" section missing the most important instances. CapitalSasha ~ talk 17:08, 23 April 2018 (UTC)

I also think CapitalSasha's comments are a support because of the idea that a very significant instance can be blue-linked in the article AND also appear in the "see also" section. Vanguard10 (talk) 03:17, 24 April 2018 (UTC)

• Oppose The section is see also, not see again. A proper see also section very often only contains lists of... because these, while relevant to many articles, are very difficult to link to in prose w/o a clunky piping. Primergrey (talk) 01:36, 1 September 2018 (UTC)

Why is is "proper" to exclude highly relevant repeat links in See also? Butwhatdoiknow (talk) 18:17, 1 September 2018 (UTC)

Because the see also section is for relevant blue links that do not appear in the article. The also in see also means just that. Also, in addition to, further all indicators of novel, not repeated, content. Primergrey (talk) 15:23, 2 September 2018 (UTC)

You state a conclusion, not a rationale. What is the rationale for making it difficult for a reader to find a "very strongly related incident or article" in the See also section? Butwhatdoiknow (talk) 16:59, 2 September 2018 (UTC)

The conclusion, or consensus, has already been arrived at. The unambiguous wording as to the purpose of a see also section as, I must assume, agreed upon by the community. Speaking of which, as this proposal would significantly alter a long-standing guideline and would affect millions of articles, an RFC might be the way to go. Primergrey (talk) 18:27, 2 September 2018 (UTC)

"We've always done it that way" is not a particularly strong argument. Butwhatdoiknow (talk) 00:37, 3 September 2018 (UTC)

There actually was an RFC last year [[2]]. Rejected with a "strong consensus". Primergrey (talk) 18:33, 2 September 2018 (UTC)

"We've looked at this recently and rejected it" is a winning argument. Butwhatdoiknow (talk) 00:37, 3 September 2018 (UTC)

• Support especially on long articles readers look at selected sections and may well miss the link altogether. I think it is more important to emphasize the most useful links than to worry about a duplicated link. Rjensen (talk) 02:01, 1 September 2018 (UTC)
• Support because it benefits the reader. Butwhatdoiknow (talk) 18:17, 1 September 2018 (UTC)

Having a laundry list of repeated links that compete with and obscure the links that do not appear in the article is no benefit to any reader. Primergrey (talk) 15:23, 2 September 2018 (UTC)

What you say is certainly true. However, it doesn't speak to the proposal to make it clear that a "very strongly related incident or article" (not a "laundry list") can be repeated. Butwhatdoiknow (talk) 16:59, 2 September 2018 (UTC)

If a link is that vital to the topic, first, it will probably be explained in the article, and second, it is sure to have the link in the lead, one in the body, and one in the infobox (if any). You are basically proposing a link synopsis section. Primergrey (talk) 18:27, 2 September 2018 (UTC)

First of all, it isn't my proposal. Secondly, yes, the proponent is advocating for a synopsis of "strongly related" links. I think that is a good idea but, as you point out above, the community has recently rejected a similar proposal. Butwhatdoiknow (talk) 00:37, 3 September 2018 (UTC)

My mistake about the OP. Apologies for that. Primergrey (talk) 01:58, 3 September 2018 (UTC)

• Oppose WP:NOTSEEALSO already states, "As a general rule, the "See also" section should not repeat links ..." It is exactly that, a general rule that usually applies, not a rule that must be blindly followed. Use common sense. WP:IAR is always the case anyways, even if it wasn't already clear in calling it a "general rule".—Bagumba (talk) 15:51, 2 September 2018 (UTC)

Navigation templates to the bottom

I'm looking over the layout guideline, and I don't see it explicitly mentioned, but navboxes are supposed to be positioned at the very bottom of articles, correct? Abductive (reasoning) 18:14, 11 September 2018 (UTC)

Not necessarily. They can be placed to the side as they are at the top of Feminism. Otherwise yes, they generally go at the bottom. If it's a stub, technically the stub template is supposed to be at the very bottom, below the navboxes, but I don't normally do that personally, because I think it looks quite stupid. GMG^talk 18:21, 11 September 2018 (UTC)

@Abductive: To specify, horizontal navbars belong at the bottom of articles, but vertical navboxes can be placed within the body of an article (as in Jesus#Life and teachings in the New Testament; though I move them if they are in the "See also" section). See MOS:SECTIONORDER, though like GreenMeansGo I disagree with certain elements of that, as I find it illogical that items that appear/display at the top of an article (coordinates, and good and featured article markers) should be placed at the bottom. I favor a consistent layout, with (as long as it's logical) the same elements in the same place throughout Wikipedia articles. —DocWatson42 (talk) 03:24, 12 September 2018 (UTC)

Where does it say that stub templates go below the horizontal navigation templates? Abductive (reasoning) 03:48, 12 September 2018 (UTC)

It says it in MOS:ORDER, where the stub templates are at the end of the "Bottom matter" list. It's reallly useful for stub templates to be listed in one consistent place as it makes it easier for stub-sorting and reduces the chance that someone will add a specific stub tag without removing {{stub}}. PamD 08:00, 12 September 2018 (UTC)

LAYOUTEL

Hello, is there a purpose for specifying at MOS:LAYOUTEL that "External links" must always be plural even if only a single link is added? Kind regards, Cavalryman V31 (talk) 18:22, 9 September 2018 (UTC).

I don't know the historic answer, but here is one I just made up: consistency. That and the risk that the editor who adds the second link won't change the heading to the plural. Okay, that's two I just made up. Butwhatdoiknow (talk) 02:13, 10 September 2018 (UTC)

So we apply the English language incorrectly and assume incompetence, they seem two very poor reasons. Cavalryman V31 (talk) 22:04, 10 September 2018 (UTC)

Perhaps. But keep in mind that assuming incompetence does have its place. Butwhatdoiknow (talk) 02:23, 11 September 2018 (UTC)

Not so sure it's applying anything "incorrectly". If, for example, there were only one featured article candidate, that wouldn't suddenly make the page Featured article candidates mis-titled. Primergrey (talk) 02:53, 11 September 2018 (UTC)

Same as for "References" - if we started with it in the singular people wouldn't notice and/or bother to change it when adding another, so having it plural all the time works fine. PamD 08:20, 12 September 2018 (UTC)

Why do links to sister projects appear in "External links" rather than "see also?"

THis is a thing this manual mentions, but doesnt explain the reasoning behind this guidance. Might I ask why is that so and why are Wiktionary and Wikisource exceptions to this rule? (but not eg Commons) 2A02:A317:2241:7A00:9F4:3E9A:A783:B4FC (talk) 00:31, 4 November 2018 (UTC)

They appear in the last section of the article, whatever name that happens to have; see Template:Sister project#Location. --Redrose64 🌹 (talk) 14:01, 4 November 2018 (UTC)

Okay, let's rephrase the question: Why do they appear in the last section rather than in the See also section? Butwhatdoiknow (talk) 17:02, 4 November 2018 (UTC)

See also is for links to Wikipedia. --Izno (talk) 17:09, 4 November 2018 (UTC)

Except for Wiktionary and Wikisource, which still appear in "See also", even though they're not links to Wikipedia. Why? 2A02:A317:2241:7A00:6157:606A:7BD5:B88B (talk) 20:20, 4 November 2018 (UTC)

You are misreading the section in question. It gives an exception to Wiktionary and Wikisource links to appear in the main text of the document, not in the "See also" section. --Izno (talk) 21:01, 4 November 2018 (UTC)

Reference {{annotated link}} in See also sections.

Project page recommends annotating links in see also section. This can be done automatically by using the {{annotated link}} which annotates the link using the content of the {{short description}}. I propose to mention this as a convenient option. · · · Peter (Southwood) ^(talk): 07:48, 27 November 2018 (UTC)

Sounds like a good idea to me. Butwhatdoiknow (talk) 17:14, 27 November 2018 (UTC)

Different POV on NOSEEALSO

Currently, regarding "no See also" this page reads The "See also" section should not link to pages that do not exist (red links), nor to disambiguation pages (unless used for further disambiguation in a disambiguation page). As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes. I disagree fully: the beauty of Wikipedia over previous encyclopedias is that it allows super-quick cross-referencing, while the "See also" sections should serve to call out important elements for further reading – especially for people who are often "clicking through" a document and are susceptible to missing the big picture. Which is to say, I'd like to see the NOSEEALSO policy changed. Any responses? If any agreement, can fellow Wikipedians guide me as to how to recommend and get that change made? Gratefully, Aboudaqn (talk) 16:02, 24 November 2018 (UTC)

I agree with you. Unfortunately, making the change you suggest would be an uphill battle. See Wikipedia:Manual_of_Style/Layout#cite_note-9. Butwhatdoiknow (talk) 17:41, 24 November 2018 (UTC)

"...especially for people who are often "clicking through" a document and are susceptible to missing the big picture". Who is deciding an article does not contain the information they are looking for after only skimming through it? No amount of links anywhere will help such an attention-deficient character. At some point these people, whoever they are, must actually read an article to get information on a subject. Primergrey (talk) 19:04, 24 November 2018 (UTC)

That's crazy talk. Hawkeye7 (discuss) 23:34, 15 January 2019 (UTC)

I understand your question to be: Who would decide what links we would need in See also for those who just skim an article? I'm thinking the answer is: "Whether a link belongs in the 'See also' section is ultimately a matter of editorial judgment and common sense." (From Wikipedia:Manual_of_Style/Layout#"See_also"_section.) Butwhatdoiknow (talk) 17:35, 26 November 2018 (UTC)

Recent change to where to place links

A box-type template can result in excessive white space and serious legibility concerns when placed in the reference section.

• We seen to have a flurry of edits to this section today....removing info about nav boxes as per WP:NAVBOX and recommending putting it in the reference section dispte the fact we give the example of what happens when we do this. Not sure if you guys are in a dispute somewhere but we've just removed a recommendation refetcted in another MOS and added something that causes a format problem. I'm pretty sure no one wants to have accessibility concerns by breaking up sentences and sandwiching our references..... are references one of the most important features of an article.--Moxy (talk) 22:27, 15 January 2019 (UTC)

And your response to your navbox change being reverted is just to start being disruptive for the sake of it. I've got no dog in your little game, but I'm damned if I'm going to sit here. Andy Dingley (talk) 23:44, 15 January 2019 (UTC)

What an odd comment... if your in some fight somewhere best keep it there. Very odd reply to a wish to talk about changes. I can only assume you think I am someone else.--Moxy (talk) 23:57, 15 January 2019 (UTC)

Your change re not embedding sister project links into a navbox has just been reverted (not by me). But you've chosen that as an excuse for a fit of pique and to start bulk reverts, including some quite unrelated text improvements. Andy Dingley (talk) 00:09, 16 January 2019 (UTC)

So It's all because your mistaken.....I did not revert my addition of the removal of the navigation box info.....I reverted the addition about references you added 2 times. As you can clearly see I am the one that restored the stable version. So what really happened is you added back 2 different disputed content one of them 2 times .....where no one else has. You added back the navbox info after it was removed and added the stuff about the ref section 2 times. So let's start all over shall we.--Moxy (talk) 00:23, 16 January 2019 (UTC)

I don't understand the reasoning behind not having a consistent section for sister project links, or why it's a "bad thing" if they are placed in an "empty" "External links" section. (Sister project links are external links, so if they are there, the section is not empty.) I'm not trying to be contrarian here for it's own sake. I just believe that not being consistent is more confusing than having an "empty" section, and am asking if there is some higher reason I'm overlooking. - BilCat (talk) 23:14, 15 January 2019 (UTC)

I have always wondered where this rule came from.... just because of the fact we made the inline sister template just for this reason to make it the first line in external link section on the left.. Perhaps outlining some of these problems... see if we can get some change based on common sense.--Moxy (talk) 00:02, 16 January 2019 (UTC)

• No, we did not make a competely different inline version of the sister boxes, just so they'd be somehow "better" in an empty External links section.

If there's an issue with {{Reflist}} not using the full column width if there's a floating box involved, then that should be fixed within Reflist's column model. But if it isn't, then use a {{-}} or {{Clear right}} to fix it and don't break the sister link boxes. Andy Dingley (talk) 00:09, 16 January 2019 (UTC)

No one said the inline version was made just to fill an empty section? Not sure adding a clear all over is fesable....but adding a {{Clear right}} to the start of yhe ref template would make the most sense in my view.--Moxy (talk) 00:35, 16 January 2019 (UTC)

• we made the inline sister template just for this reason??

There's usually no difference between {{Clear right}} and {{-}}, unless there are images floated to the left. If there are, {{-}} (or {{Clear left}}) are usually needed before References (or See also, or anything with a list) anyway. Andy Dingley (talk) 01:23, 16 January 2019 (UTC)

Odd to quote just half the statment ...but I guess I was not clear....my bad. So we have one solution that needs to be implemented before we add to the section about refs. So what about the external links? Should we mention this here as we do at the other MOS page? Still not sure why it was removed but hopefully they will reply soon.--Moxy (talk) 01:31, 16 January 2019 (UTC)

A sister project box template is not a reference, so should not go in References section. It is an external link (external to English Wikipedia anyway), so External links would be a reasonably rational place to put it. If it is in External links, the External links section is not empty, it contains an external link to a sister project. A bar style may look better, but the place is reasonable. There may be other, better places, but External links seems a reasonable option based on logic.

I would prefer to see a section dedicated to navigational tools, which would include navboxes, portal links, sister project links, regular external links, and most other navigational tools, both internal and external, clustered at the bottom of the page, where people will get to expect to find them, but that is another issue. · · · Peter Southwood ^(talk): 14:58, 16 January 2019 (UTC)

See also

I am confused by this, I tried to add an internal link to Star Wars: Knights of the Old Republic and Star Wars Knights of the Old Republic II: The Sith Lords for see also because technically it's not on the page for specialist browsers or mobile view however ferret removed them quoting MOS:SEEALSO , but nav-boxes disregard WP:ACCESS for disability readers. So whats the best out come to help a reader get to page for the characters? Govvy (talk) 23:56, 22 January 2019 (UTC)

Scan this talk page you can see this is a frequent topic, with a section above from only two months ago. The argument that "Mobile doesn't see it" would simply throw this rule and many other MOS guidelines to the wind. I'm in camp "well why AREN'T navboxes on mobile?" -- ferret (talk) 00:07, 23 January 2019 (UTC)

Yes time for an update ....as more then 50% of our readers don't see templates of this nature because of mobile view limitations.... with another 10% because of disability problems not being able to use the show button. Should be added if it's beneficial to all readers but all links should be discussed if there's a dispute..... with the concept of it being in the navbox being null and void during a dispute of this nature because the majority of readers don't see. Just cuz it's in a box is no reason for not to be in see also.--Moxy (talk) 00:10, 23 January 2019 (UTC)

Sorry, didn't notice the above discussion, I do get annoyed at navboxes sometimes due to being colour blind and people making them in annoying colours. This is partly why I avoid navboxes. Govvy (talk) 00:16, 23 January 2019 (UTC)

Off topic...Many of us that use Google on our 60+ inch TV's and have color vision problems add the Google "Dark Mode"app here. It gives you a toggle button to turn it on and off whenever you wish on any page.--Moxy (talk) 00:39, 23 January 2019 (UTC)

Another See Also question

Please see the discussion at Talk:Kidnapping_of_Jayme_Closs#Joseph_E._Duncan_III about whether a certain link belongs in that article's SEE ALSO question. Giving us your take would be appreciated. --В²C ☎ 23:28, 24 January 2019 (UTC)

Hiding the TOC

Help:Section § Hiding the TOC is linked from here and shows how to hide the TOC. I don't find any information here or there about when it is appropriate to hide the TOC. François Robere claims a TOC is unneeded for a short stub. Disregarding the fact that this example is not particularly short, is this a valid reason to use __NOTOC__? ~Kvng (talk) 14:51, 16 February 2019 (UTC)

No, not really. --Izno (talk) 15:05, 16 February 2019 (UTC)

Presumably you have some policy or guideline to back this up? François Robere (talk) 16:41, 16 February 2019 (UTC)

In general, tables of contents are aids to accessibility, so if you want the general point, WP:ACCESS. --Izno (talk) 16:45, 16 February 2019 (UTC)

It's true that TOCs can be useful for accessibility, but that too assumes there's some length of text to navigate. If the whole article fits within a single page or a single screen, then adding a TOC isn't necessarily helpful, and might even be counter productive - adding more tab points and text where they're not necessarily needed, and even pushing the text beyond the limits of a single screen. François Robere (talk) 21:06, 16 February 2019 (UTC)

If an article has fewer than 3 (at least I think it's 3) headings then the table of contents won't appear even without __NOTOC__. As François Robere argues, having a table of contents in the case of a very short article with 3 or more headings can be a distraction. (I would say "minor" distraction; François Robere probably disagrees.) However, solving this problem with __NOTOC__ creates a new problem: when the very short article becomes longer article it won't have a table of contents until someone figures out there is a hidden __NOTOC__. Weighing the costs and benefits of (a) a very short article with a table of contents and (b) a longer article without one, I favor (a). Butwhatdoiknow (talk) 23:43, 16 February 2019 (UTC) P.S. - It occurs to me that François Robere's "fits within a screen" rule would vary in application depending upon whether one is viewing the article on a small smart phone or a wide screen TV. Butwhatdoiknow (talk) 23:46, 16 February 2019 (UTC)

That's a valid concern, but I don't think it's much of an issue. If one spends enough time expanding a short article, one is bound to encounter the __NOTOC__ directive - look how visible it is here; and in an article it's placed directly after the lead, which would itself be edited.

Regarding "fits within a single screen" - smartphones get a different version of the site, that ignores TOC directives. Tablets', desktops' and notebooks' resolutions are usually given by the browser.[3] You can see how the page looks at these two resolutions - a middle of the road 1280x720 pixels and a small 1024x768 pixels; you can see the TOC creates a lot of empty vertical space without actually improving navigation. François Robere (talk) 13:23, 17 February 2019 (UTC)

@Butwhatdoiknow: according to Help:Section § Hiding the TOC, the magic number is 4. An article with 4 or more headings will, by default, have a TOC. This seems to work well for articles I've worked on. Even if we're "wasting" vertical space in some edge cases, having a consistent visual layout for articles is beneficial. Despite improved efficiency, a dense wall of content without whitespace is also not clearly an improvement. A truly short article with 4 short sections could be better improved by combining or expanding sections than removing the TOC using __NOTOC__. The maintenance issue is not to be discounted; Articles typically grow by small increments and it is likely that __NOTOC__ will be overlooked in the process. With regard to screen size, this does vary a lot more than François Robere's examples indicate; For one thing, not everyone uses their browser in full-screen mode. ~Kvng (talk) 14:31, 17 February 2019 (UTC)

the magic number is 4 And why? Because of length - because an article with three sections or less is assumed to be short enough to navigate without a TOC. But what about an article with 4 tiny sections - a stub? It could be as short as a "regular" article with two sections.

having a consistent visual layout for articles is beneficial if that layout makes sense; the current layout is both wasteful and ugly. And it's not that inconsistent to hide the TOC: Some articles have infoboxes, some don't; some have hatnotes, some don't; some have pictures at the right, some have them at the left, and yet other have none at all; etc. etc. Hiding the TOC isn't that different.

a dense wall of content without whitespace is also not clearly an improvement The longest paragraph in that article is 96 words in five sentences. That's not a "wall of content".

A truly short article with 4 short sections could be better improved by combining or expanding sections than removing the TOC Probably, but its length won't necessarily change; and if it doesn't need a TOC for that length, how does the number of sections change it?

maintenance issue is not to be discounted I really doubt it. It's in all caps and just after the lead; it's much easier to miss eg. a typo or an English variant switch, yet we're still fairly consistent with those. Put differently: It's much uglier and more wasteful to the reader than it is to restore when the article grows longer.

With regard to screen size, this does vary a lot more than François Robere examples indicate Yes, many people use larger displays, where the text easily fits on one screen. For one thing, not everyone uses their browser in full-screen mode Which is even worse - how much vertical space will a TOC take then? A third of the screen? For what? Do you really need a TOC for two sections (the other two are the "see also" and "references", which no one bothers with anyway)? François Robere (talk) 15:49, 17 February 2019 (UTC)

I assume it is because a TOC with one entry is clearly not useful. Where does it become useful? 4 entries seems like a reasonable guess. ~Kvng (talk) 16:14, 17 February 2019 (UTC)

You don't seem to appreciate the value of consistency. Have a look at WP:ASTONISH. ~Kvng (talk) 16:14, 17 February 2019 (UTC)

Getting below 4 sections automatically hides the TOC. ~Kvng (talk) 16:14, 17 February 2019 (UTC)

For a larger display, there's plenty of room for the TOC and the entire article; No good reason hide the TOC in this case. If the entire article doesn't fit in a small browser window, the TOC is useful. ~Kvng (talk) 16:14, 17 February 2019 (UTC)

I assume it is because a TOC with one entry is clearly not useful What about one with two? The article in question has only two readable sections.

You don't seem to appreciate the value of consistency You didn't really counter my point: Articles vary much more than just the TOCs, so changing those won't affect consistency that much. Alternatively, if you so care about consistency, why not switch sides and hide TOCs where they're not needed?

Getting below 4 sections automatically hides the TOC You didn't counter my point: The "4 rule" is meant to reflect article length, not article structure. A TOC could be extremely useful in a long article with a few sections, and completely useless in a short article with many sections.

For a larger display, there's plenty of room for the TOC and the entire article Yeah, but if you're interested in accessibility you're not going check only against larger screens. But if you do have a big display then you're you don't really need the TOC, so why have it? It's bad design.

If the entire article doesn't fit in a small browser window, the TOC is useful Unless (again) it's the TOC preventing it from fitting in one window. In that case the TOC is harmful, and as I've already shown that's the case here.

Bottom line: For short articles the TOC is a poorly designed element that wastes a lot of space for very little utility. François Robere (talk) 19:56, 17 February 2019 (UTC)

Definition of "short"?

It seems that your solution to what you perceive as a design problem is to manually apply __NOTOC__ to "short articles". I believe your definition of "short article" is an article that "fits on one screen". Considering the many ways Wikipedia is published/rendered can you suggest an objective criteria for determining whether an article fits on one screen? ~Kvng (talk) 21:02, 17 February 2019 (UTC)

• If someone researches a topic and writes a new article which is currently short, they might choose to use NOTOC. Others might disagree but fighting a content creator over a style issue would not be helpful. However, no one should visit random pages and add NOTOC without an extremely good (WP:IAR) reason. Anyone arguing that would be desirable should open a widely publicized RfC at WP:VPR and get consensus that such activity would be worthwhile. Johnuniq (talk) 23:31, 17 February 2019 (UTC)

The typical estimate for the number of words in a printed, double spaced page in 250-300. Not including headers and references, that would make a good bar here as well. Alternatively, we can pick a cutoff resolution that would include eg. 95% or 99% of users across all devices, with a particular emphasis on accessibility, and work from there. I don't particularly care to do either, but if you want a standard there are ways to determine a reasonable one.

@Johnuniq: At the moment there's no policy nor guideline for how to use the NOTOC directive, and no one presented statistics on its use, so I don't think it reasonable to suggest one use is more "accepted" than the other and place the burden of proof on either user. But more importantly: All of yours assumption that editors should either accept MediaWiki layout errors or fix them manually, is wrong. What you should be suggesting is that WP:Vector and the underlying rendering engine are fixed such that TOCs aren't wasteful to begin with. François Robere (talk) 13:08, 18 February 2019 (UTC)

@François Robere: although I don't see a serious problem with how short pages are rendered, I appreciate that you do and I support you putting energy into advocating for improvements to the rendering software. I don't support any solution to this problem that results in editors going around and arguing over formatting minutia on an article-by-article basis. ~Kvng (talk) 14:20, 18 February 2019 (UTC)

You and I both! Thanks. François Robere (talk) 18:56, 18 February 2019 (UTC)

So does that mean we can remove __NOTOC__ from Digital current loop interface? ~Kvng (talk) 01:05, 19 February 2019 (UTC)

François Robere, do you propose two classes of editors: "content creators" and "layout editors"? If so, where would copy editors (who modify but don't "create") fall into that dichotomy? And what about someone who adds to the initial article, whould that person have authority to add a TOC? Butwhatdoiknow (talk) 17:48, 18 February 2019 (UTC)

That wasn't my comment... François Robere (talk) 18:56, 18 February 2019 (UTC)

Doh! You're right. My humble apologies. Butwhatdoiknow (talk) 23:26, 18 February 2019 (UTC)

Conclusion

It looks like this has run its course. I'm going to suggest we we have achieved consensus on two points:

1. __NOTOC__ should not be added to articles with more than three sections less than 4 sections
2. __NOTOC__ should not be added to articles that don't fit on one screen

I appreciate that we don't have a consensus definition of what "fit on one screen" means but we'll have to leave that for another day. I will update Help:Section#Hiding_the_TOC to reflect these points. ~Kvng (talk) 13:37, 20 February 2019 (UTC)

Regarding the first point: even without NOTOC no table of contents appears unless there are 4 sections; all that is accomplished by adding NOTOC to an article with 3 or fewer sections is assuring that no TOC will appear when the article grows unless someone notices and removes the NOTOC. Regarding the second point: I'll be fascinated to see how we can have a "fit on one screen" rule without a definition of "one screen." Butwhatdoiknow (talk) 17:26, 20 February 2019 (UTC)

My iPhone has a screen measuring two inches by three. That's not even enough for the lead section of today's featured article. --Redrose64 🌹 (talk) 21:40, 20 February 2019 (UTC)

@Butwhatdoiknow: Sorry I messed up #1 and have corrected. No reason to put __NOTOC__ on an article where it will have no effect.

@Redrose64: François Robere made a good point above with the observation that WP on an iPhone uses a different navigation scheme either with the WP app or the mobile version of the website. I doubt __NOTOC__ is relevant to these schemes. ~Kvng (talk) 22:22, 20 February 2019 (UTC)

I'm still concerned about "one screen" being the standard. I gather that, without a TOC, the short stub "Digital current loop interface" fit on to the screen of the editor who started this discussion. It did not fit on my 8.5" x 14.5" screen. (Full disclosure: for legibility I have my display set at 125%. Then gain, variances in display settings are another reason why "one screen" has no universal meaning.) Butwhatdoiknow (talk) 17:27, 23 February 2019 (UTC)

Yes, you reported that Digital current loop interface did not fit on your screen and so you removed __NOTOC__ from the article and no one objected. That's where I got the idea that we had consensus on "one screen". I hope the text I added to Help:Section#Hiding_the_TOC doesn't encourage anyone to add __NOTOC__ to articles; It is just trying to list the cases where we agree it is not appropriate. ~Kvng (talk) 00:19, 24 February 2019 (UTC)

Where to put a gallery?

Where could a WP:GALLERY be placed? There may be more options in the layout; if so then please indicate considerations. -DePiep (talk) 22:04, 20 February 2019 (UTC)

Wikimedia Commons. - BilCat (talk) 22:09, 20 February 2019 (UTC)

I'm serious. -DePiep (talk) 22:12, 20 February 2019 (UTC)

So am I. The best place for a gallery is on Wikipedia Commons. - BilCat (talk) 23:11, 20 February 2019 (UTC)

That was not my question. This is Wikipedia talk:Manual of Style/Layout. Please leave this discussion. -DePiep (talk) 23:19, 20 February 2019 (UTC)

It is unclear what do you mean with "WP:GALLERY". --Thinker78 (talk) 23:25, 20 February 2019 (UTC)

Then click the link I provided/you omitted. And read. -DePiep (talk) 23:27, 20 February 2019 (UTC)

The best place for a gallery is at commons. Are you asking how to move them?--Moxy (talk) 23:32, 20 February 2019 (UTC)--Moxy (talk) 23:32, 20 February 2019 (UTC)

It is still unclear what you mean. Why you say "a WP:GALLERY" and not "the WP:GALLERY" or "the gallery"? Generally editors shouldn't overlink, you linked once, that is good enough, folllowing MOS:OVERLINK, which can apply to talk pages also in my opinion. --Thinker78 (talk) 23:37, 20 February 2019 (UTC)

I did not say that. Please leave this thread. -DePiep (talk) 00:02, 21 February 2019 (UTC)

Rephrased

Where could a WP:GALLERY be placed? There may be more options in the layout; if so then please indicate considerations. -DePiep (talk) 00:02, 21 February 2019 (UTC)

WP:Gallery discourages galleries of images: "In articles that have several images, they are typically placed individually near the relevant text (see WP:MOSIMAGES). Wikipedia is not an image repository." Or are you defining a "gallery" as something else? Butwhatdoiknow (talk) 01:16, 21 February 2019 (UTC)

If a WP:GALLERY were not appropriate ever, it would have been MOS-forbidden. Duh. Why can't you just read and answer my well-linked question? Do you think I have not reason to ask this? Do you think I have not read WP:GALLERY? Why second-guessing my question? Why must I defend my question?

Now seriously, pls answer my OP. -DePiep (talk)

I'm thinking that Layout doesn't say where to put image galleries because they are so rarely appropriate that there is no generally established "rule" for where to put them. Butwhatdoiknow (talk) 02:05, 21 February 2019 (UTC)

Gallery sections appear to exist in dozens, hundreds or possibly thousands of articles. They are almost always near the end of the article just before the See also section. ~Kvng (talk) 21:11, 21 February 2019 (UTC)

In my opinion, a gallery section position should be left to the discretion of the editors. Tip: it would be less confusing if you write "a gallery" instead of "a WP:GALLERY".--Thinker78 (talk) 22:39, 21 February 2019 (UTC)

The gallery ought to go where it is most relevant - if it's a series of illustrations appropriate to just one section of an article, it might go into that section. But in general, as Kvng says, they go just before any "See also" section - as in the example cited in WP:Image use policy where it says " See Women's suffrage in New Zealand for an example of a good use of gallery." PamD 23:13, 21 February 2019 (UTC)

There is no "correct" place to put a feature that is discouraged. --Redrose64 🌹 (talk) 00:13, 22 February 2019 (UTC)

Sure there is. You can discourage it, but still say, "But if there is one, it goes in such-and-such place". EEng 06:30, 6 March 2019 (UTC)

A good rule of the thumb is that if it's placed in a section of its own called "Gallery", it's probably indiscriminate. – Finnusertop (talk ⋅ contribs) 00:21, 22 February 2019 (UTC)

What does "domains" mean?

Regarding the change from -

The order of sections in the body of a Wikipedia article may be recommended by a relevant WikiProject, or may not exist at all for some topics.

to

Certain domains have advice for the layout of an article. The below are the community-wide MOS pages dedicated in part to layout:

- What does "domains" refer to? Can we add an adjective? Butwhatdoiknow (talk) 15:48, 28 February 2019 (UTC)

wikt:domain #3: A group of related items, topics, or subjects. Feel free to use another word. --Izno (talk) 18:36, 28 February 2019 (UTC)

Topic areas? EEng 15:55, 9 March 2019 (UTC)

BWDIK made this edit in response to my comment. --Izno (talk) 18:00, 9 March 2019 (UTC)

Notice of RfC

RfC created at Talk:Companion (Doctor Who)#Request for comment on notes format, regarding the placing of discursive notes on pages consisting of tabulated information. MOS is not specific on this currently. U-Mos (talk) 02:37, 16 March 2019 (UTC)

Interwiki link placement

Where are the interwiki links placed? "See also" or "External links"? —Wei4Green | 唯绿远大 (talk) 09:22, 15 April 2019 (UTC)

Until someone who knows more says I'm wrong, I'll say: An interwiki linked word would appear in the text of an article wherever appropriate. A general link to another wiki-project would appear in "External links," for more about that see Layout#Links_to_sister_projects. Butwhatdoiknow (talk) 11:24, 15 April 2019 (UTC)

The question seems insufficiently clear. Do you mean "links visible in the main page text" or "links visible in the sidebar"? The latter should, with super-rare exception, all be placed on Wikidata. Where an exception is the case, they should go in the last section of the page, whatever that section is titled. The former, "links visible in the main page text", should be placed wherever appropriate. In the main text, it is reasonable to use something like {{ill}}, which indicates best that the content may not be in English. --Izno (talk) 13:26, 15 April 2019 (UTC)

Not merely in the last section, but at the very end of the last section - after the categories and stub templates (if any). See the last version where H:ILLs were mentioned. But as Izno points out, Wikidata has been the way to do this for over six years now. --Redrose64 🌹 (talk) 20:23, 15 April 2019 (UTC)

Categories in See also?

Is it appropriate to include relevant categories in a "See also" section? I don't think so, but would like to enquire before deleting them. Case in point: Bibliography of Donald Trump#See also, which links to Category:Books about Donald Trump and Category:Books about the 2016 United States presidential election. — JFG ^talk 08:15, 20 April 2019 (UTC)

I've seen them occasionally, and left them alone. It does 1) make the category more prominent, especially if it is relevant to the article in question, and 2) make it visible to mobile users (categories are hidden in my smart phone's browser). However, I don't have particularly strong feelings on the subject. —DocWatson42 (talk) 09:25, 21 April 2019 (UTC)

Saw another example today: List of Falcon 9 first-stage boosters has Category:Individual Falcon 9 boosters in its "See also" section. I understand that it's informative, but it still looks strange to me. SMcCandlish, some expert opinion? — JFG ^talk 00:44, 8 May 2019 (UTC)

MOS:LAYOUT#"See also" section says of that section that (in mainspace) it consists of "A bulleted list of internal links to related Wikipedia articles." Categories (and templates and yadda yadda) aren't articles. I just checked WP:CAT and there's no suggestion there to put cats. in "See also". There are a few other guideline snippets that tie into this section, and call for certain other things to go in there, such as {{Portal}} templates (while inter-wiki stuff goes in "External links"); but categories aren't among them. The practice of adding categories to "See also" is unusual, and usually redundant, since the article in question is already in the category (or a child or parent one), so the relevant category branch is already accessible, in a way the reader generally already knows well. (WP does surely get a handful of new users every day, but probably 99.99% of our readers have been here many times before and already know how the site's forms of navigation work.) Semi-relevant is that we don't redirect list articles to categories, or link in mid-sentence to categories as if they are list articles, even when a list article does/would have exactly the same elements in it as the category. This suggests a clear divide between categories as navigation and maintenance tools, and articles (of any kind) as content; I suppose portals are blend of content and navigation. I generally remove cat. links from "See also" when I run across them, and don't recall anyone ever reverting me on it. But it's not something I go around looking for. I don't feel that strongly about it, since "See also" is a navigational section, so it's not misleading to have a cat. in it, as would be putting inter-wikis in "See also", or links to WP articles in "References". If someone wanted to RfC the idea of expanding "See also" to expressly permit cat. links, I'd probably be neutral or at most weakly opposing on the matter, but the current state of the guidelines suggests nothing goes in there but articles and portal tag and maybe a few other things specified somewhere else.  — SMcCandlish ☏ ¢ 😼  04:24, 8 May 2019 (UTC)

Renaming sections

I sometimes (not all that often, but repeatedly) come across broken wikilinks to sections that no longer exist. Normally, the reason for this is that the section has been renamed.

The easy fix for this is to add an anchor template. In fact I think this should be the recommended fix, as so far as I know there is no easy way to locate incoming wikilinks that have been broken or are about to be broken by the renaming of a section. There seems no downside to creating the anchor, and it neatly solves any problems.

But I think we should also be proactive in this. Such broken links are easily avoided, hard to detect once created, and both puzzling and annoying to the reader, particularly within the article namespace.

So I propose that we add something like the following to the guideline:

Whenever a section heading is deleted or its name is in any way modified, an anchor template should be added so as not to break incoming links to the old section name.

This doesn't mention what to do if the section and its content is completely deleted, but I think those can be dealt with case by case. This would handle most cases, and at least alert editors to the potential problem. Andrewa (talk) 01:25, 30 April 2019 (UTC)

Good idea. I'd only suggest that "anchor template" in the proposed text be changed to anchor template (that is, linked to "Template:Anchor"). Butwhatdoiknow (talk) 06:03, 30 April 2019 (UTC)

Agree. I hadn't attempted to wikify thesuggested text, and that's an obvious wikilink. Andrewa (talk) 10:09, 30 April 2019 (UTC)

Done. It grew a bit, further comments welcome. Andrewa (talk) 02:25, 2 May 2019 (UTC)

I now see that this is already covered at Wikipedia:Manual of Style/Linking#Broken section links. The advice (but not the phrasing) is identical, and this is a better place for it... we want to get the attention of people who are changing or deleting headings, while MOS/Linking is going to be instead read by people linking to these headings. Andrewa (talk) 02:39, 2 May 2019 (UTC)

This needs to be toned down. As it now stands, an editor cleaning up a brand new article with non-standard headings (capitalisation, typos, unsuitable wording) would be told to make an anchor for each of these, so that changing "Personal Life", "Personnel life" or "Personal lif" to "Personal life" becomes a much bigger job. PamD 05:30, 2 May 2019 (UTC)

(More detail now I'm not editing on phone...) I can sympathise with the intention of this, but a guideline telling me that when I gnomishly copy-edit or improve a bad section heading I "should always" create an anchor template is overkill. I'll either defy the guideline, feeling uncomfortable about doing so, or just leave grotty section headings to stand, which also goes against the grain. Perhaps wording such as "If it seems likely that the section may be linked to" would be useful.

Or, another approach: Get a bot to check the whole encyclopedia for all links to sections, and to add an anchor for each of those, so that the link is not broken in future. It would be a large bot task initially, but could then be run regularly (or continuously?) to check on all recent changes. Then editors would see the anchor when making any reorganisation of a page, and could avoid breaking any incoming section links. PamD 08:29, 2 May 2019 (UTC)

If you choose to change a section heading without creating an anchor I doubt anyone will sanction you... I certainly will not! But it would improve Wikipedia if you did create the redirect... not very much perhaps. The hope is that others will follow the guideline, and we'll have fewer broken links as a result.

All I'd ask is that you discuss such changes on the article talk page and clearly indicate that you have not created a redirect. Then other Wikignomes can clean up after you.

The bot is an excellent idea, but I'm not quite sure how it would work... deciding exactly where the anchor was to be added would often be simple but sometimes quite involved. And until it's written, the new guideline will reduce the number of unnecessarily broken links, and if everyone follows the (new) guideline the bot won't be necessary anyway, so there may not be many volunteers to write it. Happy to be proven wrong! Andrewa (talk) 09:39, 2 May 2019 (UTC)

@Andrewa: I think you may have written "redirect" where you mean "anchor" twice in the above.

But talk of "discuss such changes on the article talk page" is in a different universe from the kind of drive-by copy-editing I'm talking about: the "see it, fix it, move on" of fixing a typo etc in a heading while I've got the page open to sort the stub or do something else. Surely I'm not alone in this pattern of editing? Never mind sanctions, we should not have a guideline which says "should always" for an unrealistic level of action. And, really, do we want our articles cluttered with anchors for every typo or mis-capitalised heading which existed for a few hours in the early history of the article. I suggest "No". PamD 11:48, 2 May 2019 (UTC)

Agree with most of this. Yes, you're right, I meant "anchor".

And specifically, agree that do we want our articles cluttered with anchors for every typo or mis-capitalised heading which existed for a few hours in the early history of the article. I suggest "No". But note what the project page says... It is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply. Is the scenario you're suggesting a common one? If so, then we should, as you're suggesting I think, allow for this in the MOS. But I'm skeptical, and wary of instruction creep. Commonsense would indicate that a heading such as Alice in Wonderkand should be fixed, not linked to, and that no anchor is required. I don't see any need to spell that out. But a change of a section heading from Alice in Wonderland to Alice's Adventures in Wonderland after some time at the former title should for example be supported by an anchor. It's far less trouble to create the anchor then to try to find out whether links will be broken without it.

And even if this clutter were to arise (which I don't consider at all likely) it would do no damage that I can see.

I'd also point out that (as observed above) the change just brings this page into agreement with Wikipedia:Manual of Style/Linking#Broken section links.

We have little participation inn this discussion so far. When I made the change there seemed consensus for it. I wonder, where can we seek greater participation? Andrewa (talk) 12:51, 2 May 2019 (UTC)

I expect most wikignomes operate like Pam does, so yes, it is common. --Izno (talk) 18:11, 2 May 2019 (UTC)

I hope not. But you may be right! Andrewa (talk) 20:06, 2 May 2019 (UTC)

Nikkimaria has participated by actions not words. I think their version is an improvement. PamD 18:19, 2 May 2019 (UTC)

Indeed... and the first part of that edit is quite OK IMO. But it should still have been discussed here beforehand, particularly the total removal of the new section, and I'm unhappy at the removal of the link to Wikipedia:Manual of Style/Linking#Section links). Andrewa (talk) 20:06, 2 May 2019 (UTC)

If you'd like to readd that parenthetical feel free, but a whole new section was way overkill, and not discussed before "It grew a bit". Nikkimaria (talk) 22:07, 2 May 2019 (UTC)

So, is it agreed that the link to the other MOS section should go back? Andrewa (talk) 23:53, 2 May 2019 (UTC)

Fine. PamD 21:47, 3 May 2019 (UTC)

@Andrewa: Surely Nikkimaria's change was along the lines of WP:BRD: You were Bold, they Reverted (but then added a bit), we are Discussing. There wasn't much discussion before your original change to the Guideline, and I was trying to have a wikibreak - which I need to resume. PamD 21:47, 3 May 2019 (UTC)

Disagree that I was bold... it was discussed here first, I was quite patient and received only support. Enjoy your wikibreak. Andrewa (talk) 17:45, 6 May 2019 (UTC)

What was discussed early in this section was the addition of a single line. No mention of more content / a new section was made until the "it grew a bit" comment after implementation. IMO my version is closer to what was discussed here first than yours. Nikkimaria (talk) 18:07, 6 May 2019 (UTC)

Why I want a section heading

Nobody is proposing to make more work for wikignomes. Just the opposite. I do gnomelike work too, such as adding an anchor to fix a broken section link whenever I follow one. And it happens regularly.

But it should not be necessary. The best time to fix these is when they are first broken. That's when it is the least work, and also the most productive, in that it avoids inconveniencing any readers at all. Andrewa (talk) 23:53, 2 May 2019 (UTC)

But copy-editing or standardising a section heading will very rarely be breaking an incoming link (especially when dealing with newly-created articles eg at NPP), while your proposal would add a huge proportion to the work involved in making these changes which I am sure are made vastly more often than your "regular" need to fix a broken section link.

Scenario 1: Correct "Personal Life" to "Personal life" by changing one letter to lower case. Two keystrokes.

Scenario 2: As above, plus also type "{{anchor:Personal Life}}" 2 + 24 keystrokes (or some copy-and-paste to cut the keystrokes down to 2 + 11 + copy-paste.

Scenario 3: Given that there is now a guideline mandating that I perform scenario 2, decide "Stuff this for a game of soldiers, I'll just leave that grotty subject heading as it is rather than go to all the bother I'm instructed to do".

I don't want to see a Guideline which instructs me to go into scenario 2, and I don't think the article would be improved by having that clutter. Nikkimaria's reminder to consider adding an anchor is much more realistic. After all, if the incoming link is "broken" it still leads to the appropriate article, where a reader can search or scan to find the information they want. If it has been removed from the article, then no anchor will help them. By all means remind editors that if they are making significant changes to well-established section headings they should think about adding an anchor, but leave drive-by wikignomes the freedom to improve articles simply and swiftly. The key phrase in the linked section of MOS:SECTIONLINKS is "It is good practice to place an anchor whenever the section is expected to be the target of an incoming wikilink", which is very different from your "always". PamD 21:36, 3 May 2019 (UTC)

Nobody is proposing scenario 2 or 3. Note the guideline box... commonsense. Nobody should be forced to add an anchor if the result is that instead they fail to MOSify a recently-added heading, and you're right, the wording could perhaps be improved by making this explicit. And this should be discussed, as I have always attempted and am now.

But neither should wikignomes like yourself be left unaware of the broken links they are creating on occasions, which other wikignomes then need to clean up after you. And which is more important... that a reader sees a wrongly capitalised heading (which other style guides might accept), or that they are astonished to be taken to an article which doesn't seem related to the link they followed? I think that addressing both of these problems improves Wikipedia. Andrewa (talk) 17:59, 6 May 2019 (UTC)

I agree with PamD that this idea, phrased as proposed, is onerous and messy. We don't actually need an anchor unless we know for a fact there are incoming links to it (and they are too many to correct). I know there's a tool for checking, but I forget what it is. If someone can figure that out, then that would be good mention in the guideline: tell people how to to see if there's an issue and how to resolve it, instead of telling them to do busywork to inject code clutter that isn't actually needed probably 95% of the time or more.  — SMcCandlish ☏ ¢ 😼  04:35, 8 May 2019 (UTC)

If the link is broken, the reader lands at the top of the article and needs to search or scan to find their topic. If the link is not broken, they may even so find themselves at the start of a section longer than some other whole articles, and need to search or scan to find what they want. The broken link is mildly inconvenient, but not disastrous. It isn't enough to rely on "common sense" and "occasional exceptions" in the top box of the guideline to dilute an excessive demand: we should not introduce a guideline which says that an anchor should always be created when a section heading is removed or its name is changed, however trivially.. An instruction reminding people rearranging an established article that they should make anchors for altered subject headings is quite different, and desirable. Nikkimaria's version is fine. PamD 08:03, 8 May 2019 (UTC)

Section edit summary issue

I don't remember where I saw it but I recall a long discussion somewhere in Wikipedia talk about putting {{Anchor}} in section headings. Doing so creates a messy edit summary when a section is edited and so is not an ideal solution. My recollection is that the conversation went through a few ideas before concluding that there was really no good solution. You can use Rdcheck to find and fix broken redirect targets but I don't know of a way to find and fix broken links from normal articles. ~Kvng (talk) 13:39, 4 May 2019 (UTC)

Very good point!

Agree that the anchor should not be in the heading, for exactly that reason. The anchor should normally go immediately after the heading, if there are no other changes.

Is there any problem with that? I confess I'm puzzled by the conclusion that there's no good solution.

Either way that's another good reason to have a section somewhere in the project namespace that describes the correct way to use anchors when changing a heading. I don't care where this section goes just so long as it's linked to from here. Maybe just a link to the other MOS section which deals with this is adequate, but the link I added was removed.

I still think that we could improve Wikipedia by better avoiding these broken links in the first place. See discussion above. Andrewa (talk) 18:18, 6 May 2019 (UTC)

I may be misremembering this, but I think that anchors below the section header tend to take the reader to the section without the section header being displayed on the screen, which is generally a bit confusing. I have seen attempts to solve this by putting the anchor above the section header, but that also has its problems, in that to change it you must edit a different section, so I would agree there is no good solution yet. It may need a modification to mediawiki, as the logical place to have the anchor(s) would be in the same line as the header, after the closing "===". · · · Peter Southwood ^(talk): 08:23, 7 May 2019 (UTC)

Ideally we'd not have to put any {{Anchor}} code in to keep section links from breaking. There would be a bot or magic metadata to take care of things. Or there would at least be a tool WP:GNOMEs could use to find broken section links. ~Kvng (talk) 15:52, 7 May 2019 (UTC)

This has been discussed many times before. Short version: The heading just summarizes the material in the section, so it not being instantly visible in some browsers isn't a big deal, since everything said in the heading is also said in richer detail in the content just below it. If there's a case in which it is thought to be a big deal, the code that doesn't wreck edit summaries is this: ==Foo bar baz<span id="Quux"></span>==, using HTML not a template, and after the current name of the section. Given the frequency with which {{Anchor}} is in fact used, just below the current heading, surely a near totality of our readers are already familiar with the fact that if they click a link and are taken to mid-page that if the scroll up a tiny bit they will then see the heading. PS: Another approach sometimes used is putting the achor template just above the heading (which makes it part of the prior section, at the code level). This only works in very stable articles, since if you re-organize the sectional layout and don't look out for anchors, you'll end up moving the anchor along with the section in which is technically lives to no longer be above the heading and section to which the anchor pertains.  — SMcCandlish ☏ ¢ 😼  04:35, 8 May 2019 (UTC)

Can you link to previous discussion? My recollection is that landing such that readers can't see the section heading was considered a serious problem. ~Kvng (talk) 00:18, 10 May 2019 (UTC)

• There's a cryptic comment at Template:Shortcut#Positioning that I've puzzled about for some time; it seems to suggest there's some magic solution for placing an anchor inside a section in such a way that it nonetheless takes the reader to the section's heading. Or maybe I misunderstand. EEng 03:17, 20 May 2019 (UTC)

"As a general rule, the "See also" section should not repeat links that appear in the article's navigation boxes."

Then first at least make these article's navigation boxes appear visible to readers at mobile devices in your disfunctional mobile version. SNAAAAKE!! (talk) 06:08, 26 November 2018 (UTC)

A bit late, but I concur. You raise a valid point. Jay D. Easy (talk) 21:45, 15 December 2018 (UTC)

The navbox example is one case, with overlinking being another. A lot of the MOS would be tossed out if we took mobile versions into consideration, and the people who write the MOS aren't going to allow that to happen. The MOS is more important than some inconvenience to lesser readers, given the amount of time these people spend discussing and writing it, and they aren't going to permit their hard work to be devalued. - BilCat (talk) 23:08, 15 January 2019 (UTC)

Time to update some things I would guess.... considering the majority of our readers are now on mobile devices.--Moxy (talk) 23:10, 15 January 2019 (UTC)

I totally agree with that. But it will be a huge undertaking, and will probably face a lot of opposition. - BilCat (talk) 23:16, 15 January 2019 (UTC)

At the last Wiki conference I was at 2017..... there was a talk about just making these templates visible in some manner in mobileview, thus no big change to policies and guidelines. I find it odd this hasn't come up in the community at Large.... only argument I've ever seen is that templates are considered spam by a lot of cotent editors and shouldn't waste valuable space ( I don't agree).--Moxy (talk) 23:36, 15 January 2019 (UTC)

What really needs to happen, obviously, is for the mobile version to be fixed to stop breaking nav templates (or for those templates to be rejiggered in ways – probably just a changed CSS class – that prevents the mobile version mangling them). And that If the community wants to do anything about this at all. Regarding a post below, it's not possible for the mobile and desktop versions to serve all readers on all devices equally, without being very nearly identical. Much of the point of the mobile version is to do triage on non-essential stuff to trim down both the screen real estate required and the bandwidth consumed. That necessarily comes at the cost of features. "Working around" this intentional trimming by re-inserting the same material a different way (that negatively impacts the desktop version with clutter) defeats the purpose of separate mobile and deskop versions. So, if that's where we want to go, the solution is to undo some of what the mobile version is doing differently from desktop, not change guidelines in way that messily address the matter in ways with negative side effects. Analogy: if your tooth hurts, go to a dentist, don't shoot heroin.  — SMcCandlish ☏ ¢ 😼  04:45, 8 May 2019 (UTC)

Change the general rule?

Given the time lapse, it might make sense to start a new section on this topic, but I'll attempt to chime in here with call-outs @SNAAAAKE!!: @Jay D. Easy: @BilCat: and @Moxy: → It seems somewhat problematic that MOS:Layout guidelines make only a single mention regarding mobile. Mobile access to English WP has consistently outpaced desktop access since April 2018. (Across all Wikimedia sites, the trend begins November 2017.) I'm actually a fan of Navigation boxes and Categories, but since noting their absence on mobile, lately I've preferred See also sections and templates. I don't typically advocate for guideline changes, but I do think the current "general rule" merits reconsideration. So long as the mobile/app interfaces hide various navigation features, the current Layout guideline does not serve all readers equally. Perhaps I'm biased as a regular mobile reader, but I think it's vital to account for different UX when crafting See also sections. Specific example: I had a contribution reverted on the basis that the See also section duplicated a link in a navigation template below; when I raised my concern about mobile access, the reverting editor subsequently pointed to MOS:Layout as justification. — HipLibrarianship ^talk 03:04, 6 March 2019 (UTC)

In your specific example, it shouldn't be difficult to mention the 2019 Presidents Day protest in the article Not My Presidents Day, probably best under "Aftermath" or "Impact". I suggest that weaving "See also" point into the article's text is always the best solution. -- Michael Bednarek (talk) 06:02, 6 March 2019 (UTC)

But it should be pretty difficult to ensure the inclusion of relevant materials from the navboxes in every single other article's body. SNAAAAKE!! (talk) 11:19, 6 March 2019 (UTC)

Valid point, Bednarek. It simply takes more time and effort to weave relevant links into an article. Undoubtedly the encyclopedia's overall quality would benefit from more robust in-depth contributions; yet taken to its logical conclusion, as suggested by SNAAAAKE, it would border on impossible to continually sync every relevant link from every navbox into every associated article. — HipLibrarianship ^talk 03:57, 7 March 2019 (UTC)

I have long supported this change (or, at least, adding a jump to the navigation boxes in See also) because many casual readers are not aware of navigation boxes lurking at the ends of articles. The absence of navboxes on mobile deices now makes the change imperative. Butwhatdoiknow (talk) 15:33, 6 March 2019 (UTC)

So the suggestion is to repeat all (relevant) links in all (relevant) navigation boxes in each article's "See also" section? The solution is obviously either to display navigation boxes in the mobile interface or to abandon navigation boxes. -- Michael Bednarek (talk) 01:21, 7 March 2019 (UTC)

A better solution would be to just not be so strict on what links are allowed in the See also sections. Navboxes are still useful to people using the desktop versions. If/when navboxes are made visible to mobile users, then we can go back to being more strict on what links are allowed. - BilCat (talk) 01:50, 7 March 2019 (UTC)

Hear, hear! What BilCat said. In terms of a formal suggestion, I'd propose revising MOS:NOTSEEALSO to strike the final four words ("or its navigation boxes"). Such a revision would also address the concern raised by Govvy, regarding navboxes relative to WP:ACCESS. — HipLibrarianship ^talk 03:57, 7 March 2019 (UTC)

Could we solve all of this by adding a "related articles" function to all platforms? This would alphabetically list all outgoing links from the article text and navigation templates. ~Kvng (talk) 15:38, 9 March 2019 (UTC)

While this is an interesting suggestion for project functionality, it significantly differs from the outcome I'd like to see achieved. Namely, revise the MOS:Layout guideline to support See also sections that include a specifically selective subset of links, regardless of whether any link appears in a navbox below. Emphasis on selective. Since navboxes don't display in mobile interfaces, or may often be closed in desktop interfaces, including a few focused links in a See also section could be helpful to all readers. (A secondary contrast with Kvng's suggestion: the distinct advantage of a good navbox is that links appear intentionally grouped/arranged, not in a single alphabetical list. This is a key usage benefit, particularly when the current article is visually emphasized (bold) within the topical scope of the navbox.) — HipLibrarianship ^talk 17:11, 9 March 2019 (UTC)

The consensus end goal for WP:GA is generally to eliminate the See also section. Coverage of all topics that would appear in See also should be covered in the article body. In this context, See also is a stopgap for article development. I've watched articles develop this way and it works.

What you're saying is that a curated See also is always useful to readers. I appreciate that but we already have navigation boxes and categories that make those connections. If those mechanisms need improvements to work better for readers (I think they do, especially for mobile readers), let's replace or fix them. I don't think adding yet another curated navigation mechanism is the solution. ~Kvng (talk) 18:42, 9 March 2019 (UTC)

We agree that navboxes and categories should be improved to better serve mobile readers. (Although I'm afraid I don't know enough about the MediaWiki software to be helpful in that ongoing project.) Yet the persistence of the software hurdle strikes me as a reasonable basis to ease the MOS:NOTSEEALSO constraint regarding links in navboxes. Whether serving as a "stopgap for article development" or a simple navigational aid, a See also section can offer real benefits to readers in the immediate present. Seems unclear whether we can gauge how far in the future navboxes might be fixed/revamped/replaced. — HipLibrarianship ^talk 03:20, 12 March 2019 (UTC)

I suggested we replace or fix navboxes and categories. After reading [4] I'm leaning towards replacing, not fixing navboxes, at least for mobile. There is talk in that Phabricator article, of the mobile team developing a Related articles feature. I would like to see how that's coming along before assessing whether the replacement needs to be curated. ~Kvng (talk) 13:13, 14 March 2019 (UTC)

I concur with pretty much everyone else here that the rule about navbox links makes no sense. Even if navboxes were visible in mobile, the rule would still be silly because barely anyone looks at navboxes way down at the bottom. And most of the time the navboxes are closed by default, with some containing dozens of links... so maybe 0.1% of the people that visit a page are going to notice a particular link in the navbox and think anything of it. Since there is a clear consensus here for making the change can I go ahead and do it or does it have to be done by an admin? I just want to change the following sentence to remove the last 4 words:As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes.--Jamesy0627144 (talk) 04:48, 13 April 2019 (UTC)

Either get navboxes to appear on mobile or get agreement to phase out navboxes, rather than adding more bloat to the See also section. Nikkimaria (talk) 14:00, 13 April 2019 (UTC)

• Yes, change it. Many navboxes are now so bloated, and often hidden, it makes no sense at all, even for us desktop dinosaurs. Johnbod (talk) 03:59, 2 August 2019 (UTC)
• Change it within reason per common sense and above comments. See also shouldn't be overly large, and should add entries selectively and within reason. But since navbox templates don't appear on mobile we're discussing apples and llamas, as the topic of duplication isn't really applicable. The coding problem for navbox use on mobile might not be able to be overcome, but each mobile page should probably include a notice at the bottom of the article notifying mobile users that "Many Wikipedia features on laptop are not shown on mobile, including site-wide navigational maps and categories". That would go a long way towards template respect. Randy Kryn (talk) 04:15, 2 August 2019 (UTC)
• I'd like to work on an actual RFC, neutral in intent and put in more-public place (e.g. WP:VPPOL), with a subsequent moratorium on the matter (because certain editors keep pushing :). These discussions keep coming up over and over specifically about navbox links. I have a clear position on the matter and wouldn't want to hack it alone. Anyone interested? --Izno (talk) 04:39, 2 August 2019 (UTC)

• This discussion has many editors and a long history. It seems to have consensus, and the words have been removed by two editors. Would suggest linking this discussion wherever you want, but this one seems to have enough reasons which would hold-up during an RfC that it would just be repeating the obvious viewpoints. An RfC on adding something like the wording I added above to the bottom of every article on mobile might be a good idea, maybe put the wording up for discussion before presenting it as an RfC (side question, are talk pages on mobile? I've only seen a Wikipedia page on mobile twice, and never edited one). The small boxed message shouldn't be obtrusive, although maybe mildly colored to attract the eye, and would alert every mobile user that there is a lot more to Wikipedia than they probably know about. Just rambling, but I'd suggest first putting the box as a site-banner for two or three days before adding the bottom statement. And I'm assuming that a code could accomplish adding the bottom message on a site-wide basis, and have no idea if that's possible. Template respect (what would that be in Latin?). Randy Kryn (talk) 16:44, 2 August 2019 (UTC)
• I'm surprised that there's been no WMF progress on this. I assume we're tracking with the general trend where over 50% of internet access is mobile. I can see simple software improvements that would make more of connections in the encyclopedia usable by mobile users but maybe WMF, consciously or unconsciously (though inability to make these improvements), needs editors to get it done in a more labor intensive manner. ~Kvng (talk) 23:06, 2 August 2019 (UTC)

Order of navboxes

If an article has multiple navboxes in its external links section, how should they be ordered? Alphabetically? Or grouped according to content/media (for example, navboxes pertaining to a comic are grouped together, followed by navboxes pertaining to the comic's TV or film adaptations, etc.)? – KuroMina (talk) 04:33, 18 December 2019 (UTC)

@KuroMina: Find a related FA or GA article and mimic their style. Otherwise, inquire at the relevant WikiProject if there are conventions for that domain.—Bagumba (talk) 05:49, 18 December 2019 (UTC)

The general ordering across the many pages I have surveyed is by most relevant to least relevant e.g. on Barack Obama, his presidency and family first, his Nobel prize last. --Izno (talk) 14:42, 18 December 2019 (UTC)

@Bagumba: @Izno: Thanks for your replies! I think I'll follow the order of most relevant to least relevant from now on. – KuroMina (talk) 11:14, 19 December 2019 (UTC)

Where to put {{short description}}

No mention of {{short description}} in this MOS. A lot of pages is tagged with it on the first line, and AWB (and friends) seems to think it should not be the first line, but after the hatnotes. Any opinions? Christian75 (talk) 15:37, 13 April 2019 (UTC)

You can argue that the description is associated with the title. Hatnotes are also associated with the title. It would make sense for the description to go with the hatnotes either before or after. If you choose before hatnotes, then it will be the first line. If some consensus is reached about this, the shortdesc helper gadget may need to be updated. ~Kvng (talk) 17:07, 13 April 2019 (UTC)

Also might be good to provide some guidance for placement of {{Use British English}}, {{Use dmy dates}} and the like. These are also vying for space in the front matter of articles. ~Kvng (talk) 17:19, 13 April 2019 (UTC)

I think it should go in position 1.5 (i.e., after hatnotes, and before deletion/protection tags). Hatnotes are about discovering if you are even in the right place, and logically speaking, you certainly wouldn't want the description of what this page was about, before you knew if this is the page you were looking for. Once that is settled, the description could go after the hatnotes, or even after deletion/protection tags, although I prefer the former.

English-variety and dmy templates should go in position 2.5, after deletion/protection, and before Maintenance/dispute. Deletion/protection is a stricter type of control (e.g., who even gets to edit the article) than English or date templates, in that protection templates can involve compulsion, in the sense of the WM software blocking certain users from editing the page at all. What kind of date, or what variety of English to use, is merely a community decision based on some guidelines and the only compulsion comes from community action (if at all). To me, this argues for placing dmy and English templates after the deletion/protection material. Secondly, since dmy and English are recommendations about "what's right with the article" (this type of English is right, this type of date is right), they should go above Maintenance templates, many of which suggest what's wrong with the article. This argues for placing the tmeplates at position 2 1/2.

This would make this portion of the the sequence look like this:

1. Hatnotes
2. Short description
3. Deletion/Protection tags (CSD, PROD, AFD, PP notices)
4. English variety and date style
5. Maintenance / dispute tags

Mathglot (talk) 18:42, 13 April 2019 (UTC)

The position of the dmy/English templates doesn't matter in principle since they do nothing to the page text, they merely add a category at the bottom - which is hidden by default. However, if they are put between two banners - such as between an AfD and a {{unreferenced}} - they cause a slight separation of the banners, which on some setups may be visible as a gap, or as an extra-thick border between the banners (example). --Redrose64 🌹 (talk) 21:00, 13 April 2019 (UTC)

Agreed. This being the case, and given that the short description is also invisible, I propose putting the invisible tags below the visible ones. This would make this portion of the the sequence look like this:

1. Hatnotes
2. Short description
3. Deletion/Protection tags (CSD, PROD, AFD, PP notices)
4. Maintenance / dispute tags
5. English variety and date style

Hawkeye7 (discuss) 02:13, 14 April 2019 (UTC)

Looks good. Anybody care to implement this overleaf? -- Michael Bednarek (talk) 03:34, 14 April 2019 (UTC)

Looks good to me too. ~Kvng (talk) 14:15, 14 April 2019 (UTC)

The only flaw is that short descriptions are not invisible. You have the order wrong. --RexxS (talk) 17:28, 15 July 2019 (UTC)

Done. Butwhatdoiknow (talk) 22:22, 15 April 2019 (UTC)

Should be after the hatnotes, since those are meta-data pertaining to the page address, not the content of the page.  — SMcCandlish ☏ ¢ 😼  04:37, 8 May 2019 (UTC)

I hope this discussion isn't considered closed. IMO Short description should go above hatnotes because 1) that is where they are being placed by Shortdesc helper; and 2) WP:ACCESSIBILITY—Short descriptions will be the first thing that a screen reader will find, followed by the disabiguation hatnotes. It seems to me that short descriptions will disambiguate more quickly/specifically than hatnotes. Thoughts? —DocWatson42 (talk) 07:26, 14 July 2019 (UTC)

Except most people don't see them! We cannot depend for disambiguation on a feature that is only visible to logged-in users and even then to those who've turned that feature on. And we are not dictated to by bots or any other tool; they are to be written to conform to editing norms. Editors don't abandon their norms to conform to mis-functional scripting. The tail does not wag the dog.  — SMcCandlish ☏ ¢ 😼  04:37, 28 October 2019 (UTC)

I have come around to this too after manually moving a bunch of descriptions. Path of least resistance here is to put the description first because that's where the helper is putting them and displaying them. Your WP:ACCESSIBILITY quote is also good justification. ~Kvng (talk) 14:22, 14 July 2019 (UTC)

@SMcCandlish: On the contrary, short descriptions are clearly content, not metadata. Install the Wikipedia App on your phone and look at some articles. You'll soon see that short descriptions are not metadata. It's about time that the small group of regulars here who are creating editing prescriptions for the whole encyclopedia started to consider how most of our readers actually see the content. --RexxS (talk) 17:26, 15 July 2019 (UTC)

If you want to take that view, they they double-extra-especially belong after the hatnote[s], which are absolutely metadata about the page and not content of the page.  — SMcCandlish ☏ ¢ 😼  04:37, 28 October 2019 (UTC)

The short description should be first as it is new and is being added to pages to avoid Wikidata vandalism from affecting articles. Theoretical considerations about metadata are of no concern to general editors who just need a guideline that specifies the standard order—it is much simpler to put the description at the top because that is where it appears in mobile devices using the Wikipedia app. In a browser, the description is not seen by default so it logically belongs above all the content that is seen, including hatnotes. Johnuniq (talk) 03:53, 15 July 2019 (UTC)

Short description also appears before the hatnotes if you've installed the short description helper. It is nice when the order of a rendered page matches the order in the wikicode. One thing I am having trouble reconciling is the position of dmy/English templates. If you make the argument that stuff you don't see should go at the top, why are these in the middle of the frontmatter? — Preceding unsigned comment added by Kvng (talk • contribs) 14:01, 15 July 2019 (UTC)

@Kvng: A little further above, Redrose64 makes the point that we don't really want to place invisible content between two pieces of visible content in the wikitext, as the newlines can produce unwanted spacing between the two visible elements. So you are quite right to question why we should advise placing things like dmy/English advisory templates between two pieces of visible content. --RexxS (talk) 22:29, 15 July 2019 (UTC)

@RexxS and Kvng: I agree that invisible templates sometimes create undesirable spacing, but I haven't seen that happen much at the top of articles. However, to me the date and English language variant templates belong at the top of the article because they need to be immediately visible to editors. —DocWatson42 (talk) 09:37, 17 July 2019 (UTC)

I assume when you say, "the date and English language variant templates belong at the top of the article", you mean they belong somewhere in the frontmatter. I genarally agree with this. If we want to avoid putting these between visible content, we can put them either immediately before or immediately after short description. Does anyone see either of those solutions as a big enough improvement to twiddle with things more? ~Kvng (talk) 13:19, 17 July 2019 (UTC)

I wouldn't suggest trying to refine further. This is the problem of attempting to be prescriptive with ordered "laundry lists" when the underlying principles are nuanced and will lead to exceptions. Ralph Waldo Emerson said "A foolish consistency is the hobgoblin of little minds." It's hard to disagree with him. --RexxS (talk) 14:13, 17 July 2019 (UTC)

Kvng: "I assume when you say[...]": Yes, and next to each other. And after the short description and hatnote(s). —DocWatson42 (talk) 03:20, 18 July 2019 (UTC)

@DocWatson42: Hatnotes are definitely visible items and date and English language variant templates are invisible. Your suggestion puts invisible stuff between visible things. We're trying to avoid such interleaving so as not to introduce unintentional vertical whitespace in the rendered page. ~Kvng (talk) 13:40, 18 July 2019 (UTC)

@Kvng: I (think I) meant "the date and English language variant templates belong at the top of the article" and next to each other—rather than placed with something else separating them. And somewhere after the short description and hatnote(s). <shrug> That's all. Though again, I don't recall having seen any cases (at least in my browsers) in which date and English language variant templates have created gaps in "top matter". —DocWatson42 (talk) 05:19, 20 July 2019 (UTC)

Short descriptions are rendered well before hatnotes in the Wikipedia App. Just take a look at Dunwich on the app as an obvious example. Why would anyone want to arrange the order of items in the wikitext differently from the order in which they are displayed? That simply confuses any new editor seeking to correct an error, for absolutely zero benefit. --RexxS (talk) 17:07, 15 July 2019 (UTC)

In case further clarification may be helpful, a short description should be written as an annotation to the title. Functionally, it should follow the title as closely as reasonably practicable. I would argue that the best place would be directly following the title, in line, in smaller text, but that would probably require mediawiki changes, so not reasonably practicable at present. · · · Peter Southwood ^(talk): 08:08, 20 July 2019 (UTC)

Just a note, Shortdesc helper mainly places it at the top because doing so is easy compared to placing below hatnotes etc. That would require maintaining a list of hatnote templates and decent a bit of work implement. I find the argument re short description being an annotation to the title and it being right below the title where it is displayed (in search results and in the apps) to be quite compelling, though that may be simply because I don't particularly want to put the effort to making Shortdesc helper place the short description below the hatnotes :) Galobtter (pingó mió) 23:23, 21 July 2019 (UTC)

Bump. While good points have been raised, we don't seem have reached a consensus (at least not an explicit one), so I'm asking what, if anything, we want to do. —DocWatson42 (talk) 00:54, 31 July 2019 (UTC)

RexxS already moved {{Short description}} to the top. I am good with that. The lingering discussion here is whether the language and date templates should be moved. ~Kvng (talk) 04:34, 31 July 2019 (UTC)

I strenously object to an order of 1. short description, 2. hatnotes, 3. ..., for reasons I've already outlined above and which have not been refuted.  — SMcCandlish ☏ ¢ 😼  04:37, 28 October 2019 (UTC)

It appears your reasons are that 1/ hatnotes are metadata and metadata should come first and 2/ short description is not visible to most readers so shouldn't be at the top.

It looks like both of these have been refuted. You just don't accept the arguments. ~Kvng (talk) 13:57, 30 October 2019 (UTC)

@Kvng: Then you're simply not paying attention. My argument was that if we consider them metadata, they go up with hatnotes (the other metadata) before the content proper, and between hatnotes (which are about other pages) and the content proper since descriptions are metadata about the content, nto about other pages. Separate content from navigation is a fundamental principle of interface design. RexxS argued for descriptions being content because they're visible in a mobile phone app. If we accept that argument (and I doubt many CS, information architecture, web design, or other relevant professionals would – any utility can be forced to display metadata, or metadata would generally serve no purpose; this doesn't magically make it content except in an extremely narrow context), it still goes under hatnotes because those are not content but are cross-page navigation. So, please try again.  — SMcCandlish ☏ ¢ 😼  04:31, 10 February 2020 (UTC)

DocWatson42 Kvng Galobtter Johnuniq SMcCandlish I may be very very late, but I support the short descriptions being at the top as per the way the page looks. Ultimately, that's the way that improves/streamlines editing for new users. The reason I'm making this comment is because this hadn't been updated over at MOS:LEADORDER until I did it just now. Had me confused for a sec. · • SUM1 • · (talk) 03:50, 10 February 2020 (UTC)

Good. I don't agree with the exact order of placement at page top (just with page top, not page bottom or in mid-page), but I appear to be outvoted for now. To the extent there's a rough consensus, it should be recorded in the relevant place. I expect others will notice the failure to separate content and navigation and that we'll eventually move it to be below hatnotes, but WP:THEREISNODEADLINE.  — SMcCandlish ☏ ¢ 😼  04:31, 10 February 2020 (UTC)

Though I wanted to point out that I do understand your argument fully SMcCandlish. It follows the general rule. It's just an exception that may be warranted based on user functionality/appearance or indeed the maintenance difficulty it may result in otherwise (since short descriptions are much more likely to need to be maintained or altered on a per-article, per-category or per-template-presence basis, unlike hatnotes, and ultimately all articles are supposed to have them). If Galobtter finds a way to maintain a list of active hatnotes used so he can maintain the template around them accordingly, there may be a lesser argument. I seem to be speaking for the newer editors; I believe only the most experienced editors would notice/point out the discrepancy, while others would see it as intuitive at face-value. But if enough do notice to get consensus, I'll gladly accept. · • SUM1 • · (talk) 22:19, 10 February 2020 (UTC)

Thanks SUM1 consistency and rough consensus is goodness. ~Kvng (talk) 14:24, 10 February 2020 (UTC)

If Galobtter needs to make a list of hatnote templates, I very certain that editor is competent enough to know that Category:Hatnote templates exists! A temporary technical glitch (in an entirely optional tool a few people use) is not a sound rationale for mingling content and metadata, or for putting metadata about other pages (nav hatnotes) between the main content and metadata (short-description) pertaining exclusively to the current page's main content. Separation of content from meta-content (also including navigational templates, cleanup tags, references, etc.) and an arrangement of that metadata by closeness of relationship to the central content, is important for WP:REUSE, WP:ACCESS, and other usability reasons. Metadata which contain content are content within their own sub-context but remain metadata in the primary context. Infoboxes are a more familiar example: they are not part of main content, and go above it, and are separated out from it (visually, and, more importantly here, in the code as floated divs – i.e., outside the flow of the main document^[5] – with classes that make them auto-identifiable and excludable). They summarize key points from the content and are metadata (in exactly the same way that an abstract of a journal paper is metadata about the paper), even if they are also, internally to their sub-context, a content vehicle, just as is an abstract or any other form of summary of any larger work.)

Ignoring content vs. metadata separation and/or relevance-ordering of metadata, for no sound reason will call into question our entire layout rationale, which is based on the same separation and ordering principles. ("See also" comes after content because it is navigation, i.e. a form of metadata, but it comes before "References" which are a different kind of metadata but about external resources; but that comes before "External links" which are also metadata about external resources, but with less direct relevance to the content. The order is very specific.) This is ultimately a WP:NOT#WEBHOST matter in a sense: WP doesn't exist for individuals' personal experiments in restructuring (or just breaking) the structural design of a shared information-presentation project. Stuff is in a particular order for sound information-architectural reasons, which really don't relate to what someone subjectively thinks will look best. E.g., plenty of editors would love to put topical navboxes (succession boxes, or film- or TV-related ones, or whatever) in mid-article positions (they've tried, trust me). Similarly, people have injected sister-project links into the content, or moved stub tags to topical sections of articles, and done other such things out of a personal sense of organizational logic that pertains to subject matter rather than distinguishing primary content from navigational and other metadata. We revert them. (It's a very "bloggy" approach, e.g. "I'm writing about dubstep, so I should make sure a music ad goes right here for my monetization purposes." It's an expediency- and visual-results-driven viewpoint that takes no account of other uses of the content.)

When there are genuine exceptions, they are for objectively not subjectively good reasons. E.g., when what could be (if not for WP:N) an article on an album is merged to the article on the artist, it's permissible to inject an album infobox into the section on the album; the i-box is metadata about the section only (and remains an out-of-flow float, and would be confusing if put at top of page along with artist i-box). Another example is sectional hatnote navigation like {{Main}}; they're distinguished by templated classes (including unprintworthiness) and by the italic style we use for unavoidable self-references); they're an exception to the separation because, of course, they could not serve their purpose if not used in the relevant sections. Such rationales doesn't apply to the short-description case; there isn't a failure-of-purpose if short-description code goes below hatnote templates. PS: This is making me think that what we should be doing ultimately is putting short-descriptions into out-of-flow boxes with CSS classes (perhaps with specific positioning by default, which someone can fine-tune with user CSS, but which would at least prevent short-description material from visually disrupting articles if placed in mid-page; it would still need to be fixed, but it wouldn't be a big deal.
 — SMcCandlish ☏ ¢ 😼  00:17, 11 February 2020 (UTC)

Notes and references

There are many different acceptable referencing and citing styles on Wikipedia. We have a thus far clear understanding (consensus or mandate) that we should not change any acceptable style from that of the author without clear reasoning and consensus.

The "Notes and references" subsection gives examples and uses "sections" when multiple partitions are used. When I run across these I have been converting "Reference" related sections to subsections without controversy. We use sections throughout Wikipedia and subsections are generally related to the sections they are under. That is common (the "Notes and references" subsection is a part of and listed under the "Standard appendices and footers" section), so related reference sections should, and largely does, follow suit.

It is just that the "instructions" show that separate "sections" be used. This has nothing to do with any "style", but presentation and consistency, so the word "subsection" should be substituted for "section" that follows the more common use.

• Bibliography: "Bibliography" is discouraged because it is not clear whether it is limited to the works of the subject of the article.. While some articles still use this it seems it is more commonly being replaced with "Works or publications".

I have run across the use of "Bibliography" in the references sectioning (as a section and subsection) and have been replacing it with "References cited" and converting any sections to subsections. This is more related to biographies but for consistency I have also been changing it on non-biographical articles. If we are going to use "Bibliography" at all it should be in a section that is for "Works or publications" to follow MOS:NOTES and better left out of use under references. Otr500 (talk) 10:33, 3 February 2020 (UTC)

Related discussion at #Notes and references alternative titles, I believe. :) --Izno (talk) 14:41, 3 February 2020 (UTC)

Izno responds to your Bibliography concern. With respect to "section" vs. "subsection," I am unclear what you are proposing. Can you give an example of a sentence that would change if we adopted your proposal? Butwhatdoiknow (talk) 16:12, 3 February 2020 (UTC)

This doesn't actually describe the WP:CITEVAR rules. It has nothing to do with "the author" except under a specific circumstance, and even then it doesn't have to do with the author personally or their preferences, only with what was chosen back when. The rule is to not change the citation style at an article that has a consistent citation style (or had one for a long tiem until someone recently messed it up), absent a discussion on the talk page in favor of changing it. If the matter goes to such a discussion and no consensus can be reached in it (e.g. even to prefer what the presently dominant style is), then default to what was chosen for the first non-stub version. It's the same rule and process as MOS:ENGVAR and MOS:DATEVAR. In particular, in no case does the maker of that edit (the one you're calling "the author", as if this were a single-author page) have more "voting rights" now or going forward as to what the cite format should be.

Anyway, I'm also unclear on exactly what you're proposing. I would think that in either one- or two-section referencing, we should just use sections (== level). I've seen a few cases where people do things like ==Citations and references== (or ==Notes and references==), followed by ===Citations=== (or ===Notes===) then ===References=== (yeah, sometimes other exact wording like ===Works cited===, whatever.) This sub-sectioning seems pretty pointless and just makes the ToC longer for no benefit. I don't often see things like just ==Citations== followed by ===References===, and am skeptical that's useful (logically the citations are more a subset than the other way around). Finally, the "Bibliography" related stuff appears to be a duplicate of a thread just a little above this one. Short version: we have other terms to use (e.g. "References" or a two-section "Citations" and "References" pair), so we have no reason to use the ambiguous "Bibliography" (nor "Notes" which is actually often for something else).

I prefer clarity in these section titles, and have been using "Citations" and "General sources" as section/subsection titles, with "Footnotes"/"Explanatory footnotes" and "Works" (subsections "Books", "Films", etc.) above them. —DocWatson42 (talk) 05:09, 17 February 2020 (UTC)

Oh, and I have no preference as to sections versus subsections, though I change "Notes" to something else if the section does not actually include {{Reflist}}, <references />, or something similar. —DocWatson42 (talk) 05:13, 17 February 2020 (UTC)

Notes and references alternative titles

I am concerned that "...although each is questionable in some contexts" implies that the alternative titles are deprecated in some way. "Bibliography", especially, is used in many articles, including quite a few Featured Articles. Even in a biography, it would be quite hard to mistake a list of works by named authors for a list of works by the subject. Most of the other examples are even more far-fetched. The actual contents of the section would immediately show to a reader that it is not what was assumed (and there is precious little evidence that anyone is making these incorrect assumptions). I could just as easily argue that "Notes" or "References" meant something else. References can be references to the subject of the article in other works for instance. I think we should just state that there are some alternative titles and leave it at that. SpinningSpark 10:54, 10 November 2019 (UTC)

Is there some middle ground? I gather from the current text that the alternative,less frequently used titles should be employed with caution. That may not be deprecation, but it's not nothing either. Butwhatdoiknow (talk) 01:08, 11 November 2019 (UTC)

But I don't think they should be used with caution. Describing the use of "Bibliography" as infrequent when about a third or so of FAs use it is just misleading. It is universally used as an appendix title in printed works and its meaning couldn't be more clear and well known. The current wording strikes me as a weasely attempt to discourage certain styles with no real evidence of a problem. SpinningSpark 09:58, 11 November 2019 (UTC)

This material (deprecating some titles) was originally inserted with this edit. The edit summary says "see talk", but the talk page discussion at this date has no discussion of actually deprecating titles or the reasons that might be necessary. The discussion is centred on the statistical proportion of titles used and the order they ought to be in. There is thus no historical consensus for this. SpinningSpark 10:51, 11 November 2019 (UTC)

Challenging a 10-year-old edit over "no consensus" is probably not going to get the page changed. --Izno (talk) 17:52, 11 November 2019 (UTC)

Ok, but what do you think of the substantive issue I raised? I wasn't putting that forward as a reason to change in itself, I was just showing that I'm not going against a long established consensus here. The actual practice of editors, even for our most highly regarded articles, shows that people don't think these titles are problematic. SpinningSpark 19:43, 11 November 2019 (UTC)

@Spinningspark: I've had this on my backlog to look at for some time. What is the origin of your concern? I am wondering if you came from a particular place to discuss the section in question. Having a little more background would be useful. --Izno (talk) 01:27, 6 December 2019 (UTC)

There is no one particular incident that brought me to this, but we frequently get people who try to "standardise" the headings. I'm trying to avoid giving them justification in guidelines for doing that. In most articles nobody cares, but it can be very controversial with some editors, especially when Featured Articles or other high quality articles are involved that a lot of work has been invested in. There is no benefit in causing this kind of conflict over some very spurious supposed drawbacks. SpinningSpark 18:18, 9 December 2019 (UTC)

I've checked a sample of FAs. A significant fraction of them, for instance, use "Bibliography". We definitiely should not be deprecating something that is accepted in our highest quality articles without some evidence that it is problematic. SpinningSpark 18:22, 9 December 2019 (UTC)

Okay, so having looked at the current guidance and the discussion on the the archived talk page, my opinion is that it should remain deprecated entirely, as the guideline currently indicates it is, because of the ambiguity of the word (either meaning list of referenced works in some cases and list of published works in the others [and possibly other meanings]). I might be willing to meet in the middle and say it can be used for one or the other (i.e. at most once per page, and with one standard meaning across all articles), but I do not think I would side with the meaning of list of referenced works, for much the same reason as in the archived discussion. That leaves me thinking that I would oppose a change here. --Izno (talk) 00:21, 10 December 2019 (UTC)

@Isaidnoway: I feel that in most articles the content of the section "Notes and references" is obvious and that subtitles for the lists of explanatory notes, short, and full references should not often be needed. In many articles the automatically created Contents block becomes too long if we do. However, the heading Bibiliography does not seem to cover explanatory notes. I propose the heading "Notes and references" for articles that include explanatory notes. MOS:LAYOUT uses "Notes and references as a heading in its own text but does not explicitly propose it as a heading to be used in articles. I feel it should. Johannes Schade (talk) 12:51, 23 December 2019 (UTC)

I'm finding that I can't agree with the OP on this. We too often have "Bibliography", "Discography", and "Filmography" sections in bios, and not only is it confusing in situ to use "Bibliography" me mean sources in such cases (and may even result in duplicate headings when people aren't paying close attention), it's a pointless cross-article consistency problem that doesn't actually buy us anything. In both single-section and two-section referencing, there are other ways to express what these sections are, and alternatives are actually far more common ("References" in single-section style, and "Citations" followed by "References" in two-section style, i.e. citations to references [reference works], then those references themselves). In two-section style we sometimes have "Notes" instead of "Citations", but thi is also a poor idea, since the same heading is commonly used for non-citation-related notes (e.g. with {{efn}} and {{notelist}}). It's preferable to use "Notes" for that to avoid the perennial and rather stupid argument-to-the-death about whether they are "Foodnotes" or "Endnotes" (it's lame because in a non-paginated publication they are the same thing).  — SMcCandlish ☏ ¢ 😼  04:40, 10 February 2020 (UTC)

I remember the discussions that led to those changes. We were trying not to tell people the One True™ answer, while also encouraging them not to confuse readers needlessly. Thus, ==Bibliography== is fine, but please consider other options in an author's article, and ==Sources== is fine, but please consider something else if the subject is open source software, etc.

As to its use in FAs, I just hit Special:RandomInCategory/Featured articles 10 times, and here's what I found:

1. Science-Fiction Plus: ==References== and ==Sources==. Is someone going to confuse that with "place I can buy this magazine"? Maybe, but they'll figure it out when they get there, and we don't have a perfect set of section headings for this combination of short citations + long citations.
2. Mosaics of Delos: ==Notes== and ==References==. This is the most common set of headings for short citations + long citations.
3. Isle of Skye: ==Notes==, ==Citations==, and ==References==, for explanatory footnotes, short citations, and long citations (in that order).
4. Imleria badia: ==Notes== and ==References==, for one explanatory footnote and then the citations.
5. Fanny Bullock Workman: ==References== with a ===Cited sources=== subsection, for short citations followed by long citations.
6. The Boat Race 2012: ==References== alone.
7. Fir Clump Stone Circle: ==References== with three subsections: ===Notes===, ===Footnotes===, and ===Bibliography===, for explanatory footnotes, short citations, and long citations (in that order).
8. Sonic X: ==Notes== and ==References==, for one explanatory footnote and then the citations.
9. Cosima Wagner: ==Notes and references==
10. Distributed-element filter: ==References== and ==Bibliography==, for short citations + long citations.

The ==Bibliography== section probably does appear more often in Featured Articles, but this is still just a small fraction of FAs. I estimate the overall prevalence at about three percent of all articles, and that includes non-citation-related uses, e.g., in articles about authors such as Barack Obama#Bibliography and C. S. Lewis#Bibliography (but not Lewis Carroll#Bibliography). I notice that in my small sample of FAs, that neither of the ones using a ==Bibliography== section are subjects capable of writing their own works, so the potential for confusion is low. WhatamIdoing (talk) 03:44, 23 February 2020 (UTC)

MOS:SECTIONORDER different for FAs?

Any comments?

Midland Railway War Memorial and "rv, per multiple other FAs and WP:CITEVAR" Andy Dingley (talk) 15:18, 4 March 2020 (UTC)

Help us out here. What is the issue? Butwhatdoiknow (talk) 16:17, 4 March 2020 (UTC)

We have a pretty uncontroversial MOS for section order. The CITEVAR wars are endless and futile, but we rarely argue the broad layout of an article. Except for this one, with an insta-revert against MOS, justified because "that's how FAs do it". I have no idea why FAs would be the ones to ignore this, nor do I see any virtue to going against MOS here. There are many times I'd argue against rigid MOS on small details for particular cases, but never like this. Andy Dingley (talk) 16:29, 4 March 2020 (UTC)

You made two changes there (order of sections + location of commonscat template). Is it only the {{commonscat}} template that you're concerned about? The template's own /doc page says that it belongs "at the top of the last section on the page." WhatamIdoing (talk) 19:49, 4 March 2020 (UTC)

Both. When did we start placing sources above the citations to them? Andy Dingley (talk) 20:20, 4 March 2020 (UTC)

Andy Dingley, you really should have notified HJ Mitchell (talk · contribs) of this discussion. Harry, the placement of full sources above the short citations does seem unusual to me, please give examples of other FAs where this is done. --Redrose64 🌹 (talk) 10:11, 5 March 2020 (UTC)

• I just happen to have noticed this, WT:Manual of Style/Layout/Archive 11#Commons category in see also, by the same editor. Andy Dingley (talk) 16:32, 4 March 2020 (UTC)

Educate me, please.

Two questions: What do we call the informational boxes that appear at the top of a page, for example: {{WPMOS}} and {{Information page}} Thanks. Butwhatdoiknow (talk) 16:19, 12 March 2020 (UTC)

Butwhatdoiknow, these are called message boxes or banners. —⁠andrybak (talk) 16:29, 12 March 2020 (UTC)

Second question: Are message boxes and banners already listed in this sequence?

1. Short description
2. Hatnotes
3. Deletion/Protection tags (CSD, PROD, AFD, PP notices)
4. Maintenance / dispute tags
5. English variety and date style
6. Infoboxes
7. Foreign character warning boxes
8. Images
9. Navigational boxes (header navboxes)

If so, where? If not, where should they go? Thanks. Butwhatdoiknow (talk) 16:55, 12 March 2020 (UTC)

These are mostly created using Module:Message box, which is the same module as underlies #3 and #4. Does that answer your questions? --17:53, 12 March 2020 (UTC)

Thanks. The list above is from wp:Layout#Body_sections. I'm thinking that we should either add "message boxes" and "banners" to a current listing or add a new listing for them. But I don't yet know enough to do that. Butwhatdoiknow (talk) 18:23, 12 March 2020 (UTC)

@Butwhatdoiknow: The list that you gave at 16:55, 12 March 2020 (UTC), being from wp:Layout, is relevant for articles, but neither {{WPMOS}} nor {{Information page}} should ever be used on an article. {{WPMOS}} is for use on talk pages, for which WP:TALKORDER applies; and in that list, this is a WikiProject banner, item 9 in the list. --Redrose64 🌹 (talk) 19:45, 12 March 2020 (UTC)

Well, that explains it. Thanks! Butwhatdoiknow (talk) 16:17, 13 March 2020 (UTC)

Nothing should go between navboxes and authority control

This is very bad advice:

Bottom matter

1. Succession boxes and geography boxes
2. Other navigation templates (footer navboxes)^[…] (navbars above {{Portal bar}})
3. Geographical coordinates (if not in Infobox) or {{coord missing}}
4. Authority control templates (taxonbar above Authority control)
5. […]

Placing anything between #2 and #4 creates an annoying gap because their borders don't collapse together when they are not truly adjacent. Note that template {{coord|…|…|display=title}} automagically floats to the top-right for rendering purposes when entered literally anywhere on the page. But today I learned (from somebody else's edit summary) that "consensus" says to put it in the one place where it causes a problem. Unfortunately I can't say I'm surprised. ―cobaltcigs 21:45, 20 October 2019 (UTC)

True. It goes way back to this edit which relates to Wikipedia talk:Manual of Style/Layout/Archive 9#Authority control, which itself is related to User talk:VIAFbot#Authority control and stub templates and Wikipedia:Authority control#Using the template. --Redrose64 🌹 (talk) 22:31, 20 October 2019 (UTC)

I offer the following suggestions, in exact descending order of expected popularity:

1. {{authority control}} should be regarded as the last member of whatever group of navboxes (or otherwise navbox-shaped things) is present, and positioned accordingly.
2. Coord templates, if they need a designated place, should probably be grouped with the FA/GA icons (and whatever other crap displays at the top regardless of actual position).
3. Succession boxes currently look like ass and should be flattened (made full-width and stripped of <br />s). Better yet would be totally phasing them out in favor of collapsible navboxes which would show the entire succession (or some sub-range thereof if the list is prohibitively huge) and be more practical to maintain than anything allowing freeform input.
4. Portalbar should be deleted immediately, with no proposed replacement.
5. Ideally the "navbox" group (ending with authority control) would be dead last, and CSS would be used to make the lowest navbox border collapse against (share a 1px horizontal line with) the top of <div id="catlinks" […]> in the mw-interface. Yes, I realize the invisible <div class="printfooter"> is right in the way, and would need to be moved lower by some software change.

―cobaltcigs 23:21, 20 October 2019 (UTC)

I seem to concur with cobaltcigs, word-for-word.  — SMcCandlish ☏ ¢ 😼  04:33, 10 February 2020 (UTC)

@SMcCandlish, Redrose64, and SUM1: So while I generally agree with cobaltcigs, I have been wondering why coord/coord missing (I second that these make unsightly gaps when placed before {{authority control}}) and featured article/good article templates are placed at the bottom of articles, instead of where they display. Putting them at the top of articles (unless the coord template is included in an infobox, which I prefer in all cases) would make them much easier to find and edit. As for portals, I favor always placing them in "See also" sections so that they are (again) easy to find (unless they duplicate a portal in an article's infobox). —DocWatson42 (talk) 06:53, 10 February 2020 (UTC)

DocWatson42: "portals, I favor always placing them in 'See also' " – what if there isn't any? cobaltcigs: "Portalbar should be deleted immediately, with no proposed replacement." is a radical departure from current advice here and at {{Portal bar}}, and wide-spread practice. Implementing it without wider input will likely create some adverse reactions. -- Michael Bednarek (talk) 11:12, 17 February 2020 (UTC)

Given how unpopular portals are (relative to the number and prominence of links), I wonder why linking to many portals (via {{portal bar}} or otherwise) would be pointful. WhatamIdoing (talk) 03:04, 23 February 2020 (UTC)

For whatever it's worth, the Puerto Rico project and the Roads project, i.e.Puerto Rico Highway 133 is one that uses portals and portal bars.--The Eloquent Peasant (talk) 13:30, 23 February 2020 (UTC)

For a very clear example, see the article Bill Szymczyk, before and after my edit. It seems some aspect of the {{good article}} indicator/icon's "magical" leap to the top-right corner leaves behind an empty paragraph element <p class="mw-empty-elt"></p>. That class is display: none; by default, which is good, but insufficient. Despite being empty and invisible, this placeholder element still exists, which is enough to prevent two <div>s of class navbox from being recognized as adjacent (by the CSS rule .navbox + .navbox { margin-top: -1px; } in MediaWiki:Common.css). Verily, I can't think of any other scenario in which only moving the GA icon causes a visible change. Hopefully this one doesn't get reverted. ―cobaltcigs 09:32, 19 March 2020 (UTC)

It's not the {{good article}} template per se; boxes with collapsed borders (such as navboxes and authority control) shouldn't have other objects between them. The border-collapse effect only triggers when the two boxes are physically adjacent. --Redrose64 🌹 (talk) 21:18, 20 March 2020 (UTC)

Here's an attempt to generate a diff to the quote above using first suggestions from cobaltcigs's list:

1. Succession boxes and geography boxes
2. Other navigation templates (footer navboxes)^[…] (navbars above {{Portal bar}})
3. Geographical coordinates (if not in Infobox) or {{coord missing}}
4. Authority control templates (taxonbar above Authority control)
5. Geographical coordinates (if not in Infobox) or {{coord missing}}
6. […]

Should an RFC be started? Or should we flesh out the options from cobaltcigs's list first? —⁠andrybak (talk) 14:57, 2 April 2020 (UTC)

I think we have consensus for this. All the best: Rich Farmbrough (the apparently calm and reasonable) 21:06, 7 April 2020 (UTC).

I still favor placing the "Coord"/"Coord missing" templates at the top of articles, where they can be easily found (when there isn't an infobox). —DocWatson42 (talk) 03:50, 8 April 2020 (UTC)

This certainly sounds good if the "display top" is set. But it's a separate question. All the best: Rich Farmbrough (the apparently calm and reasonable) 07:33, 8 April 2020 (UTC).

• I have moved Navboxes and A/C together, per consensus. The following questions still remain:

1. Coords (somewhere) at the top sometimes/always/never?
2. Succession boxes to be made full width (even on every wide screens) ?
3. GA/FA (somewhere) at the top (star shows at top) with page prot templates?

All the best: Rich Farmbrough (the apparently calm and reasonable) 07:54, 8 April 2020 (UTC).

MOS:ORDER in regards to Template:Featured article, Template:Good article, and similar templates

So ... I'm looking at MOS:ORDER's target, and it says nothing about where templates such as {{Featured article}} and {{Good article}} should go. If I had to guess, they would be placed with the "Deletion/Protection tags (CSD, PROD, AFD, PP notices)" section, but that, of course, is just my thought. Either way, this information obviously needs to be added to this page; so ... where should they go? Steel1943 (talk) 19:06, 8 April 2020 (UTC)

Steel1943, please see the sublist under item 4 "End matter": 5. {{Featured list}}, {{Featured article}} and {{Good article}} (where appropriate for article status). Also, there is a related ongoing discussion (albeit it slowed down) at #Nothing should go between navboxes and authority control. —⁠andrybak (talk) 19:45, 8 April 2020 (UTC)

• Yay, I can't see stuff. Disregard my silliness. Steel1943 (talk) 20:58, 8 April 2020 (UTC)